IntenseWebs/freeipa
3
0
Fork 0
mirror of https://salsa.debian.org/freeipa-team/freeipa.git synced 2025-01-28 09:06:44 -06:00
Code Issues Packages Projects Releases Wiki Activity

Check for locked-out user before incrementing lastfail.

Browse Source 
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
This commit is contained in:
Rob Crittenden 2012-05-17 13:17:21 -04:00 committed by Martin Kosek
parent 46c6ff69ac
commit 560f2ce8bd
1 changed files with 6 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
daemons/ipa-kdb/ipa_kdb_audit_as.c
View File

@ -93,16 +93,18 @@ void ipadb_audit_as_req(krb5_context kcontext,
client->mask |= KMASK_FAIL_AUTH_COUNT;
}
if (client->last_failed + ied->pol->lockout_duration > authtime &&
(client->fail_auth_count >= ied->pol->max_fail &&
ied->pol->max_fail != 0)) {
/* client already locked, nothing more to do */
break;
}
if (ied->pol->max_fail == 0 ||
client->fail_auth_count < ied->pol->max_fail) {
/* let's increase the fail counter */
client->fail_auth_count++;
client->mask |= KMASK_FAIL_AUTH_COUNT;
}
if (client->last_failed + ied->pol->lockout_duration > authtime) {
/* client already locked, nothing more to do */
break;
}
client->last_failed = authtime;
client->mask |= KMASK_LAST_FAILED;
break;