Solved nss_ldap problem with only few base system commands

patpro

patpro

Hello,

I'm running a bunch of FreeBSD 10.3-RELEASE servers (MX servers, Web servers…). All of them are bound to an LDAP server for user authentication/access.

I can ssh to those server with my LDAP account, I can use id, ldapsearch and so on without any problem. The LDAP server is queried over TLS (ldaps://...).

Today, a user contacted me because he was no longer able to access his crontab:

Code: 
$ crontab -e
(very long wait, then: )
crontab: your UID isn't in the passwd file, bailing out

I've been able to reproduce the problem on every FreeBSD servers. This is not a problem of LDAP server availability: commands like id and ldapsearch are working great.
After digging into the log files, I've found out that those processes/commands have trouble connecting to the LDAP server:

install
crontab
cron

They all fail with this error message:

Code: 
nss_ldap: failed to bind to LDAP server

A ktrace of crontab shows that connection occurs, SSL negotiation starts, then something fails and connection is dropped.
If I change ldap.conf settings to use non-SSL connection crontab works great.

Of course, using ldap:// instead of ldaps:// is not an option in production.

For now I've a workaround: using nscd to cache passwd entries does a great job: as soon as a user entry is cached ( id myuser for example), this user can use the crontab command successfully, but it's not a decent solution.

Any idea?
 
Last edited:
patpro said:
Noboby?
Click to expand...

Please check this post of mine for ssh authentication and authorization with LDAP on FreeBSD (I am guessing that already works for you). You can replace keyword "allow" with "hard" in the configuration files so yes it does use TLS. I am using it with "hard" in production.

https://marc.info/?l=freebsd-questions&m=149830694115893&w=2

It sounds like you have a problem with one of PAM files. I am altering only ssh PAM file for my user case scenario (need only ssh and correct file permission). I have 8 servers in production which works well. Make sure before you configure LDAP that your DNS is properly configured.
There are few people here who know stuff but for large part this forum is more noise than the signal. Unfortunately questions@freebsd is not much better. LDAP documentation in handbook is obsolete. FreeBSD also have now ypladap daemon from OpenBSD which is much simpler but apparently we are not suppose to use it according to mailing lists at least. I see people pushing for sssd Red Hat insanity which is even worse than what I described in my post.
 
Hi Oko, thanks for contributing. Unfortunately my problem is not with PAM. The whole PAM/Authentication layer is working great. Querying LDAP with commands like id or ldapsearch works great too.
I'm not using nslcd (no nss-pam-ldapd), I'm using nss_ldap.

Moving away from nss_ldap in order to use nss-pam-ldapd instead will require comprehensive testing. I've switched from nslcd few years ago because I had problems I could not solve. I would rather find a solution with my current setup (5 servers + about 20 jails, all "production").

Nevertheless, if I found some time to test inside a jail I'll report here.
Thanks
 
In your nss_ldap.conf file, check that your binddn is good - can authenticate, password not expired, etc. Bump up slapd's loglevel to 16640 or so and see what's happening on the ldap server side when users try to authenticate from the client - you should be able to find out there.
 
Hi Datapanic
As far as I can tell everything in the config is OK, because:
- authentication works
- when I issue the command id some-ldap-login I get the correct answer
- crontab -e for an LDAP user used to work, and I've changed nothing apart from applying system updates/upgrades
- if I switch to ldap://my-ldap-server instead of ldaps://my-ldap-server crontab -e no longer fails for ldap users

I can't play with debug on the LDAP server side, it handles auth for 45K users, but the ktrace output of the crontab process clearly show that connection is dropped during or just after SSL negotiation.

So something has changed during an unidentified system/software upgrade that breaks SSL negotiation in some (not all) process that query the LDAP server ( id works, crontab does not).
 
One other thing I though of is perhaps you have some depreciated (SHA1) certs that aren't being accepted anymore by the LDAP server.
 
Client-side (FreeBSD) I don't have any cert, and server-side (LDAP) the certificate is not deprecated and works perfectly with at least 130 Linux servers.
 
Nothing, but I do have a tls_cacert defined pointing to the certificate chain.
I can unset tls_cacert and the result is the same: crontab fails with ldap users.
 
Ok, so problem solved.
Old LDAP server would only do 768 bits DH key, hence I've had to tune the FreeBSD ldap.conf and nss_ldap.conf to use only certain ciphers (AES*). Worked very well for ssh login, for command like ldapsearch, id, and so on, but failed with command like cron, crontab, install…

We've ended up increasing DH key size on the LDAP server to 1024 bits and removed the tls_cipher_suite from config files, and the problem was solved.
 
You must log in or register to reply here.
Back
Top