NOTE: These instructions are assuming that the LDAP client runs on the same machine as the LDAP server runs.
Environment:
IP: 192.168.100.27
LDAP Client Machine names: ldapc.itmatrix.srv ldapc
LDAP Server Machine names: ldaps.itmatrix.srv ldaps
NOTE: This tutorial is a short and updated version of the one found at:
http://techpubs.spinlocksolutions.com/dklar/ldap.html
Edit /etc/hosts and se the content as follows:
Set the names of localhost(nothing more, nothing less)
127.0.0.1 localhost localhost.localdomain
Set the LDAP client and server machine names and IPs
192.168.100.27 ldapc.itmatrix.srv ldapc ldaps.itmatrix.srv ldaps
Note: If you have a private LAN DNS server you can set the IPs in it instead on in /etc/hosts
just make sure your first ‘nameserver’ in /etc/resolv.conf is set to this LAN DNS.

Configure debconf to a known state
$ dpkg-reconfigure debconf
When asked, answer
   interface=Dialog
   priority=low.

LDAP Server Installation

$ apt-get install slapd ldap-utils
When asked answer the questions as follows:
Omit OpenLDAP server configuration? No
DNS domain name: itmatrix.srv
Organization name? itmatrix.srv
Administrator password: {PASSWORD}
Confirm password: {PASSWORD}
Database backend to use: HDB
Do you want the database to be removed when slapd is purged? No
Allow LDAPv2 protocol? No
As soon as the installation is done, the OpenLDAP server (command slapd) will start.

Edit the file /etc/ldap/ldap.conf (creating the file if necessary)
Change the verbosity level from 0 or “none” to 256:
loglevel 256
Search for line “index objectClass eq” and add another search index.
In particular combinations, it may be possible to receive no results when the searched entries are not indexed,
so this step is important:
index objectClass eq
index uid eq

To make the new index option apply, run the following commands:
$ invoke-rc.d slapd stop
$ slapindex
$ chown -R openldap:openldap /var/lib/ldap
$ invoke-rc.d slapd start

Testing the LDAP database

Offline test:
(extract the information directly from the ldap database files)
$ slapcat
Result:
dn: dc=itmatrix,dc=srv
objectClass: top
objectClass: dcObject
objectClass: organization
o: itmatrix.srv
dc: itmatrix
structuralObjectClass: organization
entryUUID: cf6b09ce-581f-102f-8806-87a0cf98f8fa
creatorsName:
createTimestamp: 20100919095542Z
entryCSN: 20100919095542.752910Z#000000#000#000000
modifiersName:
modifyTimestamp: 20100919095542Z
#
dn: cn=admin,dc=itmatrix,dc=srv
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator
userPassword:: e2NyeXB0fWRsOHl5TkhGYWtMNUE=
structuralObjectClass: organizationalRole
entryUUID: cf6b2bd4-581f-102f-8807-87a0cf98f8fa
creatorsName:
createTimestamp: 20100919095542Z
entryCSN: 20100919095542.753850Z#000000#000#000000
modifiersName:
modifyTimestamp: 20100919095542Z
Online test:
(connects to the local LDAP server and makes the query)
$ ldapsearch -x -b dc=itmatrix,dc=srv
Result:
# extended LDIF
#
# LDAPv3
# base with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
#
# itmatrix.srv
dn: dc=itmatrix,dc=srv
objectClass: top
objectClass: dcObject
objectClass: organization
o: itmatrix.srv
dc: itmatrix
#
# admin, itmatrix.srv
dn: cn=admin,dc=itmatrix,dc=srv
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator
#
# search result
search: 2
result: 0 Success
#
# numResponses: 3
# numEntries: 2

ADDING “organizational units”
such as people, groups, hosts, services, networks, protocols, etc.

Adding the ‘people’ and ‘group’ organizational units(equivalent to /etc/passwd and /etc/group)
Such units can be added directly by creating an ‘LDIF’ type file and adding it OFFLINE’ using ‘slapadd’ command
or using via the LDAP the server using ‘ldapadd’ command.

Creating the LDIF type file (/var/tmp/ou.ldif)
IMPORTANT:Notice the empty line between the Units
dn: ou=People,dc=itmatrix,dc=srv
ou: People
objectClass: organizationalUnit
  
dn: ou=Group,dc=itmatrix,dc=srv
ou: Group
objectClass: organizationalUnit
Adding the data (LDIF) to ldap server using ‘slapadd’
$ invoke-rc.d slapd stop
$ slapadd -c -v -l /var/tmp/ou.ldif
$ invoke-rc.d slapd start

Checking the new content
$ ldapsearch -x -b dc=itmatrix,dc=srv ou=people
Result:
# extended LDIF
#
# LDAPv3
# base with scope subtree
# filter: ou=people
# requesting: ALL
#
#
# People, itmatrix.srv
dn: ou=People,dc=itmatrix,dc=srv
ou: People
objectClass: organizationalUnit
#
# search result
search: 2
result: 0 Success
#
# numResponses: 2
# numEntries: 1

Creating user accounts
Account for user Michel
Content of LDIF file /var/tmp/michel.ldif
dn: cn=michel,ou=group,dc=itmatrix,dc=srv
cn: michel
gidNumber: 1001
objectClass: top
objectClass: posixGroup
#
dn: uid=michel,ou=people,dc=itmatrix,dc=srv
uid: michel
uidNumber: 1001
gidNumber: 1001
cn: Michel
sn: Michel
objectClass: top
objectClass: person
objectClass: posixAccount
objectClass: shadowAccount
loginShell: /bin/bash
homeDirectory: /home/michel

Adding the data (LDFI) file
using the ‘ldapadd’ command (via the LDAP server)
$ ldapadd -c -x -D cn=admin,dc=itmatrix,dc=srv -W -f /var/tmp/michel.ldif
(Enter the ‘admin’ password that you gave during the LDAP server installation)

Adding a password to the new user’s account:
(step not needed with kerberos auth)
$ ldappasswd -x -D cn=admin,dc=itmatrix,dc=srv -W -S uid=michel,ou=people,dc=itmatrix,dc=srv
(Enter the new user’s password twice , then the ‘admin’ password for authorization)

Verifying that the user is been created
(the passowrd will not show due to restrictions set in /etc/ldap/slapd.conf)
$ ldapsearch -x -b dc=itmatrix,dc=srv cn=michel
Result:
# extended LDIF
#
# LDAPv3
# base with scope subtree
# filter: cn=michel
# requesting: ALL
#
#
# michel, Group, itmatrix.srv
dn: cn=michel,ou=Group,dc=itmatrix,dc=srv
cn: michel
gidNumber: 1001
objectClass: top
objectClass: posixGroup
#
# michel, People, itmatrix.srv
dn: uid=michel,ou=People,dc=itmatrix,dc=srv
uid: michel
uidNumber: 1001
gidNumber: 1001
cn: Michel
sn: Michel
objectClass: top
objectClass: person
objectClass: posixAccount
objectClass: shadowAccount
loginShell: /bin/bash
homeDirectory: /home/michel
#
# search result
search: 2
result: 0 Success
#
# numResponses: 3
# numEntries: 2

Congratulations, your LDAP server is working.

Adding the NSS

Now that we have a new user created in LDAP, we should allow the system to see it.
For example, let’s test for existence of users root and michel.
The administrator will be present, while michel will not, at least till now.

$ id root
uid=0(root) gid=0(root) groups=0(root)

$ id michel
id: michel: No such user

To enable the system to see LDAP accounts, we need to install libnss-ldap
(which may automatically install libpam-ldap and nscd as well):
$ apt-get install libnss-ldap nscd
During this installation the ‘libnss-ldap’ will be configured and you will be promted with some questions.
This will configure the file /etc/libnss-ldap.conf and request the LDAP admin password.
———
LDAP server URI: ldap://127.0.0.1/
NOTE1: (Note the “ldap://”, NOT “ldapi://”!)
NOTE2: The address ‘localhost’ is not used but could be since the NSS priority will be ‘files ladp’
‘files’ means /etc/hosts. But since localhost is almost always 127.0.0.1, well, why not use this one.

Distinguished name of the search base: dc=itmatrix,dc=srv
LDAP version to use: 3
Does the LDAP database require login? No
Special LDAP privileges for root? No
Make the configuration file readable/writeable by its owner only? No
Allow LDAP admin account to behave like local root? Yes
Make local root Database admin. No
Does the LDAP database require login? No
LDAP administrative account: cn=admin,dc=itmatrix,dc=srv
LDAP administrative password: {PASSWORD}
Local crypt to use when changing passwords: md5
If asked: PAM profiles to enable: select all
———

NOTE: Example of libnss-ldap configuration can be found at: /usr/share/doc/libnss-ldap/examples/nsswitch.ldap

Activate the LDAP NSS module:
Edit /etc/nsswitch.conf by replacing the 3 following lines:
passwd:   compat
group:    compat
shadow:   compat
WITH
passwd:    files ldap
group:     files ldap
shadow:    files ldap
Stopping the NSCD daemon:
Nscd (the Name Service Caching Daemon) is used to cache metadata locally, instead of querying the LDAP server each time. It is a very efficient service in the long run, but we will stop it for for the moment, during testing, to always retrieve the data directly from the LDAP server:
$ invoke-rc.d nscd stop
Now we can verify that LDAP users have become visible:
$ id michel
uid=1001(michel) gid=1001(michel) groups=1001(michel)

PAM configuration

The final step in this article pertains to integrating LDAP into the system authentication procedure.
Let’s install and configure libpam-ldap.
(You might have already done this step automatically, during libnss-ldap installation —
in that case Debian will just report the package is already installed).
Optional: If you want to reconfigure it again then issue the command:
$ dpkg-reconfigure libpam-ldap
(This will configure the file /etc/pam_ldap.conf)

Answers recomended:
ldap://127.0.0.1/
Make local root Database admin. - No
Does the LDAP database require login? - No
Local crypt to use when changing passwords. - md5

Now let’s configure Linux-PAM itself.
PAM configuration is quite fragile, so use the provided examples that have been verified to work.
For any modifications, you will want to look at PAM Configuration File Syntax
(http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/sag-configuration-file.html)
and pay special attention to seemingly insignificant variations — with PAM,
they often make a whole world of difference.

PAM will require the user to be present either in the local password file or in LDAP
and to know the correct password, for the authentication process to continue.

NOTE:
Authentication through LDAP, as shown here, is not secure, due to connections to the LDAP
server being made in plain text and passwords travelling over the wire.
Instead of encrypting the connection to the LDAP server, the PAM files shown below also support
Kerberos for authentication, if you’ve installed Kerberos as explained in MIT Kerberos 5 Guide.
In that case, modify the PAM lines as noted in file comments and the authentication will be performed
in a completely secure and superior manner using Kerberos.

In our case we are not worried about security on the network because our LDAP server is running
on the same host as the services requesting it, therefore using ‘locahost’ as network connection.

Edit /etc/pam.d/common-account:
Make sure the file content looks like this
account sufficient&bsp;&bsp;&bsp;&bsp;pam_unix.so
account required&bsp;&bsp;&bsp;&bsp;pam_ldap.so
 
# Enable if using Kerberos:
#account required    pam_krb5.so
Edit /etc/pam.d/common-auth:
Make sure the file content looks like this
# Disable the three lines if using Kerberos:
auth [success=1 default=ignore] pam_unix.so nullok_secure
auth required pam_ldap.so use_first_pass
auth required pam_permit.so
  
# Enable the three lines if using Kerberos:
#auth        pam_unix.so nullok_secure
#auth        pam_krb5.so use_first_pass
#auth        pam_deny.so
Edit /etc/pam.d/common-password
Make sure the file content looks like this
password sufficient   pam_unix.so nullok obscure md5
   
# Disable if using Kerberos:
password required   pam_ldap.so use_first_pass
   
# Enable if using Kerberos:
#password required pam_krb5.so use_first_pass

Edit /etc/pam.d/common-session
Make sure the file content looks like this
session required    pam_unix.so
session required    pam_mkhomedir.so skel=/etc/skel/ umask=0022
  
# Enable if using Kerberos:
#session optional pam_krb5.so minimum_uid=1000
Having everything adjusted as shown, login to the system should succeed as user michel.
ssh michel@127.0.0.1
Bingo I’m in.
And root stays as it was through /etc/passwd and /etc/shadow

Web LDAP Browser Installation

Note: Since I didn’t have a very good experience with the Stable Debian version of phpLDAPAdmin ver. 1.1.0.5
I decided to try the unstable version 1.2.0.5 and that worked better. So I’m providing the steps to install the unstable version.

Change the Debian repository temporarily to install the unstable version:
Edit the file: /etc/apt/sources.list
Add the following line:
deb http://ftp.fi.debian.org/debian/ unstable main contrib non-free
Run the commands:
$ apt-get update
$ apt-get install phpldapadmin
When asked:
– Chose ‘session‘ as authentication method
– Select only ‘apache2‘ on next screen

Delete the Apache symlink
which includes the Apache configuration as Global and include it in the SSL virtualhost.
$ rm /etc/apache2/conf.d/phpldapadmin
Edit your Apache2 SSL VirtualHost configuration
and add the following line:
Include /etc/phpldapadmin/apache.conf
To bring the Debian Packages source back to normal:
Edit the file: /etc/apt/sources.list
Disable the following line as follows:
#deb http://ftp.fi.debian.org/debian/ unstable main contrib non-free
Run the command:
$ apt-get update

Restart Apache2 and try it.
/etc/init.d/apache2 restart
In your browser:
https://yourservername/phpldapadmin

Want to add extra security with web authentication using your brand new LDAP server?
Here we are going to allow only the authenticated user ‘michel’ which is already a user entry in our LDAP server.

Syntax of AuthLDAPURL
Protocol://ServerName/SearRealmFilter?searchAttribute
Protocol: ldap
ServerName: 127.0.0.1
SearRealmFilter: ou=People,dc=itmatrix,dc=srv
SearchAttribute: cn

Apache Directives
Edit your Apache VirtualHost configuration file of the ‘Web LDAP Browser’ and add the following lines:

<Location /phpldapadmin>
    AuthType Basic
    AuthBasicProvider ldap
    AuthName "LDAP Auth"
    AuthzLDAPAuthoritative On
    AuthLDAPURL "ldap://127.0.0.1/ou=People,dc=itmatrix,cd=srv?cn"
    require ldap-user michel
</Location>

Have fun LDAPping.