https://bugzilla.redhat.com/show_bug.cgi?id=740527
Description of problem: The revocation error process is triggered not when maximum number of tries is reached but the next time after. This seems to have changed in Sun DS 6 and is considered the right behaviour and is required by customer applications. Example: say we configure 3 tries maximum for revocation, the flow is the following: 1st try: Invalid password 2nd try: Invalid password 3rd try: Invalid password 4th try and next : Revoked password Version-Release number of selected component (if applicable): 8.2 How reproducible: Always. Steps to Reproduce: 1. Define maximum number of login tries to 3 2. Login with wrong password until password is revoked 3. Actual results: 1st try: Invalid password 2nd try: Invalid password 3rd try: Invalid password 4th try and next : Revoked password Expected results: 1st try: Invalid password 2nd try: Invalid password 3rd try and next : Revoked password Additional info:
batch move to milestone 1.3
Reproduced:
ldapsearch -D "uid=scarter, ou=people,dc=example,dc=com" -w badpassword -b "dc=example,dc=com" uid=* ldap_bind: Invalid credentials (49)
ldapsearch -D "uid=scarter, ou=people,dc=example,dc=com" -w badpassword -b "dc=example,dc=com" uid=* ldap_bind: Constraint violation (19) additional info: Exceed password retry limit. Please try later.
We don't check if the account is locked until the bind comes in. We increment the retryCount during the backend processing. After the third failed bind the account is essentially locked. The fourth bind, even with the right password, will not work.
So it seems that the request is just to log a different error(19 instead of 49), even though the behavior is correct.
Continuing investigation...
Added a new config setting:
passwordLegacyPolicy: on|off
The default is "on" to keep existing customers from facing any regressions with their LDAP clients. If you turn it "off", we will log the appropriate error and message when the maxRetryCount is reached.
ldapsearch -D "uid=tmorris, ou=people,dc=example,dc=com" -w badpassword -b "dc=example,dc=com" uid=* ldap_bind: Constraint violation (19) additional info: Invalid credentials, you now have exceeded the password retry limit.
Please replace 19 with LDAP_CONSTRAINT_VIOLATION. Openldap folks may change the value any day. ;)
380 if(update_pw_retry( pb ) == 19 && !pwpolicy->pw_is_legacy){ 381 / 382 * If we are not using the legacy pw policy behavior, 383 * convert the error 49 to 19 (constraint violation) 384 * and log a message 385 / 386 err = 19;
Other than that, your fix/enhancement looks good.
attachment 0001-Ticket-183-passwordMaxFailure-should-lockout-passwor.patch
git merge ticket183 Updating c039fd4..396c932 Fast-forward ldap/servers/slapd/libglobs.c | 30 ++++++++++++++++++++++++++++++ ldap/servers/slapd/proto-slap.h | 1 + ldap/servers/slapd/pw.h | 2 +- ldap/servers/slapd/pw_retry.c | 38 +++++++++++++++++++++++--------------- ldap/servers/slapd/result.c | 10 +++++++++- ldap/servers/slapd/slap.h | 2 ++ 6 files changed, 66 insertions(+), 17 deletions(-)
git push origin master Counting objects: 21, done. Delta compression using up to 4 threads. Compressing objects: 100% (11/11), done. Writing objects: 100% (11/11), 1.92 KiB, done. Total 11 (delta 9), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git c039fd4..396c932 master -> master
subentry password policy support 0001-Ticket-183-passwordMaxFailure-should-lockout-passwor.2.patch
ack
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=834060
Added initial screened field value.
Metadata Update from @mreynolds: - Issue assigned to mreynolds - Issue set to the milestone: 1.2.11
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/183
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Login to comment on this ticket.