diff options
author | Rob Crittenden <rcritten@redhat.com> | 2012-05-17 13:17:21 -0400 |
---|---|---|
committer | Martin Kosek <mkosek@redhat.com> | 2012-05-18 09:03:22 +0200 |
commit | 560f2ce8bd0525189e45ff7d8f8d4df11f9c20ff (patch) | |
tree | de640799d78eafb243d9daf4cf6ae7aad8bef3a3 /ipaserver | |
parent | 46c6ff69ac2a4fa39e99f954bd9cfbd78bfd70c9 (diff) | |
download | freeipa-560f2ce8bd0525189e45ff7d8f8d4df11f9c20ff.tar.gz freeipa-560f2ce8bd0525189e45ff7d8f8d4df11f9c20ff.tar.xz freeipa-560f2ce8bd0525189e45ff7d8f8d4df11f9c20ff.zip |
Check for locked-out user before incrementing lastfail.
If a user become locked due to too many failed logins and then were
unlocked by an administrator, the account would not lock again. This
was caused by two things:
- We were incrementing the fail counter before checking to see if the
account was already locked out.
- The current fail count wasn't taken into consideration when
deciding if the account is locked.
The sequence was this:
1. Unlocked account, set failcount to 0
2. Failed login, increment failcount
3. Within lastfailed + lockout_duration, still locked. This skips
update the last_failed date.
So I reversed 2 and 3 and check to see if the fail count exceeds policy.
https://fedorahosted.org/freeipa/ticket/2765
Diffstat (limited to 'ipaserver')
0 files changed, 0 insertions, 0 deletions