0

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

0

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.

  • If the rootbinddn was not specified with libldap 2.4.40 the end user would receive an error when attempting to change their password: passwd: Authentication token manipulation error passwd: password unchanged And while removing that would have fixed the security concern, I would prefer having all functionality actually work. – Corvar Jul 20 '15 at 21:13
0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.