[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: replication breaks ppolicy
On Tuesday, 23 August 2011 16:12:52 rocke.robertson@pch.gc.ca wrote:
> From: Buchan Milne <bgmilne@staff.telkomsa.net>
> To: openldap-technical@openldap.org
> Cc: rocke.robertson@pch.gc.ca
> Date: 23/08/2011 09:45 AM
> Subject: Re: replication breaks ppolicy
>
> On Tuesday, 23 August 2011 15:12:41 rocke.robertson@pch.gc.ca 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.