GLPI SSO and identity integration guide

How GLPI single sign-on decides who gets in and what they can do

GLPI can authenticate against LDAP or Active Directory, trust a reverse proxy that passes the REMOTE_USER value, or use a marketplace plugin for SAML or OAuth sign-in. The harder problem is mapping each authenticated identity to the right profile and entity, because a successful sign-in only proves who someone is. An IT team that wants staff to use their directory accounts instead of separate GLPI passwords has to decide which method fits its identity source, how users and groups enter GLPI, and which rules grant access. Those decisions determine who can open tickets, see assets and change configuration, so they deserve the same review as the login page itself.

The GLPI user documentation describes authentication being tried against the internal database first, then LDAP directories, then IMAP mail servers, and then other external methods such as REMOTE_USER. That order matters for local accounts. If a local account shares a login name with a directory user, GLPI may accept the local password before the directory is consulted, so the directory password never gets checked for that person. Confirm in your version how a username that exists both locally and in the directory is handled, and decide whether local passwords should remain usable at all once the directory is the intended source. Test an account that exists in both places before go-live and record which path succeeded.

Identity work becomes harder than it looks once people change roles and leave. A user promoted into a support group in Active Directory will not receive the matching GLPI profile until the import or assignment rule runs again. A user removed from a group may keep rights granted earlier unless a process removes them. Disabling a leaver's directory account blocks new directory logins, but it does not by itself settle existing sessions, open tickets or assets assigned to that person. Service accounts used for LDAP binds, API clients or proxy integrations fall outside normal staff life cycles, so each one needs a named owner, a documented purpose and a scheduled review.

Every single sign-on design also needs a way in when the directory, identity provider or reverse proxy is unavailable. Decide in advance who holds a local administrator account, where its credentials are stored, how it is tested and under what conditions it is used. Check the proxy path carefully as well. REMOTE_USER trusts the header that the proxy sets, so a misconfigured proxy that forwards a client-supplied header could let a visitor claim another identity. Ask the implementer to show how the proxy strips inbound identity headers and to demonstrate that a direct request to GLPI cannot bypass the proxy.

Before choosing a method, write down the source of truth for each profile, the rule that maps directory groups to GLPI profiles and entities, the owner of each service account and the steps taken when someone leaves. Then ask for a test matrix that covers a new hire, a role change, a leaver, a directory outage and a proxy header test. Profile and entity structure is covered in the implementation plan section, and session review and step-up controls are covered in the hardening section, so this work should connect those decisions rather than repeat them.

Which identity method fits your directory and login policy

This table compares four ways to sign users into GLPI: LDAP or Active Directory bind, REMOTE_USER behind a reverse proxy, a marketplace SAML or OAuth plugin, and local break-glass accounts. Read each row against your directory type, MFA location and existing gateway, then weigh the operational cost column before committing. Confirm plugin compatibility with your target GLPI version before choosing any plugin-based option.

Method	When it fits	Operational cost	Confirm before choosing
LDAP or Active Directory bind	Users and groups live in an on-premises directory that GLPI can reach over the network, and password checks can stay with the directory.	GLPI holds a service bind account and must reach the directory server. Directory outages block logins unless local break-glass accounts exist. MFA is not enforced by GLPI itself.	Directory reachability from the GLPI network segment, LDAP or LDAPS settings, and which group attributes you need for profile assignment.
REMOTE_USER behind a reverse proxy	An existing proxy or SSO gateway already authenticates users and can pass the username in a header, and MFA is enforced there.	Trust rests on the proxy: GLPI must only be reachable through it, or users can spoof the header. Proxy or gateway downtime stops all logins. Proxy configuration becomes part of GLPI change control.	That the proxy strips inbound copies of the header, and how it passes the identity to the web server for your specific gateway product.
Marketplace SAML or OAuth plugin	You use a cloud identity provider or need federated sign-in with MFA at the provider, and a maintained plugin exists for your GLPI version.	Plugin upkeep is recurring: each GLPI update can break compatibility, and plugins are suspended after a new version is detected until reactivated. Adds a third-party code dependency and certificate or metadata rotation work.	Plugin compatibility with your target GLPI version, its maintenance status, and whether the plugin's license and support terms fit your policy.
Local accounts kept for break-glass use	Any deployment, as a small set of named administrator accounts that work when the directory, proxy or identity provider fails.	Local passwords need their own policy, storage and rotation. Accounts must be reviewed regularly so they do not become a standing bypass. Their use should be logged and reported.	Your password policy, where credentials are stored, and who approves use. Confirm which GLPI 12 step-up controls apply to these accounts.

How to build GLPI SSO in order, with a check at each step

This sequence takes a GLPI instance from a verified staging copy to directory-based sign-in with groups mapped to profiles and entities. Each step closes with a test that proves the step worked before the next one starts, and the last step confirms that a local administrator can still recover the system.

Confirm version and prerequisites on staging
Build a staging copy of the GLPI version you plan to run in production, on the same PHP and database versions. Check the PHP and database minimums in the README and in the installation documentation for that release, because they do not always match for a given major version. Confirm the target version's requirements with Teclib' or in the release notes before you install. The step is complete when the setup requirements check passes with no blocking errors, the document root points to the public directory, and an administrator can log in to the staging copy.
Create a read-only directory bind account
Ask the directory team to create a dedicated service account in the directory with read access to the user and group containers that GLPI needs, and no write permissions. Use a long, unique password stored in your secrets manager, and set it to not expire on an interactive schedule only if your policy allows it. Do not reuse an administrator account. The step is complete when the account can bind and read the search base from the GLPI host, and a write attempt with the same account is refused by the directory.
Configure the LDAP connection with TLS
In GLPI, add the LDAP directory under the authentication settings and enter the server host, port, base DN and bind account. Use LDAPS or StartTLS so the bind password and user credentials never travel in clear text, and make sure the GLPI host trusts the certificate issued by your internal certificate authority. Confirm the certificate chain and hostname match. The step is complete when the connection test in GLPI succeeds with certificate validation enabled, and a packet capture or directory log shows no simple bind over an unencrypted channel.
Test a user lookup before importing
Before importing anything, run a test search in GLPI for a known standard user and for a known disabled account. Compare the returned distinguished name and the login attribute with what the directory shows, and confirm the search filter matches only the population you intend to allow. Record any attribute GLPI cannot read, such as a missing email field used for notifications. The step is complete when the standard user is found with the expected attributes and the disabled account is found but shows as inactive or unable to authenticate.
Import users and groups in a scoped set
Import a small, defined set of users and the groups they belong to, typically one organizational unit that contains a pilot team. Avoid importing the full directory at this stage, because it makes errors harder to trace. Confirm that group membership comes through in the form your directory uses, whether through member attributes on the group or memberOf on the user, and that nested groups behave as your design expects. The step is complete when the pilot user count matches the directory count for that scope and a sample user shows the correct group memberships in GLPI.
Map groups to profiles, entities and default access
Create group-to-profile and group-to-entity rules that give each directory group the least access it needs. Decide what a new user who matches no rule receives: the usual choice is no access until a rule grants it, and this should be agreed with the service desk owner before go-live. Write the mapping table so each group has one owner. The step is complete when a test login with a non-admin account from each pilot group lands in the expected entity with the expected profile, and a pilot user in no mapped group is denied or sees only the minimal access you chose.
Configure the SSO path: proxy header or plugin
Decide whether sign-in comes from directory authentication in GLPI, from a reverse proxy that passes an authenticated username in the REMOTE_USER header, or from a marketplace plugin for SAML or OAuth. With a proxy, the proxy must authenticate the user, remove any client-supplied REMOTE_USER header, and forward only its own value, and GLPI must be reachable only through the proxy. With a plugin, confirm it supports your GLPI version and plan to reactivate it after major updates. The step is complete when a non-admin user signs in through the chosen path, and a direct request to GLPI that presents a forged header is refused.
Keep and test a local administrator for recovery
Keep at least one local GLPI administrator account that does not depend on the directory, and store its credentials in a sealed, access-logged vault. Limit its use to recovery and document the procedure for using it. Include the procedure for disabling a failing directory connection so the local account can still sign in. Keep backups of the database, files, and the glpi.key and glpicrypt.key files. The step is complete when the local administrator signs in from the vault during a planned test, and a disabled directory account is denied while the recovery login still works.

How profile assignment rules keep access matched to roles

The step that most often produces over-privileged GLPI accounts is not the login itself but the rule that turns a directory group into a GLPI profile and entity access. Authentication answers the question of who the user is. Authorization answers what that user may do once inside. In GLPI, the first is handled by the external source (LDAP or Active Directory, or a header passed through REMOTE_USER), while the second is decided by the profiles and entity rights the import rules attach to the account. A user can authenticate correctly and still receive a profile far broader than their job requires, so the authorization side needs its own review before go-live.

Before importing anything, define a small set of profiles that match real duties, such as requester, technician, team lead and administrator, and decide which entities each one may reach. Map directory groups to those profiles, not the other way round. If the team creates profiles after the import, the rules tend to accumulate exceptions and default grants that nobody later remembers. Keep the number of profiles deliberately small so that every rule has an obvious target and every profile can be explained in one sentence to an auditor. The entity hierarchy itself belongs to the implementation plan, so this section only assumes the profiles that will reference it.

Group membership changes after first login are where access drifts. Confirm in the GLPI version you run how the rules are re-evaluated on subsequent logins, whether a user who leaves a privileged group loses the matching profile at their next sign-in, and whether previously assigned profiles are retained when no rule matches. Test this with a dedicated account that you move between groups, and record what the user can see before and after. Also decide whether a user with no matching group gets no profile at all, a minimal default requester profile, or a login refusal. The safest default is usually that no matching group means no elevated rights, and the exact rule options that enforce this must be confirmed against your GLPI release documentation.

Differences between LDAP, reverse proxy and plugin sign-in

With direct LDAP or Active Directory authentication, GLPI receives the username and password from its sign-in form and checks them against the directory by binding to the LDAP server. The trust chain runs from the user to GLPI to your directory, so the directory's password and lockout policy decide who can sign in.

Trust chain: GLPI holds the bind credentials, and the directory answers each check. Password rules, lockouts and account disablement are enforced in the directory.
Reachability: the GLPI application server must open a connection to the directory on the port you configure, normally with TLS. Confirm the certificate chain from the GLPI host itself.
Provisioning: users and groups are imported into GLPI and can be synchronized on a schedule. Imported accounts exist in GLPI, so you need a documented rule for what happens to accounts that disappear from the directory.
Logout and expiry: GLPI session lifetime is controlled in GLPI, separately from directory state. A user disabled in the directory may keep an open GLPI session until it expires, so test this case.
After a GLPI update: confirm the authentication source is still listed and passes a test bind with a service account and a test user, and confirm that group imports still map to the intended profiles.

Check these items after every update and read the release notes for the version you run, because authentication and synchronization settings are the areas most likely to change.

What drives SSO effort and how to keep it down

This table lists the factors that change the scope, cost and recurring effort of a GLPI SSO build, with a way to reduce each one. Read it before scoping, because the first two drivers (identity sources and gateway choice) usually decide whether the work is a configuration task or a build with testing and evidence. Use the rows to decide what to standardize before a partner quote is requested.

Driver	Why it changes effort	How to keep it down
Number of users and groups	Group membership drives profile assignment rules and the size of the initial import. Large or nested group trees mean more mapping decisions and more tests.	Agree a small set of GLPI profiles and map only the directory groups that set them. Import users only from groups that need GLPI access.
Directory structure (domains and forests)	Each domain or forest adds bind accounts, search bases, trust questions and login name formats. Users in several domains need a rule for which one wins.	Use one authoritative domain or a single source of truth for GLPI groups. Confirm trust and search base design with the directory team before build starts.
Number of identity sources	GLPI tries authentication sources in a set order (internal database, LDAP, then other external methods such as REMOTE_USER). Every extra source adds a configuration, a fallback path and a test case.	Keep one external source for staff. Keep local accounts only for a small break-glass group, documented and reviewed.
Existing reverse proxy or SSO gateway	If a gateway already handles sign-in, REMOTE_USER integration reuses it. If none exists, a new gateway or a marketplace plugin for SAML or OAuth becomes a separate build, with its own certificates and support.	Reuse the gateway your organization already runs. Confirm which headers it sends and that GLPI sits behind it so trusted-header login cannot be bypassed.
Plugin sourcing and validation	A SAML or OAuth plugin must be chosen, checked for compatibility with the target GLPI version, and tested after each GLPI update. Plugins are suspended after a new version is detected and must be reactivated after major updates.	Prefer built-in LDAP or REMOTE_USER where they meet the requirement. Record the plugin version, its source and its supported GLPI versions before committing to it.
MFA and conditional access at the identity provider	MFA prompts, device checks and sign-in risk rules live in the identity provider, not GLPI. Each policy must be tested through GLPI's login flow, including session timeouts and mobile clients.	Keep MFA and conditional access policies in the identity provider and apply them to one GLPI application. Avoid per-application exceptions unless a documented need exists.
Audit evidence for access reviews	Reviewers need to see who can sign in, which profile each user holds and when access changed. Evidence collection adds logging design, export queries and a review calendar.	Decide the review fields and frequency early. Use directory groups as the source for profile assignment so reviews happen in one place.
Number of environments to test	Each environment (test, staging, production) needs its own directory binds, callback URLs and test accounts. Sign-in testing repeats for each one and after each change.	Use a staging copy of GLPI and a test directory group. Keep the same configuration template across environments and change only host names and secrets.
One-time versus recurring cost	One-time work covers design, the directory and gateway build, plugin validation and first-round testing. Recurring work covers plugin updates after GLPI releases, directory changes, access reviews and administrator time.	Ask any quote to separate build from run. Confirm who owns plugin updates, directory change requests and the review cycle after go-live.

How to protect the bind account, the trust boundary and recovery access

These six controls cover the points where GLPI relies on something it does not verify itself: the directory bind account, the directory connection, headers set by a reverse proxy, third-party sign-in plugins, recovery administrators and session controls. Each card names one control and what to check before go-live.

Read-only bind account

GLPI uses a directory account to search for users and groups during sign-in and import. Create a dedicated account with read access only to the user and group containers it needs, and confirm with your directory team that it cannot modify objects. Rotate its password on the schedule your directory policy sets, and store the value in a secrets manager or a root-owned file outside the web root, where the web server cannot serve it.

Encrypted directory transport

Credentials and user attributes travel between GLPI and the directory on every sign-in and import, so that connection must be encrypted. Use LDAPS or StartTLS, configure GLPI to validate the directory server certificate against your internal certificate authority, and test that a certificate with a mismatched server name is refused. Confirm the exact configuration options in the GLPI version you run.

Reverse proxy header control

When GLPI trusts REMOTE_USER, any client that can set that header can sign in as another user. Configure the reverse proxy to set REMOTE_USER only after its own authentication succeeds, and to remove any value the client sent in that header and similar identity headers before forwarding the request. Then send a direct request with a forged header to confirm GLPI rejects it.

Plugin source and maintenance review

A plugin that handles sign-in becomes part of your authentication path, so it needs the same scrutiny as the core platform. Before installing a SAML, OAuth or other external sign-in plugin, review its source code, its maintainer, its release history and its compatibility with your target GLPI version. Ask the vendor how security reports are handled and who will patch the plugin after each GLPI upgrade.

Tested local recovery administrator

Keep at least one local GLPI account that does not depend on the directory or the reverse proxy. Give it its own strong password, store that password in your privileged credential vault, and limit its use to recovery. Test the login before go-live and after each change to LDAP or proxy settings, because a broken authentication setting can otherwise lock every administrator out of the service.

Session review and step-up checks

The GLPI 12.0.0 release notes describe a view of active user sessions with the ability to revoke them, and step-up authentication for certain administrative actions. Confirm with the vendor and in a test instance whether both features apply to sessions created through SSO and to the actions you need to protect, and record the answer. Then decide who may revoke sessions and which administrative actions require a second check.

How to test SSO and confirm it fails safely

Before GLPI goes live with directory or proxy sign-in, the team should run a fixed set of test cases and confirm that every failure leaves users with less access, not more. Write the expected result for each case in a test sheet before anyone runs it. A test without a written expectation tends to pass by default, because the tester decides afterward what looked right. Record the account used, the GLPI authentication source it should match, the profile and entity it should receive, and the exact screen or log entry that proves the outcome. Keep the sheet with the change record so the same checks can be repeated after upgrades, plugin changes or directory changes.

Start with the positive paths. Sign in as one directory user from each group that you have mapped to a GLPI profile, and confirm that the user lands in the expected entity with the expected profile and no extra rights. Repeat for the LDAP path and for the REMOTE_USER path through the reverse proxy if both are enabled. Then test the negative paths that matter most: a user removed from the directory, a disabled account, and a user who belongs to no mapped group. Each of these should be refused or should receive no privileged profile. Check the GLPI user record afterward, because a refused login can still leave a stale account or a profile assigned from an earlier sync. Confirm the expected behavior for password and group changes too, and note how long it takes for a group change to appear in GLPI, based on the import and synchronization settings you chose.

Test the proxy path separately, since it trusts a header that the proxy sets. Send a request directly to the GLPI application with a spoofed user header, bypassing the proxy, and confirm that GLPI refuses it. Then send the same header through the proxy from a user who is not authenticated there and confirm the result is still a refusal. Test session reuse as well: after a proxy session ends, a stored session cookie or a replayed request should not sign in. Also confirm that the proxy strips any client-supplied copy of the identity header before it adds its own. Ask your web and proxy team to show the configuration that does this, because GLPI cannot tell a forged header from a genuine one on its own.

Failure behavior needs its own tests. Stop the LDAP server or make the proxy unavailable in a test environment, then attempt sign-in with a directory user and record what the user sees: a clear error or a login page that does not accept the credentials. Confirm that the failure does not create new GLPI accounts, does not change existing profiles, and does not fall back to a permissive method. Check the authentication order in the GLPI user documentation against your own configuration so you know which method is tried after a failed directory call. Verify that the local GLPI administrator account can still sign in while the directory is unreachable, using a password held by the administrators and stored under your normal secret controls. Finally, review the user and profile tables after the outage test and confirm no unexpected accounts or elevated rights appeared. Confirm with GLPI's documentation and your own environment how your version handles each case before you rely on it.

What to monitor, review and document after SSO goes live

Going live is the start of the work, not the end. The items below are the recurring checks, reviews and records that keep GLPI sign-in correct as directories change, certificates expire and GLPI itself moves to new versions.

Failed logins and directory errors

Track failed sign-in attempts and LDAP or Active Directory bind and search errors in the GLPI logs and your directory service logs. A spike in failures often means an expired bind password, a changed service account, or an unreachable domain controller rather than a user problem. Confirm who receives these alerts and how quickly the on-call team can act on them.

Scheduled group synchronization

Confirm the GLPI automatic LDAP synchronization task runs on schedule and that its results are reviewed. Decide in advance what happens to a user whose directory group disappears, such as whether the account is kept, disabled, or stripped of profiles. Test that rule with a disposable account before relying on it, so a renamed group does not silently remove access to open tickets.

Periodic access reviews

Compare each GLPI profile and entity assignment with the directory group that is supposed to grant it. Reviews catch users who kept elevated profiles after a role change, and profiles that were assigned by hand and never mapped to a group. Record who approved each review, the date, and the changes made, so the evidence is available for an internal or external audit.

Bind account and certificate records

Document the LDAP bind account, its owner, its permissions, and the date its password was last rotated. Record the expiry date of the TLS certificate used for directory connections and the certificate on the reverse proxy, and set reminders well before each expiry. Also record the exact proxy header rules used for REMOTE_USER, since a changed header name can break sign-in for every user at once.

Plugin versions and post-update testing

Keep a current inventory of every authentication-related plugin and its version. After each GLPI update, re-test SSO before users return, because GLPI 11 and later suspend plugins when it detects a new version. Major updates require you to reactivate each plugin manually, so plan that step and its test as part of the update, not as an afterthought.

Current recovery procedure

Keep a written procedure for restoring local administrator access if the directory or SSO path fails. Store it outside the GLPI server, and confirm that at least one named person can use the local fallback account. Review the procedure after every change to the directory, proxy or plugin set, and test it on a staging copy at a set interval.

Questions buyers ask about GLPI SSO and identity integration

How much more effort is LDAP or Active Directory sign-in than a SAML or OAuth plugin?

LDAP or Active Directory sign-in is usually the lighter build because GLPI already has a native authentication path for directories, so the work centers on connection settings, user and group import, and profile mapping. A SAML or OAuth plugin adds a third-party component, its own configuration, certificate or client registration steps, and a validation cycle for that plugin against your GLPI version. Plugin effort also grows when you upgrade GLPI, because plugins can be suspended after a new version is detected and must be reactivated after major updates. Ask any partner to split the estimate by method so you can see where the extra work sits.

Effort differences to ask about:

Directory bind account, search base and certificate handling
Identity provider configuration and metadata exchange
Plugin compatibility with your target GLPI version

What makes GLPI single sign-on cost more or less?

Cost follows the complexity of your identity estate and how much testing it needs, not the single sign-on step itself. The main drivers are the number of identity sources (one directory or several), the number and shape of groups that must map to GLPI profiles and entities, whether you need a marketplace plugin validated against your GLPI version, whether multi-factor authentication sits in front of GLPI, and whether auditors need documented evidence of each mapping decision. Each driver adds design, build and test work. Recurring costs appear when group rules change or when plugins need revalidation after upgrades. Ask for a quote that lists each driver as a separate line with a named deliverable.

What does the client need to provide for an identity integration?

The work depends on access and decisions from your side more than on tooling. You will typically need a read-only directory service account with a documented search scope, a change window for the GLPI server and directory changes, and a named approver who signs off on how directory groups map to GLPI profiles and entities. A test group of real users is needed to check sign-in, logout, password behavior and profile results before go-live. You will also need the identity provider owner for SAML or OAuth work, and access to the GLPI server to make configuration changes. Confirm each item in writing at scoping.

Can our internal team set up GLPI SSO without outside help?

Yes, a capable internal team can configure LDAP or Active Directory authentication in GLPI if it has directory administration skills, GLPI administration experience and a test environment. The harder parts are usually profile mapping decisions, plugin validation after upgrades, and documenting the result for audit. Teams often underestimate how many group and entity combinations need testing. A partner adds value when you need a fixed scope with written test cases, an independent review of mappings, or evidence prepared for an assessment. DeployOpen prepares systems, controls and evidence for compliance assessments but does not issue audit reports or certifications.

How long does a GLPI SSO project take?

Duration depends on the number of identity sources, how many groups need profile rules, the chosen method (native directory, reverse proxy header or plugin), and how quickly your directory owners, approvers and test users respond. Scheduling the change window and the approval of profile mapping often takes longer than the build itself. Ask any provider for a timeline tied to named phases and deliverables in the written scope rather than a single number. Our fixed-scope engagements are agreed in writing before work starts, so the timeline is confirmed at that point.

What should a written scope for GLPI identity integration include?

A useful scope names each deliverable and the test cases that prove it works. Ask for the authentication method and why it was chosen, the list of identity sources, the group-to-profile and entity mapping table with the approver's sign-off, the test cases covering sign-in, first login user import, group changes, denied access and logout, and the configuration backup or documentation handed over. Also ask what is excluded, such as plugin development, MFA product setup or future GLPI upgrades, and how post-go-live support is handled. A scope without test cases is hard to verify at acceptance.

Does GLPI SSO need a plugin, or can it use the built-in directory login?

GLPI can authenticate users against an LDAP directory, including Active Directory, as a built-in method, and it can also accept a user identity passed from a reverse proxy through REMOTE_USER. A marketplace plugin is typically needed when you want SAML or OAuth sign-in against an identity provider. The user documentation describes the order in which GLPI tries authentication sources, which matters when local accounts and directory accounts share names. Confirm the exact behavior, the supported options and the compatibility of any plugin with your GLPI version against the official documentation before choosing a design.

How DeployOpen works on this

DeployOpen plans and implements GLPI single sign-on inside infrastructure you control, including your cloud accounts, data centers or air-gapped networks. Work is typically fixed-scope, with the scope, deliverables and timeline agreed in writing before any configuration begins.

How we scope

Inventory which directories hold identities, such as LDAP or Active Directory forests, and which groups should map to GLPI profiles.
Confirm whether sign-in uses LDAP bind, REMOTE_USER through a reverse proxy, or a marketplace plugin for SAML or OAuth.
Record the written scope for user and group import, profile assignment rules, fallback local accounts and test users.
Agree which GLPI version and PHP and database versions the integration targets before design starts.

How we build

Configure the authentication order in GLPI, confirming how directory sign-in interacts with the internal database login.
Set up LDAP or Active Directory import filters so only intended users and groups are created in GLPI.
Build profile assignment rules that map directory groups to GLPI entities and profiles, then test each mapping with sample accounts.
Where REMOTE_USER is used, configure the reverse proxy to pass the authenticated username and verify that spoofed headers are blocked.

How we hand over

Document the authentication order, directory bind settings, import schedule and group-to-profile mapping table.
Provide test evidence for sign-in, denied access, group changes and disabled accounts, with results recorded for your review.
Write runbooks for adding a directory group, rotating the bind account password and recovering local administrator access.
Walk your administrators through the configuration and confirm who owns each setting after handover.

How we support

Review identity settings again whenever GLPI or a marketplace plugin is updated, since plugins are suspended after a new version is detected.
Retest directory sign-in after changes to domain controllers, certificates, reverse proxy rules or GLPI upgrades.
Ongoing support and upgrades are available as a retainer, with coverage agreed in writing.
Ask any partner to confirm in writing which identity protocols and plugin versions their support covers.

GLPI SSO and identity integration