[SSSD] SSSD - Configuration w/ 2008 R2

Stephen Gallagher sgallagh at redhat.com
Tue May 3 15:48:57 UTC 2011


On Tue, 2011-05-03 at 08:35 -0700, Ben Kevan wrote:
> On Tue, May 3, 2011 at 7:39 AM, Stephen Gallagher
> <sgallagh at 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
>         > <sgallagh at 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 = ldapbinddn at 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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20110503/f2f652a7/attachment.sig>


More information about the sssd-devel mailing list