GLPI-Wiki/wiki/doku.php?

id=en:ldap

Page 1 of 7

Trace: Integracin con LDAP y Active Directory GLPI, LDAP and Active Directory

GLPI, LDAP and Active Directory

Introduction
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.

Overview
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.

http://www.glpi-project.org/wiki/doku.php?id=en:ldap

29/05/2012

GLPI-Wiki/wiki/doku.php?id=en:ldap

Page 2 of 7

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://192.168.1.10), 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))

GLPI/LDAP Links
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).

http://www.glpi-project.org/wiki/doku.php?id=en:ldap

29/05/2012

GLPI-Wiki/wiki/doku.php?id=en:ldap

Page 3 of 7

Traditional LDAP directory setup:

Since the defaults should work, you will only need to specify the most basic parameters: host: ldap.myhost.fr 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 Host: ldap://myDC.myAD.example.com BaseDN: DC=myAD,DC=example,DC=com 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.

http://www.glpi-project.org/wiki/doku.php?id=en:ldap

29/05/2012

GLPI-Wiki/wiki/doku.php?id=en:ldap

Page 4 of 7

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 Base DN Root DN : 192.168.1.1 : DC=MYDOMAIN, DC=NET : 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 Time Zone : samaccountname : 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.8 : <Blank>

Group Attributes Containing Users

GLPI/LDAP Links
Surname First Name Comments E-mail Phone Phone2 Mobile : sn : givenname : nothing : mail : telephonenumber : homephone : 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).

http://www.glpi-project.org/wiki/doku.php?id=en:ldap

29/05/2012

GLPI-Wiki/wiki/doku.php?id=en:ldap

Page 5 of 7

C:> ntdsutil ntdsutil: ldap policies ldap policy: connections server connections: connect to server 192.168.1.1 ( 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. Mod_Security 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
Dependencies Our environment runs GLPI and OCS in VServer guests (www.linux-vserver.org). 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 wget http://packages.sw.be/rpmforge-release/rpmforge-release-0.3.6-1.el5.rf.x86_64.rpm wget http://rpms.famillecollet.com/el5.i386/remi-release-5-7.el5.remi.noarch.rpm wget http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-3.noarch.rpm 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:

http://www.glpi-project.org/wiki/doku.php?id=en:ldap

29/05/2012

GLPI-Wiki/wiki/doku.php?id=en:ldap

Page 6 of 7

[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

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 ServerAdmin operators@mycompany.com ServerName glpi.mycompany.com:443 DocumentRoot /usr/local/glpi <Directory "/usr/local/glpi"> Options Indexes FollowSymLinks AllowOverride None Order allow,deny Allow from all </Directory> 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 </VirtualHost>

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):

http://www.glpi-project.org/wiki/doku.php?id=en:ldap

29/05/2012

GLPI-Wiki/wiki/doku.php?id=en:ldap

Page 7 of 7

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., ldaps://ldap.mycompany.com. 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://ldap.mycompany.com, and sets Use TLS to Yes. The two settings are mutually exclusive. Using ldaps://ldap.mycompany.com 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.

http://www.glpi-project.org/wiki/doku.php?id=en:ldap

29/05/2012