#2792 [RFE] Allow quering user lock status
Opened 11 years ago by dpal. Modified 5 years ago

In the UI probably in the details page there should be some kind of place when admin can click to see what is the status of the current user in terms of lockout. I see it as a subsection that expends in a list that contains following columns:

Name      Status       Failed attempts   Will unlock in 
replica1  Unlocked     0                 
replica2  Unlocked     2
replica3  Locked       3                 3 hours 26 minutes 16 sec

The locked status will be a clicable link that will pop up a confirmation dialog and would allow user to unlock the user on the specific server.
There should also be a refresh button to reacquire the status from the servers.
If replica can't be accessed it should say "Unreachable".
This should be a link to and clicking this link would act as refresh of this specific replica status.


Worth testing this with anonymous disabled in one or more of the replica servers to be sure we still get status.

Changing 3.2 priority

Web UI can't unlock locked accounts on different replicas until #3863 is implemented.

Moving back to Needs triage. Either #3027 Replicate account lockout or #3863 user-unlock command should unlock user accounts on other replicas too is required for this.

There are actually three server side tickets which can solve the issue, each in slightly different way:

  • 3027 Replicate account lockout

  • 3863 user-unlock command should unlock user accounts on other replicas too

  • 3700 [RFE] Failed login replication

As it seems, from looking at ticket history, #3700 was(is?) the preferred solution.

The UI proposed in this ticket requires just #3863 in order to work.

Solutions proposed in #3027 and #3700 make the UI simpler. 'user-status' command doesn't have to be used because lockout/failed login information is replicated and therefore same on each replica. The resulting UI enhancement could be:

  • new row in user account section: 'Locked out: Locked/Unlocked'
  • new action in user account section action panel: 'Unlock account'. This action would call user-unlock command.

Downside of #3700 is that the enhancement can be configured to be disabled. Thus the simple UI won't be reliable and a need for the original UI proposal and hence also #3863 reappears.

Replying to [comment:11 pvoborni]:

There are actually three server side tickets which can solve the issue, each in slightly different way:
#3027 Replicate account lockout
#3863 user-unlock command should unlock user accounts on other replicas too
* #3700 [RFE] Failed login replication

There are two options. Replicate the lockout (configurable). If configured the lockout will be replicated and thus unlock will be replicated too. If it is not replicated then one should be able to list and manage lock status per replica as listed in the tickets. The point is that we need to do both rather than one or another. I do not see a reason to re-triage.

3.4 development was shifted for one month, moving tickets to reflect reality better.

Adjusting time plan - 3.4 development was postponed as we focused on 3.3.x testing and stabilization.

Adjusting time plan - 3.4 development was postponed as we focused on 3.3.x testing and stabilization.

We do not even have the backend solving this issue, moving Web UI part to backlog then.

I am moving #3863 out of FreeIPA 4.0 release, but let me keep this RFE here so that we can support at least unlock operation on current replica.

This RFE contained 2 use cases which are not dependent on each other and which will end in different releases. I created #4407 which aims to add Unlock button to UI.

This RFE stays to provide user-status command on all replicas. Moving to release 4.3 to other similar tickets (#3700 and others).

Metadata Update from @dpal:
- Issue assigned to pvoborni
- Issue set to the milestone: FreeIPA 4.5 backlog

7 years ago

#4407 is closed so one can unlock a user on a single IPA master via the UI.

Metadata Update from @rcritten:
- Issue close_status updated to: None

5 years ago

Login to comment on this ticket.

Metadata