When a domain user cannot sign in
The sign-in portal has no "Forgot password" link that emails a reset link. A domain user's address is also their mailbox, so a reset link there would hand the whole account to anyone who can read the mail, e.g. a mail client with an app password. Instead, you, the account holder, set up the sign-in again.
The portal helps the user ask you. Under the sign-in form, Can't sign in? opens a page with two parts:
- What the user can do alone:
- A user who forgot the password can sign in with a passkey and then change it.
- A user who lost the authenticator app can enter a backup code.
- Ask your administrator, which you configure. See Choose what the page shows.
The two-factor prompt links to the same page: Can't use your authenticator app?
The request
With Ask for help, the user sends you a request: they type their username and pick a reason from a fixed list. There is no free-text message.
Anyone who knows a username can send a request. It tells you what the system saw, not who asked. Before you send a setup link, confirm the request with the user through a channel you already trust, e.g. a phone call, and never send the link to an address a stranger gives you.
A request changes nothing on the user's account: it doesn't disable the password or sign out a session, so a stranger can't use the page to lock a user out.
The page gives the same answer for every username, including one that doesn't exist, so it doesn't reveal which users exist.
What you get
When a user asks, the panel:
- emails your system mailbox
- shows the request on every tab of the user's page
- adds it to Sign-in Help Requests, under Email & Identity in the menu
- adds a line to the user's auth log
The user is also told, by email to their mailbox and a notification to their devices, so a user who didn't ask can tell you.
The request shows:
| Fact | What it tells you |
|---|---|
| Reason | What the user selected: the password, the authenticator app, the passkey, or something else. |
| From | The browser, IP address, and country. |
| Device | Whether the browser is one of the user's registered devices. The strongest sign that the user really asked. |
| Correct password | The request came from the two-factor prompt, so the person entered the correct password. |
| Requests | How many times the user asked. |
A user has at most one open request; asking again adds to it. The panel sends at most one email per request per day.
Answer a request
The user's page shows the request with these actions:
| Action | When to use it | Result |
|---|---|---|
| Reset credentials | The user lost the password. | You get a setup link to give to the user. The old password stops working. |
| Reset Authenticator App | The user lost the authenticator app and the backup codes. | The user sets up a new app at the next sign-in. |
| Mark as handled | You helped the user some other way. | The request closes. Nothing else changes. |
| Decline | You don't help, e.g. the user didn't ask. | The request closes. Nothing else changes. |
A request also closes when the user signs in and when you lock down the user. An unanswered request closes after 14 days, and a closed request is kept for 90 days.
The panel doesn't tell the person who asked that you declined, because it can't know who that person is.
Choose what the page shows
You choose what Ask your administrator shows per identity provider. Open OpenID Connect, select the identity provider, and open the Authentication tab. The setting is in the Sign-in Help section.
| Option | What the page shows |
|---|---|
| Users can ask you for help | The request form. The default. |
| Show your contact details | Text you write, e.g. your help desk's address. Markdown, like the portal's footer. |
| Show nothing | Only what the user can do alone. |
The API and the MCP server also list
and answer requests. An agent reads the open ones with
sign-in-help-request_list.