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

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

I am in the process of deploying a Openldap/pam_ldap based centralized authentication scheme. I am utilizing the password policy overlay, and that is what makes the strangeness stand out.

Specifically, with pam_ldap configured identically between a Debian Wheezy based client and a Debian Jessie based client, password overlay behavior like pwdHistory and pwdMinLength work under Wheezy but not under Jessie.

I downgraded the pam_ldap package to the Wheezy version, and see the same result. So I would believe that the issue is not actually with pam_ldap, but something underlieing like PAM

It appears that pam_ldap is is operating as if the passwd command was executed by root, and is using the rootbinddn credentials to change the password. This bypasses the ppolicy overlay, not checking pwdHistory or pwdMinLength.

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.