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?

illabout
  • 133
  • 6

1 Answers1

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.

Michael Ströder
  • 974
  • 5
  • 9
  • Like I said in the post, the LDAP server _is_ available, and nscd is not serving directly from its cache. – illabout Mar 04 '21 at 00: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. – Michael Ströder Mar 04 '21 at 02: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 04 '21 at 04: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 04 '21 at 05: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 04 '21 at 05:03
  • First find out which variant of ldap.conf is really used by nss_ldap on your system. Or even better save yourself lots of trouble and use a decent NSS/PAM service like nss-pam-ldapd, sssd or winbindd. There are various reasons why people started developing these solutions to replace PADL's nss_ldap and pam_ldap. – Michael Ströder Mar 04 '21 at 08:39