Is Nscd required on the client for accessing an LDAP server without anonymous access?
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?
Solution 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.