Why GLPI 12 re-authentication matters for administrator accounts
GLPI 12 adds step-up authentication for certain administrative actions, which asks for recent sign-in confirmation before those changes are saved. If several administrators can change users, profiles, authentication sources and plugins, this matters because a handful of actions carry most of the risk. An administrator who can edit these areas can quietly grant lasting access to themselves or to an attacker. The usual route to that position is not a guessed password but a hijacked session, where someone reuses a valid session cookie from a browser, a shared workstation or a lost laptop. A session that is already signed in passes ordinary checks, and that is the gap this feature narrows.
Session hijacking bypasses the login form entirely, so a strong password or a two-factor sign-in at the start of the day does not help once an attacker holds a live session. Re-authentication for sensitive actions adds a question at the moment of risk: before a profile change or a new authentication source is saved, GLPI requires confirmation that the person using the session has signed in recently. Administrators will see this as an extra prompt during routine changes, so plan for it. Decide which roles keep these actions, who approves changes to authentication sources, and whether plugin administration stays with a small named group. The feature complements session hardening, access reviews and logging. It does not make a compromised workstation safe.
The GLPI 12.0.0 release notes, published on October 7, 2026, describe this step-up authentication alongside a view of active user sessions with the ability to revoke them. Read these together: session review shows who is signed in, while step-up limits what a signed-in session can change. Before rollout, confirm in the release notes and on your own test instance exactly which actions prompt for sign-in, how long the confirmation stays valid and how it behaves with your chosen sign-in method. Then run a short pilot with two or three administrators, record the prompts they see, and agree a support path for lockouts before enforcing the change for the wider admin group.
Configuration options for GLPI 12 step-up authentication and when each fits
This table compares the decisions that shape GLPI 12 step-up authentication: which administrative actions are covered, how long a recent sign-in counts, how local and externally authenticated accounts behave and how session review supports the control. Read each row as a question to answer in your test instance and the GLPI 12 documentation. The main takeaway is that the protected scope and window should be confirmed against the 12.0.0 release notes before you write them into an administrator access policy.
| Option or decision | What it controls | When it fits |
|---|---|---|
| Protected action: user administration | Requires a fresh sign-in before user accounts are created or changed. Confirm the exact screens in the GLPI 12 documentation. | Any team where administrators create, change or disable accounts. |
| Protected action: profile administration | Requires a fresh sign-in before profiles and their rights are changed. Confirm the exact actions in the 12.0.0 release notes. | Always, because profile edits decide what each account can see and do. |
| Protected action: authentication administration | Covers settings for authentication sources, which control how users sign in. Confirm the scope in the documentation. | Always, since changes here can alter who is able to log in. |
| Protected action: plugin administration | Covers plugin changes where GLPI applies step-up. Confirm which plugin actions are included in your version. | Production instances where plugin changes go through change control. |
| Re-authentication window length | Sets how long a recent sign-in counts before GLPI asks again. Confirm the exact value in the GLPI 12 documentation before writing it into policy. | Use the documented value as the baseline, then compare it with your privileged access policy. |
| Local database accounts | Applies step-up to accounts that authenticate against the internal GLPI database. Confirm the prompt type in a test instance. | Smaller instances where most administrators sign in with local accounts. |
| Externally authenticated accounts | Accounts that sign in through LDAP, IMAP or REMOTE_USER may follow a different path. Test each authentication source before rollout. | Organizations that centralize sign-in in a directory and need consistent administrator behavior. |
| Active session review and revocation | The 12.0.0 release notes describe a view of active user sessions with the ability to revoke them. | After suspected account takeover, role changes or offboarding, alongside step-up. |
| Session timeout and sign-in policy | Controls how long ordinary sessions last, separate from the step-up window. Confirm the settings in the GLPI 12 documentation. | When privileged sessions must be shorter than general user sessions. |
How GLPI 12 decides when to ask an administrator to sign in again
GLPI 12.0.0 adds step-up authentication for certain administrative actions, as listed in the GLPI 12.0.0 release notes. When an administrator requests one of those actions, GLPI checks when that administrator last confirmed their identity. If the confirmation is recent enough, the action proceeds. If it is not, GLPI prompts for credentials before the action can continue. The point of the check is to make a hijacked session less useful for changing user accounts, profiles, authentication settings or plugin configuration, because an attacker who holds a session cookie still has to supply the password. Confirm which screens and actions fall inside this check before you describe them to administrators, since the release notes name only the category.
The brief describes a 15-minute window during which a recent confirmation is accepted, but that value has not yet been checked against the GLPI 12 documentation. Before you write it into an administrator standard, confirm the exact duration, whether it can be changed in the configuration, and whether it applies identically to every covered action. Also confirm what happens to the request that triggered the prompt. The reader needs to know whether GLPI holds the pending change and runs it after sign-in, or whether the administrator must submit it again. A half-completed form that is lost after the prompt is a usability problem and can lead administrators to disable or work around the control, so test this flow in a non-production instance first.
The audit trail should let you reconstruct who was asked to re-authenticate, whether they succeeded, and which privileged action followed. Ask the vendor or check the documentation to confirm which events GLPI records for the prompt, failed and successful attempts, and the action itself, along with the user, timestamp and object affected. If the event detail is thinner than you need, plan a log forwarding route or a compensating review of the change history. For rollout, start with a small group of administrators in a test instance, measure how often the prompt appears during normal work, and brief the group on the expected behavior before production enablement. Record the results so the window and the covered actions can be adjusted with evidence.
What re-authentication protects against and what it does not cover
Step-up authentication in GLPI 12 narrows what a stolen or unattended browser session can change, but it is one control among several. The cards below set out what it addresses, what companion controls it depends on, and where it stops, so you can decide what else your administrators need.
Unattended browser sessions
The GLPI 12.0.0 release notes describe step-up authentication for certain administrative actions. For an administrator who leaves a workstation unlocked or a session cookie is copied from a shared machine, the prompt asks for credentials again before a sensitive change is saved. Check which actions your version gates and test each one with a non-production account, because the list of protected actions is what determines the real benefit.
Authentication source and plugin changes
Changes to authentication sources, such as adding an LDAP directory or an IMAP server, and changes to plugin activation can widen who gets in or what code runs. These are the changes an attacker with a hijacked session would most want to make. Review which of these actions require re-authentication in your build, and pair the control with a change record for every authentication source edit.
Session viewing and revocation
The 12.0.0 release notes also add a view of active user sessions with the ability to revoke them. This shortens the time a suspicious session stays valid, because an administrator can end it without waiting for it to expire. Make session review part of the response runbook for suspected account compromise, and confirm who in your team holds the right to revoke sessions for other users.
Logging and review of outcomes
A re-authentication prompt only helps if failed and successful attempts leave a trail. Confirm in your installed version whether these events appear in GLPI's own logs or only in the web server and database logs. Forward the relevant records to your central log platform and review repeated failures on administrator accounts, since a burst of failed prompts can signal an attacker who has the session but not the password.
What the control does not stop
Re-authentication does not stop an administrator who is authorized to make a change and makes it on purpose, including a malicious insider. It also does not stop an attacker who holds valid credentials, because they can type the password again. Read-only access to tickets, assets and stored data is outside its scope. Plan detection and approval workflows for these cases instead of relying on the prompt.
Least privilege and key protection
Re-authentication works best when administrator profiles are narrow, so fewer accounts can reach sensitive pages at all. Keep the glpi.key and glpicrypt.key files backed up under controlled access, because an attacker who reads the configuration and the keys can recover stored secrets without ever passing a prompt. Review profile assignments on a fixed schedule and remove rights that are no longer needed.
Rollout by sign-in method: local accounts, LDAP and web server SSO
GLPI 12.0.0 added step-up authentication for certain administrative actions, and accounts stored in GLPI's internal database are the simplest case to reason about. The administrator confirms with the password GLPI holds for that account, so the check happens entirely inside the application. Confirm in a test instance exactly what the prompt asks for, and whether it changes when two-factor authentication is also enabled. The GLPI 12.0.0 release is the reference for which actions the step-up applies to.
- Prompt contents: confirm whether the prompt requests only the local password or any additional factor.
- Password policy: test that a forced password change or expired password does not break the confirmation flow.
- Failed attempts: test how failed confirmations interact with your lockout settings and whether they count toward account lockout.
- Named accounts: shared administrator logins weaken attribution, so confirm the audit trail records the person who confirmed each action.
- Window behavior: perform a sensitive action after the confirmation window has passed and confirm the prompt returns.
Check these points with a non-production account first, then confirm the same behavior for every administrator profile you intend to protect.
GLPI's user documentation describes authentication against the internal database, LDAP directories, IMAP mail servers and REMOTE_USER, tried in that order. For an LDAP or Active Directory account, the password belongs to the directory, so the team must confirm whether the re-entry is verified by a directory bind or by a credential GLPI keeps locally. That answer determines what happens when the directory is slow, unreachable or has changed a password. Confirm the exact behavior in your GLPI version with the GLPI user documentation on authentication and a test directory.
- Directory outage: confirm whether sensitive actions are blocked or can proceed, and document a break-glass path that does not depend on the directory.
- Recent password changes: test a user whose directory password changed after the last sign-in.
- Name collisions: because the internal database is tried first, a local account sharing a directory username can take precedence, so confirm that case is blocked.
- Group removal: remove a test administrator from the directory group that grants admin rights and confirm the account can no longer confirm sensitive actions.
- Account lockout: check whether directory lockout policy and GLPI confirmation attempts interact.
Record which directory server answers the bind in each environment, since replicas and failover paths can return different results.
When a web server module or an SSO gateway authenticates the user and passes the identity to GLPI through REMOTE_USER or a similar header, GLPI usually never receives the password. Step-up confirmation therefore has to be satisfied either by a prompt GLPI can complete or by a fresh authentication at the identity provider. The identity provider's own session and step-up features decide which of these is possible. Confirm the flow with your identity provider documentation and with a test user before any administrator relies on it.
- Prompt location: confirm whether the user is returned to GLPI to confirm or must re-authenticate at the identity provider.
- Session alignment: test that the identity provider session lifetime and GLPI session lifetime do not produce confusing prompts or silent expiry.
- Header trust: confirm the reverse proxy removes any identity header sent by clients, so a user cannot set the username themselves.
- Revocation: test that ending the SSO session ends the GLPI session, and that session revocation in GLPI takes effect for SSO users.
- Fallback order: because REMOTE_USER is tried last, confirm which source actually authenticates each administrator in your setup.
Document the chosen path per administrator profile so auditors can see which control protects each sensitive action.
How to roll out re-authentication to administrators
This sequence moves GLPI 12 re-authentication for sensitive actions from release notes to a tested, documented control for administrators. Each step closes with a check, so the owner knows when the rollout can move on to the next stage.
Confirm the GLPI 12 version and release notes
The platform owner confirms that the target instance runs a GLPI 12 release and reads the 12.0.0 release notes, which describe step-up authentication for certain administrative actions and a view of active sessions with the ability to revoke them. Record the exact version and the list of protected action classes described in your build. Confirm the behavior against the release notes and your own instance, because the documentation is the reference for which actions are covered. The step is complete when the version, release notes and covered actions are written into the rollout record.
Inventory administrator profiles and protected actions
The GLPI administrator lists every profile that can manage users, profiles, authentication sources and plugins, then maps each profile to the named accounts that hold it. Include service or integration accounts, since their sessions and credentials matter as much as human logins. Note which protected actions each profile can reach, so the pilot covers the full set. The step is complete when each profile has an owner, an account count and a list of reachable protected actions, reviewed by the security lead.
Test on a restored non-production copy
The engineering team restores a recent backup of the database, files and configuration directory into a non-production instance, including the encryption key files, and runs the upgrade or configuration check there first. Test accounts representing each administrator profile sign in and attempt protected actions. Confirm that the test environment matches production's version and authentication setup. The step is complete when the restored copy runs cleanly and each test profile reaches the expected behavior.
Brief administrators on the prompt
The security lead explains to administrators that GLPI will ask them to confirm their identity before certain changes are saved, and what to expect when it does. Cover the case where a form is interrupted: the administrator should re-authenticate and then resubmit, and should not retype large changes from memory. Give a short internal contact for problems. The step is complete when each administrator confirms the briefing and can describe the steps in their own words.
Enable or verify the setting
The platform owner confirms in the administration settings of the production instance that the re-authentication behavior is active for the covered actions, using the option names shown in the 12.0.0 documentation for your build. Record the setting value, the person who changed it and the change ticket reference. If the behavior is always on in your version, record that finding instead. The step is complete when the configured state is documented and matches the pilot instance.
Verify the prompt for each action class
A test administrator signs in on the pilot instance and attempts one action from each protected class, such as creating or changing a user, a profile, an authentication source and a plugin setting. Confirm that each attempt prompts for re-authentication and that an ordinary, unprotected change does not. Record the results in a table with the version, profile and outcome for each action. The step is complete when every protected class has a documented pass and any gap has an owner and a fix.
Review session activity after the pilot
After the pilot period, the security lead opens the active session view available in GLPI 12 and compares the listed sessions with the administrator inventory from step two. Look for sessions that belong to departed staff, unexpected devices or service accounts that should not hold interactive sessions. Revoke any session that cannot be explained, then repeat the review at a set interval your team chooses. The step is complete when the review record shows each session was accounted for or revoked.
Document the locked-out administrator procedure
The platform owner writes a runbook for an administrator who cannot complete re-authentication, for example after losing a second factor or a device. The procedure should name who can verify identity, which recovery path is available in your version, such as a second administrator account or direct console access on the server, and how the event is logged. Confirm each recovery path against the 12.0.0 documentation and test it on the non-production instance before relying on it. The step is complete when the runbook has been walked through once by a person who did not write it.
Limits to confirm before you rely on the control
Sudo mode in GLPI 12 is a useful layer, but its coverage and behavior depend on your exact build, your plugins and how users reach GLPI. Confirm each item below with the GLPI documentation or the vendor before you write the control into your access policy.
Covered actions in your build
Confirm which administrative actions in your GLPI 12 build require re-authentication. Coverage for user, profile, authentication and plugin administration should be checked screen by screen, because a sensitive action missed in the list leaves a gap a hijacked session can use. Record the list you verify so that later upgrades can be compared against it.
Whether the window is configurable
Confirm whether the re-authentication window is fixed or set by configuration, and what the default is in your version. If it can be changed, decide the value with your security team and document who is allowed to change it. Do not assume a window length from secondhand summaries of the feature.
Plugins with their own admin pages
Confirm how the control behaves with plugins that add their own administrative pages. A plugin page that changes users, profiles or configuration may not trigger step-up authentication. Test each administrative plugin you run with a session that is past its window, and ask the plugin author how it handles this.
Custom authentication and reverse proxies
Confirm how the control interacts with LDAP, external methods, web server SSO and reverse proxy setups. Re-authentication only works if GLPI can ask for credentials in a way your identity flow supports, so test a fresh sign-in, a proxy-forwarded session and an SSO-only account before you rely on the prompt.
API clients and automation accounts
Confirm whether sudo mode applies to API clients, OAuth2 tokens and service accounts that run scripts. Automation rarely has a person available to re-authenticate, so you need to know whether such calls are blocked, bypass the prompt or fall under a different control, and plan the account design accordingly.
Behavior across the GLPI 11 upgrade
Confirm how the control fits with your upgrade path from GLPI 11. Plugins are suspended after a new version is detected and must be reactivated after major updates, so a plugin that adds administrative pages may be inactive during the window when administrators are most active. Plan the reactivation order and retest the control after each step.
What buyers ask about GLPI 12 re-authentication
Is GLPI 12 re-authentication turned on by default, and how do I check?
The GLPI 12.0.0 release notes list step-up authentication for certain administrative actions, but they do not confirm whether it is enabled in every new or upgraded instance, so check your own build before assuming it. Read the release notes for the list of protected actions, then compare the administration settings of a test instance with a copy of production. Record the GLPI version, the image tag or package you deployed and the result in your change ticket. Repeat the check after each upgrade, because the setting you tested on one version may differ on the next.
What does it cost to enable GLPI 12 re-authentication?
Most of the cost is internal time. Administrators must agree which actions to protect, test how each prompt behaves for their roles and retest after plugin changes. If your team does this, the cost is their hours plus the test environment you already run. If you engage a partner, the fee follows a written scope that names the instances, plugins, identity setup and deliverables. Ask any quote to separate one-time work (test plan, configuration, documentation, training) from recurring work (retesting after GLPI updates and plugin changes, periodic access reviews). DeployOpen does not publish a price list, so the written scope is the basis for any figure.
How long does a GLPI re-authentication rollout take?
No duration has been established for this work, so any timeline should come from the written scope rather than a general estimate. The main drivers are the number of administrators who will be prompted, how many installed plugins expose administrative actions that need testing, how complex the sign-in path is (for example LDAP, web server SSO or an external identity provider) and how many entities and profiles carry administrative rights. Each driver adds test cases. Ask for a plan that ties each phase to a named change window and to sign-off from the administrators affected.
What does the work need from our team to start?
Start with a test instance that matches production in GLPI version, PHP and database versions, web server layout, authentication sources and installed plugins. Provide an administrator list with profiles and entities so testing covers each role. Agree a change window and a rollback path, including backups of the database, the files and the config directory with glpi.key and glpicrypt.key. Share the identity provider details, the plugin inventory and the list of sensitive actions your policy requires to be protected. Missing plugin details are the most common cause of late test changes.
Can our internal team roll out GLPI re-authentication alone?
Yes, if your team already runs GLPI and has people who can read the release notes, test administrative workflows and make production changes under your change process. The work is mostly verification and communication. A partner adds value where the team has limited GLPI administration depth, runs many plugins, needs a documented audit trail or has little spare test capacity. In either case, document which actions were tested, which administrators were trained and how the checks will be repeated after each upgrade.
Does re-authentication replace SSO or multi-factor authentication?
No. Re-authentication asks an administrator to prove their identity again before a sensitive action, which limits what a hijacked session can change. It does not decide how users first sign in. Sign-in still depends on your authentication sources, which GLPI tries in order: the internal database, LDAP directories, IMAP mail servers and other external methods such as REMOTE_USER. Confirm separately which multi-factor options your GLPI version and identity setup support, then test them with the same administrator accounts you use for re-authentication.
How does re-authentication affect a GLPI 11 to 12 upgrade?
Test it as part of the upgrade, not afterward. The update procedure requires backing up the database, files and config directory, replacing the application files and running php bin/console db:update. Since GLPI 11.0, plugins are suspended when a new version is detected and must be reactivated after major updates, so a plugin that exposes administrative actions may behave differently until it is reactivated and retested. Check the README requirements (PHP 8.3 or later, MariaDB 10.11 or later, or MySQL 8.0 or later) before scheduling, then repeat the protected-action tests on the upgraded instance.
Which administrative actions does GLPI 12 protect?
The control is intended for sensitive changes to user, profile, authentication and plugin administration, which are the areas where a hijacked session could do the most damage. The exact list depends on the GLPI version, so take it from the 12.0.0 release notes and from your own test instance rather than from a summary. Ask your team to map each protected action to an internal policy requirement, then note any sensitive action that does not prompt for re-authentication so it can be covered by another control or a documented exception.
How DeployOpen scopes and delivers GLPI administrator hardening
DeployOpen plans, builds and documents step-up authentication for GLPI 12 administrators inside infrastructure you control. The work starts from your administrator roles, identity setup and the sensitive actions in your GLPI instance, then carries through to a tested rollout. Engagements are fixed-scope, with scope and deliverables agreed in writing before work starts.
How we scope
- Inventory of sensitive actions in your GLPI instance: user, profile, authentication and plugin administration
- Written scope that names which administrator profiles must re-authenticate and which exceptions are approved
- Confirmation of GLPI 12 version, PHP and database levels, and the identity source used for sign-in
How we build
- Configure step-up behavior in a staging copy first, using only the controls your GLPI 12 release exposes
- Test each sensitive action with administrator accounts, including expired re-authentication and failed sign-in attempts
- Review plugin administration pages, since plugins can add administrative actions that need the same protection
How we hand over
- Runbook covering the re-authentication flow, which actions prompt for it, and what users see
- Administrator briefing and a short rollout note so staff know why they are asked to sign in again
- Documentation of the configuration, change record and test results, kept in your infrastructure
How we support
- Optional retainer for upgrades, since re-authentication behavior should be rechecked on each GLPI release
- Ongoing support and continuous testing are available as retainers, scoped in writing
- Ask for the upgrade and regression checks in your quote, so the hardening survives the next version
