How GLPI signs users in through Google Secure LDAP
If your organization runs Google Workspace and wants GLPI users to sign in with their Workspace accounts instead of local GLPI accounts, the supported route is GLPI's LDAP authentication. GLPI checks its internal database first and then tries LDAP directories, in that order, so you will still want a local administrator account that stays available if the directory connection fails. Google Secure LDAP is the directory endpoint GLPI connects to in this design. GLPI does not ship a Google-specific connector, and nothing in the research behind this page confirms Google-specific behavior, so treat the steps below as a plan to verify rather than a settled configuration.
The Google-specific parts need confirmation before you build anything. Ask Google, in its current administrator documentation, which Workspace edition and license include Secure LDAP, whether a client certificate is required for your tenant, how that certificate is issued and renewed, and which bind DN, search base and attributes the service expects. Then check those answers against the GLPI version you run, because LDAP settings and the certificate handling in the GLPI LDAP directory configuration can differ between releases. Record the license decision and the certificate owner in your change ticket, since a lapsed certificate or a downgraded license will stop every GLPI sign-in at once.
Before you test with real users, run a controlled sign-in with one test account and one account that should be refused. Confirm that the user is created or matched in GLPI, that the expected profile and entity are applied, and that a disabled Workspace account cannot sign in. Decide now how you will handle users who leave the organization, because a directory-backed GLPI account can remain active in GLPI until its status is changed. Plan the rollback path too: know which local account you will use to reach GLPI if Secure LDAP becomes unavailable, and confirm that it still works after the change.
Google Secure LDAP prerequisites for GLPI
Five items must be confirmed before anyone opens the GLPI LDAP directory form. Each one depends on a different owner, so the Google admin, the network team and the GLPI admin each need to sign off on their part. Settle the license and certificate first, then the network path and service account, so configuration starts from a known state.
GLPI version and runtime
Confirm the GLPI release line first, because it sets the PHP and database floor. 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 GLPI 11.0 install docs list PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6. Only MySQL and MariaDB are supported. The GLPI admin should match the server build to the chosen branch before any packages are ordered.
Google Workspace edition and license
The Google admin owns this item. Secure LDAP needs a license that covers the users GLPI will read, and the edition must include the capability for your tenant. Ask Google which editions and add-ons include Secure LDAP, and whether the license must be assigned to users or to the organization. Record the edition in the change ticket, because a later downgrade or license reassignment can stop GLPI sign-in without any change on the GLPI side.
Client certificate and key issuance
The Google admin issues the certificate, and the GLPI admin installs it. Secure LDAP authenticates the client with a certificate, so the GLPI server needs a client certificate and private key that Google accepts. Confirm the generation steps, validity period and file format in Google's current documentation. Restrict read access to the key on the GLPI host, record the expiry date in the asset inventory, and schedule replacement before it lapses.
Outbound network path to Google
The network team owns the path from the GLPI web and cron hosts to Google's LDAP endpoint. Check egress firewall rules, any forward proxy, DNS resolution of the endpoint name and TLS inspection, since inspection can break client certificate authentication. Confirm the port Google documents for Secure LDAP and allow it only from the GLPI servers. Test from the same host and network identity that production GLPI uses, because a test from a workstation does not prove the server path.
Read-only service account
The Google admin creates the account, and the GLPI admin plans how its bind credentials are stored. Create a dedicated service account for GLPI's directory searches and keep it separate from personal administrator accounts. Grant read-only directory scope covering the users and groups that login and authorization rules need, with no write permissions. Confirm how this account authenticates to Secure LDAP and whether interactive sign-in controls apply to it. Store its credentials in a secrets vault and set a review date.
Configuring the GLPI LDAP client for Google Secure LDAP
This sequence connects GLPI to Google Workspace Secure LDAP so GLPI can authenticate users and read groups from the directory. It runs from the license check through the client certificate, a read-only bind account, the GLPI directory entry, and tests of one sign-in and one group read. Each step ends with a check you can record before moving on.
Confirm the Google license and enable Secure LDAP
A Google Workspace super administrator confirms that the organization's edition includes Secure LDAP, then turns the service on in the admin console. Ask your Google account team to confirm the entitlement in writing before you schedule the rest of the work, because the requirement depends on edition and is set out in Google's current documentation. The step is complete when the Secure LDAP client page is visible in the admin console and you can add a client.
Create the LDAP client and install its certificate
In the Secure LDAP area, create a client for GLPI and set its access scope to the users and groups GLPI needs. Google issues a client certificate and key for the client. Download them, along with the root certificate chain Google references, and copy them to the GLPI host, where the web server and PHP process can read the files and other local users cannot. Add the certificate's expiry date to your renewal calendar. The step is complete when the client shows as active and the certificate files open on the GLPI host with a valid validity period.
Create a read-only service account for binds
Create a dedicated user in the Workspace directory for GLPI to bind as. Keep it separate from any administrator and any person's account. Grant it only the directory read access that Secure LDAP needs to return the user and group attributes GLPI uses, and nothing that changes accounts. Store its password in your secrets management process, and record who owns the account. The step is complete when the account exists, has no administrator role, and its password is stored in the approved location.
Add the LDAP directory in GLPI
In GLPI, open the setup menu, go to the authentication section, and add a new LDAP directory. Enter the Secure LDAP host name, the LDAPS port that Google documents for this service, the base DN for the organization, and the bind DN and password of the service account. Select the TLS option that matches the certificate chain you installed, and set the certificate path if your GLPI version requires one. Confirm every value against Google's Secure LDAP documentation. The step is complete when the directory appears in the list without an error.
Run the directory connection test
Run the connection test from the directory form. A pass means the bind succeeded over TLS and the base DN returned entries. If the test fails, check these in order: whether PHP trusts the certificate chain, the format of the bind DN, whether the service account has directory read access, and whether the Secure LDAP host name resolves from the GLPI server. Do not continue until the test passes. Save the test output in your change record.
Set the login identifier and user search filter
Set the login identifier to the attribute Google users sign in with, which is usually the primary email address, and confirm the choice with your identity owner before saving. Add a user search filter that limits results to the people who should have GLPI accounts, such as one organizational unit or group. Keep the filter narrow enough that service and test accounts are excluded. The step is complete when the user preview lists the expected accounts and the count matches the in-scope users you see in the admin console.
Test one user sign-in and one group read
Sign in to GLPI with one test user from the in-scope set. Confirm that the account is created with the expected name and email and that it receives the profile you assigned. Then run a group lookup for a known Workspace group and confirm GLPI returns its members. Also confirm that a user outside the filter cannot sign in. Record the results with the GLPI version you tested. Repeat the sign-in with a second in-scope account before you open access to the wider group.
Google directory attributes mapped to GLPI user fields
This table maps each Google Secure LDAP attribute to the GLPI user field it fills, whether GLPI uses it to match an existing account or only displays it, and which authorization rule depends on it. Attribute names shown are typical LDAP names and must be confirmed against the Google directory schema and attribute mapping in your tenant before you configure the LDAP client. The main takeaway is that login name, email and group membership carry the most risk, because a change to any of them can create duplicate accounts or move users to the wrong profile.
| GLPI field | Google Secure LDAP attribute | Used for | Rule or behavior that depends on it |
|---|---|---|---|
| Login name | uid (confirm the login attribute in your tenant) | Matching | Matches the GLPI account at sign-in, so it must stay unique and stable |
| Matching | Matches or updates the account and feeds notifications; domain-based rules key on it | ||
| First name | givenName | Display | Shown in ticket requesters and assignee lists; display only |
| Last name | sn | Display | Combined with first name in user lists and ticket history; display only |
| Phone | telephoneNumber | Display | Contact details on the user record; confirm the field is populated for all users |
| Location | l or physicalDeliveryOfficeName (confirm mapping) | Matching if used in rules | Entity assignment rules that place users by office or site |
| Department | department (confirm attribute mapping in the Admin console) | Matching if used in rules | Profile and entity rules that must change when a user moves departments |
| Group membership | Group search results from Google group objects | Matching | Authorization rules that grant profiles or entities by group; read through group search, so confirm the group base and filter |
Choosing an access model for GLPI sign-in
This model lets any active user in the Google Workspace directory sign in to GLPI through LDAP. The LDAP user filter defines the population, so the directory decides who has a GLPI login. Excluding service accounts and disabled accounts is part of the filter, and that filter is the main control on who can reach the application at all.
- Filter scope: The user filter defines the population. Confirm which attributes Google Secure LDAP exposes for account status, because that is what keeps leavers from signing in.
- Maintenance: The directory team owns the filter and the account lifecycle. GLPI administrators own the rules that follow from it.
- Profiles: Every user receives the profile GLPI assigns to new directory users, so that profile should carry the least privilege the organization can accept. The profile design topic covers this in detail.
- Entities: Without assignment rules, all users may land in one entity, which can expose records across divisions. The authorization assignment topic explains how to place them.
Before you enable sign-in for everyone, run the filter as a test and compare the returned accounts with the population you expect to see.
This model limits sign-in to members of one Google group, such as a group for GLPI operators or for a single department. The check relies on group membership, either as a condition in the LDAP filter or as a separate test that GLPI applies after the user authenticates. Which method works depends on what Secure LDAP exposes for group membership, so confirm that with Google's documentation before you design around it.
- Group check: Membership in the Google group decides who may sign in. Test it with an account that is inside the group and one that is outside it.
- Maintenance: The group owner adds and removes members. A leaver disappears from the group, but only after that removal happens, so the removal process needs an owner.
- Nested groups: If the group contains other groups, confirm whether the check follows nesting. Otherwise, members of nested groups may be excluded without warning.
- Profiles: Group membership can also drive authorization rules that choose the profile and entity. Keep the sign-in group and the profile logic consistent so that each group does one clear job.
Write down who owns the group, how changes are approved, and how often its membership is reviewed.
This model keeps one or more local GLPI accounts outside the directory so that administrators can still sign in if the directory, the Google license or the LDAP connection fails. GLPI's user documentation describes an authentication order that tries the internal database first, then LDAP, then other methods, so a local account is checked before the directory. That order is what makes recovery work during a directory outage.
- Custody: The password must be stored in a controlled location that an authorized person can reach during an incident. Record who holds it and how it is released.
- Maintenance: Nobody in the directory team maintains this account automatically. Assign an owner who rotates the password and tests sign-in on a schedule.
- Profiles: Assign the Super-Admin profile only to the accounts that need it, and keep the number of such accounts small. The profile topic covers how to protect that profile.
- Entities: Confirm that the recovery account sits in the entity structure you expect, so that it can administer the whole instance.
Test the local sign-in path before the directory cutover, and repeat the test after each GLPI upgrade or LDAP change.
Securing the Google LDAP connection in GLPI
A Google Secure LDAP connection gives GLPI a read path into your directory, and that path carries credentials, a client certificate and login traffic. The cards below cover the transport, the secrets, the service account, the administrators who can change the settings and the logs you need to detect misuse. Confirm each control against your own security policy before go-live.
Encrypted transport and certificate validation
Configure GLPI's LDAP connection to use encrypted transport so bind credentials and user lookups never cross the network in clear text. Make sure the server certificate is validated against a trusted chain rather than accepted without checks, and confirm that the host name in GLPI matches the name on the certificate. Test the connection from the GLPI server itself, since a firewall or DNS difference between the web tier and your workstations can hide a failure. Confirm the exact transport and validation settings your GLPI version offers against its LDAP configuration documentation.
Client certificate key and bind password storage
The client certificate private key and the bind password are the two secrets that let GLPI reach Google Secure LDAP. Store the key file where only the web server user and the administrator running GLPI can read it, with restricted ownership and mode, and keep it outside the web document root. Keep backups of these files encrypted and limited in the same way. GLPI also protects stored credentials with its own encryption keys, so back up and restrict glpi.key and glpicrypt.key alongside the database. Confirm the storage location and permissions against your key management policy.
Read-only service account scope
Use a dedicated service account for the GLPI bind and grant it read access only to the organizational units that hold users and groups GLPI needs. It should not be able to change user objects, reset passwords or read attributes that GLPI does not import. Limit the search base to those units so a compromise of the GLPI server exposes less of the directory. Ask your Google Workspace administrator to confirm which read permissions the account receives and to document the account owner and review date.
GLPI administrators who can edit directory settings
Anyone who can change the LDAP server definition in GLPI can redirect authentication, point GLPI at a different directory or weaken certificate checks. Restrict the profile that edits authentication settings to a small group of administrators, and keep the Super-Admin profile for named individuals only. Review that list when staff change roles. Confirm the profile and permission model you intend to use against your GLPI profile design, since these rights are granted per profile and per entity.
Local recovery administrator
If Google Secure LDAP becomes unreachable, expired or misconfigured, users authenticated through it cannot sign in. Keep at least one local GLPI administrator account that is not dependent on the directory, with a strong password held under dual control and a documented procedure for using it. Test that the account still works after each change to the directory integration. Confirm with your identity team how this account is authorized, logged and retired, since it is an intentional path around central sign-in.
Failed bind and login log review
Repeated failed binds can show an expired client certificate, a changed service account password or an attempt to guess user credentials. Enable GLPI's logging for authentication events and forward or copy those records to the log platform your security team already monitors. Set an alert threshold for failures from the GLPI server and review the trend after certificate renewals. Confirm log location, retention and who receives alerts against your logging standard and incident process.
Testing Google LDAP sign-in before users depend on it
Test the Google Secure LDAP connection in a non-production GLPI instance before any user signs in through it. Start with the bind itself: confirm that the LDAP client connects to the Secure LDAP endpoint with the client certificate, that the service account used for searches can read the user and group objects it needs, and that the base DN and user filter return the expected population and nothing outside it. Then run sign-in tests with a written sample of accounts that covers active, suspended and removed users, plus at least one account from each group that will drive profile or entity assignment. Record for each account what GLPI should do: allow sign-in, refuse it, or refuse it and keep the local record. A suspended or removed Google account that still signs in to GLPI is the failure this test exists to catch, so check it explicitly after the account state changes in the Google Admin console, not only before.
Check group-based access separately from sign-in. For each test account, confirm which profile and entity GLPI assigns and compare that against the expected result in your plan, since a correct sign-in with the wrong profile is still a fault. Test the recovery administrator path as well: sign in with a local super-administrator account while the LDAP authentication source is enabled and disabled, and confirm that the account you rely on during an outage still works. Finally, review the GLPI logs and the LDAP server's own logs for bind failures, search errors and certificate problems across the whole test window, not only the failed logins. Write the account list, expected outcomes and log checks down before the test starts, so the results can be measured against the plan rather than judged after the fact.
Keep the test record with the configuration it verified, including the LDAP client settings, the certificate version in use and the Google Workspace license state of each test account. The Secure LDAP and license requirements are covered in the setup sections, so confirm them against Google's current documentation at the time of the test instead of relying on notes from an earlier build. Repeat the sign-in and recovery checks after any change to the certificate, the LDAP client, the GLPI version or the Google organizational structure, because each of those can change the result without any visible error on the login page.
Common Google Secure LDAP failures in GLPI
This table lists the failures teams most often meet when GLPI reads users from Google Workspace Secure LDAP, with the likely cause and the first thing to check for each. Work down the rows in order, because the certificate and TLS checks usually have to pass before a search can return anything. Exact error text differs by version, so confirm messages against Google's and GLPI's own documentation.
| Failure | Likely cause | Check first |
|---|---|---|
| Connection fails with a certificate error | The client certificate is expired, not yet issued, or was not generated for this Secure LDAP client. GLPI's host may also lack the trust chain it needs. | Confirm the certificate validity dates in the Google Admin console and that the key pair in GLPI matches the uploaded certificate. Check the certificate on the GLPI host with the same tools you use for other LDAP clients. |
| TLS handshake fails from the GLPI host | Outbound traffic to the Secure LDAP endpoint on port 636 is blocked, or the PHP LDAP extension is not using the expected TLS settings. Some firewalls also inspect and break TLS. | Test TCP reachability to port 636 from the GLPI web and cron hosts, not only from your workstation. Confirm the PHP LDAP extension is loaded and that TLS inspection is not applied to this destination. |
| Bind succeeds but no users are returned | The service account lacks the directory read scope for user objects, or the Secure LDAP client was not enabled for the organizational units that hold your users. | Review the Secure LDAP client's access settings in Google's admin console and the scope granted to the account GLPI binds with. Confirm the account can see a known user in a test query. |
| Search returns zero users | The base DN or user search filter does not match how Google Workspace structures user entries, so the query runs but matches nothing. | Run the search outside GLPI with the same base DN and filter. Compare them with the attributes Google exposes for user entries, then update the GLPI directory configuration to match. |
| Users sign in with the wrong identifier or fail to match | GLPI's login field is set to a username attribute while your users sign in with their primary email, or the reverse. This leads to duplicate accounts or failed matches. | Decide which attribute is the login identifier and set it consistently in GLPI's LDAP directory settings and in any authorization rules. Test with one account from each domain alias you use. |
| Users disappear after suspension or license change | A suspended account or one without the required Google license no longer appears in directory results, so GLPI deactivates or cannot import it on the next synchronization. | Check the account status and license assignment in Google's admin console for an affected user. Review what GLPI does during synchronization for users no longer found in the directory, and confirm this with GLPI's documentation. |
| Group-based rules stop applying | Rules reference a group name that was renamed, or membership comes through nested groups that the group search does not follow, so the user matches no rule. | Compare the group's current name and identifier with the value in the GLPI rule. Confirm how nested membership is resolved in your configuration, and test a user who is a member only through a nested group. |
| Users get the wrong profile or entity after a sync | Multiple authorization rules overlap, or a rule runs before the attribute it depends on is populated for that user. | Review rule order and criteria in GLPI, then test one user with each rule enabled on its own. Confirm the attribute values that GLPI receives for that user during the last synchronization. |
Questions buyers ask about GLPI and Google Secure LDAP
Does GLPI support Google Secure LDAP directly or only through generic LDAP settings?
GLPI connects to Google Secure LDAP through its generic LDAP authentication settings, and the connection parameters are what decide success. GLPI's user documentation describes authentication as tried in order against the internal database, LDAP directories, IMAP and external methods such as REMOTE_USER. Secure LDAP relies on TLS and a client certificate, so you need to confirm that the TLS, certificate and bind options your GLPI version exposes meet Google's requirements. Test the bind with a single non-administrator account before you open sign-in to all users, and confirm the exact settings with Google's current Secure LDAP documentation and your GLPI version's LDAP configuration screens.
Which Google Workspace license does Secure LDAP require, and who must buy it?
Secure LDAP access depends on your Google Workspace edition and any add-on license that Google requires for it, and that requirement can change. Confirm the exact license name, whether it applies to all directory users or only to the accounts that sign in to GLPI, and the per-user cost with Google or your reseller before you request a quote. The purchase sits with your organization's Google contract, so your Google administrator or procurement team buys and assigns it. GLPI itself is open-source software under the GNU General Public License version 3, so the Google license is a separate cost line from GLPI, and any GLPI Network subscription is a separate decision.
How long does Google Secure LDAP configuration take and what drives it?
No reliable duration can be given before the scope is known, so ask for the timeline in the written quote and the assumptions behind it. The main drivers are how quickly a certificate can be issued and installed in GLPI's environment, how long Google administrator approvals take in your tenant, and how complex the group design is. Each mapped group changes which GLPI profile and entity a user receives, so a flat directory with a few groups moves faster than a directory with nested groups and many departments. Ask the quote to list each dependency on your side, the people who must approve each step and the testing period before production.
What does the work need from our Google and GLPI administrators?
The work needs named administrators on both sides and their time at defined points. On the Google side, a super administrator or delegated administrator must enable Secure LDAP access, create or approve the LDAP client, and provide the client certificate material through your approved process. On the GLPI side, an administrator must provide a supported installation and confirm the version. GLPI 11.0 documentation lists PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6, and the README on the main branch lists PHP 8.3 or later with MariaDB 10.11 or later or MySQL 8.0 or later, so check your version against the matching requirements. Both sides also need a business owner to approve which Google groups map to which GLPI profiles and entities.
Can our internal team set up GLPI with Google Secure LDAP without outside help?
An internal team can do this if it has three skills at working level: Google Workspace administration, LDAP and TLS troubleshooting, and GLPI authorization design. The steps that most often slow internal projects are certificate chain issues, search filters that return too many or too few accounts, and mapping groups to least-privilege profiles. Those steps are hard to test without a staging GLPI instance and a test tenant or test group. If one of those skills is missing or the team has a fixed deadline, a fixed-scope engagement can cover the parts it cannot staff. Decide early which parts your team will own after go-live so the handover is clear.
What does a fixed-scope engagement for this topic cover?
DeployOpen works on most engagements under a fixed scope, and the scope, deliverables and timelines are agreed in writing before work starts. For this topic, a written scope typically covers a review of the Google prerequisites and license position, configuration of the LDAP client in GLPI within your infrastructure, the handling of the client certificate under your approved process, the group-to-profile mapping, a test plan with test accounts, and a handover to your administrators. Items to confirm in the quote include whether certificate issuance, Google license purchases and production change approvals are in or out of scope. DeployOpen prepares systems and evidence for compliance assessments, but independent auditors and certification bodies issue audit reports and certifications.
What recurs after go-live, such as certificate renewal and access reviews?
Several tasks recur after go-live. The client certificate must be renewed before it expires, so set a calendar reminder and test the renewal in staging. Access reviews should confirm that Google groups still map to the right GLPI profiles and entities, and that leavers lose access on time. Upgrades also recur: the GLPI update procedure requires backing up the database, files and the config directory including glpi.key and glpicrypt.key, and since GLPI 11.0 plugins are suspended after a new version is detected and must be reactivated after major updates. Ask the quote whether these tasks sit with your team or under an ongoing support retainer, which DeployOpen offers separately.
How DeployOpen works on this
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For GLPI with Google Secure LDAP, that means the directory connection, the access model and the Google license requirement are agreed in writing before any configuration changes are made.
How we scope
- Confirm which Google Workspace edition and Secure LDAP access your organization already holds, and who approves the license.
- Define which Google organizational units or groups are imported, and which GLPI profiles and entities they map to.
- Agree in writing how the client certificate is issued, stored, renewed and who holds its private key.
- Fix the scope, deliverables and timeline in a written statement of work before the build starts. Engagements are fixed-scope.
How we build
- Configure the GLPI LDAP authentication server against the Google Secure LDAP endpoint in a non-production GLPI instance first.
- Test bind, user search and group membership with accounts from each access tier, including users who should be refused.
- Verify that local administrator accounts still sign in when the directory is unreachable, and record the fallback path.
- Check that certificate and key files are readable only by the GLPI service account and that certificate expiry is tracked.
How we hand over
- Document the LDAP server settings, filters, field mappings and the certificate renewal procedure for your administrators.
- Provide a test matrix with expected results for sign-in, profile assignment and refused access, ready for your own re-testing.
- Walk through the change steps needed when Google changes the directory or your GLPI version moves to a new release.
- Deliver the configuration record and runbook into infrastructure you control, so your team owns every setting after handover.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial handover.
- Retainer scope can cover re-testing the directory connection after GLPI updates, which require backing up configuration first.
- Ask any partner to confirm which Google license and certificate responsibilities sit with your organization versus theirs.
- Agree in the scope how certificate renewal alerts, access reviews and directory changes are routed to your team.
