Tuesday, November 22, 2011

Linux and UNIX HOW-TO: Setup a basic OpenLDAP Client and Server

What is LDAP?

LDAP stands for Lightweight Directory Access Protocol. As the name suggests, it is a lightweight protocol for accessing directory services, specifically X.500-based directory services. LDAP runs over TCP/IP or other connection oriented transfer services.

What is a directory service?

A directory is a specialized database optimized for reading, browsing and searching. Directories tend to contain descriptive, attribute-based information and support sophisticated filtering capabilities.

How does LDAP work?

LDAP directory service is based on a client-server model. One or more LDAP servers contain the data making up the directory information tree (DIT). The client connects to servers and asks it a question. The server responds with an answer and/or with a pointer to where the client can get additional information (typically, another LDAP server). No matter which LDAP server a client connects to, it sees the same view of the directory; a name presented to one LDAP server references the same entry it would at another LDAP server. This is an important feature of a global directory service, like LDAP.

What is the difference between LDAPv2 and LDAPv3?

LDAPv3 was developed in the late 1990's to replace LDAPv2. LDAPv3 adds the following features to LDAP:
  • Strong authentication and data security services via SASL
  • Certificate authentication and data security services via TLS (SSL)
  • Internationalization through the use of Unicode
  • Referrals and Continuations
  • Schema Discovery
  • Extensibility (controls, extended operations, and more)
What is slapd and what can it do?

slapd is an LDAP directory server that runs on many different platforms. You can use it to provide a directory service of your very own.

What is slurpd and what can it do?

slurpdis a daemon that, with slapd help, provides replicated service. It is responsible for distributing changes made to the master slapd database out to the various slapd replicas. It frees slapd from having to worry that some replicas might be down or unreachable when a change comes through; slurpd handles retrying failed requests automatically. slapd and slurpd communicate through a simple text file that is used to log changes.

The topic of LDAP seems to be little bit complicated at the beginning, so we will start with a simple example to for demonstration purposes.
We will use two machines in this example: a client and a server, both running Red Hat Enterprise Linux 5.4. We will use the OpenLDAP rpm package that’s available with Red Hat. The setup is:
Server: station1.example.com 192.168.0.1

Client: station2.example.com 192.168.0.2
To demonstrate some of the functionality of an LDAP server, we will add local users to “station1.example.com” (our Server) BEFORE we configure it as an LDAP server. Then, we will configure it as an LDAP Server so that all the users (i.e. /etc/passwd and /etc/shadow and /etc/group contents) will be imported to the LDAP database, and finally after configuring “station2.example.com” as an LDAP client, we will verify our configuration by listing the users that the system can see which should include the users that we created on “station1.example.com”.
We will break out configuration into a very simple steps. We will start with the server “station1.example.com”:
1. Create test users:
[root@station1 ~]# useradd user1
[root@station1 ~]# useradd user2
[root@station1 ~]# useradd user3
2. Install the following packages (rpms):
[root@station1 ~]# yum install openldap-servers-2.3.43-3.el5
[root@station1 ~]# yum install openldap-2.3.43-3.el5
[root@station1 ~]# yum install openldap-clients-2.3.43-3.el5
3. Edit the LDAP config file to add the name of our suffix (in this case, it’s dc=example,dc=com). Edit only three lines:
[root@station1 ~]# vi /etc/openldap/slapd.conf
suffix          "dc=example,dc=com"
rootdn          "cn=Manager,dc=example,dc=com"

...
rootpw          123

[root@station1 ~]# 
In the above file, we only edited three lines to make “dc=example,dc=com” because that’s our suffix in this demo. We also made the root password (rootpw) = 123, that’s the root admin for LDAP. Password is store in text format here for simplicity.

4. The next step is to migrate the local files (/etc/passwd, /etc/shadow, and /etc/group) contents to an LDIF file. This is done using scripts that are ready with the packages we installed at the beginning
[root@station1 migration]# cd /usr/share/openldap/migration/
[root@station1 migration]# ./migrate_base.pl > a.ldif
[root@station1 migration]# ./migrate_passwd.pl  /etc/passwd >> a.ldif
[root@station1 migration]# ./migrate_group.pl /etc/group >> a.ldif
The resulting file “a.ldif” is a text file, you can read the file to verify that the contents were migrated properly.

An entry can look like this when represented in LDAP Data Interchange Format (LDIF) (LDAP itself is a binary protocol):
dn: cn=John Doe,dc=example,dc=com
cn: John Doe
givenName: John
sn: Doe
telephoneNumber: +1 888 555 6789
telephoneNumber: +1 888 555 1232
mail: john@example.com
manager: cn=Barbara Doe,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top

"dn" is the distinguished name of the entry; it's neither an attribute nor a part of the entry. "cn=John Doe" is the entry's RDN (Relative Distinguished Name), and "dc=example,dc=com" is the DN of the parent entry, where "dc" denotes 'Domain Component'. The other lines show the attributes in the entry. Attribute names are typically mnemonic strings, like "cn" for common name, "dc" for domain component, "mail" for e-mail address and "sn" for surname.

5. Since the LDIF file is ready, we can now build the LDAP database:
First check the existing LDAP database (it should be empty):
[root@station1 ~]# ls /var/lib/ldap/
openldap-severs-update.log
[root@station1 ~]#
There’s only one empty log file, that’s fine. Now we can build the database:
[root@station1 ~]#ldapadd -x -D "cn=Manager,dc=<example>,dc=<COM>" -W 
-l  /usr/share/openldap/migration/a.ldif

Where -v enable verbose mode
-x 
Use simple authentication instead of SASL.
-D binddn 
Use the Distinguished Name binddn to bind to the LDAP directory. For SASL binds, the server is expected to ignore this value.
-W 
Prompt for simple authentication. This is used instead of specifying the password on the command line.
-l ldif-file 
Read LDIF from the specified file instead of standard input.

6. Verify that the database has been successfully created:
[root@station1 ~]# ls -l /var/lib/ldap
total 1880
-rw-r--r-- 1 root root     2048 Oct 21 12:28 alock
-rw------- 1 root root    36864 Oct 21 12:25 cn.bdb
-rw------- 1 root root    24576 Oct 21 12:25 __db.001
-rw------- 1 root root   278528 Oct 21 12:25 __db.002
-rw------- 1 root root   270336 Oct 21 12:25 __db.003
-rw------- 1 root root    98304 Oct 21 12:25 __db.004
-rw------- 1 root root   352256 Oct 21 12:25 __db.005
-rw------- 1 root root    24576 Oct 21 12:25 __db.006
-rw------- 1 root root    36864 Oct 21 12:25 dn2id.bdb
-rw------- 1 root root     8192 Oct 21 12:25 gidNumber.bdb
-rw------- 1 root root   114688 Oct 21 12:25 id2entry.bdb
-rw------- 1 root root 10485760 Oct 21 12:25 log.0000000001
-rw------- 1 root root     8192 Oct 21 12:25 loginShell.bdb
-rw------- 1 root root     8192 Oct 21 12:25 memberUid.bdb
-rw------- 1 root root     8192 Oct 21 12:25 nisMapName.bdb
-rw------- 1 root root    20480 Oct 21 12:25 objectClass.bdb
-rw-r--r-- 1 root root       37 Oct 21 11:54 openldap-severs-update.log
-rw------- 1 root root     8192 Oct 21 12:25 ou.bdb
-rw------- 1 root root    20480 Oct 21 12:25 uid.bdb
-rw------- 1 root root     8192 Oct 21 12:25 uidNumber.bdb
[root@station1 ~]#
As we can see, the database files have been created. We can check that the database is actually true to the LDIF we created by executing this command:
[root@station1 ~]# slapcat
The output should match the contents of the LDIF file generated earlier.
7. Change permissions of the LDAP database files. Since they will be accessed by the LDAP daemon, then they shouldn’t have “root” as owner and group.
[root@station1 ~]# chown ldap.ldap * /var/lib/ldap
[root@station1 ~]# ls -l /var/lib/ldap
total 1880
-rw-r--r-- 1 ldap ldap     2048 Oct 21 12:28 alock
-rw------- 1 ldap ldap    36864 Oct 21 12:25 cn.bdb
-rw------- 1 ldap ldap    24576 Oct 21 12:25 __db.001
-rw------- 1 ldap ldap   278528 Oct 21 12:25 __db.002
-rw------- 1 ldap ldap   270336 Oct 21 12:25 __db.003
-rw------- 1 ldap ldap    98304 Oct 21 12:25 __db.004
-rw------- 1 ldap ldap   352256 Oct 21 12:25 __db.005
-rw------- 1 ldap ldap    24576 Oct 21 12:25 __db.006
-rw------- 1 ldap ldap    36864 Oct 21 12:25 dn2id.bdb
-rw------- 1 ldap ldap     8192 Oct 21 12:25 gidNumber.bdb
-rw------- 1 ldap ldap   114688 Oct 21 12:25 id2entry.bdb
-rw------- 1 ldap ldap 10485760 Oct 21 12:25 log.0000000001
-rw------- 1 ldap ldap     8192 Oct 21 12:25 loginShell.bdb
-rw------- 1 ldap ldap     8192 Oct 21 12:25 memberUid.bdb
-rw------- 1 ldap ldap     8192 Oct 21 12:25 nisMapName.bdb
-rw------- 1 ldap ldap    20480 Oct 21 12:25 objectClass.bdb
-rw-r--r-- 1 ldap ldap       37 Oct 21 11:54 openldap-severs-update.log
-rw------- 1 ldap ldap     8192 Oct 21 12:25 ou.bdb
-rw------- 1 ldap ldap    20480 Oct 21 12:25 uid.bdb
-rw------- 1 ldap ldap     8192 Oct 21 12:25 uidNumber.bdb
[root@station1 ~]# 
8. Now the LDAP server is ready! Start the service:
[root@station1 ~]# service ldap start
Checking configuration files for slapd:  bdb_db_open: Warning - No DB_CONFIG file found in directory /var/lib/ldap: (2)
Expect poor performance for suffix dc=example,dc=com.
config file testing succeeded
                                                           [  OK  ]
[root@station1 ~]#
Next, we will configure “station2.example.com” as an LDAP client. It’s very simple, we will use the GUI for simplicity:
Execute this command to lunch the GUI tool:
[root@station2 ~]# system-config-authentication
Choose “Enable LDAP Support”, then click “configure LDAP”:

Enter the settings as follows then click “OK” :

Now that the system “station2.example.com” should be configured as an LDAP client, we can test our configuration with LDAP Search commands:
1. To use LDAP commands, we should have this pacakge installed in the clients:
[root@station2 ~]# rpm -qa|grep ldap-clients
openldap-clients-2.3.43-3.el5
[root@station2 ~]
2. Execute ldapsearch commands to retrieve information about the users we configured on the LDAP server:
[root@station2 ~]# ldapsearch -x uid=user1
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <> with scope subtree
# filter: uid=user1
# requesting: ALL
#

# user1, People, example.com
dn: uid=user1,ou=People,dc=example,dc=com
uid: user1
cn: user1
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword:: e2NyeXB0fSQxJHlIUGxDcWk2JGJnbHFKSVpaUlFIbGFrSzFwNzlvby8=
shadowLastChange: 15268
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 500
gidNumber: 500
homeDirectory: /home/user1

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1
[root@station2 ~]# 
This means that both the client and server are working fine.

Note that this document comes without warranty of any kind. But every effort has been made to provide the information as accurate as possible. I welcome emails from any readers with comments, suggestions, and corrections at webmaster_at admin@linuxhowto.in

Copyright © 2012 LINUXHOWTO.IN


1 comment: