LDAP authentication fails for users not in /etc/passwd

D

dennyp

Hi guys,

Relatively new to FreeBSD. I'm trying to authenticate users logging in via SSH against Active Directory using pam_ldap. It works fine when the user is in /etc/passwd, but authentication fails for users that are not. A packet trace reveals the password sent to LDAP in the bindRequest is 08:0a:0d:7f:49:4e:43:4f:52:52:45:43:54 in hex or "....INCORRECT" in ASCII - hence the failure.

I've followed the LDAP configuration instructions at http://www.freebsd.org/doc/en/articles/ldap-auth/ldap.html. I'm sure it's something obvious but endless searches have not turned up anything for me. Here's my /etc/pam.d/sshd for reference.

Code: 
# auth
auth            required        pam_nologin.so          no_warn
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
auth            required        pam_unix.so             no_warn try_first_pass

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

# session
session         required        pam_permit.so

# password
password        required        pam_unix.so             no_warn try_first_pass

Thanks
Denny
 
nsswitch.conf looks okay to me. I've tried reversing the order of 'files ldap' to no avail

Code: 
#group: compat
group: files ldap
group_compat: nis
hosts: files dns
networks: files
#passwd: compat
passwd: files ldap
passwd_compat: nis
shells: files
services: compat
services_compat: nis
protocols: files
rpc: files

Here's an excerpt from /var/log/messages following a login attempt. Is there a way to increase the debug level? debug 9 in /usr/local/etc/ldap.conf seemed to have no effect.

Code: 
Oct 27 09:21:47 ciw-ns1 sshd[13289]: pam_ldap: error trying to bind as user "CN=Test User,OU=Users,DC=vmmodel,DC=local" (Invalid credentials)
Oct 27 09:21:47 ciw-ns1 sshd[13287]: error: PAM: authentication error for illegal user testuser from 10.1.2.3
 
Hi, I find myself in the exact same situation. Trying to use an A.D. LDAP server for authentication for users in FreeBSD. If the user is in the local /etc/passwd all is well. If not, user is called "illegal" and credentials are called invalid. A log excerpt:

Code: 
Apr 11 11:21:22 box sshd[34835]: pam_ldap: error trying to bind as user "CN=Schlub Jones,OU=Users,OU=Admin Users,OU=Users and Computers,OU=Springfield NOC,OU=CCI,DC=CORP,DC=EXAMPLE,DC=com" (Invalid credentials)
Apr 11 11:21:22 box sshd[34830]: error: PAM: authentication error for illegal user schlub from otherbox
Apr 11 11:21:22 box sshd[34830]: Failed keyboard-interactive/pam for invalid user schlub from 172.17.1.1 port 52407 ssh2

I tried nss_switch.conf, too, with no luck. Is there a way (outside of logging in) to verify that nss_switch/LDAP is working correctly?

Has anyone solved this particular issue? Has anyone else run into it? Thanks for any thoughts.
 
If you ever face the same kind of issue with INCORRECT sent to LDAP instead of a/the password:
  1. Check nss_ldap ( getent passwd user, id user, etc.).
  2. Make sure that user shell specified for user in LDAP is available on client system (/etc/shells).
The second took me three days to figure out! All Linux systems work like a charm with /bin/bash but in FreeBSD we have /usr/local/bin/bash. So ln -s /usr/local/bin/bash /bin/bash and adding it to /etc/shells fixed this problem for me.
 
Re:

melco said:
If you ever face the same kind of issue with INCORRECT sent to LDAP instead of a/the password:
  1. Check nss_ldap ( getent passwd user, id user, etc.).
  2. Make sure that user shell specified for user in LDAP is available on client system (/etc/shells).
The second took me three days to figure out! All Linux systems work like a charm with /bin/bash but in FreeBSD we have /usr/local/bin/bash. So ln -s /usr/local/bin/bash /bin/bash and adding it to /etc/shells fixed this problem for me.
Click to expand...
Registered to say "thank you" for this.
 
You must log in or register to reply here.
Back
Top