Full_Name: Buchan Milne Version: 2.3.41 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (196.207.32.38)
When both the smbk5pwd and ppolicy overlays are loaded, and an entry is in a state that requires a password change (I tested with 'pwdReset: TRUE' on the entry), the entry cannot change its password via an LDAP password change extended operation:
$ ldapsearch -H ldapi:// -LLL -x "(uid=bgmilne)" pwdReset pwdPolicySubEntry dn: uid=bgmilne,ou=People,dc=ranger,dc=dnsalias,dc=com pwdPolicySubentry: cn=default,ou=Password Policies,dc=ranger,dc=dnsalias,dc=co m pwdReset: TRUE
$ ldapsearch -H ldapi:// -LLL -x -s base -b 'cn=default,ou=Password Policies,dc=ranger,dc=dnsalias,dc=com' @pwdPolicy dn: cn=default,ou=Password Policies,dc=ranger,dc=dnsalias,dc=com objectClass: pwdPolicy objectClass: namedObject pwdAttribute: userPassword pwdLockout: TRUE pwdMustChange: TRUE
$ ldappasswd -H ldapi:// -x -D uid=bgmilne,ou=People,dc=ranger,dc=dnsalias,dc=com -W -S New password: Re-enter new password: Enter LDAP Password: Result: Insufficient access (50) Additional info: Operations are restricted to bind/unbind/abandon/StartTLS/modify password
The relevant parts of the slapd.conf follow:
[...] include /usr/share/openldap/schema/ppolicy.schema include /etc/openldap/schema/local.schema pidfile /var/run/ldap/slapd.pid argsfile /var/run/ldap/slapd.args modulepath /usr/lib64/openldap moduleload back_monitor.la moduleload syncprov.la moduleload ppolicy.la moduleload auditlog.la moduleload smbk5pwd.so moduleload allop.so moduleload rwm.la moduleload back_relay.la TLSCertificateFile /etc/ssl/openldap/ldap.pem TLSCertificateKeyFile /etc/ssl/openldap/ldap.pem TLSCACertificateFile /etc/ssl/openldap/ldap.pem localSSF 56 loglevel 256 access to dn.exact="" by * read access to dn.exact="cn=Subschema" by * read overlay allop database bdb suffix "dc=ranger,dc=dnsalias,dc=com" directory /var/lib/ldap rootdn "cn=manager,dc=ranger,dc=dnsalias,dc=com" checkpoint 256 5 cachesize 1000 idlcachesize 3000 index objectClass eq index uidNumber,gidNumber,memberuid,member eq index uid eq,subinitial index cn,mail,surname,givenname eq,subinitial index sambaSID eq,sub index sambaDomainName,displayName,sambaGroupType eq index sambaSIDList eq index krb5PrincipalName eq index uniqueMember pres,eq index zoneName,relativeDomainName eq index sudouser eq,sub index entryCSN,entryUUID eq index dhcpHWAddress,dhcpClassData eq authz-regexp "gidNumber=0\+uidNumber=0,cn=peercred,cn=external,cn=auth" "uid=Account Admin,ou=System Accounts,dc=ranger,dc=dnsalias,dc=com" sasl-regexp uid=(.*),cn=ranger.dnsalias.com,cn=gssapi,cn=auth ldap:///dc=ranger,dc=dnsalias,dc=com??sub?(krb5PrincipalName=$1@RANGER.DNSALIAS.COM) authz-regexp "" "" include /etc/openldap/mandriva-dit-access.conf overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 overlay ppolicy ppolicy_default "cn=default,ou=Password Policies,dc=ranger,dc=dnsalias,dc=com" overlay smbk5pwd overlay auditlog auditlog /var/lib/ldap/audit.log database monitor access to dn.subtree="cn=Monitor" by group.exact="cn=LDAP Monitors,ou=System Groups,dc=ranger,dc=dnsalias,dc=com" read by group.exact="cn=LDAP Admins,ou=System Groups,dc=ranger,dc=dnsalias,dc=com" read by * none database config rootdn cn=config rootpw xxxxx
Commenting out the 'overlay smbk5pwd' results in the user being able to change their password (with identical input to the previous case):
$ ldappasswd -H ldapi:// -x -D uid=bgmilne,ou=People,dc=ranger,dc=dnsalias,dc=com -W -S New password: Re-enter new password: Enter LDAP Password: Result: Success (0)
Changing the order the modules are stacked in does not seem to make a difference. I could find no other reason why the password change was not being allowed, except that smbk5pwd is interfering.
I have not run this same test case on 2.4.x yet, but I remember having problems trying to change passwords on 2.4.10 with a very similar configuration, so I think it exists in 2.4.10 as well.