We are looking to implement the lock out policy
Is there a way to manually unlock a user?
Right now it seems if they lock there account it has to wait until it unlocks by the system. When you go to the user account the Locked check box is grayed out.
Thank you…I don’t know why I didn’t think of looking under actions…I know better.
I don’t know. A checkbox is an active control. If I kept the unlock function on the menu, I’d use a shape instead of a disabled checkbox to indicated the lock-out status - maybe with a number of tries in it to see if someone was hammering that account.
Mark W.
There is also an unlock on admin console as a failsafe if your admin accounts are locked out.
THANKS 
How is the account duration typically used? We want to have the system lock them out forever after 5 failed attempts where they need to contact the service desk to get unlocked. Even if I set the duration value to zero it keeps the user locked out, but also does not provide them a prompt at un-successful login attempt that they are even locked out. Whats funny as well is even if I fail login like 27 times in a row and the user ID shows locked out, I can then put in the correct password and get into Epicor and the system automatically removes the lock on the account. Am I the only one that thinks that is either a logic flaw a bug or just a flat out bad design??
10.2.300.22 currently
So in your Lockout Policy, you determine how lockout works. You don’t want people hammering on passwords to guess so the lockout policy determines how stringent you want to be.
The user gets locked out after Number of Threshold Attempts + 1. You can then reset the attempts counter after a certain amount of minutes. But I think the account remains locked - bu t I may be wrong about that. Incremental Lockout keeps doubling the seconds between attempts up to the Threshold count.
The Reset Counter After allows the user to wait and then reset the counter.
The balance you want to make is to make it hard for people to guess but give users a chance not to get locked out.
What are your Lockout Policy settings?
Mark W.
correct. We have 5, 30 and 0. and even if we change the Lockout duration from 0 > 1min the result is essentially the same. the user hits failure #6, gets locked out. if duration is at 0, they don’t get a prompt that they are locked out. the user id screen shows they are locked out, but if they enter the correct password then they get into Epicor fine and the system removes the lock.
if duration is set at 1 min, they DO get a prompt that they have to wait 1 min before making more attempts. but at attempt #7, they can enter the correct password and the same above applies. they get into Epicor just fine, and the system removes the lock.
Currently this isn’t going to fly with our auditors. Even if we set the lockout duration to 1 hour or 24 hours, it still seems not very secure. Someone could just try to hack the password every 1 hour. and if they guess the password correctly, then the user gets logged into Epicor and the system auto-removes the lock. It just seems to me as though once the user is locked, they are locked forever if the duration is set to 0. But currently the logic is: the user is locked, or it shows they are locked. but if they happen to get the correct password then surprise, they are now into your system and the lock is removed. that seems very flawed to me.
Yeah, I would probably report that.
I sure did! Thank you for the quick feedback though!
@Drozy2017 - do you see the ability to login with the correct password (after it’s been “locked”) with all users? Or just yourself.
And is your user account a Sec Manager? I see lots of security settings get totally ignored if the user is s Sec Manger. Maybe this is another one of them - which would be a horrible idea, because it would allow brute forcing an account with the highest privileges.
both security manager and non security manager, yes.
I took a random non-security manager user id in my test environment and used that as the test case.
The timeout between attempts is designed to counter an automated process attempting to brute force passwords in my thinking - if there are 2 services, one which has the timeout and one which doesn’t, the latter is way more attractive to try and crack. With even a small timeout, it would take many years to crack a password using brute force, by which time the password would have hopefully changed (due to p/w change policy).
The way the OP described it, it sounds like the “lockout” isn’t actually locking out the account. But rather locking out the ability to attempt a login. Consecutive failed attempts are a good indicator of an unauthorized login attempt. When that happens, that user/pw should not be allowed to ever login in (at least not through the front door)
And brute force attacks aren’t always just a sequential or dictionary attack. If you had an old password for the user, and say it was Pa$$word, you might try Pa$$word1, Pa$$word2, Pa$$word!, etc…
There was an earlier thread that linked to a NIST article about forcing password complexity actually makes them less secure, as the “new” password is usually just the old one with a number after it.
yep I agree with the comments. But if the timeout between attempts value is the major counter to attacks, then why is there even a lock out value for the user ID if the user could just eventually remember the correct password and get in and then boom, they aren’t locked out again. Epicor has responded saying that this is by design. Pretty much what is said above: just increase the timeout duration. However in my career, locked out means locked out. Not locked out unless you magically use the correct password or remember it hours later and then we let you in anyway and remove the lock out flag on your account. I don’t know… the logic just seems kind of silly. You should just get 5 attempts and then get locked out. Period.
But based on the ticket response from Epicor this is all by design and its either move to SSO with Active directory or increase the timeout duration value to something extreme like hours or days essentially forcing the user to call to get unlocked.
“it sounds like the “lockout” isn’t actually locking out the account. But rather locking out the ability to attempt a login.”
Not really. locking out the ability to attempt a login is the duration value. The lockout flag just seems like a flag to me as an indicator at this point. Your user is having trouble logging in = go open up the user ID and look for the failed login attempts and the lockout flag. its just a flag that they have exceeded the set number of attempts. Again, the behavior I can demonstrate is that the user can be locked out, but I can still enter the correct username and pw combo and log into the system just fine, and then Epicor automatically removes the lockout flag.
Okay … either way, it’s not “locking out” the account from being used.
