Every guide to using SSSD for LDAP authentication I've found thus far shows you how to do more than just authenticate a user, such as provide their shell, groups, etc. I don't know how to remove those features without things breaking because there are several moving parts like SSSD, PAM, and NSS.

Due to limitations on what information is provided via LDAP (it's not AD), only authentication of users can be done. There isn't even a uid available because the only id provided via LDAP are consistently formatted alpha-numeric strings (won't work on linux). Basically, how can SSSD be configured on Ubuntu to treat ldap as the "shadow" database, but get the uid, groups, and shell from your local system databases (passwd, group).

This is currently done with libpam-ldap, but my understanding is there are better alternatives like libpam-ldapd and sssd, the latter of which RHEL has moved to. If I had to guess, it can be done similarly to how we currently do it, which is nss will check local databases first, and if the user doesn't have a shadow file entry, check ldap.

As a summary, if I can use SSSD or, as a backup, libpam-ldapd, to authenticate the following way:
uid -> /etc/passwd
authenticate -> ldap
shell -> /etc/passwd
groups -> /etc/group

Even better if it's possible to stop users from creating passwords locally that would end up in /etc/shadow thus causing it to check ldap at all in future login attempts. Also, all local and service accounts shouldn't be impacted, and ldap authenticated users can be determined with simple regex. I'll be very grateful for any good suggestions on how to handle this. Thanks!

2 Answers 2


The approach of using id_provider=proxy and auth_provider=ldap is absolutely correct. You're hitting bug https://fedorahosted.org/sssd/ticket/2620 that we only fixed in the 1.13 release. It was a really simple fix, ask Ubuntu to cherry-pick it from upstream.

  • That's the problem I was indeed running into with the version on 14.04. I had given up on using the repo one because it's not until the next LTS that looks like it will have the version with the fix. But if I can ask them to bring that patch in, what's the appropriate place to put in the request? Nov 22, 2015 at 19:38
  • Just add the link to this discussion and the upstream bug to the bug report. The Ubuntu maintainer (Timo) knows me.
    – jhrozek
    Nov 23, 2015 at 12:35
  • btw Timo also has a PPA with more recent versions, maybe it would help? launchpad.net/~sssd/+archive/ubuntu/updates
    – jhrozek
    Nov 23, 2015 at 12:35

The file which controls which datasource contact for each search is nsswitch.conf. You need something as:

passwd:         compat
group:          compat
shadow:         compat sss

passwd means users lookup, group means groups lookup, shadow means auth informations.

Just setup sssd normally, but for users lookup it won't be used.

Order of authentication sources is in pam files (next one is common-auth):

auth    [success=2 default=ignore]  pam_unix.so nullok_secure
auth    [success=1 default=ignore]  pam_sss.so use_first_pass
# here's the fallback if no module succeeds
auth    requisite           pam_deny.so

so it is up to you to ensure the local /etc/shadow file does not contain valid passwords for users meant to be authenticated on LDAP.

  • I tried this and seemed to make progress, but now I'm getting an error in SSSD. After some stumbling I configured SSSD to use a proxy as the id_provider, and the proxy is files. I have debug logs enabled and now it queries ldap with ldap_search_ext, which generates an error saying "Ldap connection is not connected!". I know for a fact it could connect with currents settings before I told it to proxy to local files, just didn't return entries it was expecting. Nov 18, 2015 at 22:29
  • 1
    no: your sssd should contact ldap, not a proxy. If you instructed nsswicth to use sss for auth, auth has to be performed on ldap. You are not using sssd altoghether for users enumeration, if you write 'compat' in nsswitch it uses what sssd calls 'proxy'.
    – 473183469
    Nov 19, 2015 at 7:27

You must log in to answer this question.

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