PAM_LDAP Authentication failure with correct credentials on freebsd

42,980

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.

Share:
42,980

Related videos on Youtube

floodpants
Author by

floodpants

Updated on September 18, 2022

Comments

  • floodpants
    floodpants almost 2 years

    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.

  • user14793161
    user14793161 over 3 years
    According to man 5 nsswitch.conf on FreeBSD, no shadow database is known. I am not sure why it needs to be set.