I have a internet facing gateway that is used for office processes.
This morning, I had an issue where an employee wasn’t able to login because they had locked themselves out due to excessive login attempts. As far as I know the only way I can unlock them out is to turn off the lockout feature and the turn it back on.
I do see the occasional unrecognized IP address attempting to login so I would prefer not to turn lock off off/on and reset attempts for everyone, which would give nefarious actors additional attempts. Is there a way to only unlock a specific account instead of doing it whole sale and resetting all attempts for everyone in the user source?
If not I am asking this as a requested feature as though its not a big deal for gateways that are completely isolated, for the internet facing gateway I manage it’s a more important thing not to give more opportunities to external actors than absolutely necessary.
According to the docs you just need to hit save on user source page.
Lockout Enabled
Lock out a user's account after more than the maximum allowed number of failed authentication attempts occur within the lockout window. Default is true.
Note that access can be restored to all locked out users by editing the user source, and clicking the Save Changes button.
Lockout Attempts
Maximum number of failed authentication attempts allowed within the lockout window before locking the user out. Default is 5. If this value is set to something less than zero (for example, -1), then the lockout functionality will be entirely disabled, regardless of what the Lockout Enabled property is set to.
Lockout Window
The duration of the lockout window in minutes. Default is 15. Setting this property to a value of less than zero (for example, -1) will disable the lockout functionality entirely, regardless of what the Lockout Enabled property is set to.
https://docs.inductiveautomation.com/display/DOC81/Classic+Authentication+Strategy
1 Like
That is how I fixed it earlier yes.
However,
This is what I don't want though. I want to specify exactly who I want to unlock due to the public nature of my gateway.
If the company is that afraid of 5 more external retry attempts, than they should make better paswords.
It’s about not providing an additional 5 attempts unnecessarily. Strong passwords will still be cracked if enough attempts are allowed. My gateway only experiences minimal invasive attempts so risk is minimal but its very easily conceivable that online facing gateway is frequented more than mine and has more external attacks and this would be a bigger issue.
Other login management systems let you do it on a user basis like Active Directory, so it’s not like I am asking for something brand new just for ignition, only to mimic the existing user management systems that Ignition already interfaces with.
A good password is not bruteforceable in a human lifespan even without a delay in between attempts, even with a one second delay it would take billions of years to crack a 13+ symbol psw.
That one time 5 attempts is insignificant
Would be easier to enforce that if I had a small userbase but I inherited this program with thousands of existing users who chose their own passwords.
I’m don’t think I am asking for much just to expose what they’re already tracking internally. Ignition already is obviously tracking in the background which specific users are locked out as those are the only ones who get locked out when logging in. I don’t see the big issue with exposing that list to the gateway administrator so I can unlock only the appropriate user.
Plus I think it would be a good thing to be able to see the current list of all people locked out - it would let me know what accounts may be compromised - currently I only see who’s locked out if one of the users who uses it daily complains or I happen to see it in the logs.
Unlocking a single user is doable in a pure python program that interfaces with a active directory or alternative user source. I really don’t see any good argument why a platform as powerful as Ignition shouldn’t allow this given other (probably less complex) applications allow this.
1 Like
This i agree with.
You might find something in here
This is a function isLockedOut(java.lang.String user)
https://files.inductiveautomation.com/sdk/javadoc/ignition81/8.1.15/com/inductiveautomation/ignition/gateway/user/LockoutTrackingUserSourceProfileKernel.html
At first sight, loginattempts seem to be saved in memory and not in a database.
It seems to be working with timestamps, and there is no way to remove things from the list only adding, except by restarting the user service (by saving)
So its not something igntion already has prepared.
4 Likes
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 not yet been spec’d and designed. I went ahead and linked this forum thread to that ticket for tracking purposes.
2 Likes
Great thank you.
@victordcq ah interesting. I guess I would have assumed it was in the internal database. So a gateway restart or shutting down the server completely and restarting it would also undo lockouts since its only in memory and not stored in the internal db?
Yes it does seem like that would be the case.
Just seeing if there is any update on this.
My internet facing gateway (and company's network at large) has recently been under more probing attempts by outside actors and a few users I see are getting locked out in my logs from unknown IP addresses. Today I had a coworker legitimately get locked out so I had to unlock everyone just to let her in. This feature is pretty important for me and I assume anyone with a internet facing gateway.
1 Like