> For the complete documentation index, see [llms.txt](https://docs.openiam.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openiam.com/administration-guide/security/cannot-sign-in.md). # A user cannot sign in Triage a sign-in failure by what the user actually sees, from a refused password to a second factor that never prompts, and know which page fixes each cause. ## What this is, and when you need it Somebody cannot get in and you have their name, not a log line. This page starts from **what the user sees on their screen** and routes to the page that explains that cause. It covers one person locked out, and the case where nobody can sign in at all, which is a different problem with different evidence. Two facts shape every case here. OpenIAM deliberately **never says which half of a sign-in was wrong** — `Invalid Login and/or Password` is returned for an unknown login, a wrong password and a locked account alike, so the message is not evidence that the account exists. And **lockout is not on the password policy**: `FAILED_AUTH_COUNT` and `AUTO_UNLOCK_TIME` live on the *authentication* policy, which ships as `4001`, while composition and expiration live on password policy `4000`. ## Triage by what the user sees | What the user reports | Usually | Go to | | ----------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | *"It says my login or password is wrong"*, and they are sure it is not | The account is locked, the identity does not exist on the managed system that authenticates them, or the password has expired | [The password is refused](#the-password-is-refused) | | *"It let me in and then said I had to change my password"* | Expected. The password expired, or the account was reset and is in `PENDING_INITIAL_LOGIN` | [Password policy](/administration-guide/security/password-policy.md#expiration-warning-and-grace-are-three-separate-parameters) and [Run a user lifecycle action](/administration-guide/identities/user-lifecycle-actions.md) | | *"It never asks for my code"*, when a second factor is configured | The matched URI pattern carries its own rule, so the content provider's rule is not consulted | [The Authentication model, When it goes wrong](/administration-guide/security/authentication-model.md#when-it-goes-wrong) | | *"It demands a method I have never set up"* | A step-up or adaptive rule reached a step this user cannot satisfy. That is a lockout, not a prompt | [Step-up authentication](/administration-guide/security/step-up-authentication.md#what-the-user-experiences) | | *"I signed in and got a permission error"*, a `403` | Entitlement, not authentication. They authenticated and are not entitled to the resource | [The Authentication model, When it goes wrong](/administration-guide/security/authentication-model.md#when-it-goes-wrong) | | *"Forgot password does nothing"*, or the reset mail never arrives | The recovery path is not reachable, the token expired, or mail is not being delivered | [Configure password recovery and account unlock](/administration-guide/security/password-recovery.md#when-it-goes-wrong) | | *"The help desk cannot verify me"* | Caller verification ran out of answers or out of attempts | [Verify a help-desk caller](/administration-guide/security/helpdesk-verification.md#when-it-goes-wrong) | | *"My smart card stopped working"* | Lockout is evaluated before the certificate is, and a failed certificate increments the same counter a wrong password does | [Certificate authentication](/administration-guide/security/certificate-authentication.md#what-the-idp-flow-does-in-order) | | *"The login page keeps reloading"* | A cookie-name or content-provider problem on the sign-in path, not a credential problem | [Troubleshoot the Access Gateway](/administration-guide/gateway/troubleshoot-the-gateway.md#symptom-cause-fix) | | **Nobody** can sign in, and it survived a restart | The UI has no cached authentication provider and no default to fall back on | [Nobody can sign in](#nobody-can-sign-in) | | The administrator locked themselves out changing an authentication rule | There is no in-product way back | [Keep a working way in](/administration-guide/security/authentication-providers-and-mfa.md#keep-a-working-way-in) | ## The password is refused Work through these four in order. The first three are read-only. **Is the account locked?** Lockout is a *secondary* status — `LOCKED` after too many failures, or `LOCKED_ADMIN` when an administrator set it — and it is separate from the user's status. The threshold is `FAILED_AUTH_COUNT` and the automatic release is `AUTO_UNLOCK_TIME`, both on authentication policy `4001`; neither is on the password policy. Confirm which policies the provider is using on **Access Control → Authentication Providers**, and look up the parameters in [Password and authentication policy parameters](/administration-guide/reference/policy-parameters.md#authentication-policy-4001). The audit trail is `INCREMENT_FAIL_AUTH_COUNT` per failure and `USER_ACCOUNT_LOCKED` when the threshold is crossed, at **Administration → Log Viewer**. **Is the identity in a status that cannot sign in?** Only two of the 21 statuses permit a sign-in at all: `ACTIVE` and `PENDING_INITIAL_LOGIN`. Every other status is refused before the password is even considered, and so is any user whose *secondary* status is `DISABLED`, `LOCKED` or `LOCKED_ADMIN`. Read the status and the secondary status back off the record rather than from search. {% hint style="warning" %} **"Counted as active" is not "can sign in".** `org.openiam.ui.webconsole.active.user.status` ships `ACTIVE,LEAVE,LEAVE_OF_ABSENCE,LEAVE_WITH_PAY,PENDING_INITIAL_LOGIN`, so the Webconsole's screens treat somebody on leave as an active user — but a user in `LEAVE`, `LEAVE_WITH_PAY` or `LEAVE_OF_ABSENCE` cannot sign in, and returning them to service is the **Active** lifecycle action, not a property change. Prove it on a disposable identity before you argue with a manager about it. The two lists are in [User lifecycle reference](/administration-guide/reference/user-lifecycle-reference.md). {% endhint %} The same status check applies to a session already in progress: renewal re-checks it on every request and refuses, logging *"RenewToken: user status failed for userId = %s"* in the ESB log — [What an OpenIAM session is, and what ends one](/administration-guide/security/session-management/session-management-reference.md#the-users-account-stops-being-usable). This is the first thing to check for anybody who was recently offboarded, see [Offboard a leaver end to end](/administration-guide/lifecycle/offboard-a-leaver.md). **Does the identity exist on the managed system that authenticates them?** The ESB logs `Data Key is null. Skipping decryption...` when it is asked to decrypt a value it holds no data key for, and the commonest cause is a sign-in attempt for an identity that does not exist. Read the user's **Identities** on their record; a person can exist in OpenIAM and hold no login on the default managed system. **Has the password expired, or was the account reset?** Expiration, the warning window and the grace period are three separate parameters on the password policy and interact — [Password policy](/administration-guide/security/password-policy.md#expiration-warning-and-grace-are-three-separate-parameters). An account that has had **Reset Account** run against it is in `PENDING_INITIAL_LOGIN` with its password, security questions and secret word all cleared, which is not recoverable by the user's old credential: [Run a user lifecycle action](/administration-guide/identities/user-lifecycle-actions.md). ## Nobody can sign in This is a different problem, and the evidence is in the UI service log rather than on the user. Repeating `FATAL ERROR. No Authentiation Provider was found for the current HTTP Request. There is also no any default providers in DB also.` that survives a restart means this UI instance has no authentication provider cached for the request and no default to fall back on — typically because a provider sweep ran while the ESB was unreachable. The diagnosis and the way out are on [Troubleshoot the Access Gateway](/administration-guide/gateway/troubleshoot-the-gateway.md#no-authentiation-provider-was-found-what-actually-broke), and the short answer is also in [Gateway, SSO and federation](/administration-guide/faq/gateway-and-federation.md). Two neighbours produce the same "nobody can get in" report and are not this: * **A login loop on `/idp/login`**, which is a mismatch between the cookie name the proxy reads and the content provider's **Authentication Cookie Name** — [Troubleshoot the Access Gateway](/administration-guide/gateway/troubleshoot-the-gateway.md#symptom-cause-fix). * **A rule change that reached a step nobody can satisfy.** Detach the rule; do not edit the graph while people are locked out. The break-glass path is [Keep a working way in](/administration-guide/security/authentication-providers-and-mfa.md#keep-a-working-way-in), and the gateway's own version is [Recovering from a lockout](/administration-guide/gateway/troubleshoot-the-gateway.md#recovering-from-a-lockout). ## Getting one person back in now | What you need to do | The supported path | | ------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Let the user recover their own password | The **Forgot your password?** flow, if it is configured and reachable — [Configure password recovery and account unlock](/administration-guide/security/password-recovery.md) | | Have a technician verify the caller and reset for them | [Verify a help-desk caller](/administration-guide/security/helpdesk-verification.md), then the reset action — the service-desk grant is [Giving a service desk the reset-password action](/administration-guide/security/helpdesk-verification.md#giving-a-service-desk-the-reset-password-action) | | Clear a lock an administrator set | The user's secondary status on their record — [Run a user lifecycle action](/administration-guide/identities/user-lifecycle-actions.md) | | Re-enable an identity that was disabled or terminated | Reverse the lifecycle action on the record. Memberships removed rather than end-dated do not come back — [Run a user lifecycle action](/administration-guide/identities/user-lifecycle-actions.md) | | Re-enrol a second factor the user has lost | [Add TOTP as a second factor](/administration-guide/security/totp.md), [FIDO2 and WebAuthn](/administration-guide/security/fido2-and-webauthn.md#recover-a-lost-replaced-or-compromised-authenticator) | | Recover the built-in administrator | [Recovering the built-in administrator](/administration-guide/security/password-recovery.md#recovering-the-built-in-administrator) | ## The evidence to collect before you change anything Take these in this order; each one narrows the cause without changing the system. 1. **The exact string on the user's screen**, and the exact time. Match it in [Error and symptom index](/administration-guide/error-and-symptom-index.md). 2. **The audit trail for that user** at **Administration → Log Viewer**: `LOGIN`, `DO_LOGIN`, `DO_LOGIN_AGAINST_MANAGED_SYSTEM`, `INCREMENT_FAIL_AUTH_COUNT` and `USER_ACCOUNT_LOCKED`. A `DO_LOGIN` with no `LOGIN` and a run of `INCREMENT_FAIL_AUTH_COUNT` tell different stories — [Find audit evidence](/administration-guide/operations/find-audit-evidence.md). 3. **Which rule the path resolved to.** `/webconsole/authenticationDebug` reports how the request was evaluated, which settles "the second factor never prompts" in one step — [The authentication model](/administration-guide/security/authentication-model.md#how-a-request-selects-a-rule). 4. **The user's status, secondary status and identities**, read back off the record rather than from search: search is served from an index and can disagree with the record. 5. **Whether it is one person or everybody.** One person is a credential, a status or an entitlement; everybody is a provider, a content provider or a rule. {% hint style="info" %} **A change to an authentication rule or provider does not take effect immediately.** Provider and rule caches sweep on `org.openiam.auth.provider.sweep.time` (60 s), so re-test after a minute before concluding a fix did not work — [Caches, and why your change has not taken effect](/administration-guide/security/authentication-model.md#caches-and-why-your-change-has-not-taken-effect). {% endhint %} ## Related * [The authentication model](/administration-guide/security/authentication-model.md) — the five objects, and which one a symptom belongs to * [Configure password recovery and account unlock](/administration-guide/security/password-recovery.md) — the self-service way back in * [Verify a help-desk caller](/administration-guide/security/helpdesk-verification.md) — the assisted way back in * [Terminate a user's sessions](/administration-guide/security/session-management.md) — the opposite requirement, when somebody should *not* be able to sign in * [Error and symptom index](/administration-guide/error-and-symptom-index.md) — the exact-string index for everything above *Applies to OpenIAM 2026.8.1. Last reviewed 7 August 2026.* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.openiam.com/administration-guide/security/cannot-sign-in.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.