nss-pam-ldapd password authentication doesn't work on CentOS 7 only when using `su`

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.