> For the complete documentation index, see [llms.txt](https://help.glpi-project.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.glpi-project.org/glpi-12/overview/reauthentication.md).
# Reauthentication
Some areas of GLPI are more sensitive than others: user accounts, profiles and rights, groups, authentication settings, plugins, system logs, general configuration.
Being logged in is no longer enough to reach them. When you open one of these pages — or trigger one of these actions — GLPI asks you to prove, one more time, that you are really you. This short extra step is called **re-authentication** (informally "sudo mode", by analogy with the `sudo` command on Linux).
Once you have passed it, you keep a **15-minute** window during which sensitive areas open without asking again.
***
## What is the use of it?
Your GLPI session is a key. As long as it is open, anyone who gets hold of it can act as you. Re-authentication limits what that key alone can do:
* **Unattended workstation.** A session left open on an unlocked computer can be used to browse tickets, but not to grant a profile, create an administrator account or install a plugin.
* **Stolen or replayed session.** If a session cookie leaks, the attacker holds the session but not your password nor your authenticator app. Privilege escalation is blocked.
* **Booby-trapped link or URL.** A link received by mail, a chat message, an image on another site can make your browser send a request to GLPI in your name — for instance "create this administrator account" or "assign this profile". Such a request travels with your session and therefore used to look legitimate. It now runs into the prompt, and whoever crafted the link cannot type your password or your 2FA code for you.
* **Injected script (XSS).** If a malicious script manages to run inside a GLPI page — from a field filled in by someone else, a compromised plugin, a browser extension — it inherits your session and can send requests without you noticing. Sensitive actions no longer follow. Better: a request sent in the background (AJAX) *cannot* display the prompt, so GLPI refuses it outright rather than performing it. To reach a sensitive action, the script would have to take over the whole page and produce a genuine proof of identity.
* **Slip of the hand.** The prompt is also a deliberate pause before an action that changes who can do what in your GLPI.
The principle: **the most damaging actions require a fresh proof of identity**, not just an old login.
***
## What you see
When a sensitive area requires it, GLPI leaves the page you were on and displays a dedicated screen:
* **Verify** → if the proof is correct, GLPI replays automatically the action you had asked for: you land on the page you were opening, or your form is submitted, with nothing to redo. If the proof is wrong, an *Authentication failure* message is displayed and you can try again.
* **Cancel** → you go back to the page you came from, and nothing happens. Cancelling is always safe.
Everything you had typed in the form is preserved during the detour, so an unexpected prompt never costs you your input.
***
## How your identity is verified
The prompt does not offer a choice: GLPI picks the strongest method available on your account.
| What is asked | When it applies |
| ------------------------------------------------- | ------------------------------------------------------------------------ |
| **A code from your authenticator app** (2FA) | You have two-factor authentication enabled. Always preferred. |
| **Your GLPI password** | Your account is a local GLPI account with a password. |
| **Your directory password** | Your account comes from an LDAP / Active Directory server. |
| **Your CAS password** | You use a CAS server to log in to GLPI (method not recommended) |
| **Your email account password** | You log in using an IMAP mail server |
| **A simple confirmation** ("confirm this action") | No stronger method is available on your account (see the warning below). |
Plugins may add their own method — for example a confirmation through the identity provider you log in with (SSO). When such a method is installed and applies to your account, the prompt shows it instead.
{% hint style="danger" icon="shield-exclamation" %}
**Important — accounts that only get a confirmation.**
An account with neither a local password, nor a directory password, nor 2FA (typically a pure SSO account) cannot really be challenged: the prompt then only asks for a confirmation click. It keeps the deliberate pause, but it is **not** an identity check.
Enabling two-factor authentication on such accounts — especially administrator accounts — restores the protection.
{% endhint %}
***
## How long it lasts
* The window opens **when a verification succeeds**, and lasts **15 minutes**.
* Logging in does **not** open it: the first sensitive action of a session always prompts.
* It is **not** extended by activity. 15 minutes after the successful verification, the next sensitive action prompts again — even if you never stopped working.
* The window is tied to your session: logging out closes it.
* The duration is fixed in this version and cannot be configured. *(to confirm: whether it is meant to become a configuration option)*
***
## Where it applies
Re-authentication is required on the areas below. Reading them is enough to trigger the prompt in most cases, not only writing.
### Users, rights, organisation
* Users (including creating, importing from an external source, changing authentication data)
* Impersonating another user
* Profiles, and the assignment of profiles to users (authorisations)
* Groups, and group memberships
### Authentication and security
* LDAP directories
* Mail servers (IMAP authentication)
* OAuth clients
* Changing your own password
* Changing your own two-factor authentication settings
### Configuration and system
* General configuration
* Inventory configuration
* Plugins: the plugin list and the marketplace, plus install / uninstall / enable / disable actions
* Historical entries (the log of who did what) and the system log files (viewing, downloading, emptying, deleting)
### Massive actions
* A massive action that targets one of the item types above prompts once, then applies to the whole selection.
{% hint style="info" %}
*Your personal **Settings** > **Preferences** page is marked as sensitive in the code, but the page itself does not trigger the prompt. Changing the password, however, will require re-authentication.*
{% endhint %}
Everything else — tickets, assets, knowledge base, reports, dashboards… — is untouched. A user who never goes near administration never sees the prompt.
***
## Administrators
{% hint style="info" %}
**It cannot be configured from the interface.** There is no option, no per-profile exception, no adjustable delay.
{% endhint %}
{% hint style="warning" %}
**It can be disabled globally — and should not be.** Setting the `GLPI_DISABLE_REAUTH` constant in the local configuration file turns off every prompt. Doing so lowers the security level of the whole instance: a stolen session then grants full administrative power. While it is set, a **warning is displayed on the dashboard** of administrators. The constant is a temporary escape hatch, planned for removal in a future 12.x release — do not build a workflow on it.
{% endhint %}
### Recommendations
* Enable two-factor authentication on administrator accounts. It is both the strongest proof at the prompt, and the only real one for accounts without a password in GLPI or in a directory.
* Review the accounts that would only get the confirmation prompt (SSO accounts without 2FA), especially those holding configuration or user-management rights.
* Do not confuse re-authentication with rights. It never grants anything: an action already forbidden by a profile stays forbidden. It only adds a condition on top of existing rights.
### Support notes
* LDAP verification fails closed: a directory outage blocks sensitive actions instead of letting them through.
* Plugins can provide their own verification method; check with the plugin's documentation what its prompt asks for.
***
## Not covered by this mechanism
* It does not protect against a compromised password or a compromised authenticator: it only makes an unattended or stolen *session* far less useful.
* Against an injected script, it raises the bar without closing the door: such a script cannot pass the prompt by itself, but it can act during a window you have already opened, and it could try to imitate the prompt to capture what you type. Re-authentication is a second line of defence, not a substitute for fixing the injection.
* It does not log a specific audit trail of the prompts themselves. *(to confirm)*
* It applies to the web interface, not to the API, the CLI, or the inventory agents.
---
# 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 dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://help.glpi-project.org/glpi-12/overview/reauthentication.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
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.
