[SSSD] Config problem or bug(?) with sssd and Windows AD 2008

Patrick Grieshaber pgr at patrickgrieshaber.net
Mon Jan 31 12:44:58 UTC 2011


Hi,

sorry that it took me so long until reply.

You were right. It is a Windows 2008 AD, but the schema was set up earlier (and was upgraded). This is my config - works:

[domain/example.com]
enumerate = false
id_provider = ldap
chpass_provider = krb5
ldap_uri = ldap://dc.example.com
ldap_search_base = dc=example,dc=com
tls_reqcert = demand
ldap_tls_cacert = /etc/pki/tls/certs/ca-bundle.crt
ldap_tls_cacertdir = /etc/pki/tls/certs
ldap_default_bind_dn = CN=serviceuser,OU=example IT,DC=example,DC=com
ldap_default_authtok_type = password
ldap_default_authtok = secret!
ldap_user_name = sAMAccountName
ldap_search_base = OU=IT Administrators,DC=example,DC=com
ldap_pwd_policy = none
ldap_user_object_class = person
ldap_schema = rfc2307bis
ldap_user_uid_number = uSNCreated
######ldap_user_uid_number = objectSid
ldap_user_gid_number = logonCount
auth_provider = krb5
krb5_kdcip = dc.example.com
krb5_realm = EXAMPLE.COM
krb5_changepw_principle = kadmin/changepw
krb5_ccachedir = /tmp
krb5_ccname_template = FILE:%d/krb5cc_%U_XXXXXX
krb5_auth_timeout = 15

So far I have one important problem left. It is regarding the ldap_user_uid_number and ldap_user_uid_number. 

For auditing reasons, the uid/gid must be easy to recognize. So for the uid mapping I chose extensionAttributeX 
to read a value (number) that refers to a user.

Now for the gid mapping I'd like to use the same attribute again. But sssd does not allow me
to set uid/gid by the same attribute :(.

The second option I'd like to chose is using the objectSid for example. Because
this is the only attribute that persists as long as an object is 
available in AD. Regardless of any schema upgrade or whatever. This attribute 
cannot be used since it contains "-" and a "S"-character.

So how do you solve that problem? Can sssd "cast" an attribute or so..?

Thank you,
pat 


----- Original Message -----
From: "Simo Sorce" <ssorce at redhat.com>
To: sssd-devel at lists.fedorahosted.org
Sent: Tuesday, October 12, 2010 4:44:35 PM
Subject: Re: [SSSD] Config problem or bug(?) with sssd and Windows AD 2008

On Mon, 11 Oct 2010 09:34:05 -0400
Stephen Gallagher <sgallagh at redhat.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 10/11/2010 09:31 AM, Simo Sorce wrote:
> > On Mon, 11 Oct 2010 08:42:58 -0400
> > Stephen Gallagher <sgallagh at redhat.com> wrote:
> > 
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> On 10/11/2010 08:35 AM, Patrick Grieshaber wrote:
> >>>> Thank you very much for the SUA hint. The auth works now :-).
> >>>
> >>>> But still ldap_schema = rfc2307bis was not enough information.
> >>>> I had to adjust:
> >>>> - ldap_user_name = sAMAccountName
> >>>> - ldap_user_object_class = person
> >>>> - ldap_user_uid_number = uSNCreated
> >>>> - ldap_user_gid_number = logonCount
> >>>
> >>>> I want a unique uid (by default it takes the value of the
> >>>> attribute userAccountControll - not unique!). uSNCreated is a
> >>>> unique attribute value in AD. Unforunately sssd auth does not
> >>>> work if ldap_user_gid_number has the same attribute as value as
> >>>> ldap_user_uid_number.. I am still looking for a sensual
> >>>> attribute.
> >>
> >>
> >> try:
> >> ldap_user_uid_number = msSFU30UidNumber
> >> ldap_user_gid_number = msSFU30GidNumber
> >>
> >> Also, you probably want:
> >> ldap_user_name = msSFU30Name
> >>
> >>
> >> I'm guessing you're using an older ActiveDirectory, so chances are
> >> this is the more-or-less complete set of attributes you want:
> >>
> >>
> >> ldap_schema = rfc2307bis
> >> ldap_user_object_class = person
> >> ldap_user_name = msSFU30Name
> >> ldap_user_uid_number = msSFU30UidNumber
> >> ldap_user_gid_number = msSFU30GidNumber
> >> ldap_user_home_directory = msSFU30HomeDirectory
> >> ldap_user_shell = msSFU30LoginShell
> >> ldap_user_principal = userPrincipalName
> >> ldap_group_object_class = group
> >> ldap_group_name = msSFU30Name
> >> ldap_group_gid_number = msSFU30GidNumber
> >> ldap_force_upper_case_realm = True
> > 
> > Just an FYI, newer AD servers use the standard rfc2307 attribute
> > names, so if Services For Unix (or whatever new name they have for
> > it) is installed all you need to map is ldap_user_name to
> > samAccoutnName and probably set the ldap_force_upper_case_realm.
> > 
> > You also most probably want to use "ldap_user_object_class = user",
> > person would match stuff you do not want to match.
> > 
> > Simo.
> > 
> 
> My assumption is that Patrick is using AD 2003 here, since he
> previously stated that SUA alone was not enough.

Ok, but those attributes need to be explicitly set on users in AD in
any case. Their absence on a user is no indication of what schema is in
use really.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York
_______________________________________________
sssd-devel mailing list
sssd-devel at lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/sssd-devel



More information about the sssd-devel mailing list