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

[Patrick Grieshaber]

Hello folks,

first let me say that the sssd project is great and I am lucky that this
project is available for CentOS/Redhat through the EPEL repo :-).

I've installed version sssd-1.2.1-27.el5.x86_64 and I want to be able to
fetch user infos plus enable login through AD 2008 - but I fail..

sssd.conf:
[domain/example.com]
enumerate = false
id_provider = ldap
chpass_provider = krb5
ldap_uri = ldap://dc1.example.com, ldap://dc2.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,DC=example,DC=com
ldap_default_authtok_type = password
ldap_default_authtok = serviceuserpassword
ldap_user_name = sAMAccountName
ldap_search_base = OU=IT,DC=example,DC=com
ldap_pwd_policy = none
ldap_user_object_class = person
ldap_schema = rfc2307bis
ldap_user_principal = userPrincipalName
ldap_user_uid_number = sAMAccountName
ldap_user_gid_number = sAMAccountName
ldap_user_uuid = sAMAccountName
ldap_user_fullname = displayName
# kerberos config
auth_provider = krb5
krb5_kdcip = dc1.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

For debugging reasons I run: sssd -d9

Here the output if I attempt: su - [e-mail]

...snip...
(Tue Oct  5 09:16:45 2010) [sssd[be[example.com]]] [sdap_get_generic_send]
(6): calling ldap_search_ext with
[(&(sAMAccountName=myuser)(objectclass=person))][OU=IT,DC=example,DC=com].
...snip...
(Tue Oct  5 09:16:45 2010) [sssd[be[example.com]]] [sdap_process_result]
(8): Trace: sh[0x8f876c0], connected[1], ops[0x8f87500], ldap[0x8f876f0]
(Tue Oct  5 09:16:45 2010) [sssd[be[example.com]]] [sdap_process_result]
(8): Trace: ldap_result found nothing!
(Tue Oct  5 09:16:45 2010) [sssd[be[example.com]]] [sdap_process_result]
(8): Trace: sh[0x8f876c0], connected[1], ops[0x8f87500], ldap[0x8f876f0]
(Tue Oct  5 09:16:45 2010) [sssd[be[example.com]]] [sdap_parse_entry] (9):
OriginalDN: [CN=my,OU=IT,DC=example,DC=com].
(Tue Oct  5 09:16:45 2010) [sssd[be[example.com]]] [sdap_process_result]
(8): Trace: sh[0x8f876c0], connected[1], ops[0x8f87500], ldap[0x8f876f0]
(Tue Oct  5 09:16:45 2010) [sssd[be[example.com]]] [sdap_get_generic_done]
(6): Search result: Success(0),
(Tue Oct  5 09:16:45 2010) [sssd[be[example.com]]] [sdap_get_users_process]
(6): Search for users, returned 1 results.
(Tue Oct  5 09:16:45 2010) [sssd[be[example.com]]] [sdap_process_result]
(8): Trace: sh[0x8f876c0], connected[1], ops[(nil)], ldap[0x8f876f0]
(Tue Oct  5 09:16:45 2010) [sssd[be[example.com]]] [sdap_process_result]
(8): Trace: ldap_result found nothing!
(Tue Oct  5 09:16:45 2010) [sssd[be[example.com]]] [ldb] (9): start ldb
transaction (nesting: 0)
(Tue Oct  5 09:16:45 2010) [sssd[be[example.com]]] [sdap_save_user_send]
(9): Save user
(Tue Oct  5 09:16:45 2010) [sssd[be[example.com]]] [sdap_save_user_send]
(1): no uid provided for [myuser] in domain [example.com].
(Tue Oct  5 09:16:45 2010) [sssd[be[example.com]]] [sdap_save_users_process]
(2): Failed to store user 0. Ignoring.
(Tue Oct  5 09:16:45 2010) [sssd[be[example.com]]] [ldb] (9): commit ldb
transaction (nesting: 0)
(Tue Oct  5 09:16:45 2010) [sssd[be[example.com]]] [sdap_get_users_done]
(9): Saving 1 Users - Done
(Tue Oct  5 09:16:45 2010) [sssd[be[example.com]]] [acctinfo_callback] (4):
Request processed. Returned 0,0,Success

And su outputs: su: user [e-mail] does not exist

What is wrong? I do the mapping of a uid/gid... any help is appreciated!

Thank you,
pat

[Jakub Hrozek]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/05/2010 09:37 AM, Patrick Grieshaber wrote:
> ldap_user_uid_number = sAMAccountName
> ldap_user_gid_number = sAMAccountName
> ldap_user_uuid = sAMAccountName

Looking at the debug log, the user object could not be saved due to
missing UID number. Using sAMAccountName does not sound like the best
attribute to me, though..I think that with 2008, there was no need to
fine-tune the UID/GID attributes and just go with the defaults.

Jakub
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkyq9AkACgkQHsardTLnvCVzpACfRA8756IkIehPD4nRmYtpv7w7
> TkcAn3qHO3fp9cEOZyKm6VkkLjeqKXvJ
> =vm3r
> -----END PGP SIGNATURE-----

[Patrick Grieshaber]

On Tue, Oct 5, 2010 at 11:47 AM, Jakub Hrozek  wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 10/05/2010 09:37 AM, Patrick Grieshaber wrote:
> > ldap_user_uid_number = sAMAccountName
> > ldap_user_gid_number = sAMAccountName
> > ldap_user_uuid = sAMAccountName
>
> Looking at the debug log, the user object could not be saved due to
> missing UID number. Using sAMAccountName does not sound like the best
> attribute to me, though..I think that with 2008, there was no need to
> fine-tune the UID/GID attributes and just go with the defaults.

I totally agree.. but with the config above plus this mods:
#ldap_user_principal = userPrincipalName
#ldap_user_uid_number = sAMAccountName
#ldap_user_gid_number = sAMAccountName
#ldap_user_uuid = sAMAccountName
#ldap_user_fullname = displayName

... i receive the exact same debug output (--> no uid found). The reason why
i've set sAMAccountName as uid is because the value of this field is always
a unique employee _number_ in our active directory. It is strange that the
ldap entry about myuser is found, but the uid mapping is such a problem...
any other suggestion? Tried this for a couple of hours...
>    Jakub
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkyq9AkACgkQHsardTLnvCVzpACfRA8756IkIehPD4nRmYtpv7w7
> TkcAn3qHO3fp9cEOZyKm6VkkLjeqKXvJ
> =vm3r
> -----END PGP SIGNATURE-----
> _______________________________________________
> sssd-devel mailing list
> [e-mail]
> https://fedorahosted.org/mailman/listinfo/sssd-devel

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/05/2010 06:09 AM, Patrick Grieshaber wrote:
> On Tue, Oct 5, 2010 at 11:47 AM, Jakub Hrozek <[e-mail]
> > wrote:
>
> On 10/05/2010 09:37 AM, Patrick Grieshaber wrote:
> > ldap_user_uid_number = sAMAccountName
> > ldap_user_gid_number = sAMAccountName
> > ldap_user_uuid = sAMAccountName
>
> Looking at the debug log, the user object could not be saved due to
> missing UID number. Using sAMAccountName does not sound like the best
> attribute to me, though..I think that with 2008, there was no need to
> fine-tune the UID/GID attributes and just go with the defaults.
> > I totally agree.. but with the config above plus this mods:
> > #ldap_user_principal = userPrincipalName
> > #ldap_user_uid_number = sAMAccountName
> > #ldap_user_gid_number = sAMAccountName
> > #ldap_user_uuid = sAMAccountName
> > #ldap_user_fullname = displayName
> > ... i receive the exact same debug output (--> no uid found). The reason
> > why i've set sAMAccountName as uid is because the value of this field is
> > always a unique employee _number_ in our active directory. It is strange
> > that the ldap entry about myuser is found, but the uid mapping is such a
> > problem... any other suggestion? Tried this for a couple of hours...
>    Jakub

Please make sure that your Active Directory server has Subsystem for
UNIX-based Applications (SUA) installed on it. This is necessary for
support of POSIX clients like SSSD.

On Active Directory 2008 with SUA installed, you should not need to set
any of the ldap_user_* options in sssd.conf, as Active Directory's POSIX
compatibility layer should be providing the standard values.

If possible, could you also send the complete LDIF (sanitized as needed)
for one example entry in your Active Directory server, so we can see
what attributes it DOES have, and try to work from there?

The ldapsearch command line tool can be used for this.

- -- 
Stephen Gallagher
RHCE 804006346421761

Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkyq/iUACgkQeiVVYja6o6PWFQCghXkRJyKX2nny+Z+Lk5pvs2F4
> PmQAnihOoiO2ttnUaZSeb30mKA/bvnWe
> =DZ63
> -----END PGP SIGNATURE-----

[Patrick Grieshaber]

On Tue, Oct 5, 2010 at 12:29 PM, Stephen Gallagher wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 10/05/2010 06:09 AM, Patrick Grieshaber wrote:
> > On Tue, Oct 5, 2010 at 11:47 AM, Jakub Hrozek <[e-mail]
> > > wrote:
> >
> > On 10/05/2010 09:37 AM, Patrick Grieshaber wrote:
> > > ldap_user_uid_number = sAMAccountName
> > > ldap_user_gid_number = sAMAccountName
> > > ldap_user_uuid = sAMAccountName
> >
> > Looking at the debug log, the user object could not be saved due to
> > missing UID number. Using sAMAccountName does not sound like the best
> > attribute to me, though..I think that with 2008, there was no need to
> > fine-tune the UID/GID attributes and just go with the defaults.
> > > I totally agree.. but with the config above plus this mods:
> > > #ldap_user_principal = userPrincipalName
> > > #ldap_user_uid_number = sAMAccountName
> > > #ldap_user_gid_number = sAMAccountName
> > > #ldap_user_uuid = sAMAccountName
> > > #ldap_user_fullname = displayName
> > > ... i receive the exact same debug output (--> no uid found). The reason
> > > why i've set sAMAccountName as uid is because the value of this field is
> > > always a unique employee _number_ in our active directory. It is strange
> > > that the ldap entry about myuser is found, but the uid mapping is such a
> > > problem... any other suggestion? Tried this for a couple of hours...
> >    Jakub
>
> Please make sure that your Active Directory server has Subsystem for
> UNIX-based Applications (SUA) installed on it. This is necessary for
> support of POSIX clients like SSSD.
>
> On Active Directory 2008 with SUA installed, you should not need to set
> any of the ldap_user_* options in sssd.conf, as Active Directory's POSIX
> compatibility layer should be providing the standard values.
>
> If possible, could you also send the complete LDIF (sanitized as needed)
> for one example entry in your Active Directory server, so we can see
> what attributes it DOES have, and try to work from there?
>
> The ldapsearch command line tool can be used for this.

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.
> Stephen Gallagher
> RHCE 804006346421761
>
> Delivering value year after year.
> Red Hat ranks #1 in value among software vendors.
> http://www.redhat.com/promo/vendor/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkyq/iUACgkQeiVVYja6o6PWFQCghXkRJyKX2nny+Z+Lk5pvs2F4
> PmQAnihOoiO2ttnUaZSeb30mKA/bvnWe
> =DZ63
> -----END PGP SIGNATURE-----
> _______________________________________________
> sssd-devel mailing list
> [e-mail]
> https://fedorahosted.org/mailman/listinfo/sssd-devel

[Stephen Gallagher]

-----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

- -- 
Stephen Gallagher
RHCE 804006346421761

Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkyzBlIACgkQeiVVYja6o6OHsQCcCrZlbq74ii5mRan049WDa7Wc
> V5MAoJ11GJATjq6RaX7jIeArHIk9DKzH
> =/mlZ
> -----END PGP SIGNATURE-----

[Simo Sorce]

On Mon, 11 Oct 2010 08:42:58 -0400
Stephen Gallagher  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.

[Stephen Gallagher]

-----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  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.

- -- 
Stephen Gallagher
RHCE 804006346421761

Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkyzEk0ACgkQeiVVYja6o6PNdQCfdJnLePcbBLZFm0KAjoRv+r2L
> V6UAmwTATUtWnyXt+TxE2unwI7GbbGhV
> =8oCN
> -----END PGP SIGNATURE-----

[Simo Sorce]

On Mon, 11 Oct 2010 09:34:05 -0400
Stephen Gallagher  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  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.

[Patrick Grieshaber]

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" 
To: [e-mail]
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  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  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]

On Mon, 31 Jan 2011 13:44:58 +0100 (CET)
Patrick Grieshaber  wrote:
> 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.

Why don't you simply update your directory to support the posix schema
(it is a Microsoft schema extension fully supported by MS) and just set
the uidnumber and gidnumber attributes ?

That is the correct way to handle posix attributes after all and will
give you also access to loginshell and homedirectory attributes if you
want to use them.

Simo.

[Patrick Grieshaber]

Simo,
you are right. I had the known problem that the nisprop.dll was missing - so the unix attributes didn't work, even if SUA was installed. Now it works :).
Thx,
pat

----- Original Message -----
From: "Simo Sorce" 
To: [e-mail]
Sent: Monday, January 31, 2011 7:42:28 PM
Subject: Re: [SSSD] Config problem or bug(?) with sssd and Windows AD 2008

On Mon, 31 Jan 2011 13:44:58 +0100 (CET)
Patrick Grieshaber  wrote:
> 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.

Why don't you simply update your directory to support the posix schema
(it is a Microsoft schema extension fully supported by MS) and just set
the uidnumber and gidnumber attributes ?

That is the correct way to handle posix attributes after all and will
give you also access to loginshell and homedirectory attributes if you
want to use them.

Simo.