pam_ldap user password changes using rootbinddn on Debian Jessie

Question

When configuring pam_ldap on Debian Jessie, end user password changes are utilizing the rootbinddn, circumventing OpenLDAP's ppolicy overlay. This is allowing end users to change their passwords without conforming to the password policy defined within OpenLDAP, eg they can repeat passwords and ignore the minimum password length. I would like password changes to be done utilizing the end users dn, with password policies enforced.

Every relevant configuration I can think of matches my working configuration on Debian Squeeze/Wheezy, but this problem happens on all Debian Jessie installs tested.

I have created a Debian bug, but am continuing to explore the possibility (likelihood) that it is a configuration error. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790488

Blocks of relevant config files are as follows:

/etc/pam_ldap.conf and libnss-ldap.conf are identical:

debug 0 base dc=internal,dc=net uri ldaps://ldap-server/ ldap_version 3 rootbinddn cn=admin,dc=internal,dc=net port 636 pam_password exop ssl on tls_checkpeer yes tls_cacertfile /etc/ssl/certs/ldap-server.pem 

/etc/pam.d/common-passwd:

password [success=2 default=ignore] pam_unix.so obscure sha512 password [success=1 user_unknown=ignore default=die] pam_ldap.so try_first_pass password requisite pam_deny.so password required pam_permit.so 

/etc/nsswitch.conf:

passwd: compat ldap group: compat ldap shadow: compat 

That the password is being changed by the rootbinddn is confirmed from auditlogs on the OpenLDAP Server, an example entries of a password change from a Debian Wheezy server followed by a Debian Jessie Server:

# modify 1435351337 dc=internal,dc=net uid=wrttest,ou=People,dc=internal,dc=net IP=172.16.11.141:48084 conn=1066 dn: uid=wrttest,ou=People,dc=internal,dc=net changetype: modify replace: userPassword userPassword:: e1NTSEFUdIkewk5eUlOaFA4bmMvMzlvVjg= - replace: pwdChangedTime pwdChangedTime: 20150626204217Z - delete: pwdHistory pwdHistory: 20150327201545Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}NxOHHViV zwlUZs2TKWKJsdatrfeO3OF - add: pwdHistory pwdHistory: 20150626204217Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}DJJkErb9 CEyPPPYYYAAAAESjR3wDqRj9 - replace: entryCSN entryCSN: 20150626204217.320385Z#000000#001#000000 - replace: modifiersName modifiersName: uid=wrttest,ou=People,dc=internal,dc=net - replace: modifyTimestamp modifyTimestamp: 20150626204217Z - # end modify 1435351337 # modify 1435595556 dc=internal,dc=net cn=admin,dc=internal,dc=net IP=172.16.11.158:34413 conn=1080 dn: uid=wrttest,ou=People,dc=internal,dc=net changetype: modify replace: userPassword userPassword:: e1HUHJFIzFeQHpacEJQGd2VvU08= - replace: pwdChangedTime pwdChangedTime: 20150629163236Z - delete: pwdHistory pwdHistory: 20150626204102Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}Xi1p3Z44556K5c 5tcFOeLaBIL1i - add: pwdHistory pwdHistory: 20150629163236Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}13lTJmGHfgf Y45672xoyuVVswcgIP - replace: entryCSN entryCSN: 20150629163236.253982Z#000000#001#000000 - replace: modifiersName modifiersName: cn=admin,dc=internal,dc=net - replace: modifyTimestamp modifyTimestamp: 20150629163236Z - # end modify 1435595556 

Attempting to determine where the issue was coming from, I have downgraded the Debian Jessie package to the Wheezy version of libpam-ldap. I have made various changes to the PAM configuration, that either did not change the issue or broke LDAP authentication completely. From turning on debuging in pam_ldap while leaving it off in libnss-ldap, I satisfied myself that the password change routing was being handled by pam_ldap not libnss-ldap. I reviewed the code of the pam_ldap package to see if I could determine where things were going wrong.

Update: In an attempt to debug this, I have a running Jessie system where I have downgraded the following packages to try and determine what package is causing the issue: libpam-modules 1.1.3-7.1 libpam-modules-run 1.1.3-7.1 libpam-runtime 1.1.3-7.1 passwd 1:4.1.5.1-1 libpam0g 1.1.3-7.1 libpam-ldap 184-8.6

I also tried uninstalling libpam-systemd

Update 2: After various testing, I have determined the issue is with libldap. If a wheezy system is upgraded to the backports version 2.4.31+really2.4.40+dfsg-1~bpo70+1 it starts to exhibit the behaviour. And if a jessie system is downgraded to 2.4.31-2 it stops exhibiting the issue. I have sent an update to the Debian bug, and attempted to reassign it to libldap-2.4-2

Answer 1

Stop using the directory's RootDN as the dn for the local system's root account. The directory's rootdn is not subject to access controls. Use (create if necessary) a dn entry with the appropriate permissions with your LDAP server to modify passwords correctly.

Answer 2

The bug that causes this specific issue has been in the libpam-ldap source for a long time, but it's effect was only seen after a separate bug was fixed in the gnutls library that libldap-2.4-2 uses. The specifics can be found in an enlightening email from Ryan Tandy in the Debian bug page for this issue. ( Debian Bug 790488 ).

I had already known that libpam-ldap was not actively being developed, but it provided functionality that libpam-ldapd missed (specifically password policy support). I decided that the best option was actually to move newer systems to the sssd system, which is under active development, supports password policy overlays, and other features.