PAM_LDAP Authentication failure with correct credentials on freebsd

Question

I need to get our freebsd servers to auth via AD, but it is giving me problems.

Environment: AD backend (Win 2k8r2). This works with other linux hosts which auth via SSSD
FreeBSD 9.1 for client servers

I have configured everything I can think of, and i think it is correct, but when I try to log in with an AD account, it fails with:

pam_ldap: error trying to bind as user "CN=testuser,CN=Users,DC=example,DC=com" (Invalid credentials)

So I know it is getting past the initial bind, as the DN it is bringing back is correct and has come from the AD server. When it then tries to bind with that DN it can't, which causes the auth to fail. I have tested the test user's creds on the AD server, using ldapsearch and even set it as the default bind DN in ldap.conf and it works for all tests.

I cannot for the life of me figure out why the initial bind works, but then the user's bind fails.

For reference, here are my config files:

/usr/local/etc/ldap.conf

pam_login_attribute uid
base dc=example,dc=com
uri ldap://xxx.xxx.xxx.xxx/
ssl no
binddn CN=ro_user,CN=Users,DC=example,DC=com
bindpw somerandompw

/usr/local/etc/openldap/ldap.conf

pam_login_attribute uid
base dc=example,dc=com
uri ldap://xxx.xxx.xxx.xxx/
ssl no

/etc/pam.d/sshd

auth        sufficient  pam_opie.so     no_warn no_fake_prompts
auth        requisite   pam_opieaccess.so   no_warn allow_local
auth        sufficient  /usr/local/lib/pam_ldap.so  no_warn debug
auth        required    pam_unix.so     no_warn try_first_pass

account     required    pam_nologin.so
account     required    pam_login_access.so
account     required    pam_unix.so
account         required        /usr/local/lib/pam_ldap.so      no_warn ignore_authinfo_unavail ignore_unknown_user

session     required    pam_permit.so

password    required    pam_unix.so     no_warn try_first_pass

EDIT: I had a thought - does anyone know if pam_ldap definitely uses the same bind / authentication process for the initial bind and the authentication bind? I am struggling to grasp how the bind can succeed when it is the initial bind, but fail when it's a bind for authentication.

Answer 1

I've been struggling all day with a very similar error to the above. In my case, I was seeing messages like this:

Nov 26 15:19:25 digitalocean sshd[2373]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=60.196-30-62.static.virginmediabusiness.co.uk
Nov 26 15:19:25 digitalocean sshd[2373]: pam_ldap: error trying to bind as user "cn=dan.howard,ou=users,dc=example,dc=com" (Invalid credentials)
Nov 26 15:19:27 digitalocean sshd[2373]: Failed password for invalid user dan.howard from 62.30.196.60 port 63534 ssh2

'Invalid credentials' is a bit of a red herring here, and the important thing was 'invalid user dan.howard'. Apparently NSS will first look up the user name, and if it doesn't recognise the name, then the password sent to the LDAP server will be the literal string 'INCORRECT', which is bound to be wrong of course, and seems like very weird behaviour to me (more info https://unix.stackexchange.com/questions/163213/while-trying-to-ssh-pam-ldap-always-sends-the-password-incorrect-causing-bind)

I had seen lots of tutorials instructing me to put 'ldap' into my /etc/nsswitch.conf file for the passwd, group, and shadow lines, then restart nscd.

I did this, and it said [ok], so I couldn't see what was going wrong.

It turns out that I didn't have the ldap nss module installed at all. All I needed to do was this:

apt-get install libnss-ldap

Then NSS was able to identify the LDAP users, which meant PAM would send the correct passwords, and I was able to log in. Hopefully this will help someone else.

Answer 2

A couple of things:

1.) If you do a getent passwd $username for a user that only exists in ldap, does it pull back the correct entry?

2.) What does your /etc/pam.d/system-auth file look like.

3.) Does it return the results properly for

ldapsearch -D $BINDDN -W -H ldap://$HOST 'uid=$RANDOM_USER'

Lastly, It looks like the binddn you have in /usr/local/etc/ldap.conf is using ro_user and the binddn pam is auth'ing with is testuser. Why the discrepancy. Make sure both work with ldapsearch

Answer 3

On my case if it could help, I forgot to add the ldap module into /etc/nsswitch.conf

# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

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