69b1a5f On password reset also set krbLastAdminUnlock to unlock account

1 file Authored by rcritten 3 years ago, Committed by abbra 3 years ago,
    On password reset also set krbLastAdminUnlock to unlock account
    
    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>