[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.