GLPI, LDAP and Active Directory


You can make use of an existing LDAP directory to authenticate users to GLPI. Once you configure LDAP authentication, LDAP users will be added to the GLPI database as they log on. Some of the LDAP attributes (Name, email address, location) will be copied to the GLPI user database - with this approach GLPI is able to use more than one authentication scheme (e.g. simply use LDAP and GLPI-integrated logins together)

Parameters are slightly different depending on the LDAP implementation you are using. Microsoft Active Directory in particular uses attribute names which differ from standard LDAP attributes.

This documentation will thus be structured in three parts:

  • general presentation of the options present in GLPI
  • configuration example for a “traditional” LDAP server
  • configuration example for Active Directory (tested with AD 2k and 2k3)

All configuration options for the LDAP authentication integration in GLPI can be changed through the “Administration” - “Setup” - “Authentication” configuration page.

If you do not see any LDAP options there but an error message that the LDAP module for PHP is missing, install the LDAP module (it will typically come with your distribution and be named something like “php-ldap”), restart your web server and try again - the configuration options should appear now.


In Administration/Setup/External authentification you have several configuration options grouped in three sections:

  • The top section “LDAP Configuration” contains general LDAP connection settings like the LDAP server, the binding context or the search filters.
  • The bottom section “GLPI/LDAP Links” configures the mapping of LDAP attributes to fields used in GLPI. The values will have to be modified to reflect your LDAP schema.
  • The mid section is about an automatic mapping of LDAP group memberships to GLPI groups.

Possible connection modes

Depending on your LDAP directory structure you will have to choose one of the two methods on how to connect to your directory:

  • You have a flat directory (which often is the case with Samba sites using LDAP as the authentication backend), i.e. all relevant users are placed within a single organizational unit. In this case authentication is simple, since you can just add the baseDN string to the user name and ask LDAP to authenticate the user with the password provided through the user login attempt.
  • You have a hierarchic directory (which is pretty likely if you have an Active Directory site). Things are getting more complicated here, since LDAP requires a full distinguished name (like CN=John Doe,OU=Accounting,OU=Financial,DC=myAD,DC=example,DC=com) for authentication, but the user logon is only going to give us the user name.

In this case, authentication is performed in two stages:

  • GLPI needs to start a LDAP search for the user object first, providing the user name and predefined filter strings as parameters
  • In a second step it will try to ask the LDAP directory for authentication using the search result from the first step and the password provided by the user login attempt

Connection parameters

  • Host: the address of your LDAP server in LDAP URI notation (e.g. ldap://, or simply as an IP address.
  • BaseDN: The initial DN for the search
  • RootDN (for non-anonymous connections): DN of a user authorized to conduct an LDAP search query starting at BaseDN
  • Pass (for non-anonymous connections): The password for the aforementioned user.
  • Connection Filter: Filter string to restrict the LDAP search. If you want to restrict the set of LDAP objects authorized for GLPI logins and this set can be described by LDAP attributes, specify them here in LDAP filter notation. This attribute is mostly useful in AD setups to filter off “real users” from computer accounts and InetOrgPerson entries with a string like (&(objectClass=user)(objectCategory=person))

The values in this section are initialized with defaults useful for a common LDAP directory, however, these defaults will not work with Active Directory setups. Below, you will get some examples on mappings:

  • name: the logon user name (LDAP: uid, AD: samaccountmame)
  • email: user email address (LDAP: mail, AD: userprincipalname)
  • hiring: user's locarion (LDAP & AD: physicaldeliveryofficename)
  • phon: the telephone number (LDAP & AD: telephonenumber)
  • name: the surname (AD: sn)
  • given name: user's given name (AD: givenname)

The easiest way to determine which fields to use is to browse your LDAP or AD repository (using ldapsearch, for example).

Traditional LDAP directory setup:

Since the defaults should work, you will only need to specify the most basic parameters:

  • host:
  • basedn: dc=example, dc=com

Note - The default LDAP port is 389 which will search the baseDN specified. If however you have a large AD forest with multiple subdomains, port 3268 can be used to search via the Global Catalog (The “host” parameter must be a GC server for your forest). When using Global Catalog, it seems that you have to set the port number in the host field (ldap://ad.mycorp:3268). Setting the port in the port field only does not allow you to search sub-domains.

If anonymous directory search is not allowed and your user objects are not all to be found in BaseDN, you will need to specify values for a RootDN and the password (e.g. RootDN: CN=GLPI user search,CN=users,DC=myAD,DC=example,DC=com)

You can also set up a search filter. Example within the university of Poitiers (FRANCE), these fields are indicated to specify which entity the personnel is attached. If we wants to restrict with certain entities the condition is: (upempaffectation=500400)

or more complicated: (| (upempaffectation=500400) (upempaffectation=500200))

Active Directory setup:

GLPI authentication against Windows 2000 Server / Windows Server 2003 Active Directory has been tested successfully.

Specify the domain controller name or IP address and the domain name as your BaseDN

Active Directory does not allow anonymous object search, so you have to specify an authorized user and his password. If you create a user named “GLPI user search” in the “Users” container of Active Directory, the RootDN would look like this: CN=GLPI user search,CN=Users,DC=myAD,DC=example,DC=com. If you move this user to some other organizational unit, you will have to modify the string accordingly (e.g. CN=GLPI user search,OU=Inventory,OU=IT Administration,DC=myAD,DC=example,DC=com).

You also should define an LDAP search filter in order to restrict the search to user accounts only. If you do not do this, you will be searching machine accounts and InetOrgPerson accounts as well. The filter should look like this: (&(objectClass=user)(objectCategory=person))

Now take care of the data mappings. Set the fields as follows:

  • Loginfield: samaccountname (write in low case)
  • Surname: sn
  • First name: givenname
  • E-Mail: mail
  • Location: physicaldeliveryofficename
  • Phone: telephonenumber

Due to limitations in code, the LDAP names are not to be capitalized (so, enter all LDAP attribute names in lower case), otherwise you will not get the attributes imported correctly.

Tip: If you encounter difficulties, ADSIEdit.msc provided with the Support Tools on the Windows Server installation CD enables you to browse your Active Directory and allows you to see all information available through LDAP, including all attribute and object names.

If you mainly have Windows Clients in a single Windows domain, consider using integrated NTLM authentication for better user compliance.

Example Data For External Authentication (GLPI v0.7)

Name : Conn (can be anything)

Server			:
Root DN		: CN=glpi, CN=users, DC=MYDOMAIN, DC= NET

Note: Replace MYDOMAIN with your domain name

Password		: ***
Connection Filter	: (&(objectClass=user)(objectCategory=person)(!userAccountControl: 1.2.840.113556.1.4.803:=2)))
Login Field		: samaccountname
Time Zone		: GMT+5.5

Belonging to Groups

Search Type				: In Users
User Attributes containing groups	: memberof
Filter to search in groups		: (&(objectClass=user)(objectCategory=person)(!userAccountControl: 1.2.840.113556.1.4.803:=2)))
Group Attributes Containing Users		: <Blank>


Surname		: sn
First Name		:  givenname
Comments		:  nothing
E-mail			:  mail
Phone			:  telephonenumber
Phone2		:  homephone
Mobile			:  mobile	

1000 query limit:

There is a maxPageSize limit of 1000 in the windows AD which limits the LDAP query records to a max of 1000. In simple words whenever an LDAP search or query is made to the AD, no more than 1000 records are returned from the directory. This limitation is actually a security design so as to prevent the AD from DOS attacks for LDAP queries. In case less than 1000 users are defined in the AD, no additional work is required but for a large setup this limit needs to be changed at the AD using the “ntdsutil” utility. So the following steps need to be done at your AD to change the MaxPageSize value from 1000 to 5000(or whatever value suits ur requirement).

C:> ntdsutil

ntdsutil: ldap policies

ldap policy: connections

server connections: connect to server ( here a few messages regarding connectivity are displayed)

server connections : q

ldap policy : show values ( here we will see all the values including MaxPageSize which is 1000 currently)

ldap policy : set maxpagesize to 5000

ldap policy : commit changes

ldap policy : q

ntdsutil : q

After performing above commands GLPI can successfully import more than 1000 users from the AD.


The mod_security Apache module interferes with the AD connection parameters and the connection filters. Mod Security considers connection parameters as an LDAP Injection attack to a server and hence blocks the pages and gives an error “Method Not Implemented” on the web page. So as a temporary turnaround turn off mod_security on the apache web server. To do so go to /etc/httpd/conf.d directory and rename the file mod_security.conf to mod_security.temp or any other file name BUT WITHOUT THE .conf EXTENSION as apache parses all the .conf files while starting and then loads the modules as defined in the conf files. Do an apachectl restart and apache shall be loaded without mod_security. After completing the Import of AD users to GLPI mod_security may be turned on again to prevent apache server from various network attacks..

User Notes


Our environment runs GLPI and OCS in VServer guests ( We clone our guests with a minimal installation of 64-bit CentOS 5.x. As a result, many packages which are normally installed by default are missing and not necessarily listed as GLPI or OCS dependencies because most environments include them by default. To properly install GLPI + OCS in our minimal environment, we configured our repositories as follows:

yum install yum-priorities
rpm -ivh {rpmforge,remi,epel}*.rpm

Edit the .repo files in /etc/yum.repos.d/ and set up priorities by adding the line: priority=N to a repository entry as follows:

[base], [addons], [updates], [extras] ... priority=1 
[centosplus],[contrib] ... priority=2
rpmforge ... priority=15
epel . . . priority=11
remi . . . priority=20

The setup should, of course, be adapted to your environment and the latest versions of the rpms. We then installed the following packages:

yum install php.x86_64 perl-XML-Simple perl-Compress-Zlib perl-DBI perl-DBD-MySQL perl-Apache-DBI perl-Net-IP perl-SOAP-Lite php-pecl-zip php-gd mod_perl perl-XML-Entities php-mysql perl-Apache2-SOAP php-pecl-json.x86_64 php-ldap.x86_64 php-imap.x86_64

php-imap is not strictly needed; we included it in case we wanted to use IMAP authentication as well. Again, adapt them to your environment, architecture, and distribution.

Security with LDAPS and an in-house PKI

Our environment is also fairly secure. We thus only use LDAPS or start_tls. Correctly configuring the underlying PHP and Apache infrastructure was essential to our environment. We maintain our own PKI and issue our own certificates.

Most of the on-line documentation on using PHP with LDAPS recommends editing /etc/openldap/ldap.conf to set TLS_REQCERT never. This disables server certificate validation. We insist that all server certificates be validated to prevent man-in-the-middle attacks so we had to find another way.

Our environment is the Apache http server running on 64-bit CentOS in a VServer for GLPI and CentOS Directory server (based upon RedHat Directory server). We disable all access and all options for Directory / as a security precaution and so must explicitly allow any access to the GLPI directories (in our case /usr/local/glpi). Here is how we configured our environment (sensitive data altered). Adapt as needed to your environment:

Edit /etc/httpd/conf.d/ssl.conf by adding the following stanza to the bottom:

<VirtualHost x.x.x.x:443>
    UseCanonicalName On
    DocumentRoot /usr/local/glpi
        <Directory "/usr/local/glpi">
            Options Indexes FollowSymLinks
            AllowOverride None
            Order allow,deny
            Allow from all
    ErrorLog logs/glpi.error_log
    CustomLog logs/glpi.access_log common
    SSLEngine on
    SSLCertificateFile /etc/pki/tls/certs/glpic.pem
    SSLCertificateKeyFile /etc/pki/tls/private/glpik.pem

One must edit /etc/httpd/conf/httpd.conf by adding the following line to the global configuration to allow server certificate validation:

LDAPTrustedGlobalCert CA_BASE64 /etc/pki/tls/certs/MyCA.pem

Ensure that /etc/pki/tls/certs/MyCA.pem is world readable or at least readable by the web server user or group (apache):

chgrp apache /etc/pki/tls/certs/MyCA.pem

chmod 660 /etc/pki/tls/certs/MyCA.pem

Finally, the LDAP configuration within GLPI can be a little confusing if one does not understand how the PHP ldap_connect() function works. If one wishes to use LDAPS (i.e., LDAP with SSL over default port 636), one specifies the server in URI format using ldaps, e.g., This will apparently ignore the port setting and use 636. There is thus no need to change the port from the default 389 in the GLPI LDAP configuration interface. One also leaves Use TLS set to No. Use TLS appears to be for using the start_tls functionality which starts a regular LDAP connection on default port 389 and then encrypts the transmission using TLS (still on port 389 thus eliminating the need to open another port on any intervening firewalls). To use start_tls functionality, one uses an ldap URI rather than ldaps, e.g., ldap://, and sets Use TLS to Yes. The two settings are mutually exclusive. Using AND Use TLS Yes will fail.

This is not an area of expertise for us so any suggestions for improvement to this configuration are most welcome.