> For the complete documentation index, see [llms.txt](https://help.glpi-project.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.glpi-project.org/documentation/modules/configuration/authentication/other.md).

# Other external authentication methods

The integration of GLPI and authentication sources beyond internal, LDAP, and IMAP is configured from the **Setup > Authentication > Other authentication methods** menu.

### Central Authentication Service (CAS)

The configuration of a CAS server is comprised on the address of the server and its port (default 443). A base directory can be specified if needed. The return web address parameter allows you to redirect the user to a specific page after they log out from GLPI.

Once the CAS authentication is activated, each authentication is automatically redirected to the CAS server. In order to log into an internal account or one authenticated through a different method, you have to add `?noAUTO=1` to the login URL.

The php-curl or php-dom extensions are required to be enabled for CAS authentication to function.

### x509 certificate

The Email attribute for x509 authentication tells GLPI to look at the value of this attribute in the `SSL_CLIENT_S_DN` HTTP request variable passed by the authentication system.

It is possible to restrict the accepted values for the O, OR, and CN fields of the client certificate. In order to specify multiple values for each field, you may separate each value with the `$` symbol.

### Other automatic authentications

GLPI can rely on other external systems to authenticate users such as:

* Basic Apache authentication
* Windows domain authentication
* Authentication coming from an authentication server like LemonLDAP::NG, Shibboleth, etc.

When the user wishes to reach GLPI, GLPI checks the presence of a server variable storing the login/username. If the variable is present, the authentication is allowed to be done. We can map the data transmitted by the authentication system with the fields of the user account of GLPI (name, first name, email, language...). To finish, the controls of authorizations are carried out. An option allows to remove the domain of the user's login (Ex: <testuser@example.com> > testuser).

The list of possible variable names is configurable, although the most common ones are already provided by GLPI. See Configuring headings.

### SSO authentication in GLPI via a web server

In a Single Sign-On (SSO) architecture via the web server, it is not GLPI that performs the identity verification, but the upstream web server.

Example: if you use Windows authentication (Kerberos/NTLM) with Apache and the `mod_auth_gssapi` module, Apache communicates directly with the Active Directory domain controller.

Once the user is authenticated (for example, "John Smith"), Apache transmits this information to GLPI through a server variable. GLPI then simply retrieves the user ID without managing the authentication itself.

### Authentication variables used by GLPI

GLPI retrieves the user ID from variables set locally by the web server after a successful authentication. Here are the supported ones:

{% hint style="danger" %}
**Security warning**

Never use variables transmitted through HTTP headers (`HTTP_REMOTE_USER`, `HTTP_AUTH_USER` or any variable prefixed with `HTTP_`), nor `PHP_AUTH_USER`. Their value can be forged by the client, allowing anyone to log in to GLPI under any identity without authentication.

Only use variables set locally by the web server after a successful authentication.
{% endhint %}

#### 1. REMOTE\_USER

* Origin: industry standard (Apache, IIS, Nginx).
* Description: the most widely used and secure variable for SSO. It is populated by the web server after successful authentication (Kerberos, NTLM or LDAP).
* Recommendation: for integrated Windows authentication, always use `REMOTE_USER`.

#### 2. REDIRECT\_REMOTE\_USER

* Origin: Apache server with mod\_rewrite.
* Description: technical fallback variable. During an internal redirect via .htaccess, Apache may prefix `REMOTE_USER` with `REDIRECT_`.
* Use case: if authentication works on the homepage but not on some subpages, use this variable.

#### 3. USERNAME

* Origin: system environment (mostly Windows/IIS).
* Description: this variable comes from the environment of the process running PHP. It is only relevant when the web server passes the authenticated user's session to the PHP process.

{% hint style="warning" %}
**Before using USERNAME, check that:**

* the value matches the login of the user authenticated by the web server, and not the service account running PHP or the web server (e.g. `IUSR`, `SYSTEM`, `www-data`). Otherwise, every visitor would be logged in under the same identity;
* an unauthenticated request does not return any value for this variable;
* no GLPI account matches the name of a service account;
* `REMOTE_USER` cannot be used instead, as it remains the recommended option.
  {% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://help.glpi-project.org/documentation/modules/configuration/authentication/other.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.