Centos – LDAP authentication on CentOS 7

authenticationcentosldappam

After upgrading to CentOS 7 it's no longer possible to login via LDAP. With CentOS 6 I used the package pam_ldap which worked fine, but now pam_ldap is no longer available for the new version of CentOS.

Connecting via ldapsearch still works fine, but trying to authenticate via ssh does not work.

I reinstalled the package nss-pam-ldapd and reconfigured authentication via authconfig-tui, but it still does not work.

Below I replace my username with user.name and the base with dc=sub,dc=example,dc=org.

My host OS is a CentOS 7. All currently available updates are installed.

$ uname -a
Linux isfet 3.10.0-123.8.1.el7.x86_64 #1 SMP Mon Sep 22 19:06:58 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

Installed packages

$ rpm -qa | grep -i ldap
openldap-2.4.39-3.el7.x86_64
nss-pam-ldapd-0.8.13-8.el7.x86_64
openldap-clients-2.4.39-3.el7.x86_64

Content of /etc/openldap/ldap.conf

URI ldap://172.16.64.25
BASE dc=sub,dc=example,dc=org

Content of /etc/nslcd.conf

ldap_version 3
uri ldap://172.16.64.25
base dc=sub,dc=example,dc=org
ssl no

Output of /var/log/secure

Oct  6 12:12:16 isfet sshd[3937]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=172.16.64.1  user=user.name
Oct  6 12:12:17 isfet sshd[3937]: Failed password for user.name from 172.16.64.1 port 18877 ssh2

Output of /var/log/audit/audit.log

type=USER_AUTH msg=audit(1412590243.286:364): pid=3912 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:authentication acct="user.name" exe="/usr/sbin/sshd" hostname=172.16.64.1 addr=172.16.64.1 terminal=ssh res=failed'
type=USER_AUTH msg=audit(1412590243.287:365): pid=3912 uid=0 auid=4294967295 ses=4294967295 msg='op=password acct="user.name" exe="/usr/sbin/sshd" hostname=? addr=172.16.64.1 terminal=ssh res=failed'

Output of the command ldapserach

$ ldapsearch -H ldap://172.16.64.25/ -D cn=Manager,dc=sub,dc=example,dc=org -W -x -b dc=sub,dc=example,dc=org -d1

ldap_url_parse_ext(ldap://172.16.64.25/)
ldap_create
ldap_url_parse_ext(ldap://172.16.64.25:389/??base)
Enter LDAP Password:
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP 172.16.64.25:389
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 172.16.64.25:389
ldap_pvt_connect: fd: 3 tm: -1 async: 0
attempting to connect:
connect success
ldap_open_defconn: successful
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_scanf fmt ({i) ber:
ber_flush2: 61 bytes to sd 3
ldap_result ld 0x7f9b07402110 msgid 1
wait4msg ld 0x7f9b07402110 msgid 1 (infinite timeout)
wait4msg continue ld 0x7f9b07402110 msgid 1 all 1
** ld 0x7f9b07402110 Connections:
* host: 172.16.64.25  port: 389  (default)
  refcnt: 2  status: Connected
  last used: Mon Oct  6 12:04:38 2014


** ld 0x7f9b07402110 Outstanding Requests:
 * msgid 1,  origid 1, status InProgress
   outstanding referrals 0, parent count 0
  ld 0x7f9b07402110 request count 1 (abandoned 0)
** ld 0x7f9b07402110 Response Queue:
   Empty
  ld 0x7f9b07402110 response count 0
ldap_chkResponseList ld 0x7f9b07402110 msgid 1 all 1
ldap_chkResponseList returns ld 0x7f9b07402110 NULL
ldap_int_select
read1msg: ld 0x7f9b07402110 msgid 1 all 1
ber_get_next
ber_get_next: tag 0x30 len 50 contents:
read1msg: ld 0x7f9b07402110 msgid 1 message type bind
ber_scanf fmt ({eAA) ber:
read1msg: ld 0x7f9b07402110 0 new referrals
read1msg:  mark request completed, ld 0x7f9b07402110 msgid 1
request done: ld 0x7f9b07402110 msgid 1
res_errno: 0, res_error: <>, res_matched: <cn=Manager,dc=sub,dc=example,dc=org>
ldap_free_request (origid 1, msgid 1)
ldap_parse_result
ber_scanf fmt ({iAA) ber:
ber_scanf fmt (}) ber:
ldap_msgfree
ldap_err2string
ldap_bind: Success (0)
        matched DN: cn=Manager,dc=sub,dc=example,dc=org
...

Content of _/etc/pam.d/password-auth

auth        required      pam_env.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 1000 quiet_success
auth        sufficient    pam_ldap.so use_first_pass
auth        required      pam_deny.so

account     required      pam_unix.so broken_shadow
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 1000 quiet
account     [default=bad success=ok user_unknown=ignore] pam_ldap.so
account     required      pam_permit.so

password    requisite     pam_pwquality.so try_first_pass retry=3 type=
password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password    sufficient    pam_ldap.so use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
-session     optional      pam_systemd.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so
session     optional      pam_ldap.so

Content of _/etc/pam.d/system-auth

auth        required      pam_env.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 1000 quiet_success
auth        sufficient    pam_ldap.so use_first_pass
auth        required      pam_deny.so

account     required      pam_unix.so broken_shadow
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 1000 quiet
account     [default=bad success=ok user_unknown=ignore] pam_ldap.so
account     required      pam_permit.so

password    requisite     pam_pwquality.so try_first_pass retry=3 type=
password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password    sufficient    pam_ldap.so use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
-session     optional      pam_systemd.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so
session     optional      pam_ldap.so

Best Answer

Running nslcd in debug mode shows the problem:

$ $(which nslcd) -d
...
nslcd: [8b4567] <authc="user.name"> DEBUG: myldap_search(base="dc=sub,dc=example,dc=org", filter="(&(objectClass=posixAccount)(uid=user.name))")
...
nslcd: [8b4567] <authc="user.name"> DEBUG: ldap_result(): end of results (0 total)
nslcd: [8b4567] <authc="user.name"> DEBUG: "user.name": user not found: No such object
...

nslcd sets a filter by default. It's not possible to remove this filter or set it to blank.

Because none of my LDAP users has an objectClass called posixAccount the users cannot be found and the login is denied.

To fix this problem I had to overwrite this filter with an own one. Because I'm looking for the uid it's useful to set the filter on an attribute which is searched for anyways.

New content of my /etc/nslcd.conf:

filter passwd (uid=*)
uri ldap://172.16.64.25
base dc=sub,dc=example,dc=org
ssl no

After changing the nslcd.conf I had to restart the service nslcd: systemctl restart nslcd

Source: http://lists.arthurdejong.org/nss-pam-ldapd-users/2014/msg00025.html

This seems to be a problem for _nss-pam-ldapd-0.8.13-8.el7.x86_64_ on CentOS 7!

$ nslcd -V
nss-pam-ldapd 0.8.13

I tried to reproduce the problem on CentOS 6, but on this nss-pam-ldapd has dependencies to pam_ldap which has its config file in /etc/pam_ldap.conf and seems to not use /etc/nslcd.conf in the way it works on CentOS 7.

Related Solutions

Ubuntu LDAP Make Home Directory

The way we solved this is to add another attribute to LDAP, something like linuxHomeDirectory . Then you can create a mapping in ldap.conf:

nss_map_attribute homeDirectory linuxHomeDirectory

The for each user you set the attribute in LDAP to the path you want for their Linux home dir, such as /home/$username or whatnot.

If you have your home directories served from OS X server, you can mount those with an automounter in the /Volumes/$servername/$path hierarchy on Linux and then you don't need to do any LDAP attribute mangling.

More info: Here's an article how to extend the LDAP schema in OpenDirectory: http://www.afp548.com/article.php?story=20060228230005854

To populate the user attributes you can use the ldapadd and ldapmodify tools.

Ldap – FreeBSD LDAP authentication, pam_ldap, can’t bind

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

You SSH in as joeblow. Your client gives that name to the server, along with your password (that you enter).
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.

Best Answer

Related Solutions

Ubuntu LDAP Make Home Directory

Ldap – FreeBSD LDAP authentication, pam_ldap, can’t bind

Related Topic