Hi,
Is it possible to replicate password policy related attributes using sync replication while using ppolicy overlay?
I am specifically asking about replicating pwdChangedTime, pwdAccountLockedTime, pwdHistory and etc... not about password configuration related attributes,
Regards, Sadique
I did a bit more testing about this.
I set up password policy as below. Only relevant part given.
pwdLockout: TRUE pwdMaxFailure: 3 pwdLockoutDuration: 90
1 - I did bind to the master server 3 times using wrong password. I failed to bind using the right password after that and failed. Expected 2- I did bind to the consumer server using the right password. Failed. Expected.
After 90 seconds everything works fine.
3- I did bind to the consumer server using the wrong password three times. I failed to bind to the consumer using the right password after that. Failed. Expected 4 - I did bind to the master server using the right password. Success. Not expected before elapsing 90 seconds.
I know the consumer server is not supposed to update the master server database, but is there any work around? Does openldap support multi master replication? Is this a limitation. Does this mean a client locked on consumer server - as set by the policy - would be able to bind to the master server overriding the policy.
One more doubt: where the failure counts are stored?
Regards, Sadique
Sadique Puthen wrote:
Hi,
Is it possible to replicate password policy related attributes using sync replication while using ppolicy overlay?
I am specifically asking about replicating pwdChangedTime, pwdAccountLockedTime, pwdHistory and etc... not about password configuration related attributes,
Regards, Sadique
Sadique Puthen wrote:
Hi,
Is it possible to replicate password policy related attributes using sync replication while using ppolicy overlay?
I am specifically asking about replicating pwdChangedTime, pwdAccountLockedTime, pwdHistory and etc... not about password configuration related attributes,
In general, ppolicy related state values are not replicated; each replica is on its own as far as state-related attributes in enforcing password policy. I recall discussion about if and how this type of info should be replicated or somehow shared on the IETF ldapext list, but the conclusion sounded like "replication and password policy are two separate things with some overlap; if we bundle them, consensus on the draft will be harder to achieve, so let's keep them separate (and leave them to implementors, I guess)". I hope my short and incomplete summary of the discussion is not too short and incomplete.
p.
Hi,
I try password history checking in OpenLDAP 2.3.32 and change user password using LDAP browser.
When I enterer repaeted cleartext password then ppolicy returned expected decline "Password is in history of old passwords". But by password changing to any encrypted value ( the same password two and more times) OpenLDAP doesn't verify old password.
In log-file I found similar info about password changing for both cases:
Jan 18 13:25:15 KS-Test-1 slapd[5478]: acl: internal mod pwdHistory: modify access granted Jan 18 13:25:15 KS-Test-1 slapd[5478]: acl: internal mod pwdHistory: modify access granted Jan 18 13:25:15 KS-Test-1 slapd[5478]: bdb_modify_internal: delete pwdHistory Jan 18 13:25:15 KS-Test-1 slapd[5478]: bdb_modify_internal: add pwdHistory Jan 18 13:25:15 KS-Test-1 slapd[5478]: oc_check_allowed type "pwdHistory"
Slapd.conf : .... ....
moduleload ppolicy.la overlay ppolicy ppolicy_default "cn=std,ou=ppolicy,ou=users,ou=trm" ppolicy_hash_cleartext ppolicy_use_lockout
What's your thing?
Andris
Andris.Eiduks@tietoenator.com wrote:
Hi,
I try password history checking in OpenLDAP 2.3.32 and change user password using LDAP browser.
When I enterer repaeted cleartext password then ppolicy returned expected decline "Password is in history of old passwords". But by password changing to any encrypted value ( the same password two and more times) OpenLDAP doesn't verify old password.
In log-file I found similar info about password changing for both cases:
Jan 18 13:25:15 KS-Test-1 slapd[5478]: acl: internal mod pwdHistory: modify access granted Jan 18 13:25:15 KS-Test-1 slapd[5478]: acl: internal mod pwdHistory: modify access granted Jan 18 13:25:15 KS-Test-1 slapd[5478]: bdb_modify_internal: delete pwdHistory Jan 18 13:25:15 KS-Test-1 slapd[5478]: bdb_modify_internal: add pwdHistory Jan 18 13:25:15 KS-Test-1 slapd[5478]: oc_check_allowed type "pwdHistory"
Slapd.conf : .... ....
moduleload ppolicy.la overlay ppolicy ppolicy_default "cn=std,ou=ppolicy,ou=users,ou=trm" ppolicy_hash_cleartext ppolicy_use_lockout
Encrypted values can't be decrypted to check history. Ppolicy needs the cleartext password to save the history.
p.
Hi,
Very strange, because ppolicy by parameter ppolicy_hash_cleartext store also encrypted password value. Then where is the problem store recieved ecrypted passwords and also check from pwdHistory this encrypted value?
Otherwise we have a problem with PCI DSS requirements:
8.4 Encrypt all passwords during transmission and storage on all system components.
8.5.12 Do not allow an individual to submit a new password that is the same as any of the last four passwords he or she has used
Andris
-----Original Message----- From: Pierangelo Masarati [mailto:ando@sys-net.it] Sent: Thursday, January 18, 2007 5:48 PM To: Eiduks Andris Cc: openldap-software@openldap.org Subject: Re: Ppolicy - password history
Andris.Eiduks@tietoenator.com wrote:
Hi,
I try password history checking in OpenLDAP 2.3.32 and change user password using LDAP browser.
When I enterer repaeted cleartext password then ppolicy returned expected decline "Password is in history of old passwords". But by password changing to any encrypted value ( the same password two and more times) OpenLDAP doesn't verify old password.
In log-file I found similar info about password changing for both cases:
Jan 18 13:25:15 KS-Test-1 slapd[5478]: acl: internal mod pwdHistory: modify access granted Jan 18 13:25:15 KS-Test-1 slapd[5478]: acl: internal mod pwdHistory: modify access granted Jan 18 13:25:15 KS-Test-1 slapd[5478]: bdb_modify_internal: delete pwdHistory Jan 18 13:25:15 KS-Test-1 slapd[5478]: bdb_modify_internal: add pwdHistory Jan 18 13:25:15 KS-Test-1 slapd[5478]: oc_check_allowed type "pwdHistory"
Slapd.conf : .... ....
moduleload ppolicy.la overlay ppolicy ppolicy_default "cn=std,ou=ppolicy,ou=users,ou=trm" ppolicy_hash_cleartext ppolicy_use_lockout
Encrypted values can't be decrypted to check history. Ppolicy needs the
cleartext password to save the history.
p.
Andris.Eiduks@tietoenator.com wrote:
Hi,
Very strange, because ppolicy by parameter ppolicy_hash_cleartext store also encrypted password value. Then where is the problem store recieved ecrypted passwords and also check from pwdHistory this encrypted value?
The difference is that when the *server* encrypts it, it has a chance to validate the cleartext first. When the *client* encrypts it, no such opportunity exists for the server.
Otherwise we have a problem with PCI DSS requirements:
8.4 Encrypt all passwords during transmission and storage on all system components.
The obvious solution to meet this requirement is to make sure that all connections are encrypted (using TLS, SASL, or IPSEC).
8.5.12 Do not allow an individual to submit a new password that is the same as any of the last four passwords he or she has used
Andris
-----Original Message----- From: Pierangelo Masarati [mailto:ando@sys-net.it] Sent: Thursday, January 18, 2007 5:48 PM To: Eiduks Andris Cc: openldap-software@openldap.org Subject: Re: Ppolicy - password history
Andris.Eiduks@tietoenator.com wrote:
Hi,
I try password history checking in OpenLDAP 2.3.32 and change user password using LDAP browser.
When I enterer repaeted cleartext password then ppolicy returned expected decline "Password is in history of old passwords". But by password changing to any encrypted value ( the same password two and more times) OpenLDAP doesn't verify old password.
In log-file I found similar info about password changing for both cases:
Jan 18 13:25:15 KS-Test-1 slapd[5478]: acl: internal mod pwdHistory: modify access granted Jan 18 13:25:15 KS-Test-1 slapd[5478]: acl: internal mod pwdHistory: modify access granted Jan 18 13:25:15 KS-Test-1 slapd[5478]: bdb_modify_internal: delete pwdHistory Jan 18 13:25:15 KS-Test-1 slapd[5478]: bdb_modify_internal: add pwdHistory Jan 18 13:25:15 KS-Test-1 slapd[5478]: oc_check_allowed type "pwdHistory"
Slapd.conf : .... ....
moduleload ppolicy.la overlay ppolicy ppolicy_default "cn=std,ou=ppolicy,ou=users,ou=trm" ppolicy_hash_cleartext ppolicy_use_lockout
Encrypted values can't be decrypted to check history. Ppolicy needs the
cleartext password to save the history.
p.
Then do You recommend use only clearteaxt password from *client* side ?
And if *client" perform password encryption, then password history must be stored and compared by * client* side soft ?
Andris
-----Original Message----- From: Howard Chu [mailto:hyc@symas.com] Subject: Re: Ppolicy - password history
Andris.Eiduks@tietoenator.com wrote:
Hi,
Very strange, because ppolicy by parameter ppolicy_hash_cleartext store also encrypted password value. Then where is the problem store recieved ecrypted passwords and also check from pwdHistory this encrypted value?
The difference is that when the *server* encrypts it, it has a chance to
validate the cleartext first. When the *client* encrypts it, no such opportunity exists for the server.
Otherwise we have a problem with PCI DSS requirements:
8.4 Encrypt all passwords during transmission and storage on all system components.
The obvious solution to meet this requirement is to make sure that all connections are encrypted (using TLS, SASL, or IPSEC).
8.5.12 Do not allow an individual to submit a new password that is the
same as any of the last four passwords he or she has used
Andris
-----Original Message----- From: Pierangelo Masarati [mailto:ando@sys-net.it] Sent: Thursday, January 18, 2007 5:48 PM To: Eiduks Andris Cc: openldap-software@openldap.org Subject: Re: Ppolicy - password history
Andris.Eiduks@tietoenator.com wrote:
Hi,
I try password history checking in OpenLDAP 2.3.32 and change user password using LDAP browser.
When I enterer repaeted cleartext password then ppolicy returned expected decline "Password is in history of old passwords". But by password changing to any encrypted value ( the same password two and more times) OpenLDAP doesn't verify old password.
In log-file I found similar info about password changing for both cases:
Jan 18 13:25:15 KS-Test-1 slapd[5478]: acl: internal mod pwdHistory: modify access granted Jan 18 13:25:15 KS-Test-1 slapd[5478]: acl: internal mod pwdHistory: modify access granted Jan 18 13:25:15 KS-Test-1 slapd[5478]: bdb_modify_internal: delete pwdHistory Jan 18 13:25:15 KS-Test-1 slapd[5478]: bdb_modify_internal: add pwdHistory Jan 18 13:25:15 KS-Test-1 slapd[5478]: oc_check_allowed type "pwdHistory"
Slapd.conf : .... ....
moduleload ppolicy.la overlay ppolicy ppolicy_default "cn=std,ou=ppolicy,ou=users,ou=trm" ppolicy_hash_cleartext ppolicy_use_lockout
Encrypted values can't be decrypted to check history. Ppolicy needs the
cleartext password to save the history.
p.
Andris.Eiduks@tietoenator.com wrote:
Then do You recommend use only clearteaxt password from *client* side ?
Yes. Specifically, the client should always use the PasswordModify extended operation, it should not use LDAPModify on the userPassword attribute. (For one thing, there are no guarantees that a particular server even uses the userPassword attribute for anything.)
On Friday 19 January 2007 10:32, Andris.Eiduks@tietoenator.com wrote:
Then do You recommend use only clearteaxt password from *client* side ?
If you store encrypted passwords in userPassword, and do simple binds, you *have* to send the cleartext password to authenticate. Sending it to change passwords is no additional disclosure.
Of course, if you use simple binds, you want to protect the transport (TLS/SSL) anyway (e.g. require all connections to be of a sufficient ssf, or have the ACLs on userPassword require a sufficient ssf).
And if *client" perform password encryption, then password history must be stored and compared by * client* side soft ?
Yes, since the client could use different encryption types each time (and use the same password 3 or more times).
Regards, Buchan
openldap-software@openldap.org
-
Andris.Eiduks＠tietoenator.com -
Buchan Milne -
Howard Chu -
Pierangelo Masarati -
Sadique Puthen