How GLPI signs users in through Active Directory
Most IT teams that deploy GLPI want staff to sign in with their domain accounts and want users and groups to arrive from the directory rather than through manual entry. GLPI supports this through its LDAP directory settings, not through a custom connector. GLPI checks sign-in sources in a fixed order, and the directory source is tried after the internal database, so the reader should plan which accounts must remain local, such as a break-glass administrator, before the directory is switched on. In GLPI, Active Directory is reached as an LDAP directory, and the AD template in the directory settings is the sensible starting point because it pre-fills the attribute names and filters that Active Directory uses.
The mechanism is an LDAP bind and search. GLPI connects to a domain controller with a service account, searches the directory for the user who is signing in, and then binds as that user with the password supplied at the login form. The reader should decide early which base DN and which domain controller or replica GLPI will query, which service account will perform the bind, and whether the connection will use encrypted transport. Confirm these choices with the directory team, because a service account with more rights than it needs is a common finding in reviews. The exact settings and their names should be checked against the GLPI version in use, since the directory form and its defaults can differ between releases.
This page covers the directory connection itself, the AD template, group search, replicas, bulk synchronization from the console and the filters that keep Windows default groups out of GLPI. It does not cover how a directory user is turned into a GLPI profile and entity, which is handled by the authorization assignment rules, nor Kerberos single sign-on through the web server, which is covered by the Windows integrated SSO page. Active Directory Domain Services itself is documented by Microsoft in its AD DS overview, which is a useful reference when the directory team asks why a given attribute or object is involved.
What you need before you configure the LDAP connection
Most LDAP problems in GLPI start before the configuration screen opens. The platform, the database, the network path to the domain controllers and the certificate trust all have to be settled first, and the domain controller versions set limits on what the directory can answer. Confirm each item with your own AD team before you start.
GLPI, PHP and database versions
Confirm the GLPI release you will run before anything else, since the supported PHP and database versions depend on it. The GLPI 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 installation docs list PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6 for GLPI 11.0. Only MySQL and MariaDB are supported, so plan the database tier around those. Pin the version and PHP build before you build the LDAP setup.
Read-only service account
GLPI binds to the directory with a dedicated account that only needs to read users, groups and the attributes you map. Ask your AD team to create it in the domain that holds your users, with a password policy and an expiry plan that suit a service identity. Avoid Domain Admin rights, because a leaked GLPI credential would then expose the whole domain. Record the bind DN and the search base so you can test them with a directory client before entering them in GLPI.
Network paths and ports
GLPI's web and cron servers must reach the domain controllers directly, usually on the standard LDAP port 389 or the LDAPS port 636. Check the path from every GLPI node, including any container network, load balancer or firewall between the two. If you use several domain controllers, confirm each one answers, because a single unreachable controller can cause intermittent sync failures. Ask the network team to document the rules so the change is traceable.
Certificate trust for LDAPS
An encrypted LDAPS connection requires that the GLPI host trusts the certificate the domain controller presents. Obtain the issuing certificate authority chain from your AD team and install it in the trust store used by the PHP process, not only in the operating system store. Confirm the name on the certificate matches the host name you enter in GLPI. Test the handshake from the GLPI server before you save the connection, so certificate errors are not mistaken for bad credentials.
Domain controller version and lifecycle
The Windows Server version on your domain controllers sets which directory features and security defaults you can rely on. Windows Server 2025 became available on November 1, 2024 with mainstream support ending November 14, 2029, and Windows Server 2022 mainstream support ended on October 14, 2026 with extended support ending October 15, 2031, according to Microsoft's lifecycle pages. Check which version each controller runs and which support phase applies, because an out-of-support controller is a risk to the LDAP path your GLPI depends on.
LDAP settings to confirm with AD
Ask the AD team to confirm the settings GLPI will read before you map attributes. Confirm the domain name, the users and groups organizational units to search, whether groups are nested, and which attribute carries the login name, such as sAMAccountName. Also confirm whether the domain controllers allow the signing and channel options your security policy requires. Write these answers down in one place, because the same facts drive the group search and filter decisions later in this setup.
Configure the Active Directory directory in GLPI in order
This sequence turns an Active Directory domain into a working GLPI directory connection, from the first bind to users who can sign in. Each step closes with a check, so a failure is caught while the scope is still small and before anyone is locked out.
Create the directory connection from the AD template
In GLPI, open Setup, then Authentication, then LDAP directory, and add a new directory using the Active Directory template so that the attribute mappings for user login, names, email and group membership start from the AD defaults. Enter the domain controller host, the port and the bind account that GLPI will use to read the directory. Use a dedicated, read-only service account rather than a domain administrator. The step is done when the connection record saves without error and the template has populated the login field as sAMAccountName.
Set the base DN and user filters
Enter the base DN that covers only the organizational units holding people who should use GLPI, and set the user search filter so that disabled accounts and Windows default groups such as Domain Users and Built-in accounts are excluded. Confirm the exact filter syntax against your own directory structure and Microsoft's documentation before saving. The check is a sample lookup: search for one known user by login and confirm that the returned record shows the expected name and email, and that a disabled test account is not returned.
Enable group search for nested group resolution
Turn on group search in the directory settings and set the group base DN and group filter. Group search is what allows GLPI to resolve nested group membership, so a user who belongs to a child group of a group used in an authorization rule is still matched. Choose the group membership attribute that matches how your domain records membership, and confirm the choice with your directory administrator. The check is a group count comparison: count the groups GLPI returns for a test group tree and compare the result with the count you get from Active Directory Users and Computers or a PowerShell query.
Add replica domain controllers
If your domain has more than one domain controller, add them as replica servers in the same directory record so GLPI can fall back when the primary is unreachable. Replicas hold copies of the same directory data, which Active Directory replicates to every domain controller in a domain, so the lookups return consistent results. Test each replica separately by temporarily pointing a test connection at it. The step is done when each replica answers a test bind and a sample user lookup returns the same record as the primary.
Run a test connection
Use the test function on the directory record to bind with the service account and confirm that GLPI can read the users and groups inside the base DN. Check the result against the bind account's permissions: a failed bind usually points to credentials, the port, TLS settings or the base DN rather than GLPI itself. Record the test output and the configuration version so the same settings can be reproduced in a staging instance. The check passes when the test returns a successful connection and the sample lookup from the earlier step still matches.
Run a bulk user sync from the console
Run the GLPI console user synchronization command for the directory, using the console tooling in your installation so that the import runs outside the web session and can be repeated. Start with a limited scope or a test group, then widen it once the results are correct. Compare the number of users created or updated against the group and user counts from the directory, and review a sample of imported accounts for correct login names, email addresses and group membership. Keep the console output as evidence of the initial load.
Enable login through the directory
Once the sync results match expectations, enable the directory as an authentication source and confirm the order in which GLPI tries authentication methods, since the internal database is checked before LDAP by default. Keep a local administrator account available for recovery, and sign in with one directory user and one account from a restricted group to confirm that each receives the expected profile. The step is done when both test sign-ins succeed and the recovery account still works.
How attributes and groups map to GLPI users, profiles and entities
When GLPI imports an Active Directory account, it reads a fixed set of attributes from the user object and writes them into the GLPI user record. The login is the value GLPI uses to match a directory account to a local record, so it must be stable and unique. Name, email, phone and location are informational fields that populate the user card and drive notifications and ticket context. Each field is mapped from an LDAP attribute in the directory connection settings, and the defaults usually follow common Active Directory attribute names. Confirm the exact field names and default mappings against the GLPI version you run, because they have changed between releases.
- Login attribute: Choose an attribute that never changes for a person, such as the logon name your users already type. Changing it later can create a second account for the same person.
- Name fields: Check how given name and surname are split, since display names in AD often include titles or middle initials.
- Email: Confirm which attribute holds the address used for notifications, and whether users with no mailbox should be excluded.
- Phone and location: These are often blank or stale in AD. Decide whether GLPI should overwrite values entered locally.
- Synchronization behavior: Test whether a value changed in AD is updated in GLPI on the next synchronization, and whether a value edited in GLPI is overwritten.
Before go-live, import a small test group and compare the resulting user records with the directory entries for each mapped field.
Group membership is read separately from user attributes. GLPI can search for groups, read which groups a user belongs to, and use those memberships as input to authorization rules. Group search matters most in larger directories, where nested groups are common and a user's direct memberships may not show the full picture. Windows also creates built-in groups such as Domain Users, which almost every account belongs to. Those groups carry no business meaning for GLPI and can cause every user to receive the same profile if they are used as a matching condition.
- Group search base and filter: Limit the search to the organizational units that hold business groups, so GLPI does not index the whole domain.
- Nested membership: Confirm that your GLPI version resolves nested groups the way your authorization design expects, and test with a user who is two or three levels deep.
- Default groups: Exclude Windows default groups such as Domain Users from the rules that grant access, either through the group filter or by ignoring them in rule conditions.
- Group names versus distinguished names: Decide which identifier your rules match on, and keep it consistent across environments.
- Group count: A large number of groups increases synchronization time and makes rule conditions harder to audit.
Test membership reads with a privileged and an unprivileged account, and confirm the Domain Users group is not granting access.
Authorization rules connect the imported data to GLPI's access model. A rule evaluates conditions based on user attributes and group memberships, then assigns a profile, an entity and optionally a group inside GLPI. Profiles define what a user can do, and entities define which part of the data they can see. Because the rules run on the data described above, an error in attribute mapping or group reading reaches permissions directly. Rules are evaluated in an order you control, so the sequence and the conditions need to be designed together rather than set one at a time.
- Rule conditions: Match on the group or attribute that represents a real business role, not on a broad default group.
- Profile assignment: Map each rule to the least-privileged profile that covers the job, and review profiles periodically.
- Entity assignment: Assign entities based on an attribute such as department or site, and confirm the entity tree matches your organization.
- Rule order and fallbacks: Define what happens when no rule matches, and whether that user gets any access at all.
- Changes and leavers: Test that a department change moves the user to the new profile and entity, and that a removed group removes the earlier access on the next synchronization.
For a closing check, sign in with a test account from each target group and confirm the profile and entity match the rule design.
The field names and default mappings in the directory connection screen are the part of this integration most likely to differ from one GLPI release to another. Plugins, custom directory templates and inherited settings from an upgrade can also change what appears in the form. Treat any mapping you copy from a guide, a ticket or an older instance as a starting point to verify, not a fact. Document the mapping you actually use, the GLPI version it was tested against, and the directory server version, so that future upgrades can be checked against the same record.
- Version check: Record the GLPI version in your mapping document and retest after every major or minor upgrade.
- Directory template: Confirm which template you start from and what it sets by default.
- Attribute names: Verify each attribute name against your own directory schema, since custom schema extensions and renamed attributes are common.
- Test accounts: Keep a small set of accounts covering normal users, nested group members, leavers and default-group-only users.
- Upgrade regression: Compare the before and after values of each mapped field and each rule outcome.
Ask your implementation contact to provide a written mapping table for your exact version, and keep it under change control with the rest of the configuration.
Which Active Directory fields feed which GLPI fields
This table compares common Active Directory attributes with the GLPI user fields they usually populate, and the decision each one forces. Attribute names are typical defaults, so confirm each one against your own schema before you build the mapping. The main takeaway is that the login attribute and the handling of disabled accounts shape every later access decision, so settle them first.
| Directory attribute | GLPI field it feeds | Decision the reader must make |
|---|---|---|
| sAMAccountName | Login name (GLPI user name) | Confirm it is unique in your forest and whether users sign in with it or with a UPN |
| userPrincipalName | Login name when UPN is chosen | Pick one login attribute for all directories, since switching later changes existing user records |
| Email address | Decide whether one email maps to one account and how shared or alias addresses are handled | |
| givenName and sn | First name and last name | Decide whether display names come from these fields or from displayName, and confirm they are populated for your users |
| telephoneNumber or mobile | Phone fields on the user record | Decide whether these fields should be overwritten at each sync or kept as manually edited values |
| l, department or company | Location, group or entity assignment inputs | Choose which attribute drives authorization rules, since a mismatch sends users to the wrong entity |
| userAccountControl (disabled flag) | Account status on sync | Decide whether disabled accounts are imported and deactivated or skipped, and how leavers are removed |
| memberOf or group membership | Group membership and authorization rule input | Decide whether to read direct membership or search nested groups, since nested groups need a group search |
Hardening the directory connection
The LDAP connection is the part of GLPI that holds a standing credential into your directory and reads personal data for every user who signs in. The cards below cover the controls that keep that connection narrow, encrypted and recoverable, and the points your Active Directory team must confirm before go-live.
Service account with read-only rights
Create a dedicated bind account for GLPI and grant it only the read access needed to search users and groups under the directory search bases you chose. Do not reuse a domain administrator or a person's account, because GLPI stores the bind password in its database. Confirm with the AD team which organizational units the account can read, whether it can write anything (it should not), and how the password is rotated and where it is recorded.
Encrypted LDAP connections
Use LDAPS or StartTLS so bind credentials and directory data do not travel in cleartext between GLPI and the domain controllers. Trust the certificate chain on the GLPI server, not by disabling verification. Confirm with the AD team which domain controllers present certificates issued by your internal CA, which hostnames they answer on, and whether the certificate names match what GLPI connects to.
Restrict sign-in to named groups
A directory search that finds every enabled account lets anyone in the forest sign in to GLPI. Add a group filter so only members of approved security groups can authenticate, and keep Windows default groups such as Domain Users out of that filter. Confirm the exact group names and nesting with the AD team, and test with one account from each group and one account outside all of them before you enable the connection for everyone.
Limit read access to sensitive attributes
Directory objects often carry fields such as phone numbers, addresses, employee identifiers or manager links that GLPI does not need for sign-in or assignment. Map only the attributes that GLPI uses, and ask the AD team to confirm that the bind account cannot read confidential attributes on user objects it does not need. Document which attributes are imported so privacy and records teams can review them.
Back up the GLPI encryption keys
GLPI encrypts stored secrets, including the LDAP bind password, with keys kept in its configuration directory. A database restore without those keys leaves the directory connection unusable, and a restore with the wrong keys can fail in less obvious ways. Keep glpi.key and glpicrypt.key in the same protected backup set as the database and files, and test a restore that includes them. The update procedure in the installation docs makes the same point.
Hardening beyond the directory
This page covers only the directory connection. Session cookies, re-authentication, exposed endpoints and status information are handled in GLPI's security hardening guidance, which you should work through after the LDAP settings are in place. Agree with your security team who owns each control so that nothing is assumed to be covered by someone else.
Why GLPI rejects valid Active Directory users
This table lists the failures that most often make GLPI refuse or mishandle directory users that are valid in Active Directory, with the likely cause and fix for each. Read each row against the symptom you see in the GLPI authentication and LDAP directory screens, and confirm the exact menu names and settings in your GLPI version before changing production configuration.
| Symptom | Likely cause | Fix to check |
|---|---|---|
| Connection test fails or users cannot be found | The service account bind is rejected: wrong DN or UPN format, expired or locked password, or no read permission on the user container | Test the bind with the service account's full distinguished name, confirm read access to the base DN, and check the account is not locked or set to expire |
| Nested group members do not get their GLPI group | Group search is disabled, so GLPI only reads direct membership on the user object | Enable group search for the directory and check the nested group settings, then re-sync and confirm a user from a child group now receives the expected group |
| Windows default groups appear in GLPI | Built-in groups such as Domain Users or Authenticated Users are returned by the group query and imported like business groups | Add LDAP filters that exclude the default groups and retest on a sample user before running a bulk import |
| Recently changed users or groups show old data | Sign-in or sync is pointed at a replica that has not yet received the latest change from its partner domain controller | Point GLPI at a domain controller or replica that is current for the change, and allow for replication delay before troubleshooting further |
| LDAPS connection fails with a certificate error | The domain controller certificate is not trusted by the GLPI server, does not match the host name, or the chain is incomplete | Install the issuing CA certificate on the GLPI host, use the host name in the certificate, and verify the chain with the PHP LDAP client before retrying |
| User signs in successfully but has no profile or entity | Authentication works but no authorization rule matches the user's group or attribute, so GLPI assigns no profile | Review the authorization assignment rules, confirm the matched attribute or group name, and check that a default profile is set where appropriate |
Questions buyers ask before connecting GLPI to Active Directory
How much effort does a GLPI and Active Directory integration take?
Effort depends mostly on the shape of your directory and how much authorization logic GLPI has to carry. The main drivers are the number of users and groups that GLPI will import, how deeply groups nest, how many entities and profiles the sync must feed, and how many Windows default groups and service accounts need filtering out. A flat directory with one domain and a handful of groups is a small job. A multi-domain forest with nested security groups, several domain controllers to reach from GLPI and rules that place users into different entities is a larger one. Ask any partner to scope the work against a documented list of these factors rather than a single number.
Can our in-house team connect GLPI to Active Directory without a partner?
Often yes, if the team already runs GLPI and has someone who understands both LDAP and your AD structure. The GLPI side is a configuration of an LDAP directory, a template for Active Directory, group search settings and user synchronization, so the work is well documented. The harder parts are usually outside GLPI: a bind account with the right read permissions, correct handling of nested groups, and agreement on which AD groups should grant which GLPI profile. If your team lacks LDAP or AD experience, or has no time to test against production-like accounts, a fixed-scope engagement can cover the configuration, testing and handover.
What does the Active Directory team need to provide for the integration?
The AD team usually provides the search base and the bind account that GLPI uses to read the directory, along with confirmation of which OUs and groups are in scope. They also need to tell you where domain controllers and any read-only replicas are reachable from the GLPI server, and whether LDAP or LDAPS will be used. Expect to agree on group naming, the groups that map to GLPI profiles and entities, and the Windows default groups that should be excluded. Each of these decisions affects how many accounts GLPI sees, so it helps to have the AD team in the scoping call from the start.
How long does testing take before users sign in through Active Directory?
Testing duration is set by the number of test accounts, the number of group and profile combinations, and how many environments you need to validate, such as a staging GLPI instance. Plan separate passes for authentication, group membership resolution with nested groups, profile and entity assignment, and the behavior of users who leave or change departments. Repeat the user sync from the console after each change to confirm what GLPI imports. No fixed duration applies to every directory, so ask for the test plan and the number of cycles included in a written quote.
How do we ask for a fixed-scope quote for this integration?
Send a written description of your directory (forest and domain count, approximate user and group counts, nesting depth), your GLPI version and deployment, the number of entities and profiles you need, and the authentication behavior you expect. DeployOpen works from a written scope, so the quote follows the deliverables, the test plan, the environments involved and the handover items. Ask the provider to list what is one-time work, such as configuration and testing, and what recurs, such as later changes to groups or a support retainer. Confirm who is responsible for the bind account, change windows and rollback.
Do the domain controllers need extra licensing for GLPI to query them?
GLPI reads directory data through LDAP, so the licensing question is about the Windows Server infrastructure that already hosts your domain controllers, not about GLPI itself. Microsoft licenses Windows Server 2025 per core, with a minimum of 16 cores per server and 8 per processor, and Standard and Datacenter editions both need a Client Access License for every user or device that accesses the server. Confirm with your Microsoft licensing advisor whether adding an LDAP client changes your count. The Microsoft pricing page lists a suggested price of 1,176 US dollars for Standard and 6,771 US dollars for Datacenter for 16 core licenses, and notes prices vary by region.
What breaks most often in a GLPI Active Directory sync?
The most common failures are a bind account without enough read access, search bases that miss an OU, and nested group membership that GLPI does not resolve because the group search is not configured for it. Other frequent problems are imported users who should be excluded, such as built-in accounts and Windows default groups, and profile assignments that drift after a department change. Check each of these during testing, and keep a record of the search filters and mapping rules so the configuration can be reviewed and reproduced later.
How DeployOpen scopes and delivers the GLPI directory integration
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For GLPI LDAP and Active Directory integration, that means agreeing the directory design, building and testing the connection in your environment, and handing over documentation your team can run.
How we scope
- Written scope lists the directory forests, domains and OUs GLPI will read, and which account types it may import.
- Scope records the group search method, replica hosts, filters for Windows default groups and the bulk sync schedule.
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we build
- We configure the AD template and test the bind account with least-privilege read access on your domain controllers.
- We validate nested group resolution, replica failover and the filters that keep built-in Windows groups out of GLPI.
- We run test sign-ins and bulk user synchronization from the console against a staging copy before production cutover.
How we hand over
- Documentation covers connection settings, filter logic, the bind account, replica order and the sync procedure.
- Runbooks describe how to reconnect after a directory change, rotate the bind credential and review imported users.
- Your team receives test evidence showing which groups, users and filters were verified before handover.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainer work can cover re-testing LDAP settings when GLPI moves to a new major version such as 11 or 12.
- Confirm with DeployOpen which directory changes, such as domain consolidation, are included in support terms.
