We’re running Ignition 8.0.6. Users login to our Perspective projects through the built-in ID provider referencing back to a manual-mode user DB.
One of our employees couldn’t login. He then asked an admin to reset his password, who did, but he was still unable to login.
I came by 20+ minutes later and reset the password and he was able to login just fine.
Looking back through the server log, I see lines like this around the time of his original login and the attempts just after the admin reset it:
INFO | jvm 1 | 2019/12/03 17:28:00 | I [U.DB_ManualMode ] [17:28:00]: User 'xxx' is now locked out route-group=authn, route-path=/submit-username-password-challenge/:client-id
INFO | jvm 1 | 2019/12/03 17:31:53 | I [U.DB_ManualMode ] [17:31:53]: User 'xxx' is locked out route-group=authn, route-path=/submit-username-password-challenge/:client-id
INFO | jvm 1 | 2019/12/03 17:33:08 | I [U.DB_ManualMode ] [17:33:08]: User 'xxx' is locked out route-group=authn, route-path=/submit-username-password-challenge/:client-id
INFO | jvm 1 | 2019/12/03 17:34:11 | I [U.DB_ManualMode ] [17:34:11]: User 'xxx' is locked out route-group=authn, route-path=/submit-username-password-challenge/:client-id
I found the lockout settings on the user DB page, and assume that must be what was going on. I’ve searched the manual and forums for more details on the lockout feature, but I’m not finding anything.
Is there anything an admin could have done to reset the lockout period and allow him to login sooner?
The only way to immediately clear the lockout is to disable lockout on a user source profile and save. You can then immediately re-enable the lockout and save (if you wish to keep it enabled). This clears all current lockouts for all users for the user source profile.
There is no feedback to the user that login failures are due to a locked account. This is a poor UX. Can we add another feature to the backlog to fix that?
Is this still the only way to disable a lockout for a single user - to make the disable lockout for the entire user source and then re-enable? Or is there a way to do it on an individual basis now? Not a big deal just curious.
This is still the only way. We do have an internal ticket tracking an effort to add a user interface to view currently locked out users and unlock them on a more fine-grained basis (IGN-5298), but it has yet to be spec’d and designed, so it will probably be a while until it is fully implemented…
FWIW in the gateway logs it will tell you when a user get’s locked out and what IP address the sign-in attempts came from - this helped me realize it was just from my employee’s computer and not some outside source and so nothing to be too worried about.
I agree with your other points though. A way to lock or unlock a single user instead of the user-source wholesale is definitely the right way to do this sort of thing. I imagine a case where one user is legitimately locked out due to an outside IP address trying to brute force a password, and another user just accidentally messed up a few times. I wouldn’t want to unlock the first user, but would want to unlock the second user.