On Tue, 2011-05-03 at 09:11 -0700, Ben Kevan wrote:
> On Tue, May 3, 2011 at 8:48 AM, Stephen Gallagher
> <sgall...@redhat.com> wrote:
>         
>         On Tue, 2011-05-03 at 08:35 -0700, Ben Kevan wrote:
>         > On Tue, May 3, 2011 at 7:39 AM, Stephen Gallagher
>         > <sgall...@redhat.com> wrote:
>         >         On Tue, 2011-05-03 at 06:51 -0700, Ben Kevan wrote:
>         >         > On Tue, May 3, 2011 at 4:47 AM, Stephen Gallagher
>         >         > <sgall...@redhat.com> wrote:
>         >         >         On Mon, 2011-05-02 at 21:56 -0700, Ben
>         Kevan wrote:
>         >         >         > I'm wondering what the heck I'm doing
>         wrong. I'm
>         >         working on
>         >         >         getting
>         >         >         > SSSD + KRB5 working against 2008 R2 AD.
>         It's
>         >         working fine in
>         >         >         RHEL5 w/
>         >         >         > the standard LDAP.conf configuration.
>         I'm working
>         >         on sssd,
>         >         >         but am not
>         >         >         > getting a binddn connection to AD.
>         Here's my
>         >         config:
>         >         >
>         >         >         ...
>         >         >         > ldap_default_bind_dn =
>         ldapbin...@domain.com
>         >         >
>         >         >
>         >         >         This is not a DN. This is a username. It's
>         not the
>         >         same thing.
>         >         >         You need
>         >         >         to figure out ldapbinddn's full
>         distinguished name
>         >         in LDAP and
>         >         >         use that.
>         >         >
>         >         >
>         >         >
>         >         >
>         >         > This wasn't the issue. You're able to use both the
>         full DN,
>         >         or the
>         >         > shortened target method. It may not be documented,
>         but if
>         >         you're able
>         >         > to traverse AD anonymously, then you'l ll be
>         successful in
>         >         the method
>         >         > above. This is how I configured LDAP.con in RHEL5
>         even
>         >         though it
>         >         > requested the usage of a full DN.
>         >
>         >
>         >         That sounds like a non-standard extension, and I'd
>         really
>         >         advise against
>         >         relying on it. I won't guarantee that we won't parse
>         for a
>         >         valid DN and
>         >         reject it as an option (it may work right now, but I
>         might
>         >         call that a
>         >         bug rather than a feature).
>         >
>         >         >
>         >         >
>         >         >         > wtf am I doing wrong, and is ldap for
>         >         authentication better
>         >         >         then
>         >         >         > krb5? or should I stick with ldap for
>         >         authorization and krb5
>         >         >         for
>         >         >         > authentication?
>         >         >
>         >         >
>         >         >         Using krb5 for authentication allows you
>         to acquire
>         >         a
>         >         >         single-sign-on TGT
>         >         >         for use with other applications, so it's
>         probably
>         >         the
>         >         >         preferred method
>         >         >         in your case.
>         >         >
>         >         >
>         >         > The issue was the ldap_uri, where I had both
>         targets space
>         >         delimited
>         >         > and not comma delimited.
>         >         >
>         >
>         >
>         >         Ah, yes. That's caused problems for people before as
>         well.
>         >
>         >         >
>         >         > However, I'm still having an issue with the
>         results from
>         >         getent passwd
>         >         > <user>. Right now it's pulling / as homeDirectory,
>         where
>         >         homeDirectory
>         >         > should report as /home/<user>. What mapping should
>         this be
>         >         on a 2008
>         >         > R2 domain?
>         >         >
>         >
>         >
>         >         I'm guessing that ActiveDirectory isn't storing the
>         homedir as
>         >         the
>         >         "homeDirectory" attribute by default. You'll have to
>         look up
>         >         what it
>         >         should be in Windows Server 2008 R2, but at least on
>         older
>         >         systems the
>         >         attribute would have been msSFU30HomeDirectory
>         >
>         >         So you'd set
>         >         ldap_user_home_directory = msSFU30HomeDirectory
>         >         in the sssd.conf
>         >
>         >         >
>         >         > Also, pulling a getent group <groupname> I'm not
>         egtting the
>         >         correct
>         >         > list of members as it is in AD (in the pure ad
>         group and not
>         >         in the
>         >         > msSFU30 portion)
>         >
>         >
>         >         You shouldn't be. You should only see the list of
>         >         POSIX-compliant
>         >         members. If the user or group members don't have
>         POSIX
>         >         attributes, we
>         >         ignore them, since they aren't (and cannot be)
>         relevant.
>         >
>         >
>         > Doing an ldap search of a group I get the following for
>         members
>         > (without the antiquated methods of mapping msSFU30*)
>         > member: CN=Unix bpm,OU=Service
>         > Accounts,OU=Users,OU=Corporate,,DC=Domain,DC=com
>         > member: CN=Ben Kevan,OU=Standard
>         > Users,OU=Users,OU=Corporate,,DC=Domain,DC=com
>         > distinguishedName: CN=NorCal Linux
>         Admins,OU=Groups,DC=Domain,DC=com
>         >
>         >
>         > Is there a way I can see what is being linked by default in
>         sssd?
>         > Here's what I had in previous versions of ldap.conf for
>         mapping, maybe
>         > that'll help map what they should be in SSSD easier.
>         >
>         >
>         > nss_map_objectclass     posixAccount       User
>         > nss_map_objectclass     shadowAccount      User
>         > nss_map_objectclass     posixGroup         group
>         >
>         >
>         > nss_map_attribute       uid                sAMAccountName
>         > nss_map_attribute       uidNumber          uidNumber
>         > nss_map_attribute       gidNumber          gidNumber
>         > nss_map_attribute       uniqueMember       member
>         > nss_map_attribute       givenname          givenName
>         > nss_map_attribute       ou                 description
>         > nss_map_attribute       gecos              displayName
>         > nss_map_attribute       homeDirectory      unixHomeDirectory
>         > nss_map_attribute       loginShell         loginShell
>         > nss_map_attribute       shadowLastChange   pwdLastSet
>         >
>         >
>         > nss_base_passwd DC=Domain,DC=com?sub
>         > nss_base_shadow DC=Domain,DC=com?sub
>         > nss_base_group
>         > DC=Domain,DC=com?sub?&(objectCategory=group)(gidNumber=*)
>         
>         
>         
>         The easiest way to see what SSSD is using would be to set
>         debug_level = 6
>         in the [domain/default] section, restart SSSD and then look
>         at /var/log/sssd/sssd_default.log
>         
>         You'll see a number of lines like:
>         
>         (Tue May  3 11:47:08 2011) [sssd[be[default]]]
>         [dp_get_options] (6):
>         Option ldap_search_timeout has value 6
>         
> 
> 
> Perfect, that's exactly what i was looking for. I was previously
> starting sssd w/ -d4, and wasn't getting that. Looks like it's part of
> -d5. 
> 
> 
> Here's the full list for anyone that cares: 
> # grep sdap_get_map /var/log/sssd/sssd_default.log | awk -FOption
> '{ print $2 }'
>  ldap_entry_usn has value (null)
>  ldap_rootdse_last_usn has value (null)
>  ldap_user_object_class has value posixAccount
>  ldap_user_name has value uid
>  ldap_user_pwd has value userPassword
>  ldap_user_uid_number has value uidNumber
>  ldap_user_gid_number has value gidNumber
>  ldap_user_gecos has value gecos
>  ldap_user_home_directory has value homeDirectory
>  ldap_user_shell has value loginShell
>  ldap_user_principal has value krbPrincipalName
>  ldap_user_fullname has value cn
>  ldap_user_member_of has value (null)
>  ldap_user_uuid has value (null)
>  ldap_user_modify_timestamp has value modifyTimestamp
>  ldap_user_shadow_last_change has value shadowLastChange
>  ldap_user_shadow_min has value shadowMin
>  ldap_user_shadow_max has value shadowMax
>  ldap_user_shadow_warning has value shadowWarning
>  ldap_user_shadow_inactive has value shadowInactive
>  ldap_user_shadow_expire has value shadowExpire
>  ldap_user_shadow_flag has value shadowFlag
>  ldap_user_krb_last_pwd_change has value krbLastPwdChange
>  ldap_user_krb_password_expiration has value krbPasswordExpiration
>  ldap_pwd_attribute has value pwdAttribute
>  ldap_group_object_class has value posixGroup
>  ldap_group_name has value cn
>  ldap_group_pwd has value userPassword
>  ldap_group_gid_number has value gidNumber
>  ldap_group_member has value memberuid
>  ldap_group_uuid has value (null)
>  ldap_group_modify_timestamp has value modifyTimestamp
>  ldap_entry_usn has value (null)
>  ldap_rootdse_last_usn has value (null)
>  ldap_user_object_class has value posixAccount
>  ldap_user_name has value uid
>  ldap_user_pwd has value userPassword
>  ldap_user_uid_number has value uidNumber
>  ldap_user_gid_number has value gidNumber
>  ldap_user_gecos has value gecos
>  ldap_user_home_directory has value homeDirectory
>  ldap_user_shell has value loginShell
>  ldap_user_principal has value krbPrincipalName
>  ldap_user_fullname has value cn
>  ldap_user_member_of has value (null)
>  ldap_user_uuid has value (null)
>  ldap_user_modify_timestamp has value modifyTimestamp
>  ldap_user_shadow_last_change has value shadowLastChange
>  ldap_user_shadow_min has value shadowMin
>  ldap_user_shadow_max has value shadowMax
>  ldap_user_shadow_warning has value shadowWarning
>  ldap_user_shadow_inactive has value shadowInactive
>  ldap_user_shadow_expire has value shadowExpire
>  ldap_user_shadow_flag has value shadowFlag
>  ldap_user_krb_last_pwd_change has value krbLastPwdChange
>  ldap_user_krb_password_expiration has value krbPasswordExpiration
>  ldap_pwd_attribute has value pwdAttribute
>  ldap_group_object_class has value posixGroup
>  ldap_group_name has value cn
>  ldap_group_pwd has value userPassword
>  ldap_group_gid_number has value gidNumber
>  ldap_group_member has value memberuid
>  ldap_group_uuid has value (null)
>  ldap_group_modify_timestamp has value modifyTimestamp
>  ldap_entry_usn has value (null)
>  ldap_rootdse_last_usn has value (null)
>  ldap_user_object_class has value posixAccount
>  ldap_user_name has value uid
>  ldap_user_pwd has value userPassword
>  ldap_user_uid_number has value uidNumber
>  ldap_user_gid_number has value gidNumber
>  ldap_user_gecos has value gecos
>  ldap_user_home_directory has value homeDirectory
>  ldap_user_shell has value loginShell
>  ldap_user_principal has value krbPrincipalName
>  ldap_user_fullname has value cn
>  ldap_user_member_of has value (null)
>  ldap_user_uuid has value (null)
>  ldap_user_modify_timestamp has value modifyTimestamp
>  ldap_user_shadow_last_change has value shadowLastChange
>  ldap_user_shadow_min has value shadowMin
>  ldap_user_shadow_max has value shadowMax
>  ldap_user_shadow_warning has value shadowWarning
>  ldap_user_shadow_inactive has value shadowInactive
>  ldap_user_shadow_expire has value shadowExpire
>  ldap_user_shadow_flag has value shadowFlag
>  ldap_user_krb_last_pwd_change has value krbLastPwdChange
>  ldap_user_krb_password_expiration has value krbPasswordExpiration
>  ldap_pwd_attribute has value pwdAttribute
>  ldap_group_object_class has value posixGroup
>  ldap_group_name has value cn
>  ldap_group_pwd has value userPassword
>  ldap_group_gid_number has value gidNumber
>  ldap_group_member has value memberuid
>  ldap_group_uuid has value (null)
>  ldap_group_modify_timestamp has value modifyTimestamp
>  ldap_entry_usn has value (null)
>  ldap_rootdse_last_usn has value (null)
>  ldap_user_object_class has value group
>  ldap_user_name has value uid
>  ldap_user_pwd has value userPassword
>  ldap_user_uid_number has value uidNumber
>  ldap_user_gid_number has value gidNumber
>  ldap_user_gecos has value gecos
>  ldap_user_home_directory has value homeDirectory
>  ldap_user_shell has value loginShell
>  ldap_user_principal has value krbPrincipalName
>  ldap_user_fullname has value cn
>  ldap_user_member_of has value (null)
>  ldap_user_uuid has value (null)
>  ldap_user_modify_timestamp has value modifyTimestamp
>  ldap_user_shadow_last_change has value shadowLastChange
>  ldap_user_shadow_min has value shadowMin
>  ldap_user_shadow_max has value shadowMax
>  ldap_user_shadow_warning has value shadowWarning
>  ldap_user_shadow_inactive has value shadowInactive
>  ldap_user_shadow_expire has value shadowExpire
>  ldap_user_shadow_flag has value shadowFlag
>  ldap_user_krb_last_pwd_change has value krbLastPwdChange
>  ldap_user_krb_password_expiration has value krbPasswordExpiration
>  ldap_pwd_attribute has value pwdAttribute
>  ldap_group_object_class has value group
>  ldap_group_name has value cn
>  ldap_group_pwd has value userPassword
>  ldap_group_gid_number has value gidNumber
>  ldap_group_member has value memberuid
>  ldap_group_uuid has value (null)
>  ldap_group_modify_timestamp has value modifyTimestamp
> 
> 
> Doing an ldapsearch against 2008 R2 user account, i see the following
> for home directory:
> unixHomeDirectory: /home/bkevan
> 
> 
> I've set ldap_user_home_directory to unixHomeDirectory, but am still
> pulling the user with / set as home directory.
> 
> 
> Also, does sssd cache stuff? And maybe I'm pulling old data? I tried
> to getent passwd a different user, and it failed. Hummm. 

Yes, SSSD caches data for 90 minutes by default. You can reduce this for
testing by setting in [domain/default]:

entry_cache_timeout = 30

(where the value is in seconds)

Note, this only works for new cached entries, so you may want to fully
purge your cache by stopping SSSD and doing 'rm
-f /var/lib/sss/db/cache_default.ldb' as root.

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/sssd-devel

Reply via email to