0

I have an Ubuntu-18.04 machine that I need to setup to access an LDAP server that does not support anonymous lookups.

I'm wondering if Nscd is required to be running on this Ubuntu client?

Most of the guides I've found have suggested that everything should be working without Nscd running, but this doesn't seem to be the case for me.

In order to set this up, I've installed the following packages: libnss-ldap, libpam-ldap, ldap-auth-config, and nscd.

My /etc/ldap.conf looks like the following:

base dc=mycompany,dc=com
uri ldap://192.168.3.123
ldap_version 3
rootbinddn cn=admin,dc=mycompany,dc=com
pam_password md5

My /etc/ldap.secret contains the correct root bind DN credentials.

My /etc/nsswitch.conf looks like the following:

passwd:         compat systemd ldap
group:         compat systemd ldap
shadow:         compat
gshadow:        files
...

The files /etc/etc/pam.d/common-password, /pam.d/common-auth, and /etc/pam.d/common-account contain the following lines:

auth     [success=1 default=ignore]      pam_ldap.so use_first_pass
account       [success=1 default=ignore]      pam_ldap.so 
password     [success=1 user_unknown=ignore default=die]     pam_ldap.so try_first_pass

I'm able to explicitly query the LDAP server using the following command and authenticating as the admin user (using the password from the /etc/ldap.secret file):

$ ldapsearch -L -H ldap://192.168.3.123 -D 'cn=admin,dc=mycompany,dc=com' -W -b 'dc=mycompany,dc=com' uid=myuser

I'm also able to explicitly query the LDAP server using the following command and authenticating as myself (using my own LDAP password):

$ ldapsearch -L -H ldap://192.168.3.123 -D 'uid=myuser,ou=people,dc=mycompany,dc=com' -W -b 'dc=mycompany,dc=com' uid=myuser

With nscd running, I'm able to run the following getent command to query information about my own user. I'm able to run this command both as my own user and as root:

$ getent passwd myuser
myuser:x:1000062:1000000:My User:/home/myuser:/bin/bash
$ sudo getent passwd myuser
myuser:x:1000062:1000000:My User:/home/myuser:/bin/bash

However, if I stop nscd, then I can no longer run the getent command as my normal user. It still works when run as root:

$ sudo systemctl stop nscd
$ getent passwd myuser
$ sudo getent passwd myuser
myuser:x:1000062:1000000:My User:/home/myuser:/bin/bash

When running getent as my normal user with nscd not running, I get the following messages in the systemd journal:

getent[11347]: nss_ldap: failed to bind to LDAP server ldap://192.168.3.123: Inappropriate authentication
getent[11347]: nss_ldap: reconnecting to LDAP server...
getent[11347]: nss_ldap: could not search LDAP server - Server is unavailable

My guess as to why this is happening is because when nscd is running, it acts as a middleman and successfully connects to my LDAP server, authenticating as the admin user. When running getent as my normal user with nscd running, this all happens transparently.

However, with nscd not running, then getent doesn't know to either ask me for the LDAP password of my user, or somehow just use the LDAP password for my user when querying the LDAP server.

When running getent as root, getent just knows to read /etc/ldap.secret and use it to authenticate with the LDAP server.


Is there a way to setup the system so that commands like getent work for normal users without relying on nscd running? Is anonymous access to LDAP required for cases like this?

1

Is there a way to setup the system so that commands like getent work for normal users without relying on nscd running?

Simply yes.

nscd is just a caching demon for all NSS maps. In fact it does not know anything about LDAP or any other protocol used to retrieve map data from remote servers.

getent[11347]: nss_ldap: failed to bind to LDAP server

If you're LDAP server is currently not available you cannot retrieve any map data from there.

Probably you still have cached entries in nscd's database (see /var/lib/nscd or similar directory). If nscd is not running it cannot serve its cache data. If it's running it will serve its cached data until cache TTL is reached (see /etc/nscd.conf).

It's simple like that.

Don't follow outdated how-tos using PADL's nss_ldap and pam_ldap. Rather look at running sssd or nss-pam-ldapd.

The reason is that nss_ldap and pam_ldap are directly linked into each process, e.g. getent. Thus if stricter file permissions are used for file ldap.conf this won't work for every process accessing the NSS maps. Furthermore LDAP connections are not cached giving you really bad performance.

In case you accessed a NSS map as user root before and the result got cached it would also work for other users accessing a cache map entry. But not without nscd running and with rather unreliable cached results.

6
  • Like I said in the post, the LDAP server is available, and nscd is not serving directly from its cache.
    – illabout
    Mar 4 at 0:14
  • Your LDAP server is not reachable for the normal user according to the error message you gave in your question. I've added more info to the answer. Mar 4 at 2:07
  • The LDAP server is reachable for the normal users when directly using ldapsearch. getent passwd myuser also works for normal users as long as nscd is running (even immediately after cleaning nscd's passwd cache). getent paswd myuser does not work for normal users if nscd is not running.
    – illabout
    Mar 4 at 4:57
  • I think my question is how to get commands like getent passwd myuser (which internally uses libnss_ldap?) to work without nscd running. You suggest sssd in your answer. Is it related to this problem with libnss_ldap and nscd?
    – illabout
    Mar 4 at 5:01
  • In your answer, you hint that the permissions on /etc/ldap.conf may be messing up the nss_ldap, but the permissions on my /etc/ldap.conf file are 644, so this shouldn't be an issue.
    – illabout
    Mar 4 at 5:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.