summaryrefslogtreecommitdiffstats
path: root/ipaserver
diff options
context:
space:
mode:
authorRob Crittenden <rcritten@redhat.com>2012-05-17 13:17:21 -0400
committerMartin Kosek <mkosek@redhat.com>2012-05-18 09:03:22 +0200
commit560f2ce8bd0525189e45ff7d8f8d4df11f9c20ff (patch)
treede640799d78eafb243d9daf4cf6ae7aad8bef3a3 /ipaserver
parent46c6ff69ac2a4fa39e99f954bd9cfbd78bfd70c9 (diff)
downloadfreeipa-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