On Mon, Aug 12, 2019 at 07:21:15PM -0000, Jane Eason wrote:
We do not have the uid number in LDAP.
In our LDAP uid is the username, so LDAP has e.g. uid=bob. There is a local Linux user
named "bob" as well (we are not creating accounts on login).
We thought we could get around having to have the uid number in LDAP, using the following
line in sssd.conf:
ldap_user_uid_number = uid
so at least the ldap query would return something.
When "bob" tries to login we do see bob's attributes returned from the sssd
ldap query, but it stops there without any attempt at an LDAP bind from bob.
Here is the result of an ldapsearch with objectclass=inetorgperson uid=\*
dn: uid=bob,ou=people,ou=primary,ou=eid,dc=my,dc=edu
mail: bob(a)my.edu
uid: bob
initials: B
givenName: Bob
sn: Barker
objectClass: inetOrgPerson
objectClass: myPerson
objectClass: eduPerson
objectClass: organizationalPerson
objectClass: Person
objectClass: ndsLoginProperties
objectClass: Top
What is typically meant by UID in the sssd context is not the LDAP uid
attribute, but a numerical identifier (user-ID). It looks like your
entries in LDAP don't have them.
Typically what is done is that the entries also receive the posixAccount
objectclass and then you'd add a uidNumber and a gidNumber.
Without a UID number or a way to map the UID number with some other
means (right know that would be from a Windows SID), SSSD cannot resolve
those users.
(An exception is an application domain where you only use the LDAP users through
the D-Bus API by an app, but I'm guessing that's not what you are after)