Bug 1784592

Description of problem:

After a number of (usually three) failed login attempts to an application server managed by a group of IDM/LDAP servers, the authentication server handling this user session locks the user account. But it does not replicate this lockout to other authentication servers in the domain. And so users experience inconsistent behavior during login, depending on which server handles any login attempt.

When the IdM infrastructure gets into this inconsistent state, the only fix is to check each IdM server,  login as admin to any server where the user account is locked, and unlock it for that IdM server only.

Version-Release number of selected component (if applicable):
RHEL 7, RHEL 8

How reproducible:
At will

Steps to Reproduce:
1. Set up an IdM environment with a number of IdM servers. Set up a user account with a policy to lock that account after three login failures.
2. Try three times to login as that user with an incorrect password.
3. The IdM server handling the logins locks the user account.
4. The other IdM servers do not lock the user account.

Actual results:
See above - the IdM server handling the failed login attempts eventually locks the user account. But it does not replicate.

Expected results:
When an authentication server decides to lock a user account, *all* authentication servers in the domain should lock that user account.

Additional info:
The article at https://access.redhat.com/articles/3327351 makes a case that it's impractical to replicate login failure counts across authentication servers. Fair enough. However, it is still necessary to replicate actions such as account lockouts and password updates. Perhaps instead of replicating individual events, it might make sense to replicate overall state periodically. This is how other domain authentication systems handle these situations.