On Tuesday, 23 August 2011 16:12:52 [email protected] wrote: > From: Buchan Milne <[email protected]> > To: [email protected] > Cc: [email protected] > Date: 23/08/2011 09:45 AM > Subject: Re: replication breaks ppolicy > > On Tuesday, 23 August 2011 15:12:41 [email protected] wrote: > > Good morning all > > > > After quite a bit of work, I got replication working (thank you all). > > > > So I forged ahead and deployed the server in our RHEL 5.5 environment. > > > >RHEL5's openldap packages finally became somewhat usable at RHEL5.4, for > >openldap *2.3*. You may find you want newer (e.g. for > >ppolicy_forward_updates). > > Will look into getting a newer version.
You may want to look here: http://staff.telkomsa.net/packages/ (has 2.4.25, will soon have 2.4.26). > > But > > now I just realized that none of my ppolicy rules work. Also, the Redhat > > clients are configured to use MD5 hash. > > > >You don't want clients to hash passwords, you can't enforce any password > >quality checks on hashes. Use 'pam_password exop' if you want to enforce > >password quality (or otherwise be able to control password hashing on the > >server-side). > > Have tried exop and clear as the documentation suggests is needed. No > aging / history though... > > > When I look at the accounts in > > webmin, it shows it being crypt????? I know openldap likes salted SHA, > > but > > > I thought I'd do what Redhat wanted, which was MD5. > > > >Why? > > Because... I guess cause I blindly follow vendor documentation? I do see > folks complaining about this though. > > > Password history, aging etc... A search used to show me all of my ppolicy > > objects. > > > > ldapsearch -v -x -b 'dc=chin,dc=ca' cn=default > > ? > > > But now returns nothing. Users can reuse passwords, so no history or > > aging > > > is working. No locking. I had to change ACL's on the provider and > > consumer > > > to get the replication working. Would that cause the problem? > > > > No. > > THen this is good. > > > Here is my policy LDIF file I added to the server: > > > > # policies, chin.com > > dn: ou=policies,dc=chin,dc=ca > > objectClass: organizationalUnit > > objectClass: top > > ou: policies > > > > # default, policies, chin.com > > dn: cn=default,ou=policies,dc=chin,dc=ca > > objectClass: top > > objectClass: device > > objectClass: pwdPolicy > > cn: default > > pwdAttribute: userPassword > > pwdInHistory: 6 > > pwdCheckQuality: 1 > > pwdMinLength: 8 > > pwdMaxFailure: 4 > > pwdLockout: TRUE > > pwdLockoutDuration: 1920 > > pwdGraceAuthNLimit: 0 > > pwdFailureCountInterval: 0 > > pwdMustChange: TRUE > > pwdAllowUserChange: TRUE > > pwdSafeModify: FALSE > > pwdMaxAge: 10368000 > > pwdExpireWarning: 1209600 > > pwdMinAge: 86400 > > > >Show some example accounts, requesting the operational attributes ('+'), > > and > > >show authentication attempts (see ldapwhoami(1)) and password change > > attempts > > >(see ldappasswd(1)) with the ppolicy control enabled (-e ppolicy). > > -bash-3.2$ ldapwhoami -x -D "uid=bigbob,ou=People,dc=chin,dc=ca" -W -e > ppolicy > Enter LDAP Password: > dn:uid=bigbob,ou=People,dc=chin,dc=ca > Result: Success (0) > > Not a whole hell of a lot of information is produced. I don't know this > command well so I'm not sure, but I think this is a little shy on output? > An example with a password that is about to expire (coincidentally): [bgmilne@tiger ~]$ ldapwhoami -x -D uid=bgmilne,ou=People,dc=ranger,dc=dnsalias,dc=com -W -e ppolicy Enter LDAP Password: ldap_bind: Success (0) (Password expires in 14811 seconds) > -bash-3.2$ id > uid=10014(bigbob) gid=100(users) groups=100(users) > > -bash-3.2$ ldappasswd -h ldap -x -D cn=admin,dc=chin,dc=ca > "uid=bigbob,ou=People,dc=chin,dc=ca" -W -S -e ppolicy > New password: > Re-enter new password: > Enter LDAP Password: > Result: Success (0) > > -bash-3.2$ > > > I can change the password with ldappasswd, and here I am changing it to the > existing password with no errors or complaints. That used to fail. [bgmilne@tiger ~]$ ldappasswd -x -D uid=bgmilne,ou=People,dc=ranger,dc=dnsalias,dc=com -W -S -e ppolicy New password: Re-enter new password: Enter LDAP Password: Result: Constraint violation (19) Additional info: Password is not being changed from existing value control: 1.3.6.1.4.1.42.2.27.8.5.1 false MAOBAQg= ppolicy: error=8 (New password is in list of old passwords) > > > I'm sorry but I'm not %100 sure what an operations attribute of ('+')is, > but here is an account that was created with the pwdpolicy objectclass. I > used to be able to get all the aging, last changed, lock and history > information.... > > ldapsearch -v -x -b 'dc=chin,dc=ca' uid=bigbob -e ppolicy > > # extended LDIF > # > # LDAPv3 > # base <dc=chin,dc=ca> with scope subtree > # filter: uid=bigbob > # requesting: ALL > # > > # bigbob, People, chin.ca > dn: uid=bigbob,ou=People,dc=chin,dc=ca > pwdAttribute: userPassword > shadowMax: 99999 > uid: bigbob > cn: Big Bob > homeDirectory: /homes/bigbob > uidNumber: 10014 > objectClass: account > objectClass: posixAccount > objectClass: top > objectClass: shadowAccount > objectClass: hostObject > objectClass: pwdPolicy > host: db1.rcip-chin.gc.ca > host: db2.rcip-chin.gc.ca > host: db-cl1.rcip-chin.gc.ca > host: db-cl2.rcip-chin.gc.ca > shadowWarning: 7 > gidNumber: 100 > gecos: Big Bob > loginShell: /bin/bash > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 [bgmilne@tiger CatDap]$ ldapsearch -LLL -x -D 'uid=LDAP Admin,ou=System Accounts,dc=ranger,dc=dnsalias,dc=com' -W "(uid=bgmilne)" '+' Enter LDAP Password: dn: uid=bgmilne,ou=People,dc=ranger,dc=dnsalias,dc=com structuralObjectClass: inetOrgPerson entryUUID: 8b74bea0-f20d-101e-8cdf-6105b6f2f478 creatorsName: uid=account admin,ou=system accounts,dc=ranger,dc=dnsailas,dc=co m createTimestamp: 19960203002836Z pwdPolicySubentry: cn=default,ou=Password Policies,dc=ranger,dc=dnsalias,dc=co m pwdChangedTime: 20110824062606Z pwdHistory: 20110824062606Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}Os/M84d/89D oNHCc1JutMnIHnyezjE47 entryCSN: 20110824062606.003012Z#000000#003#000000 modifiersName: uid=bgmilne,ou=People,dc=ranger,dc=dnsalias,dc=com modifyTimestamp: 20110824062606Z entryDN: uid=bgmilne,ou=People,dc=ranger,dc=dnsalias,dc=com subschemaSubentry: cn=Subschema hasSubordinates: FALSE Of interest are pwdChangedTime, pwdHistory, and possibly pwdFailureTime, pwdAccountLockedTime etc. But, yes, it looks like ppolicy is not active, even though your configuration looks ok.
