My (soon to be) admin account is in two groups:

#  ldapsearch \
> -v \
> -H ldaps://localhost:636 \
> -D "${l_dirmgr}" \
> -w $(cat ${f_dirmgr_passphrase}) \
> -b "ou=groups,${l_basedn}" \
> "member=cn=testuser" \
> dn gidNumber member

dn: cn=wheel,ou=groups,dc=localdomain
gidNumber: 10
member: cn=testuser,ou=users,dc=localdomain

dn: cn=users,ou=groups,dc=localdomain
gidNumber: 100
member: cn=testuser,ou=users,dc=localdomain

However, id only sees the GID associated in my user's record:

# id testuser
uid=20001(testuser) gid=100(users) groups=100(users)

How do I dig into authconfig/sssd/ldap to see what it's actually looking for and pulling out? The 389DS access log doesn't show me anything, probably because authconfig/sssd/whatever isn't updating its cache. I haven't managed to catch an actual lookup in the log.

(I do see in the log that authconfig/sssd/something is still trying to make anonymous binds, despite my putting a ldap_default_bind_dn and ldap_default_authtok in sssd.conf.)

1 Answer 1


Never mind... ldap_default_authtok had an old password in it...

(And, that bruise you see in the middle of my forehead is from me pounding my head on my desk...)

Okay, now with more detail. I created my LDAP instance consistent with my notes on the subject. That included this bit of LDIF:

dn: cn=config
changetype: modify
replace: nsslapd-allow-anonymous-access
nsslapd-allow-anonymous-access: off
replace: nsslapd-require-secure-binds
nsslapd-require-secure-binds: on

Since I wasn't allowing anonymous access, I created a service account for PAM to use to connect, along with a service account container:

dn: ou=serviceAccounts,${l_basedn}
changetype: add
objectClass: organizationalUnit
objectClass: top
ou: serviceAccounts
description: Container for service accounts. Some will have shell access 
 (objectClass: posixUser), most won't.

dn: cn=svcAuthenticator,ou=serviceAccounts,${l_basedn}
changetype: add
objectClass: top
objectClass: person
cn: svcAuthenticator
sn: svcAuthenticator
userPassword: $(cat ${f_svcAuthenticator_passphrase})
description: Service account to allow PAM/SSS to search the LDAP database.

(I need objectClass: person to give the account a password. However, sn is required attribute of objectClass: person. So, I faked it.)

Then, I'd put that passphrase in /etc/pam_ldap.conf and /etc/sssd/sssd.conf:

sed --in-place=.$(date +%Y%m%d) "/#binddn.*/ a\
binddn cn=svcAuthenticator,ou=serviceAccounts,${l_basedn}" /etc/pam_ldap.conf

sed --in-place "/#bindpw.*/ a\
bindpw $(cat ${f_svcAuthenticator_passphrase})" /etc/pam_ldap.conf

sed --in-place=.$(date +%Y%m%d) "/^ldap_uri.*/ a\
ldap_default_bind_dn = cn=svcAuthenticator,ou=serviceAccounts,${l_basedn}" /etc/sssd/sssd.conf

sed --in-place "/^ldap_default_bind_dn.*/ a\
ldap_default_authtok = $(cat ${f_svcAuthenticator_passphrase})" /etc/sssd/sssd.conf

That was all well and good, until I changed the contents of ${f_svcAuthenticator_passphrase} while trying to solve other LDAP issues, and never passed the new value to pam_ldap.conf or sssd.conf.

Once I remembered to do that, I got good values back out of the id command, including full group lists. I also get SUDO privilege lists using cn=svcSUDO,ou=serviceAccounts,${l_basedn} and $(cat ${f_svcSUDO_passphrase}).

  • Please ahev a moer detailed answer to your question. Folk may stumble upon in futur and be happy for a precise answer.
    – Archemar
    Commented Nov 9, 2014 at 9:48

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .