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

On password reset also set krbLastAdminUnlock to unlock account

Browse Source 
This fixes the case where an account is locked on one or more servers
and the password is reset by an administrator. The account would
remain locked on those servers for the duration of the lockout.

This is done by setting krbLastAdminUnlock to the current date and
time. The lockout plugin will see this and unlock the account. Since
the value should be replicated along with the password any server
that has the new password will also be unlocked.

This does incur an additional attribute that must be replicated,
whether it is needed or not, but since lockout is computed
per-server this is the only guaranteed way to be sure that the
account will be unlocked everywhere.

My original thought was to grab password replication events and detect
whether the user was locked out and unlock them. On any given server
you can only know if the user is locked out on that server by
computing it. Doing this would require generalizing the lockout code
so it could be computed on password change. krbLastFailedAuth could
be wiped which would unlock the account on that master (the attribute
is not replicated by default).

So it is complexity vs additional replication. Assuming that admin
reset is relatively rare let's start with that. This doesn't lock
us into this solution for the future.

We could set this attribute on user-driven password changes as
well but the original ask and my thinking are that if you forgot
your password and got locked out, how can you change it yourself?
Upon reflection I guess a user could fat-finger it a bunch of times
against one IPA server then have a revelation and log in against a
different server. So they would still be locked out for the duration
on the first one. I'm not sure the extra replication is worth it for
user-generated password changes or that users would be saavy enough
to try another server for the change.

https://pagure.io/freeipa/issue/8551

Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
This commit is contained in:
Rob Crittenden 2020-10-21 18:26:56 -04:00 committed by Alexander Bokovoy
parent b153b23c75
commit 3ab3578b36
1 changed files with 14 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
daemons/ipa-slapi-plugins/ipa-pwd-extop/common.c
View File

@ -855,6 +855,20 @@ int ipapwd_SetPassword(struct ipapwd_krbcfg *krbcfg,
data->expireTime, (data->expireTime == 0));
if (ret != LDAP_SUCCESS)
goto free_and_return;
switch(data->changetype) {
case IPA_CHANGETYPE_DSMGR:
case IPA_CHANGETYPE_ADMIN:
/* Mark as administratively reset which will unlock acct */
ret = ipapwd_setdate(data->target, smods,
"krbLastAdminUnlock",
data->timeNow, false);
if (ret != LDAP_SUCCESS)
goto free_and_return;
break;
default:
break;
}
}
}