How GLPI 12 active session revocation helps after a lost laptop or offboarding
A laptop goes missing, or a leaver still has a browser tab open to GLPI. In both cases the question is whether an existing session can be ended immediately, without waiting for a password reset or a token to expire. The GLPI 12.0.0 release notes list a view of active user sessions with the ability to revoke them, and step-up authentication for certain administrative actions. These are the two controls that matter here. Teams should decide in advance who may view sessions (typically the service desk lead or a security administrator), who may revoke them, and what the runbook is for each case, so that the first lost-device report does not become the first time anyone opens that screen.
Session revocation and step-up authentication answer different risks, and neither replaces account disablement in the identity source. If the user signs in through LDAP, Active Directory or another external method, disabling or locking the account there is what stops future logins across every application. Revoking a GLPI session removes access that already exists in that browser or device, and step-up authentication asks for a fresh verification before sensitive administrative actions such as changing profiles or security settings. The GLPI authentication order tries the internal database, then LDAP, then IMAP and other external methods, so confirm which source a leaver's account actually uses before you rely on GLPI alone.
Before go-live, confirm in your own GLPI 12 instance which administrative actions trigger step-up authentication, whether revoking a session also ends related API or OAuth2 sessions, and how quickly a revoked browser is forced back to the login page. Test these with a non-production account, record the results, and include the revocation steps in the offboarding checklist with an owner and a log entry. Ask the vendor or the GLPI documentation for the current behavior of each control in the version you run, since session features are new in this release and details may change in later builds.
Session controls and when each fits
This table compares four controls: revoking one session, revoking all sessions for a user, disabling the account in its identity source, and step-up authentication for administrative actions. Read each row by the situation it fits, then check the trade-off and where the authoritative account lives in your setup. The main takeaway is that session revocation ends access that already exists, while the identity source decides whether the user can sign in again.
| Control | Best fit | Trade-off | Check before using it |
|---|---|---|---|
| Revoke one session | A lost or stolen laptop where one browser session is the known exposure | Other sessions for the same user stay active, so it can miss a second device | Confirm which session belongs to the device from the session view before revoking |
| Revoke all sessions for a user | Suspected token or cookie theft, or a user working across several devices | The user is signed out everywhere and must sign in again, which may interrupt urgent work | Confirm the user is not an approver or on-call technician who needs a warning first |
| Disable the account in the identity source | Offboarding, or any case where the person must not sign in again | Requires access to LDAP, the directory or the SSO provider, and may take effect on the next sync rather than immediately | Confirm whether GLPI reads the account from LDAP, IMAP or an SSO provider, and whether a local account also exists |
| Step-up authentication for admin actions | Protecting high-impact administrative changes from a session that is already signed in | Adds a prompt for administrators, and does not stop a session that an attacker already holds from browsing | Confirm which administrative actions GLPI 12 covers in your version and test them with a non-production admin account |
| Lockout risk | Any revocation or disablement performed by a single administrator | Revoking the only administrator's session, or disabling the wrong account, can block recovery | Keep a second administrator with a tested sign-in path before making changes |
| Authoritative account location | Accounts that come from LDAP, Active Directory or an SSO provider | A GLPI session revocation does not change the directory, so the user may sign in again | Document which system owns the account and include it in the offboarding checklist |
Setting up and testing session revocation in GLPI 12
This sequence confirms the GLPI version and upgrade state, finds the active session view, proves that a revoked session is forced to sign in again, and turns the result into a repeatable offboarding runbook. The output is a tested procedure your service desk and security team can run after a lost laptop or a leaver.
Confirm the GLPI 12.0.0 version and upgrade state
The platform owner checks the running version in the GLPI administration area and compares it with the 12.0.0 release notes on GitHub. If the instance is still on 11.x, plan the upgrade against the installation docs: back up the database, the files and the config directory including glpi.key and glpicrypt.key, replace the application files, then run php bin/console db:update. Because plugins are suspended after a major update is detected, reactivate each plugin deliberately and retest it. Done means the version matches the release you intend to run, the database update has completed without errors, and every plugin you rely on is active again.
Locate the active user session view
Sign in with a technician or administrator profile that has the rights to view sessions and open the session view added in GLPI 12.0.0. Confirm which fields the view shows for each session, such as the user, the time of activity and the origin, and record what your profiles can and cannot see. Ask the vendor or check the release notes if a field you need for audit evidence is missing. Done means you can list the sessions for a test account from a second browser and the entry matches the login you just made.
Create a test account and two sessions
Create a dedicated test user with a low-privilege profile in a test entity so that no production records are affected. Sign in to GLPI with that account from two separate browsers or devices to create two active sessions. Confirm both appear in the session view under the test user. Done means the test account shows two sessions, and you have noted which session belongs to which browser so you can target one without ending the other during the next step.
Run a test revocation
From the session view, revoke one of the two test sessions, the way a service desk technician would after a lost laptop report. Do not touch the second session yet. Record the time of revocation and the account used to perform it in your test log. Done means the revoked session has disappeared from the list, and the second session is still active, which shows the revocation is scoped to the session you selected.
Verify the revoked session must sign in again
In the browser holding the revoked session, refresh GLPI or open a new page and confirm the user is sent to the sign-in screen. Then try an administrative action in the same browser, if the test account has one, and confirm the request is refused until the user authenticates again. Also check that a sign-in with the test account from a new browser still works. Done means the revoked session cannot continue working, the next request requires a fresh sign-in, and you have noted any step-up prompts that appear for administrative actions, which the release notes describe for certain actions. Confirm with GLPI documentation which actions trigger step-up in your version.
Test step-up authentication for administrative actions
Using an administrator test profile, attempt an administrative action that the GLPI 12.0.0 release notes describe as protected by step-up authentication. Confirm the prompt appears, complete it, and confirm the action then succeeds. Repeat with a session that has not been re-verified to confirm the action is still held back. Record which actions in your environment trigger the prompt, because the release notes do not list every action and you should confirm the full set with the vendor before you rely on it. Done means you have a tested list of protected actions and a clear result for both the verified and unverified cases.
Document the offboarding runbook
Write the runbook your service desk will follow for a lost laptop and for a leaver. It should name who may revoke sessions, where to find the session view, how to match a session to a user and device, how to confirm the revocation, and when to disable the account in the directory so it cannot sign in again. Store it with your change records and have the service desk walk through it once on the test account. Done means the runbook has been executed end to end on the test account, each step has an expected result, and the owner has signed off that the process matches what your team can actually do.
Where step-up authentication fits for administrative actions
Session revocation ends an active login, but step-up authentication decides what a fresh login must prove before a sensitive change goes through. The cards below cover the actions in scope, the unattended-session risk, and how 2FA and external sign-in change the prompt.
Confirm which actions require step-up
The GLPI 12.0.0 release notes state that step-up authentication applies to certain administrative actions, but the list is not part of the summary we rely on. Pull the exact action list from the release notes before writing an access policy. Then confirm it on your own instance, by performing each candidate action with a test administrator account and recording whether a credential prompt appears. Treat any action without a prompt as unprotected by this control and document a compensating restriction.
Why unattended sessions need a fresh check
An administrator who leaves a browser open on a shared desk or a reception workstation leaves a valid session behind. Session revocation can end that session after a report of loss or offboarding, but it cannot help while the session is still live and the device is in someone else's hands. A step-up prompt forces a new credential check before a change to users, profiles or entities is saved, which narrows what a passerby can do with an open browser. Decide which of your administrative roles need this protection most.
Interaction with TOTP two-factor authentication
Two-factor authentication with TOTP protects the sign-in itself, while step-up protects a single action inside an existing session. Confirm with a test account whether the step-up prompt asks only for the password, asks for a TOTP code, or accepts either, because that answer determines how much a stolen password is worth on an unattended session. Also check how the prompt behaves for accounts that have not yet enrolled a second factor, since those accounts may pass through a weaker check.
External authentication and the step-up prompt
GLPI tries authentication against the internal database, LDAP directories, IMAP mail servers and other external methods such as REMOTE_USER, in that order. When an administrator signs in through LDAP, the step-up check may need to verify the password against the directory. When sign-in comes from REMOTE_USER, the web server or identity provider holds the credential, so GLPI may be unable to re-prompt in the same way. Test each sign-in method your administrators use and record what the prompt actually asks for.
Test revocation and step-up together
The two controls should be tested as one sequence on a staging copy of the instance, ideally the same version you will run in production. Sign in as an administrator on two browsers, revoke the session from the active sessions view, then confirm the revoked browser cannot perform any listed action. Next, sign in again and confirm each protected action asks for a fresh credential. Keep the results with the change record so reviewers can see that both behaviors were observed, not assumed.
Check logging of revocations and failed prompts
Before relying on either control as evidence, confirm what the instance records. Ask whether a session revocation, a successful step-up and a failed step-up each produce a log entry, which user and source address are captured, and how long those entries are kept on your side of the platform. If the logs do not show these events, forward web server and application logs to your central logging platform and set a review step for administrative activity after each offboarding or lost device report.
Security and operational risks to plan for
Session revocation only protects you when it is part of the offboarding and incident routine, and when the GLPI upgrade process keeps the records and keys it depends on intact. The cards below cover the gaps that tend to appear between identity systems, GLPI, and the update procedure.
Sessions outliving employment
Disabling a user in your directory or identity provider does not necessarily end a GLPI session that is already open. The session list is the check that matters: after an offboarding ticket is closed, confirm that the person no longer appears among active sessions and that their GLPI profile is removed or blocked. Record who performed the revocation and when, so the offboarding evidence matches what GLPI shows.
Revocation missed for SSO sessions
When users sign in through an external method such as LDAP, a web server SSO layer, or another identity provider, the trust chain spans systems you may not own. Revoking a GLPI session ends that GLPI session only, while the identity provider session can still issue a new one. Test a revocation with an account that signs in through SSO, and document whether the identity provider session also needs to be ended.
Administrators locked out by their own actions
Step-up authentication for certain administrative actions can interrupt a privileged task if the administrator's second factor or identity-provider path is unavailable. Likewise, revoking the session of the only administrator who can sign in leaves no one to fix it. Keep at least two named administrators with working authentication, and test step-up prompts in a non-production instance before enabling the workflow for production work.
Auditing session revocations
Revoking a session is an administrative event that should appear in your audit trail with the actor, the target account, and the reason. Confirm which GLPI logs record revocations in your version, and where they are forwarded. If your log tooling cannot separate revocations from ordinary logins, ask the implementation team to define a ticket or log convention so that an investigator can reconstruct who ended which session.
Encryption keys during updates
The documented update procedure requires backing up the configuration directory, including glpi.key and glpicrypt.key, before application files are replaced. Losing or mismatching these keys can make stored credentials and encrypted data unreadable after an upgrade. Store copies of both keys with the database and file backups, and verify the restore path before running php bin/console db:update on a GLPI 12 target.
Plugins suspended after upgrades
Since GLPI 11.0, plugins are suspended after a new version is detected and must be reactivated after major updates. A session or revocation control that depends on a plugin may therefore stop working until someone reactivates it. Include plugin reactivation and a test of revocation and step-up behavior in the post-upgrade checklist, and confirm the plugin's compatibility with the target version before the change window.
Questions buyers ask before using GLPI session revocation
Can we revoke GLPI user sessions ourselves without a partner?
Yes, if you run GLPI 12 and have an administrator who can work in the web interface and in your identity system. GLPI 12.0.0 lists a view of active user sessions with the ability to revoke them, and step-up authentication for certain administrative actions. Using the feature itself is a small task. The harder part is deciding who may revoke sessions, what happens when an account is locked in your directory, and how you prove the step was taken. Teams with a clear offboarding runbook and one or two capable GLPI administrators usually handle the basics in-house. Ask for outside help when the design spans several identity sources or entities.
How much effort does session revocation setup take?
Effort depends mostly on two things: how users authenticate and how many people hold administrative rights. GLPI tries authentication sources in a fixed order, starting with the internal database, then LDAP directories, then IMAP mail servers and other external methods such as REMOTE_USER. If accounts are split across those sources, you must confirm that revoking a session in GLPI does not conflict with the upstream account state. A small number of administrators with one directory is a short exercise. Many administrators, several entities, or web server single sign-on add review and testing time. Ask any provider to break its quote down by these drivers.
What does our team need to provide for a rollout?
You will need three things before work starts. First, identity owners who can confirm how accounts are created, disabled and linked to HR events. Second, GLPI administrators who know the profiles, entities and authorization rules in your instance. Third, a test environment that matches production closely enough to rehearse revocation and step-up prompts. Also confirm your backup position first. The GLPI update and maintenance procedures stress backing up the database, files and the config directory, including the glpi.key and glpicrypt.key files, so keep those protected and recoverable before changing security settings.
How long does a GLPI session revocation rollout take?
The duration depends on your environment, and no fixed timeline applies to every organization. The main variables are the number of authentication sources, the number of administrators who need training, whether a test environment already exists, and how many change approvals your organization requires. A single-directory instance with a tested test environment moves faster than a multi-entity deployment with external sign-in and formal change control. Ask for a schedule in the written scope, with named milestones for testing, approval and cutover, rather than accepting a single estimate.
Does step-up authentication change how administrators work?
Yes. Step-up authentication asks an administrator to prove identity again before certain administrative actions run, and GLPI 12.0.0 lists this among its features. Expect a short interruption in daily administration and a need to agree which actions require the extra check. Test each action your administrators perform, and confirm how the prompt behaves with your sign-in method. Document the list of protected actions so that help desk and technical staff know what to expect.
What are the risks of revoking sessions during offboarding?
The main risks are incomplete revocation, a mismatch between GLPI and your identity provider, and cutting off a user who still needs access for a handover. A revoked session ends access in GLPI, but it does not by itself disable the account in the directory or other systems the person can reach. Build offboarding as a sequence: disable the upstream account, revoke active GLPI sessions, reassign open tickets and assets, then record the action. Test that sequence with a dummy account before using it on a real leaver.
When should we bring in an outside partner for this work?
Consider a partner when the design covers several entities, mixed authentication sources, web server single sign-on, or a compliance evidence requirement that your team has not produced before. DeployOpen plans, implements, hardens and documents self-hosted open-source platforms in infrastructure you control, and most engagements are fixed-scope. Scope, deliverables and timelines are agreed in writing before work starts, and DeployOpen does not publish a price list, so ask for a quote based on that written scope. DeployOpen prepares controls and evidence for compliance assessments but does not issue audit reports or certifications.
Is a GLPI 12 upgrade required before we can revoke sessions?
Yes. The session view and revocation feature is described in the GLPI 12.0.0 release notes, so it is not available in earlier versions. Confirm your current version and check the prerequisites for GLPI 12 before planning. The GLPI installation documentation lists PHP and database requirements that differ between releases, so the upgrade may need its own change window. Plugins are suspended after a new version is detected and must be reactivated after major updates, so check plugin compatibility before scheduling the upgrade.
How DeployOpen scopes GLPI session controls
DeployOpen plans and implements self-hosted GLPI inside your own infrastructure, so the session view, revocation settings and step-up authentication policy run where your identity and logging controls already live. The written scope comes first. It should name the GLPI 12 instance and version, the profiles and entities that can see and revoke sessions, which administrative actions require step-up authentication, who receives alerts when a session is revoked, and which systems hold the offboarding trigger. Agreeing these items before work starts keeps the session controls tied to a clear owner and avoids discovering later that nobody can revoke a session on a Friday evening.
Revocation only works if the people who press the button know when to use it. DeployOpen tests the lost-laptop and offboarding runbooks with your team against your own accounts, checking that a revoked session is actually terminated, that the user is forced back through sign-in, and that the event appears in the logs your security team reviews. Confirm with your GLPI administrators how sessions are linked to external authentication such as LDAP or web server SSO, because a session can be ended in GLPI while the upstream identity remains active. That gap belongs in the runbook and in the scope, not in an incident review.
Because the session view and step-up behavior ship with the GLPI 12 release, upgrades and plugin changes can alter how they behave, so the work does not end at go-live. DeployOpen offers retainers for ongoing upgrades and continuous testing, and the GLPI 12 release notes are the starting reference for what to recheck after each version change. Ask any partner, DeployOpen included, to name the deliverables, the test evidence and the handover for each phase in writing before signing. DeployOpen does not issue audit reports or certifications, so evidence produced here should be reviewed by your independent auditor if a compliance assessment applies.
