How Windows integrated SSO for GLPI with REMOTE_USER works
A team that wants domain users to reach GLPI without a second password prompt is asking for web server authentication, not a GLPI login form. In this model the web server performs the sign-in (for example Apache or IIS with Kerberos or NTLM), then passes the authenticated username to GLPI in an environment variable. GLPI's authentication order includes an external method called REMOTE_USER, which is tried after the internal database and directory methods. When that method is enabled, GLPI trusts the username it receives and creates or matches a local user record for it. The web server, not GLPI, decides who is authenticated, so the security of the whole arrangement depends on the web server configuration as much as on GLPI settings.
The exact details are version specific and must be confirmed before any build starts. Check the header or environment variable name your web server module actually sets (commonly REMOTE_USER, but this depends on the module and its configuration), the Kerberos or NTLM module and its version, and the GLPI authentication settings for your release in the GLPI user documentation. Confirm also how your domain format appears in the username (for example DOMAIN\user or user@domain), because GLPI logins usually need the domain part removed. DeployOpen plans and implements this in your own infrastructure, so the sign-in path, the web server layout and the test accounts are agreed in writing before configuration starts.
Decide early which users must keep a local fallback. A local administrator account that bypasses SSO is usually needed for recovery, and it should be tested before go-live. Also decide whether the GLPI server must accept only traffic from the reverse proxy or load balancer that handles authentication, because any client that can reach GLPI directly may be able to send a forged username. Ask the implementer to show, in a test environment, that a request without a valid Kerberos ticket is refused and that a manually added user header is ignored.
What you need before configuring REMOTE_USER
Windows integrated sign-in into GLPI depends on five layers agreeing before any GLPI setting is touched: the GLPI release, the web server, the directory, the network name and the certificate. Confirm these with the people who own each layer, because a gap in one usually shows up as a login loop or a 401 rather than a clear error.
Supported GLPI, PHP and database versions
The GLPI 11.0 installation prerequisites list PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6, while the README on the main branch lists PHP 8.3 or later with MariaDB 10.11 or later or MySQL 8.0 or later. Pick the release line first, then check its prerequisites page, since only MySQL and MariaDB are supported as databases. Confirm the PHP build your web server will load matches the version you target.
Web server with the public directory as root
GLPI expects the document root to point to its public directory, not the installation root, with URL rewriting that routes requests through index.php. This matters for REMOTE_USER because the web server must be the component that performs Kerberos or NTLM authentication before the request reaches PHP. Confirm your Apache, Nginx, lighttpd or IIS build can run the authentication module you need in front of that rewrite rule.
Active Directory service account and auth module
Plan a dedicated service account, and the Kerberos or NTLM module your chosen web server requires to negotiate Windows sign-in. Record the exact module name, its version and whether the vendor still supports it, since these change over time. Ask the web server vendor to confirm the current module and its support status before you design around it.
Stable internal DNS name
Kerberos ties the service ticket to a service principal name, so GLPI needs a fixed internal hostname that clients resolve consistently, such as a name that matches the SPN your domain administrators register. A changing IP, a short NetBIOS name or a name that differs between browsers will break negotiation. Agree the name with your DNS owners and confirm reverse lookups behave as your Kerberos configuration expects.
TLS certificate for the GLPI site
Browsers only send Windows credentials to a site they trust, and the certificate name must match the hostname users type. Use an internal certificate authority that your domain-joined endpoints already trust, and confirm the chain is complete on the web server. Expired or mismatched certificates often look like authentication failures, so check them early.
Agreed users and groups for access
Before configuring anything, list the Active Directory users and groups that should sign in through Windows, and decide which GLPI profiles and entities they receive. This list determines whether you need a mapping from the domain login to a GLPI account, and it prevents the common mistake of opening access to every domain user. Keep the list in writing so the sign-in design can be reviewed.
Why the web server becomes the trust boundary
With REMOTE_USER, GLPI does not check a password itself. It accepts the identity the web server has already established, so the authenticating web server becomes part of GLPI's authentication design. The web server, its Kerberos or SSO module, the header or variable it exports and the network path to it all decide who GLPI believes is signing in. If a request can reach GLPI without passing through the authenticating proxy, that request can potentially supply a username, and GLPI will act on it. Your design needs to show that GLPI's listening address, firewall rules and reverse proxy routing leave no bypass path, and that any internal health checks or service accounts do not reach the application by a route that skips the proxy.
Authentication order also decides who gets in. GLPI tries its authentication methods in a fixed sequence, and the user documentation describes the internal database being tried before LDAP, IMAP and external methods such as REMOTE_USER. A user who already has a local GLPI account with the same login may therefore be authenticated locally rather than through Windows. Confirm, for each account type you have, which method will match before go-live, and decide in advance how existing local accounts, service accounts and the built-in administrator will be handled. The GLPI user documentation on authentication is the place to confirm the current order for your version.
Before you change anything, test local administrator access on the production instance and in a staging copy. Confirm that a named administrator can sign in with a local password while SSO is enabled, and that you can disable the SSO path again without touching the database. A lockout on a web server change is hard to recover from if the only administrator depends on the same Kerberos ticket or proxy module that just broke. Record the test results, the rollback steps and the person who can execute them, and repeat the check after each web server or GLPI upgrade.
Configuration sequence for REMOTE_USER single sign-on
This sequence takes GLPI from a working base install to Kerberos or NTLM sign-in through the web server, with a pilot, a defined username format, correct profile mapping and a documented fallback for administrators. Each step closes with a check you can repeat before users depend on it.
Confirm the GLPI version and base install
The platform team confirms which GLPI release and PHP and database versions are running, and that the document root points to GLPI's public directory with URL rewriting in place. Check the prerequisites for your release in the GLPI installation documentation before changing anything in the web server. Done means a local administrator can sign in over HTTPS, the database update has completed, and the version shown in the administration console matches the release you planned to run.
Configure Kerberos or NTLM on the web server
The web server administrator sets up Kerberos or NTLM authentication against your Active Directory domain for the GLPI path, using the module your web server platform supports. Confirm the service account, keytab or machine account, and the host name clients use, since Kerberos depends on matching names. Restrict the protected path so that only the GLPI login route is behind integrated authentication, and check that unauthenticated requests are refused. Done means a domain-joined test browser receives a session and an unjoined browser is challenged rather than silently failing.
Identify the server variable carrying the username
Confirm which server variable your web server sets for the authenticated user, most commonly REMOTE_USER, and whether it arrives with a domain prefix or suffix. Read the value from a test page or the web server log for a known account, and record the exact format. Only the variable set by the web server itself should be trusted, because client-supplied headers can be spoofed when a reverse proxy passes them through. Done means you have one recorded example of the raw value for each test account.
Enable the REMOTE_USER method and set its order
An administrator enables the external authentication method for REMOTE_USER in the GLPI authentication settings and places it in the order you intend, keeping the internal database method available for break-glass access. Review the authentication order, because GLPI tries methods in sequence and a broad external method ahead of local accounts can change who is matched. Done means the configuration saves without error and the method appears in the list of enabled authentication sources.
Strip domain suffixes and test account matching
Decide whether the domain prefix or suffix is removed before GLPI compares the value with its user table, and apply that rule consistently across the web server and GLPI settings. Compare the normalized name with existing GLPI accounts, paying attention to case and to accounts that were created earlier through LDAP. Done means test logins from several accounts resolve to the single expected GLPI user each time, with no duplicate accounts created.
Map authenticated users to profiles and entities
Assign each matched user a profile and entity through authorization rules, or confirm that existing LDAP-based assignments apply, so that SSO users do not sign in with no rights. Keep the mapping least-privilege and test each intended profile with a named account. Done means each pilot account lands in the expected profile and entity, and a user outside the pilot group is denied or given only the default access you designed.
Pilot with a small group and an unjoined browser
Run the sign-in with a small pilot group of domain users, then repeat the test from a browser on a machine that is not domain-joined to confirm the fallback behavior. Review the GLPI session list and the web server access and error logs for each attempt, looking for unexpected usernames, repeated challenges or spoofed header values. Done means the pilot logins, denied logins and unjoined-browser behavior all match the written test plan, and the logs show only the expected identities.
Document the break-glass administrator path
Record a local GLPI administrator account, stored with a strong password in your secrets process, that signs in through the internal database method even if the web server or domain is unavailable. Write down who may use it, when, and how the use is logged and reviewed. Done means a test sign-in with the break-glass account succeeds while SSO is switched off in a controlled window, and the runbook is approved by the owners of the platform and identity services.
Mapping server variables and login formats to GLPI accounts
This table compares the server variable, the Windows login formats and the GLPI login field that each one can reach. Read it as a starting guide, since the exact variable name and the value it carries depend on your web server and Kerberos module, and the takeaway is that a single username format must match the GLPI account name exactly.
| Source value | Example format (illustrative) | What GLPI receives | Action required |
|---|---|---|---|
| Server variable carrying the username | REMOTE_USER or a module-specific variable (confirm for your web server) | The value of the variable as the web server sets it after Kerberos sign-in | Confirm the exact variable name and its value in a test request before writing any GLPI configuration |
| Windows down-level format | EXAMPLE\jsmith (illustrative) | The domain prefix and backslash, unless the server or GLPI strips them | Decide whether to strip the domain, then test that the stripped value matches the GLPI login |
| User principal name | jsmith@example.com (illustrative) | The full UPN with the domain suffix, if the web server passes it | Choose whether GLPI accounts use the UPN or the short name, and confirm the suffix handling in your environment |
| sAMAccountName | jsmith (illustrative) | The short logon name, typically without a domain part | Verify that this value is the one stored in the GLPI user login field for each account |
| GLPI login field | Login name stored on the GLPI user record | The value GLPI compares against the incoming variable to find the account | Align the stored login with the chosen format, and test with a known account and a non-existent account |
| Case and character handling | Jsmith versus jsmith (illustrative) | Possible mismatch if the server preserves case and GLPI compares it differently | Test mixed-case sign-ins and document the normalization your configuration expects |
| Proxy-supplied identity header | Custom header set by a reverse proxy (illustrative) | Only trusted if the proxy strips client-sent copies of the header | Do not use a header that clients can set, and confirm the proxy overwrites it on every request |
Controls that keep the sign-in path trustworthy
REMOTE_USER moves identity trust from GLPI's login form to the web server in front of it. The controls below keep that trust in place: who can reach GLPI, which headers GLPI will believe, and how administrators stay accountable. Confirm each one against the GLPI version you run before you rely on it.
Accept identity only from the web server
GLPI believes whatever username arrives in the variable it is configured to read. If a client can reach the GLPI application path directly, it can present that variable itself and sign in as anyone. Block direct access to the application path so that every request passes through the authenticating Apache, Nginx or IIS layer, and test that a request sent without Kerberos is refused. Confirm how your web server sets the variable and whether it clears any value the client sent.
Refuse client-supplied proxy headers
Headers such as X-Forwarded-User are easy for a client to forge. Trust them only when the reverse proxy in front of GLPI removes any copy the client sent and then sets the value itself. Otherwise, a user can add the header to a request and impersonate another account. Ask your team to test with a hand-crafted header from outside the proxy and confirm that GLPI ignores it.
Restrict network paths to GLPI
Limit which network segments can open connections to the GLPI web server, and place the application behind the same authentication point on every route. Users on the corporate network, agent traffic and administrative access may need different rules. Document each allowed source, and review the list when proxies, load balancers or VPN ranges change, because a new path can bypass the sign-in layer.
Keep a tested local administrator
If Kerberos or the directory fails, an administrator still needs a way into GLPI. Keep one local break-glass account with its own password, stored outside the directory, and apply a password policy to it. Test the sign-in path at intervals so that the account works when it is needed. Confirm with your GLPI version which local login options and password settings are available.
Review sessions and step up administrative actions
GLPI 12.0.0 adds a view of active user sessions with the ability to revoke them, and step-up authentication for certain administrative actions. Use session review to spot unexpected sign-ins and revoke them quickly after a suspected compromise. Confirm which actions require step-up and whether those prompts still work when sign-in is handled by the web server, since an SSO-only path may not present a second factor the way a login form does.
Protect encryption keys and backups
GLPI stores its encryption key files, including glpi.key and glpicrypt.key, and the update procedure requires backing them up with the database and files. A backup of the database without these keys may not restore encrypted values, and a copy of the keys alongside an unprotected database lets anyone decrypt stored secrets. Restrict file permissions, store backups encrypted and access-controlled, and test a restore on a separate host.
Common REMOTE_USER failures and how to fix them
This table pairs each symptom seen with Windows integrated SSO in GLPI with its likely cause and a first direction to check. Treat each fix as a starting point to verify in your own web server and directory configuration, not a guaranteed remedy. The main takeaway is that most failures come from the web server layer, identity naming, or trust in headers, so check those before changing GLPI settings.
| Symptom | Likely cause | Fix to check |
|---|---|---|
| Users see the login form instead of signing in | The web server authentication module is not loaded, or the protected path does not include the GLPI login URL | Confirm the Kerberos or SPNEGO module is enabled and that the GLPI path is inside the protected location. Test with a domain-joined browser that can send a Kerberos ticket |
| Users are created as duplicates or cannot match an existing account | The REMOTE_USER value includes a domain suffix such as a realm, or its letter case differs from the stored login | Compare the raw value with the stored login in GLPI. Review the setting that strips domains and check how the directory stores the name |
| Users reach GLPI without authenticating | A forwarded header such as one carrying the user name is accepted from clients, or a path that skips authentication is exposed | Confirm the proxy overwrites or removes incoming identity headers, that GLPI trusts only the authenticated variable, and that no alternate path bypasses the protected location |
| Users are signed in with the wrong profile or entity | No authorization rule matches the incoming user, so default access applies | Review the authorization assignment rules for the SSO login method and test them with a sample account. Confirm the attribute the rule reads is populated for that user |
| Logins fail after a web server or GLPI upgrade | The authentication variable name, module configuration, or proxy layout changed during the upgrade | Compare the web server configuration and the variable GLPI reads against your pre-upgrade baseline. Check the GLPI release notes and test login on a staging copy before changing production |
Questions buyers ask before configuring GLPI SSO
How much effort does GLPI SSO with REMOTE_USER take to set up?
The effort depends mostly on how many entry points you expose and how your web server already handles Kerberos. A single intranet hostname behind one Apache or IIS site is a bounded task. Effort rises when GLPI is reached through several hostnames, when some users must keep local or LDAP sign-in, when there are reverse proxies to configure, or when you have several domains and need to decide how logins are normalized. Testing scope is the other major driver: each browser, client and fallback path needs a test case. Ask any partner to size the work from a written list of entry points, domains and fallback requirements.
Can our own team configure GLPI REMOTE_USER SSO without a partner?
Yes, a team with the right skills can do it in-house, but the work spans three areas. You need web server administration to enable Kerberos or Negotiate authentication and to set the variable GLPI receives, Kerberos knowledge to handle keytabs, service principals and browser delegation settings, and GLPI administration to configure the external authentication source, map accounts and test profiles. Many teams have one of these skills but not all three. A partner is most useful when the skill gap sits in Kerberos or in the web server layer, or when the team wants a documented, tested runbook before go-live.
How long does a GLPI Windows SSO project usually take?
No reliable duration can be given without the environment details, so treat any figure you hear with caution. The timeline is set by the number of web server hosts, whether the domain layout is simple or spans several forests, how quickly service accounts and keytabs can be issued, how many change windows you have, and how long user acceptance testing takes. Approvals from the identity and security teams often take longer than the configuration itself. Ask for a written plan that lists each dependency and who owns it, so you can see where the schedule is actually constrained.
What do we need to provide before SSO work starts?
Plan to provide access and decisions in five areas: read access to the relevant Active Directory domains and the Kerberos realm details, a service account or keytab process approved by your identity team, a small pilot group of users and at least one test account for each profile, a change window on the web server and GLPI host, and network access between the browser, the web server and the domain controllers. Also confirm which accounts must keep password sign-in as a fallback. Missing any of these usually surfaces as a delay in the middle of the work rather than at the start.
Is REMOTE_USER safe compared with CAS or an LDAP connection?
REMOTE_USER is safe when the web server performs the authentication and GLPI only trusts the variable the server sets. The main risk is spoofing: if a reverse proxy or client can supply the user header directly, anyone can claim any identity. Keep the header that carries the user name set only by the authenticating server, strip any incoming copies at the edge, and avoid trusting generic proxy headers. CAS and directory connections move the trust into a protocol with its own login pages and logout handling, which can be easier to reason about for some teams. Choose by threat model, and have a security engineer review the header path and the fallback accounts.
Will REMOTE_USER SSO survive GLPI upgrades and plugin reactivation?
The web server configuration is independent of GLPI's files, so a normal application update does not usually remove it, but you should verify it after every update. The GLPI update procedure requires backing up the database, files and config directory, including glpi.key and glpicrypt.key, replacing application files and running php bin/console db:update. Since GLPI 11.0, plugins are suspended after a new version is detected and must be reactivated after major updates. Add a post-update check that signs in with a test account through the SSO path and confirms that the expected profile and entity still apply. Check the GLPI installation update documentation before each upgrade.
How DeployOpen scopes and delivers GLPI SSO work
DeployOpen plans Windows integrated SSO for GLPI with REMOTE_USER inside infrastructure you control, from the web server authentication module to the GLPI login path. Engagements are fixed-scope, so the header choice, domain handling and proxy trust model are agreed in writing before any configuration changes are made.
How we scope
- Review the web server, reverse proxy and Kerberos or other authentication module that will set the user variable.
- Agree in writing which header variable carries the login and how domain suffixes are stripped.
- Document which trusted proxies may set authentication headers and which requests must be rejected outright.
How we build
- Configure the web server so the authenticated identity reaches GLPI in a single, verified variable.
- Set up GLPI's external authentication for REMOTE_USER and test the order of authentication methods used at sign-in.
- Test with valid, malformed and spoofed header requests to confirm that only the intended path can establish a session.
How we hand over
- Deliver the web server configuration, GLPI authentication settings and a record of the test cases that were run.
- Provide a runbook covering login failures, expired Kerberos tickets, proxy changes and rollback to the local login path.
- Walk through the administrator account that must remain usable if the integrated sign-in path is unavailable.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, so SSO changes are reviewed after GLPI updates.
- Re-test the header path after GLPI major upgrades, web server changes or any change to the reverse proxy.
- Confirm with your team how identity changes, such as account renames or domain moves, will be handled in the retainer scope.
