When GLPI two-factor authentication with TOTP fits your rollout
GLPI 11 adds two-factor authentication based on time-based one-time passwords (TOTP), so a user signs in with a password and a code from an authenticator app. It also adds an Enforce 2FA setting in the security configuration, which can require the second factor across accounts instead of leaving each user to opt in. Any organization running a GLPI 11 instance that holds tickets, asset records, contracts or privileged administrator accounts should consider this, because those accounts can read or change infrastructure records that attackers value.
The fit depends on how your users sign in today. If accounts authenticate against the internal database, a TOTP factor is a direct control you can enforce. If accounts authenticate through LDAP, IMAP or another external method, you need to confirm how the second factor interacts with that method before you promise anyone a single sign-on experience, because the docs describe these sign-in paths separately. Ask your team to list which profiles include administrative rights, which accounts are shared or service accounts, and which users cannot practically install an authenticator app on a managed device. Those answers decide whether enforcement applies to everyone at once or in stages.
DeployOpen plans and rolls out GLPI two-factor authentication inside your own infrastructure, including the settings, the authenticator guidance for users and the verification steps before enforcement. The GLPI security configuration documentation is the source for how the feature behaves in your version, so confirm the exact options against your installed release before you finalize the rollout plan. Treat the documentation as the reference for capability, and treat your own test instance as the reference for how your users will experience it.
How 2FA behaves for each sign-in path
Accounts stored in the GLPI database are the first source GLPI tries, and they are the simplest case to verify. The password is checked by GLPI itself, so the TOTP setting and the Enforce 2FA option in the security settings apply directly to these users. Test the full path on a non-production instance before you turn on enforcement for the whole user base.
- Enrollment: Confirm that a new local user can enroll a TOTP authenticator app at first sign-in and that the enrollment step is clear to a non-technical user.
- Enforcement: Check that a user without 2FA is prompted to enroll when Enforce 2FA is active, and that they cannot skip the step.
- Lockout recovery: Document who can reset a user's 2FA enrollment and how that action is logged.
- Issuer name: Confirm the issuer name shown in the authenticator app, including the 2FA suffix, so help desk staff can match it to your instance.
Check these steps with a test account for each profile you use, since profiles and entities can change who is asked for a code.
When a user matches an LDAP or Active Directory directory, GLPI checks the password against the directory, not against a local hash. Whether GLPI then asks for a TOTP code depends on how the account was created and which 2FA settings apply to it. This behavior is not something to assume from the general documentation, so confirm it in your own environment before you rely on it.
- Password source: Confirm that a successful directory bind still leads to the 2FA prompt for directory users, and that a directory password change does not affect a TOTP enrollment.
- Enrollment storage: Verify where the TOTP secret is stored for directory accounts, since a user imported from the directory may not have a local record until first sign-in.
- Directory outage: Test what happens when the directory is unreachable and whether a fallback path to local accounts exists.
- Multiple directories: If you have more than one authentication server, test each one, because the order of sources affects which one answers first.
- Shared accounts: Check that no service or shared account bypasses the prompt.
Record the results per authentication server, because a setting that works for one directory can behave differently for another.
GLPI can authenticate users against an IMAP mail server, which is tried after the database and LDAP. A user's mailbox password is checked by the mail server, so GLPI's 2FA prompt is the only second factor in this path. Treat IMAP-based sign-in as a separate case and do not assume it behaves like local accounts without testing.
- Order of attempts: Confirm that a user who exists locally is authenticated locally, so IMAP is not used for those accounts.
- Prompt behavior: Check whether the TOTP prompt appears after a successful IMAP bind for a user who has enrolled, and whether it appears for a user who has not.
- Mail server changes: Test how a mailbox password change, a locked mailbox or a mail server outage affects sign-in and enrollment.
- Enrollment ownership: Decide who owns the TOTP enrollment when the identity lives in the mail system.
- Logging: Verify that failed IMAP and failed TOTP attempts both appear in your audit records.
Ask your mail administrator to confirm the IMAP settings in writing, because the mail server team controls the password policy that users see.
With REMOTE_USER or web server single sign-on, the web server or an upstream identity proxy authenticates the user and passes the identity to GLPI. GLPI does not see the password, so a TOTP prompt inside GLPI may not run at all for these users. Whether 2FA applies here depends on the setup of your SSO product, and you must confirm the behavior with a real test.
- Where 2FA happens: Identify whether the second factor is enforced by the SSO provider, by GLPI or by both, and record which one is authoritative.
- Double prompts: Test for users who see a TOTP prompt from both the SSO layer and GLPI, which is a usability problem and a support cost.
- Session handling: Confirm how long a session lasts after the upstream sign-in, and how a user is signed out when their account is disabled upstream.
- Direct access: Verify that GLPI cannot be reached without going through the SSO layer, because a direct request could bypass the upstream check.
- Fallback accounts: Confirm which local accounts remain available for administrators and that they are covered by Enforce 2FA.
Write the result as a single table of sign-in paths, enforcement points and owners, and have your identity team sign it off.
Configuration options and when each fits
This table compares the four ways to roll out TOTP two-factor authentication in GLPI 11, from a single pilot group to enforcement across the whole organization. Read each row for when the option fits and the main risk it carries, especially lockout when enforcement starts before users have enrolled. The main takeaway is that enrollment should be proven with a small group before enforcement is switched on for everyone.
| Option | When it fits | Trade-off | What to confirm |
|---|---|---|---|
| Enable TOTP for a pilot group | Early validation with IT staff or a small set of technicians who can report problems quickly | Limited exposure, but the pilot does not test every profile, entity or login path | Which accounts are in the pilot and who supports them during enrollment |
| Enroll administrators first | Accounts with broad rights, such as super-admins, should be protected before general users | Administrators who lose their device may need a recovery route, and lockout here affects the whole team | Who holds a second admin account with working 2FA before enforcement starts |
| Enforce 2FA from security settings | Once enrollment is complete for the target group and a recovery plan is documented | Enforcing before users enroll can lock them out of GLPI until they complete setup | Whether enforcement applies to all profiles and how existing sessions are handled |
| Per-user enrollment without enforcement | Gradual adoption while users are encouraged to set up TOTP at their own pace | Accounts remain protected only where users choose to enroll, so coverage is uneven | Reporting method for which accounts have completed enrollment |
| 2FA suffix on the issuer name | Multiple GLPI instances or environments where users need to tell authenticator entries apart | Changing the suffix does not change existing enrollments, so set it before rollout | The suffix value your security team wants and how it appears in the GLPI security configuration docs |
| External authentication (LDAP, IMAP, SSO) | Organizations that sign users in through a directory or identity provider | GLPI's own TOTP prompt may not apply to accounts authenticated externally, so confirm the flow in a test | Where 2FA is enforced for each authentication source and who manages it (identity provider or GLPI) |
Setting up 2FA in GLPI 11 step by step
This sequence moves GLPI 11 two-factor authentication from a single test account to enforced use for every user, with a check at each stage so that a misconfiguration is caught while only administrators are affected.
Confirm the GLPI version and back up the instance
Confirm that the instance runs GLPI 11.0 or later, since TOTP two-factor authentication was added in the 11.0.0 release. Then take a full backup of the database, the application files and the config directory, including glpi.key and glpicrypt.key, as the update procedure in the installation docs requires. Store the backup somewhere the GLPI server cannot overwrite. The step is done when you can restore the database and config directory to a separate test host and the instance starts there.
Set the 2FA issuer suffix
In the security settings, add a 2FA suffix so the authenticator app shows an entry name that users recognize as your instance, for example a short label for your organization or environment. Choose a suffix before any user enrolls, because changing it later means existing users will see entries that no longer match what they expect. Confirm the label with your service desk team. The check is to enroll a test account and confirm the name shown in the authenticator app matches the suffix you set.
Pilot with administrator accounts
Enable 2FA for a small group of administrator accounts first, and have each administrator enroll a TOTP authenticator app on their own device. Keep at least one administrator who is not part of the pilot signed in to the console, so you have a working account if a pilot enrollment goes wrong. The check is that every pilot account can sign out, sign back in, and complete the second factor without help from another user.
Enable 2FA enrollment for standard users
Turn on the option that lets users enroll a TOTP authenticator from their own profile, without enforcing it yet. Send users the enrollment instructions from your service desk, and state which authenticator apps your organization accepts. Track how many accounts have completed enrollment in the user list, which is the number you will use to judge readiness. The check is that a sample of standard users from different entities or profiles can enroll and sign in.
Verify a test login with an authenticator app
Run a full test login with a dedicated test account that has a standard user profile: sign out, enter the password, then enter the one-time code from the app. Repeat it for an account that signs in through an external method, such as LDAP, if your instance uses one, because authentication order determines which checks apply. Record the results and any accounts that fail. The check is a clean run for each authentication path your users rely on before enforcement is considered.
Enforce 2FA from the security settings
Enable the Enforce 2FA option in the security settings only after the pilot and verification checks pass. Announce the enforcement date to users in advance, and confirm with your team who will handle lockouts during the first business day. Watch the authentication logs and support queue for failed second-factor attempts. The check is that users who have not enrolled are prompted to do so at sign-in and that enrolled users are not affected.
Prepare the rollback for lockouts
Document the recovery path before you need it: an administrator with access to the database can reset a user's 2FA setting, and your team should know how to do that under change control. If a change to the security settings or an update causes a wider problem, restore the backup taken in the first step, and keep the config directory with its key files together with the database so encrypted data stays readable. Test the recovery path on the separate test host. The check is a written runbook that names who can perform each recovery action.
Security and operational considerations for 2FA rollout
Turning on two-factor authentication changes how people sign in, how administrators recover accounts, and how automated clients connect. The cards below cover the decisions and checks that connect those areas, so the rollout does not lock out staff or break integrations.
Lockout recovery and administrator access
Before enforcing 2FA, decide who can reset a user's TOTP enrollment and how an administrator regains access if the only administrator loses their authenticator device. Test the reset path with a non-production account first. Confirm with your GLPI version's documentation which account can clear another user's 2FA settings, and keep at least one tested recovery route that does not depend on the lost device.
Protecting the encryption keys
GLPI stores its encryption keys in the glpi.key and glpicrypt.key files in the config directory. The update procedure requires backing these files up, and losing them can leave encrypted data unreadable. Confirm how the TOTP secrets are stored and protected, make sure the key files are included in every backup and restore test, and restrict file permissions so only the web server account and administrators can read them.
Time synchronization on user devices
TOTP codes depend on the clock of the phone or computer running the authenticator app. A device with a drifted clock can produce codes that the server rejects, which looks like a failed login rather than a time problem. Include time sync checks in enrollment guidance, and test enrollment on the device types your staff actually use. Also confirm the server clock is synchronized with a trusted time source.
Enforcement and API or agent access
Enforcing 2FA for interactive sign-in does not automatically define how API clients, scripts or inventory agents authenticate. Map every non-interactive integration before enforcement, including the OAuth2 API and any service accounts, and confirm in the GLPI documentation whether those paths are affected. Test each one after the change so that inventory collection and integrations keep working.
Session handling with the GLPI 12 session view
Enrollment and enforcement do not end a session that was already open. GLPI 12 documents a view of active user sessions with the ability to revoke them, which helps after a lost laptop or an offboarding. Decide who may use that view, how long sessions should last, and when to revoke sessions after a 2FA reset. Confirm the exact behavior of the session view in the version you run.
Logging enrollment changes
Enrolling, resetting or removing a second factor changes who can sign in to an administrative account, so those events belong in your audit trail. Confirm which 2FA events GLPI records in its logs and whether they reach your central log platform. Where the built-in logs are thin, document a manual review step for enrollment changes and assign an owner who checks them regularly.
Questions buyers ask before enforcing GLPI 2FA
Can our in-house team roll out GLPI 2FA on its own?
Yes, many teams can, provided someone owns GLPI administration, has access to the security settings and can coordinate with the people who run identity and the help desk. GLPI 11 adds TOTP two-factor authentication and an Enforce 2FA option in its security settings, so the technical switch is small. The effort sits around it: confirming which accounts sign in locally, how external sign-in is handled, what users are told and how lost devices are recovered. Teams with a thin bench often use a partner for the planning and test phases while keeping day-to-day administration in-house. Decide early which parts you will own and which you will hand over.
How long does a GLPI 2FA pilot take?
The pilot length depends on how many user groups you test, how many authentication sources are involved and how much of the help desk process you change at the same time. No supplied timeline applies to every environment, so ask for a duration in writing only after the scope is agreed. The main drivers are the number of test accounts, whether you need to test with LDAP or IMAP sign-in, whether the help desk must rehearse recovery steps, and how many approval rounds the security and identity owners require. A pilot limited to local accounts with a single admin group is much shorter than one covering every entity and external source.
What do we need to provide for a 2FA rollout?
The work depends on four client inputs. Identity owners must confirm which accounts authenticate locally and which come from directories, and they must agree on the enforcement scope. Help desk leads need written scripts for enrollment, reset and lost-device cases. You need dedicated test accounts with known profiles across entities, so the team can verify enforcement without locking out production administrators. Finally, someone must own the communication to users, including the date, the authenticator app they should install and where to get help. Missing any of these usually adds rework rather than extra build effort.
What does a partner quote for GLPI 2FA depend on?
A quote follows from the written scope, so the inputs that change it are the ones to fix first. Ask the provider to state the number of GLPI instances and entities, the authentication sources in use, whether enforcement applies to all profiles, the number of help desk scripts to write, and whether testing is limited to a pilot group or covers production. Also ask which items are one-time work, such as configuration and test plans, and which recur, such as support for new staff or policy changes. DeployOpen does not publish a price list. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How does 2FA work for users signing in through LDAP or IMAP?
GLPI tries authentication sources in a set order: the internal database, then LDAP directories, then IMAP mail servers, then other external methods such as REMOTE_USER. Before enforcing 2FA, confirm with your identity team whether the second factor should be applied to accounts that are authenticated by a directory, since the password check happens outside GLPI. Test each source separately with a dedicated account, and check the behavior for accounts that exist in more than one source. Your identity provider may already supply its own second factor, which can make a GLPI TOTP prompt redundant for some users. Confirm this design before you set the enforcement scope.
What happens when a user loses the device with their authenticator app?
The recovery path must exist before enforcement starts, or users will be locked out. Write a documented procedure that states who verifies the user's identity, how a second factor is reset, and who has the rights to perform the reset in GLPI. Test it with a test account, including the case where the administrator also loses access. Set the reset path to match your risk model, because a reset is itself a sensitive action. Review how active sessions are handled too, so that a lost device does not leave an open session behind. Confirm the exact reset steps for your GLPI version in the security configuration documentation.
Does the GLPI 2FA issuer suffix affect how users set up their apps?
The 2FA suffix is added to the issuer name that appears in the authenticator app, so users can tell GLPI entries apart from other accounts. It is a small setting, but it affects support tickets because users often search their app for the name they remember. Choose a suffix that identifies the environment, such as the organization or the instance, and state it in the user communication. If you run several GLPI instances, give each a distinct suffix so enrollments do not get mixed up. Check the exact setting in the GLPI security configuration documentation before publishing the instructions.
Limits to confirm in your environment
GLPI 11 two-factor authentication behaves differently depending on how users sign in, which authenticator apps they use and which plugins or API clients touch the login path. The cards below list what to confirm with the vendor documentation and on a test instance before you enforce 2FA for everyone.
Enforcement for external authentication
Confirm how Enforce 2FA applies to users who authenticate against LDAP, IMAP or other external methods, and whether the external directory is trusted to handle the second factor at all. The authentication order in the GLPI user documentation (internal database, then LDAP, then IMAP, then external methods such as REMOTE_USER) decides which path a user actually takes. Test each method with a dedicated account and record the result.
Supported authenticator apps
TOTP is a standard, but apps differ in how they handle time drift, account import and issuer display. Check the apps your users actually install, including any corporate mobile device management policy that restricts them. Document the approved list and the setup steps for each platform.
Recovery when a device is lost
Decide what a user does after losing the phone that holds the authenticator. Confirm what GLPI offers for resetting a user's second factor, who may perform that reset, and whether an administrator can do it without the user's device. Write the reset procedure and test it, because a locked-out administrator is harder to recover than a locked-out user.
Behavior after GLPI upgrades
Confirm that enrolled TOTP secrets and the 2FA settings survive the update path you plan to use, including the move from GLPI 11 to later releases. Back up the database and the glpi.key and glpicrypt.key files before any upgrade, then verify that existing users still reach the login prompt. Re-test after each minor release.
Plugins and API clients
Check whether plugins, REST or OAuth2 API clients, and scripts that log in with user credentials can still authenticate once 2FA is enforced. A service account that depends on password-only login may break silently. List every integration that authenticates to GLPI and test each one under enforcement.
Issuer suffix in the authenticator app
The 2FA suffix in the security settings is appended to the issuer name that the app displays. Confirm on a test account that the suffix shows as expected in each approved app, so users can tell the GLPI entry from other accounts. Check that the suffix is set before enrollment begins, since changing it later may leave users with entries that look different.
What DeployOpen plans, tests and hands over
The work starts by deciding who must use TOTP and who is exempt. Scope the account populations first: local GLPI accounts, accounts that sign in through LDAP or Active Directory, IMAP-authenticated users, and any service or API accounts that cannot answer a one-time code. GLPI tries authentication sources in a fixed order (internal database, LDAP, IMAP, then other external methods such as REMOTE_USER), so the team needs to confirm which source actually authenticates each population before deciding where 2FA is enforced. Each exception should be written down with an owner and a review date, because it becomes part of the access control evidence later.
Next, DeployOpen writes the enrollment and recovery runbook. It covers how a user enrolls an authenticator app, what the help desk does when a device is lost, how identity is checked before a reset, and who may approve it. The runbook also names the 2FA suffix that appears beside the account name in the authenticator app, so staff can recognize the correct GLPI entry. Configuration and testing happen on a non-production instance first, using a copy of the real configuration, with test accounts for each authentication source. Tests check enrollment, failed codes, recovery, and sign-in through each external source, and confirm that the security settings behave as the runbook describes.
Enforcement is then staged, one population at a time, with a rollback step defined for each stage. At handover, DeployOpen provides the configuration record, the test results, the exception register, the runbook and a record of enforcement dates. These are inputs for access control reviews run by the client and, where relevant, by an independent auditor. DeployOpen prepares controls and evidence but does not issue audit reports or certifications. Confirm with your assessor which artifacts they expect before testing starts.
How DeployOpen scopes and delivers GLPI 2FA
DeployOpen plans and delivers GLPI two-factor authentication with TOTP inside infrastructure you control, from the first decision about which accounts and entities are covered to the runbook your team keeps. Engagements are fixed-scope, so the rollout steps, the enforcement plan and the handover materials are agreed in writing before work starts.
How we scope
- Inventory which account types, profiles and entities sign in with local credentials and which use LDAP, IMAP or REMOTE_USER.
- Agree the enforcement sequence, the pilot group and the exception process for accounts that cannot use an authenticator app.
- Confirm the issuer suffix, the support contact text shown to users and the recovery path for lost devices in the written scope.
How we build
- Configure the security settings for TOTP, Enforce 2FA and the issuer suffix on a staging GLPI 11 instance first.
- Test enrollment, login, lockout and recovery for each external authentication path that remains in use.
- Check that the update procedure keeps glpi.key and glpicrypt.key intact, then validate 2FA behavior after the upgrade steps.
How we hand over
- Provide a written configuration record with each security setting, its value and the reason it was chosen.
- Deliver user enrollment guidance and help desk scripts for lost devices, reset requests and onboarding new staff.
- Document the test cases used during the rollout so your team can repeat them after future GLPI updates.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer if your team wants DeployOpen to keep working on the setup.
- Review 2FA behavior when you move to a newer GLPI release, including changes to administrative step-up authentication.
- Confirm with your identity team and the GLPI documentation any behavior you depend on before each change to the security settings.
