0

Context

I have 2 different machins here whose main difference is that one is runs CentOS6 the other CentOS7. Both run the latest distribution-available version of the lib : 0.8.13 for COS7, 0.7.5 for CentOS6 Both are running nss-pam-ldapd configured "normally" :

/etc/nslcd.conf

uid nslcd
gid ldap

uri ldap://ldap.example.org/
base dc=example,dc=org

ssl no
tls_cacertdir /etc/openldap/cacerts
idle_timelimit 240

base   group  ou=groups,dc=example,dc=org

binddn cn=Readonly,dc=example,dc=org
bindpw **************

Server's permissions :

olcAccess: {0}to attrs=userPassword,shadowLastChange by dn="cn=Manager,dc=cube-net,dc=org" write by dn="cn=Readonly,dc=example,dc=org" none by anonymous auth by self write by * none
olcAccess: {1}to dn.base="cn=Readonly,dc=example,dc=org" by dn="cn=Manager,dc=example,dc=org" write by * none
olcAccess: {2}to dn.base="" by * read
olcAccess: {3}to * by dn="cn=Manager,dc=example,dc=org" write by dn="cn=Readonly,dc=example,dc=org" read by self write by * read

The issue

I can look up for users just fine, but I cannot log in as a user using su on the CentOS 7. I get :

mveroone@vm:~$ passwd
Changing password for user mveroone.
(current) LDAP Password: 
New password: 
Retype new password: 
passwd: all authentication tokens updated successfully.
mveroone@vm:~$ su - mveroone
Password: 
su: Permission denied
mveroone@vm:~$ ssh localhost
Authorized uses only. All activity may be \ monitored and reported.
mveroone@localhost's password: 
Last login: Fri Aug 20 16:10:24 2021

Authorized uses only. All activity may be \ monitored and reported.
mveroone@vm:~$

SO yeah, I can log in using SSH, change my password, but not use su.

What I've tried

Performing a ldapwhoami on both servers works using simple bind method, but not SASL (no available mechanism)

root@vm:~# ldapwhoami -D uid=user,ou=users,dc=example,dc=org -W -H ldap://ldap.example.org  
Enter LDAP Password: 
dn:uid=user,ou=users,dc=example,dc=org

Running nslcd -d while trying to password-auth using su shows this only in COS7 :

nslcd: DEBUG: accept() failed (ignored): Resource temporarily unavailable

Although it seems to be an error that can be ignored according to a couple mailing list threads.

When running nslcd with additionnal debug (nslcd -dd), I can see that it first attemps to bind with the user, which succeeds, then it searches for '(objectClass=*)', filtering attributes : dn and base = itself which works:

ldap_free_request (origid 1, msgid 1)
ldap_parse_result
ldap_msgfree
ldap_search_ext
put_filter: "(objectClass=*)"
put_filter: simple
put_simple_filter: "objectClass=*"
ldap_build_search_req ATTRS: dn
ldap_send_initial_request
ldap_send_server_request
ldap_result ld 0x7f7a9800cf60 msgid 2
wait4msg ld 0x7f7a9800cf60 msgid 2 (timeout 10000000 usec)
wait4msg continue ld 0x7f7a9800cf60 msgid 2 all 0
** ld 0x7f7a9800cf60 Connections:
 * host: ldap.example.org  port: 389  (default)
  refcnt: 2  status: Connected
  last used: Fri Aug 20 11:42:05 2021


** ld 0x7f7a9800cf60 Outstanding Requests:
 * msgid 2,  origid 2, status InProgress
   outstanding referrals 0, parent count 0
  ld 0x7f7a9800cf60 request count 1 (abandoned 0)
** ld 0x7f7a9800cf60 Response Queue:
   Empty
  ld 0x7f7a9800cf60 response count 0
ldap_chkResponseList ld 0x7f7a9800cf60 msgid 2 all 0
ldap_chkResponseList returns ld 0x7f7a9800cf60 NULL
ldap_int_select
read1msg: ld 0x7f7a9800cf60 msgid 2 all 0
read1msg: ld 0x7f7a9800cf60 msgid 2 message type search-entry
ldap_get_dn
nslcd: [0e0f76] <authc="user"> DEBUG: ldap_result(): uid=user,ou=users,dc=example,dc=org
ldap_msgfree
ldap_abandon 2
ldap_abandon_ext 2
do_abandon origid 2, msgid 2
ldap_msgdelete ld=0x7f7a9800cf60 msgid=2
ldap_free_request (origid 2, msgid 2)
ldap_free_connection 0 1
ldap_free_connection: refcnt 1
ldap_msgfree
nslcd: [0e0f76] <authc="user"> DEBUG: ldap_unbind()
ldap_unbind

So the path is :

  • Bind (OK)
  • Search its own DN (ok)
  • Abandon
  • Unbind

Then tells me it can't authenticate the user. ("Permission Denied" so it's different from "authentication failure") I performed a packet capture and it show the same thing.

I've tried running through nslcd's changelogs of version 0.8.x to see if something changed, but there were a lot of changes, without enough details.

mveroone
  • 447
  • 7
  • 22

1 Answers1

0

Okay so it was totaly unrelated to nslcd or PAM-LDAP in the end...

/etc/pam.d/su had this line at the end (out of he "auth" block)

auth    required    pam_wheel.so    use_uid

Which wasn't in /etc/pam.d/sshd for example.

Commenting it fixed the issue

The line also existed on CentOS 6, but there was an include statement above which skipped any further line, as opposed to substack which doesn't.

mveroone
  • 447
  • 7
  • 22