How GLPI CAS authentication works and when to use it
Many IT teams want GLPI users to sign in with the same credentials they use everywhere else, through the CAS server they already run, instead of maintaining a separate GLPI password for every technician and requester. GLPI supports CAS as an external authentication method, so this is a configuration project rather than a code change. The work covers four parts: connecting GLPI to the CAS server, mapping the identity returned by CAS to a GLPI user, deciding what happens when a user signs out of GLPI and of CAS, and keeping a deliberate local administrator path for recovery. Each part has decisions that are easy to defer and expensive to fix later.
The GLPI authentication documentation is the reference for exact CAS options, and those option names and behaviors can change between major versions. Before you write any settings down, confirm them against the GLPI version you run or plan to run, including any changes planned for the GLPI 11 and 12 upgrade path. Ask your CAS administrator which attribute carries the login name and which carries the email address, because GLPI needs a stable identifier to match each person to one account. Also confirm how the CAS server handles single logout, since a user who signs out of GLPI may still hold a live CAS session elsewhere.
Plan the local administrator path before you enable CAS, not after. If the CAS server, its certificate or the network path to it fails, the only way back into GLPI may be a local account, and that account must still work. Decide which local accounts remain, who holds their credentials, where those credentials are stored, and how you will test that they sign in. Record the test as part of your change window so the first time it runs is not during an outage. Teams that skip this step often discover the gap only when they need the fallback most.
What you need in place before enabling CAS in GLPI
CAS sign-in changes how every GLPI user reaches the application, so the GLPI instance, the CAS server and the user accounts must be ready before anything is switched on. Each card below is a condition to confirm in writing and test in a non-production copy first.
A supported GLPI version
Confirm the GLPI release you run against the release notes before planning the CAS work, since the 12.0.0 notes describe changes to sessions and step-up authentication that affect sign-in. Check PHP and database versions against the installation prerequisites: the README on the main branch lists PHP 8.3 or later with MariaDB 10.11 or later or MySQL 8.0 or later, while the 11.0 installation docs list PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6. Use the version your team actually runs, and confirm which list applies to it.
A working CAS server
Record the CAS server's exact service URL, the login and logout endpoints, and the full certificate chain that GLPI's PHP runtime must trust for the connection. Confirm that the CAS server can issue tickets for the GLPI hostname you will publish, because a mismatch between the public URL and the registered service is a common cause of failed sign-in. Test the CAS flow with a separate application before GLPI depends on it.
A tested user population
Confirm that every GLPI user who must sign in via CAS has a login name that matches the identifier the CAS server returns, including case and any domain suffix. Export the list of GLPI accounts and compare it with the directory the CAS server authenticates against. Mismatched names create duplicate or orphaned accounts, and those are harder to untangle once users have been assigned profiles and entities.
A named CAS owner
Assign one person or team as the accountable owner of the CAS server, with authority to change its service registrations, certificates and attribute release. Agree who GLPI administrators contact when sign-in fails and how urgent certificate or service changes are handled. Without a named owner, a certificate expiry can lock every user out of GLPI with no one responsible for the fix.
A break-glass plan for local administrators
Before enabling CAS, identify at least one local GLPI administrator account that can sign in without the CAS server, and confirm its password is stored under your secrets controls. The noAUTO bypass exists for this purpose, but it only helps if the account works and the people who must use it know the procedure. Test it in the non-production copy so the bypass is not discovered for the first time during an outage.
A non-production GLPI copy
Build a non-production copy of GLPI with a restored database and the same web server layout, then test sign-in, logout return URLs and the noAUTO bypass there first. Use the GLPI update and backup procedure as a reference for taking a restorable copy, and keep the configuration directory and encryption keys with the copy so that the test matches production. Record every test result so the production change has a documented rollback.
Configuring CAS in GLPI step by step
This sequence takes CAS sign-in from a server registration to a tested, company-wide login. Each stage closes with a check, so a fault is caught with a single pilot account instead of blocking every user.
Confirm the CAS server and service registration
The identity team confirms the CAS server host, port and context path, and that the CAS administrator has registered your GLPI URL as an allowed service. Record the exact service URL that GLPI will send, including the scheme and path, because a mismatch is the most common cause of a failed login. Ask the CAS owner which protocol version the server runs and whether it issues the user identifier you expect. Done means you hold a written record of the CAS endpoints and the registered service URL, agreed with the CAS owner.
Export and trust the CAS certificate chain
Export the full certificate chain presented by the CAS server, including any intermediate authority, and install it in the trust store that the GLPI host's PHP runtime uses for outbound TLS. Confirm the chain from the GLPI host with a plain TLS connection test to the CAS login URL, which should complete without a certificate error. Done means the GLPI host validates the CAS certificate chain without warnings, and the check is recorded with the date and the certificate fingerprint.
Create the CAS authentication server entry
As a super administrator, open the authentication settings in GLPI and add a new external authentication server of the CAS type. Give it a name that identifies the environment, such as the CAS server name, so administrators can tell it apart from LDAP or local entries later. Leave it inactive for users until the later steps are complete. Done means the entry is saved and appears in the authentication server list with the CAS type shown.
Set host, port, path and certificate
Enter the CAS server host, port, and context path exactly as confirmed in the first step, and attach the certificate or trust reference required by your GLPI version. Confirm each field name against the GLPI authentication documentation for your release before saving, since labels can differ between versions. Save the entry and reopen it to verify the values persisted. Done means the reopened record shows the same host, port, path and certificate setting you entered.
Define the login attribute mapping
Decide which CAS attribute carries the GLPI login name and which one carries the email address, then map them in the CAS configuration of GLPI. The login value must match the name GLPI uses for existing accounts, or CAS sign-in creates a second, unlinked user. Check the mapping against a real account in the CAS server's attribute release. Done means the mapped attribute returns the expected login for a known test user, and the mapping is written down for the change record.
Test sign-in with one pilot account
Choose one pilot user who has a known profile and entity, and sign in to GLPI through the CAS login page with that account. Confirm that the session opens, that the user's name and entity match the expected values, and that the profile grants only the rights it should. Repeat with a second account that should be denied, if your CAS policy blocks some users. Done means the pilot signs in successfully, a session is visible in GLPI, and the denied case fails as expected.
Configure and test the logout return URL
Set the URL that users land on after they sign out of GLPI and from the CAS server, and confirm the value against the GLPI authentication documentation for your version. Sign out from the pilot session and verify the browser returns to the expected page, not an error or a login loop. Done means a logout returns the pilot to the expected page and a new visit to GLPI requires signing in again.
Enable CAS for all users after the pilot passes
Only after the pilot sign-in, denial and logout checks all pass, make CAS the authentication path for the wider user base and document how the noAUTO setting is used for local administrator accounts, so those accounts can still sign in if CAS is unavailable. Confirm the bypass behavior with a test using a local administrator in a non-production session. Done means the wider user base signs in through CAS, the local administrator bypass has been tested, and the change is approved and recorded.
Which identity data CAS passes and how GLPI uses it
This table compares the identity data a CAS login can bring into GLPI, where each item lands in the user record, and the decision to make before go-live. Read each row as a question your CAS and GLPI owners must answer together, because the login name, email and provisioning choices shape every later access rule. The main takeaway is that the team must confirm what their CAS server returns before settling how GLPI matches and creates users.
| Identity data item | Where it appears in GLPI | Decision before go-live |
|---|---|---|
| Login name | The GLPI username used to match an existing account on sign-in | Confirm which CAS field carries the login name and agree whether case is ignored and whether domain suffixes are stripped before matching |
| Login case and domain handling | Matching of CAS login names to existing GLPI usernames | Test mixed-case and domain-qualified logins with real staff accounts so duplicate user records do not appear |
| Email address | The email field on the GLPI user record used for notifications | Confirm the CAS server returns a mail attribute, and decide whether GLPI overwrites an existing address on each sign-in |
| User record creation | Whether GLPI creates a new user on first CAS sign-in or requires an existing record | Choose between pre-creating accounts and automatic creation, and agree who approves new users and how leavers are deactivated |
| Profile and entity assignment | The profile and entity granted to the user after sign-in | Plan this as a separate workstream using authorization assignment rules, and confirm which CAS attributes, if any, drive assignment |
| Local administrator accounts | Accounts that must still sign in when CAS is unavailable | Decide which local accounts keep password sign-in and how the noAUTO bypass is documented, tested and restricted |
| Attributes returned by the CAS server | Only the fields GLPI is configured to read at sign-in | Ask the CAS owner to confirm the exact attribute names returned for test accounts before writing any mapping |
Why logout return URLs cause most post-login complaints
Most complaints about CAS sign-in arrive after people log out, not when they log in. A user clicks logout, lands on a page on the wrong host, gets bounced back into a login prompt, or sees a stale session still active in another tab. These symptoms usually come from one mismatch: GLPI ends its own session, the CAS server ends the single sign-on session, and the browser is then sent to a return URL that may not be a page the user can use. These are three separate actions, and each can succeed or fail on its own. Plan them as three steps, not one.
A logout in this flow has to clear the GLPI session cookie on the GLPI host, clear the CAS ticket granting session on the CAS host, and then send the browser to a destination that both sides accept. If the CAS session survives, the next visit to GLPI can sign the user straight back in, which looks like a loop. If the GLPI session survives, users see a page that still shows their name after they believed they had signed out. The return URL is where these two sides meet, so it has to match what the CAS service registration expects and what the public GLPI address is. A reverse proxy that rewrites the host, a hostname change during a migration, or a second GLPI address used for internal access can each produce a return URL the CAS server does not recognize. Confirm the exact logout parameters, the service registration and the public URL setting against the GLPI version you run, and record them in your runbook. Test logout in every browser and client you support, including private windows, mobile browsers and any desktop client that opens GLPI in an embedded view, because cookie and redirect behavior differs between them.
Keeping local administrator access with the noAUTO bypass
When CAS is healthy, every user should reach GLPI through the central login page. The administrator's job is to confirm that the CAS configuration maps users to the correct GLPI accounts and that local password sign-in is not offered to people who should only use CAS. Local accounts still exist in the GLPI database, so they remain a path in until the team deliberately closes it. Treat that gap as a control to review, not as a default that someone else will notice.
- Confirm the authentication order: GLPI tries authentication methods in a fixed order, so check where CAS sits relative to the internal database and any directory source.
- Review which local accounts exist: List accounts that can sign in with a local password and record the owner of each one.
- Check user provisioning: Confirm that users arriving through CAS are created or matched correctly and receive the expected profile.
- Watch for shadow sign-ins: Look for users who still sign in with a local password after CAS went live.
- Record the normal path: Document the URL and steps that a user follows so help desk staff can recognize a broken login.
Before go-live, confirm that the normal sign-in path and the local account inventory match what the security team approved.
If the CAS server is down, misconfigured or its certificate has expired, no user can authenticate through it. Without a local path, an administrator cannot reach GLPI to fix the setting, disable a rule or restore access for a user who needs urgent help. A named local administrator account, reachable only under controlled conditions, is the usual way to avoid being locked out of the system that tracks your assets and tickets. The exact invocation of the bypass depends on the GLPI version and configuration, so confirm it against the documentation for your release before relying on it.
- Use a named account: Only a pre-approved administrator account should be able to use the bypass, and each person should have their own account.
- Invoke the bypass deliberately: Confirm with the vendor documentation for your version how the noAUTO parameter is passed at sign-in, and record the exact steps.
- Log the use: Note who signed in through the local path, when and why, and review the entry afterward.
- Restore CAS promptly: Fix the external service, then confirm normal sign-in works before closing the emergency session.
- Rotate credentials after use: Change the local password if it was used during an incident and confirm the account is still limited to its approved role.
Check that the break-glass account, its password storage and the logging process are all documented and owned by named people.
A planned change, such as a CAS certificate renewal, a server migration or a change to the service URL, carries a predictable risk of breaking sign-in. The administrator should plan the window, prepare a rollback and verify that the local path works before the change begins. Scheduling the local path test in advance means the team is not testing it for the first time during an outage. The change record should state who can use the bypass during the window and when that access ends.
- Test in a non-production instance: Apply the CAS change to a copy of GLPI first, including the logout return URL, and confirm sign-in and sign-out.
- Verify the bypass before the window: Sign in with the named local administrator account, check the access and close the session.
- Define the rollback: Write the steps to restore the previous CAS settings and the owner who approves that decision.
- Limit the window: Record when the bypass is available, who may use it and when it is disabled again.
- Confirm logout behavior: Check that users are returned to the intended page after sign-out, since a wrong return URL can strand them.
After the change, confirm that the bypass is closed for everyone except the approved accounts and that the change record reflects the final state.
Securing the CAS login path in GLPI
CAS moves password checks to a central server, so GLPI's security depends on how it trusts that server, which accounts can bypass it, and how sessions and failures are watched. The cards below cover the controls that connect those points and the checks to confirm on your own version and network.
Validate the CAS server certificate
GLPI sends users to the CAS server and trusts the ticket it gets back, so a spoofed or misconfigured CAS endpoint can undermine every sign-in. Keep TLS certificate verification enabled between GLPI and the CAS server, and make sure the CA bundle GLPI's PHP runtime uses trusts the issuing authority. Confirm this on the staging instance before go-live, and never switch verification off to get past a certificate error. Fix the chain instead.
Limit local administrator accounts
Local GLPI accounts remain a second way in, and the noAUTO bypass exists so administrators can still sign in when CAS is down. Keep the list of local administrators short, name each account to a person, and store its password in a privileged-access vault rather than in a shared document. Test the break-glass sign-in on a schedule so the account works when it is needed.
Restrict GLPI and return URLs
The GLPI base URL and the service and logout return URLs must point to hostnames you control. Register only those exact URLs with the CAS server, avoid wildcards, and confirm that the CAS service definition matches the public name users type. Review these values after any reverse proxy or DNS change, because a loose return URL can send users to a page an attacker controls.
Review session handling in GLPI 12
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. Confirm both features exist and behave as expected on the exact version you plan to run, and test that a revoked session is refused on the next request. Set session lifetime and cookie settings to match your identity policy.
Log and monitor failed CAS logins
CAS failures can come from a wrong password, an expired ticket, a clock skew between servers, or a credential-guessing attempt, and each needs a different response. Forward GLPI authentication events and the CAS server's own logs to your central log platform, and alert on spikes by account and source address. Review the events against a baseline so that a rise in failures is noticed early.
Disable leavers across both systems
A GLPI account can keep working after the directory account is removed if the CAS server is not the only gate, for example through a local account or an active session. Define who disables the CAS identity, when GLPI's user record is deactivated, and how open sessions end. Run the process as a checked procedure with a named owner, and confirm the sequence with your identity team before you rely on it.
Common CAS sign-in failures and how to resolve them
This table pairs each common CAS sign-in symptom in GLPI with its likely cause and a first check to run. Read it top to bottom when a sign-in problem appears, starting with the check that costs the least time. Most failures trace back to a mismatch between the CAS server, the URL GLPI is configured with and the authorization rules applied after login.
| Symptom | Likely cause | First check |
|---|---|---|
| Browser shows a certificate error when GLPI contacts the CAS server | The CAS server certificate is not trusted by the GLPI host, or an intermediate certificate is missing from the chain | Run a TLS check from the GLPI host against the CAS server and confirm the full chain is presented and the CA is trusted by the PHP runtime |
| Redirect loop after the user enters CAS credentials | The GLPI URL in the CAS configuration differs from the public address users type, such as http versus https or a different host name | Compare the configured service URL with the public GLPI address, including scheme, host name and any path prefix |
| Valid CAS login, but no GLPI session is created | The CAS ticket is not validated by the GLPI host, often because the validation request is blocked or the CAS server rejects the service URL | Review the GLPI and CAS logs for the ticket validation step and confirm the service URL registered on the CAS server matches GLPI's |
| Logout returns to a wrong or unreachable page | The logout return URL points to an internal host name, an old address or a page the user cannot reach from outside the network | Check the logout return URL setting against the address users can open from their browser and test logout from a clean session |
| User has the correct CAS account but lands with no profile or entity | No authorization rule matches the attributes sent after login, so GLPI creates the user without the expected profile or entity | Review the authorization rules and confirm which attribute values the user carries, then test the rules with that user's account |
| Local administrator cannot sign in during a CAS outage | Login is forced through CAS for all accounts, and the local administrator has no bypass set for direct database authentication | Confirm the noAUTO bypass is set for the named local administrator and test that account before any planned CAS change |
| Same person signs in with a different case or domain form and gets a second account or a failed login | The CAS identifier, the GLPI login field and the directory name differ in case or include a domain prefix or suffix | Compare the exact login string returned by CAS with the stored GLPI login and decide on one normalized form before go-live |
What buyers ask before they configure CAS for GLPI
Can our team configure CAS for GLPI in-house, or do we need a partner?
A team with GLPI administration experience and someone who runs the CAS server can usually do the core configuration in-house. The harder parts are rarely the login form itself. They are agreeing which CAS attributes map to GLPI accounts, deciding how local administrator accounts stay reachable when CAS is down, and proving that logout returns users to the right place. If no one on your team has tested CAS logout across a GLPI update, a partner can run that verification and document it, which is where outside review tends to save the most rework.
What drives the cost and effort of a GLPI CAS project?
The main drivers are how mature your CAS deployment already is, how many user populations sign in (for example employees, contractors and service desk staff who may come from different sources), whether logout must end the CAS session as well as the GLPI session, how much testing you need across browsers and roles, and how many GLPI instances must be configured. Each additional instance repeats the configuration and the test cycle. Ask any partner to split the quote into discovery, configuration, testing, documentation and handover, and to state which items are one-time and which recur, such as retesting after upgrades.
How long does a GLPI CAS authentication project usually take?
Duration depends on the same factors as cost: the state of the CAS server, the number of user populations, the logout behavior you require and the test scope. A single instance with an existing, well-documented CAS server and one user population is a much smaller task than a multi-instance rollout that must also satisfy a security review. Your timeline should start after you confirm CAS access and a test environment, because waiting on those inputs is the most common source of delay. Ask for a schedule tied to the written scope rather than a general estimate.
What do we need to provide before the work starts?
You need administrator access to the CAS server or a named contact who can make changes there, a test environment that resembles production closely enough to validate sign-in and logout, and a named approver who accepts the test results. You also need an owner for the break-glass local administrator accounts, since the noAUTO bypass lets those accounts sign in without CAS and must be controlled, documented and periodically tested. Confirm the GLPI version in use, because upgrade and plugin behavior differs across releases. Agree who holds the CAS service registration and certificate renewal tasks as well.
Does our organization need a CAS server before we can use CAS with GLPI?
Yes. GLPI connects to an existing CAS server, so the project depends on one being available, trusted by your users and maintained by someone accountable for it. If you do not run CAS today, the work expands to include selecting and deploying a CAS service or using an identity provider that offers CAS-compatible sign-in, which is a separate project with its own cost and risk. Confirm the CAS server's ownership, availability target and certificate management before you commit to this path, because GLPI cannot provide those for you.
How does CAS compare with LDAP or REMOTE_USER for our GLPI sign-in?
The choice depends on where your identities already live and how your users sign in. LDAP authentication checks credentials against a directory that GLPI queries directly, which suits organizations whose accounts are managed there. REMOTE_USER passes a username that the web server has already authenticated, which suits integrated Windows sign-in but depends on the web server being trusted and configured correctly. CAS fits when a central single sign-on service already brokers logins for many applications and you want GLPI to follow that policy. Review the GLPI authentication documentation to see the order in which sources are tried, and confirm how each method handles accounts that exist in more than one place.
What happens after go-live when GLPI or the CAS server changes?
Expect recurring work. Each GLPI update requires a backup of the database, the files and the config directory, including the encryption keys, followed by running the database update step. Since GLPI 11.0, plugins are suspended when a new version is detected and must be reactivated after major updates, so plugins that touch authentication need retesting. Logout behavior should be checked again after every GLPI update and after CAS server changes, because a version change can alter redirects or session handling. Ask any partner whether retesting and upgrade support are included in the initial scope or offered as an ongoing retainer.
Why is the break-glass administrator account a decision for us to own?
When CAS signs users in, a failed CAS server or a misconfigured service can lock everyone out of GLPI, including administrators. The noAUTO bypass lets local administrator accounts sign in directly, which is a deliberate exception to your central sign-in policy. Someone accountable must decide which accounts qualify, where their credentials are stored, how access is logged and how often the path is tested. Auditors and security reviewers usually ask for this record, so assign the owner before go-live rather than during an incident.
How DeployOpen scopes, builds and supports GLPI CAS sign-in
DeployOpen plans, implements, documents and supports GLPI inside infrastructure you control, including CAS sign-in configured against your existing CAS server. Engagements are fixed-scope, with the CAS settings, logout behavior and local administrator access agreed in writing before any configuration changes are made.
How we scope
- Inventory the CAS server version, its service URLs and the attributes it returns for each user.
- Document which GLPI users must sign in through CAS and which local accounts keep access through the noAUTO bypass.
- Agree in writing how logout return URLs, the GLPI base URL and certificate trust are handled for your environment.
How we build
- Configure the CAS authentication server in GLPI and test sign-in with a set of pilot accounts before wider rollout.
- Verify logout return behavior from the browser and confirm that the noAUTO bypass works for break-glass administrators.
- Test failure paths, including an unreachable CAS server, expired tickets and users missing from the directory.
How we hand over
- Deliver a written configuration record with the CAS settings, the URLs used and the reasons for each setting.
- Document the local administrator accounts that bypass CAS, where their credentials are held and how access is reviewed.
- Walk your administrators through the test cases so they can repeat sign-in and logout checks after future changes.
How we support
- Review CAS-related settings when GLPI is upgraded, since authentication changes can affect sign-in after an update.
- Support changes to the CAS server, its certificates or its URLs through a retainer agreed in writing.
- Re-run the agreed sign-in and logout tests after each change so regressions are caught before users are affected.
