I've been able to get some of my linux servers authenticating users against my LDAP directory server, but I've been having some trouble trying to do this with nss_ldap and pam_ldap in FreeBSD.

Going from FreeBSD official docs here: http://www.freebsd.org/doc/en/articles/ldap-auth/client.html

I install the 2 packages, and create a config file /usr/local/etc/ldap.conf, and also a symlink to this file in the same directory, nss_ldap.conf. According to the docs they can both use the same config file. I'm keeping it very simple until I can get it working:


base    dc=corp,dc=example,dc=org
ldap_version 3
binddn cn=admin,dc=corp,dc=example,dc=org
bindpw secret

NSS works as far as I can tell. A "getent passwd" shows information from the LDAP directory as well as local stuff.

Now I want to authenticate, so I add a line to /etc/pam.d/sshd:

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

I restart ssh (not sure if this is necessary), and then try and log in with an LDAP user that doesn't exist locally (coryj). It fails silently and logs show:

Sep  9 13:13:54 freebsd-testbox sshd[12684]: pam_ldap: error trying to bind as user "uid=coryj,ou=Users,dc=corp,dc=example,dc=org" (Invalid credentials)

Why is it trying to bind with the user I'm trying to authenticate when I specified a binddn/bindpw? I also tried rootbinddn with a .secret file with the same result. On linux binddn seems to work, where here it seems to be ignored.

I know my ldap.conf and pam files will need some more work, just trying to convince the thing to bind as admin when authenticating at this point.

2 Answers 2


Here's how LDAP authentication works, in a nutshell:

  1. You SSH in as joeblow. Your client gives that name to the server, along with your password (that you enter).
  2. The server starts walking the PAM list saying "does anyone vouch for this guy?", looking for either an OK or a NO. (PAM modules can deny as well as allow). In your case:
    1. It checks pam_opie.so. You've said this is sufficient, so it will just move on if it isn't found. I imagine it's not in this case.
    2. It checks pam_opieaccess.so. In this case, it's required, so pam_opieaccess.so has to say "yeah, he's ok". I imagine this module is just checking a list of accounts that are marked "has to auth via OPIE", which joeblow isn't on. It says OK.
    3. /usr/local/lib/pam_ldap.so gets a turn. This is the part you care about.
      1. First it binds to the server with your binddn and bindpw, to ask "hey, I've got this joeblow here, what's his real name?" The server answers uid=joeblow,ou=Users,dc=corp,dc=example,dc=org.
      2. pam_ldap.so disconnects, and tries to bind as uid=joeblow,ou=Users,dc=corp,dc=example,dc=org with the password you gave. If it can bind, you're in. If not, not.

So the error you're getting means that step 2.3.2 there is failing, probably because the password is incorrect. It's possible that there is some other problem with joeblow binding to the server, check the LDAP server logs for more details.


The binddn and bindpw options control the initial lookup that converts a username into an LDAP distinguished name -- LDAP password checks are performed by binding to the LDAP directory as the user trying to authenticate (If you were able to bind then the check was successful).
See man pam_ldap for more information on this.

In your case I suspect either the password you're entering for for coryj is wrong (perhaps their LDAP password is corrupted?), or coryj can't bind to the directory for other reasons. Try binding with ldapwhoami or ldapsearch and see if you get a helpful error message.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .