A User Cannot Sign In: Causes and Fixes

When a user cannot sign in, the login screen gives one generic message for every failure, and the real cause is a bad password, a deactivated account, or a lockout. EDGEBIC by User Solutions never reveals whether a username exists at the login prompt, so diagnosis starts on the Users grid in Settings, Security, where the Active, Locked, and Last login columns distinguish the cases the login screen deliberately blurs.

This post is the detailed version of the sign-in symptom in the EDGEBIC troubleshooting guide. For the wider access model, what an effective permission is covers what happens after a successful sign-in.

What You Are Seeing

A user types their credentials and gets "Invalid username or password." They retype carefully, possibly several times, and get the same message. Other users on the same workstation sign in without trouble. After a handful of attempts the user may report that the account seems to stop responding entirely for a while.

The message is identical in every one of these cases by design. It does not distinguish a typo from a deactivated account from a lockout, because distinguishing them would tell an attacker which usernames are real.

Why It Happens

Cause 1: The password is genuinely wrong. This remains the most common cause and is worth confirming before anything else. Keyboard layout, caps lock, and a trailing space pasted from an email all produce it.

Cause 2: The account is deactivated. Deactivating a user is the normal way to remove access for someone who has left or moved roles, and it is preferred over deleting because it preserves their history in the audit trail. A deactivated account authenticates against the same generic message, so the user has no way to tell.

Cause 3: The account is locked out. After a run of failed attempts, the account is locked for a fixed window. The default policy is five failed attempts followed by a fifteen minute lockout, and the failed attempt counter resets when the lockout is applied. A user who keeps hammering the login screen during the window simply extends their own frustration.

Cause 4: The username does not exist. A typo in the username, or an account that was deleted rather than deactivated, produces the same message. The Users grid settles it: if the name is not in the list at all, that is your answer.

Cause 5: A password policy change stranded an old password. Policy rules, such as a minimum length or a required non-alphanumeric character, are enforced when a password is set or reset. They are not applied retroactively to stored passwords, so tightening the policy does not lock anyone out by itself. It does mean that when the user next needs to set a password, the old style will be rejected, which can look like a policy-caused failure if the timing lines up with a reset.

How to Fix It

1. Open Settings, Security, Users and find the account. If the username is not in the list at all, that is the answer: a typo, or an account that was deleted rather than deactivated. A deleted account has to be recreated, and the recreated account will not carry the original's history.
2. Read the Locked column. If the account is locked, select the user and click Unlock. That clears the lockout immediately rather than making them wait out the window.
3. Read the Active column. If the account is inactive, use Activate / Deactivate to restore it. Reactivation restores access without recreating the account, so roles and history stay intact.
4. If Active and Locked both look normal, treat it as a wrong password. Click Reset password, set a compliant temporary value, and require a change at first sign-in so the user chooses their own.
5. Use Last login as the tiebreaker. A recent successful session says the account itself is healthy and the problem is at the keyboard.
6. Re-test with the user present. Watching the attempt catches caps lock, keyboard layout, and copy-paste whitespace faster than any record will.
7. Ask for a security trail extract only if the detail must be on record. Every attempt is written to the append-only security trail in the database, which your administrator or support can query. That is worth doing when the attempts arrived outside the person's shift, and unnecessary when you just needed them working again.

How to Prevent It

• Deactivate rather than delete when someone leaves. Deactivation is reversible, keeps the audit trail intact, and makes the eventual "why can this person not sign in" question answerable in seconds.
• Tell users to stop after two failed attempts and call. Continuing past the limit converts a thirty second password reset into a fifteen minute wait for no benefit.
• Tune the lockout policy to your risk, then document it. Five attempts and fifteen minutes is the default. A shop with shared shop floor terminals may want a longer window, an office environment may want a shorter one. Whatever you pick, put it in your onboarding notes so the help desk is not guessing.
• Communicate password policy changes before you make them. A tightened rule applies at the next set or reset, so warn users rather than letting them discover it during an urgent password change.
• Make the Users grid the first stop, not the last. Active, Locked, and Last login answer this in seconds, and reading three columns takes less time than reasoning backward from the generic message. If sign-in works but the user then cannot reach a screen, a tab I expect is missing and a permission change did not take effect cover those cases, and user and permission mistakes catalogs the rest.