#8250 When one IdM server in a domain locks/unlocks an account, all IdM servers in the domain should lock/unlock that account
Opened 4 years ago by pcech. Modified 4 years ago

Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 8): 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.

Metadata Update from @pcech:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1784592

4 years ago

Login to comment on this ticket.

Metadata