[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
(ITS#5569) smbk5pwd breaks ppolicy-mandated password changes
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.