> 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/faq/security-and-platform.md). # Security, recovery and platform Short answers to questions administrators ask most often about security, recovery and platform. ## What this is, and when you need it Short answers to the questions this area generates most often, each linking to the page that carries the detail. If your question is not here, the section hubs route by outcome and the [error and symptom index](/administration-guide/error-and-symptom-index.md) routes by the exact message you were given. ### Can we change which validation questions the help desk is asked, so it stops asking for employee ID and job title? No, and adding a custom field does not help — naming a user attribute in `org.openiam.am.helpdesk.possibly.asked.attributes` makes the candidate pool *larger*, it does not remove **Employee ID**, **Title**, **Email address**, **Birth date**, **Middle initial** or the secret word. No screen narrows the pool. The countermeasures available today are to populate attributes only the genuine caller would know, so the shuffle has better material to draw on, and to raise `REQUIRED_HELPDESK_QUESTION` so more than one answer has to be right. [Full detail](/administration-guide/security/helpdesk-verification.md#what-the-operator-is-actually-asked) ### Can we hide "Forgot your password?" until we know the account exists and is registered? It already behaves that way. The link is rendered only when password unlock is enabled and the login the user has typed resolves to an `ACTIVE` user holding at least one active login, so an unregistered or disabled account shows no link at all. That is the only place the sign-in screens distinguish a known account from an unknown one — the failure message itself is always `Invalid Login and/or Password`, whichever half was wrong, by design. [Full detail](/administration-guide/security/password-recovery.md#what-the-recovery-flow-does-end-to-end) ### How long is an activation or forgot-password link valid, and can we stop the reset screen offering the OpenIAM account? Validity is in days, set by **Number of days the forgot password token is valid** in the **Forget Password Parameters** of the password policy that resolves for the user; it ships with no value and the fallback is three days. To stop a managed system appearing on the reset screen, untick **Show on User Change Password Screen** on that managed system — it ships ticked — leaving only the systems you want resettable, so the mailed link points where the password of record lives. A system is listed only when the user also holds an active login on it. [Full detail](/administration-guide/security/password-recovery.md#which-managed-systems-the-reset-screen-offers) ### I added a new group to a role users already hold, and the connector reports the operation as no change. What do I re-save? Nothing on those users changed, which is exactly the problem. The membership attribute is only sent when one of the user's own direct memberships changed on that save, or when the account is being created, so a change made on the *role* produces no attribute and the connector correctly sees nothing to do. Either add the group to each user directly, or make a membership change on the user that forces the attribute to be rebuilt. The provisioning service log shows which groups were sent, one `[userGroups]:` line each, and says `there is no groups` when it sent none. [Full detail](/administration-guide/access/manage-roles-and-groups.md#what-nesting-does-not-reach) ### Operators who manage entitlements can add themselves to the privileged admin roles. How do we stop that? `org.openiam.ui.webconsole.allow.change.own.entitlements` ships `false`, and while it is `false` OpenIAM refuses any entitlement change whose target is the signed-in operator, answering **Not allowed to change your own entitlement**. Be clear on its limits before you rely on it: the test is "requester is the target user", not "the role is privileged", so there is no way to protect only the admin roles — it is all self-grants or none — and it does nothing about two operators granting each other what neither may grant alone. For that, remove the entitlement screens from the population and route the access through an approval flow. [Full detail](/administration-guide/access/manage-roles-and-groups.md#stop-an-operator-granting-themselves-access) ### Our service desk cannot see the Reset Password option in SelfService. How do we give a group blanket reset rights? The action is a shipped menu item resource, `RESET_PASSWORD_DIRECT_REPORT`, under `VIEW_DIRECT_REPORTS`; entitle the service-desk role to that menu item and it appears. It will still only reach the operator's own direct reports, so a desk that is nobody's supervisor sees an empty list. There is no shipped way to nominate a group that may reset any user's password without verification — OpenIAM has self-service, the supervisor path, and the help-desk flow that asks the caller verification questions, and nothing else. [Full detail](/administration-guide/security/helpdesk-verification.md#giving-a-service-desk-the-reset-password-action) ### The mailbox configuration's test email arrives, so why do recovery and OTP messages never turn up? Because the test proves the transport and nothing else: **Send Test Email** carries the configuration on screen, renders no template, and bypasses the rotation used by real sends. Check that a `SEND_EMAIL_NOTIFICATION` event exists at all, then the notification template's enabled flag and name, the recipient's active email address, and which mailbox configuration the round-robin actually used — every active configuration that is not somebody's failover takes its turn, so two active configurations means alternating senders. [Full detail](/administration-guide/platform/mail-and-notifications.md#when-it-goes-wrong) ### The Password tab has a "Reset password methods" field. Why does changing it do nothing? Because nothing reads it. `org.openiam.ui.reset.password.methods` ships `SMS,EMAIL,CHALLENGE_RESPONSE` and no part of the product consults its value, so the field is inert whatever it renders as. The setting that actually governs which methods appear is the authentication rule on the `/idp/resetPasswordForm` URI pattern, edited under **Access Control → Content Providers**. [Full detail](/administration-guide/security/password-recovery.md#the-uri-pattern-decides-which-factors-the-user-is-offered) ### Users choose a method on the "Forgot your password?" screen and get sent straight back to the login page. What is misconfigured? The URI pattern, not the password policy. `/idp/resetPasswordForm` is a protected URL whose bound authentication rule decides which factors the user may choose, and the shipped binding is **Any authentication**, whose steps are `CRIIPTO_AUTH`, `PASSWORD_AUTH`, `WEB_AUTH` and `CERT_AUTH`. Choosing **Password** there asks for the password the user has just said they forgot, which is the loop. Bind that pattern to a rule whose steps are recovery factors only — `EMAIL_AUTH`, `SMS_AUTH`, `CHALLENGE_RESPONSE_AUTH` — and confirm the OTP provider is selected under **Supported OTP Providers** and that mail is working. [Full detail](/administration-guide/security/password-recovery.md#the-uri-pattern-decides-which-factors-the-user-is-offered) ### We attached a business rule that grants a role, the role contains AD groups, and the account lands in Active Directory with an empty memberOf. Why? Because the membership attribute a connector writes is built from the user's own **direct** group memberships, not from anything the user reaches through a role. Nesting decides entitlement inside OpenIAM and decides which managed-system accounts get created, but a group two steps away never appears in the account's group attribute. Grant the groups to the user directly as well as the role — a business rule can carry both as separate on-match targets — or copy the shipped membership script in **Groovy Manager**, expand the role's contents inside your copy, and select it on the managed system's policy map. [Full detail](/administration-guide/access/manage-roles-and-groups.md#what-nesting-does-not-reach) ### We renamed a group in Active Directory and OpenIAM now shows both the old name and the new one. Which is wrong? Neither is wrong; the synchronization matched nothing. Incoming group records are matched by name within the managed system, so a group whose name changed in the directory matches no OpenIAM group, is created afresh under the new name, and the original row stays behind with its members. Nothing removes the stale row. Match on an attribute the directory does not change, or move to reconciliation, which compares both sides rather than only pushing the source's view forward. [Full detail](/administration-guide/access/manage-roles-and-groups.md#groups) *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/faq/security-and-platform.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.