#183 passwordMaxFailure should lockout password one sooner - and should be configurable to avoid regressions
Closed: wontfix None Opened 9 years ago by rmeggins.

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: Invalid credentials (49)

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.

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

Added initial screened field value.

Metadata Update from @mreynolds:
- Issue assigned to mreynolds
- Issue set to the milestone: 1.2.11

4 years ago

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.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)

a year ago

Login to comment on this ticket.

Metadata