LDAP

Lightweight Directory Access Protocol (LDAP)

Theory taken from http://www.tldp.org, under the GNU Free Documentation License (FDL). While this step-by-step guide is a result of in-house implementation of a given scenario.

1. Overview:

The Lightweight Directory Access Protocol (LDAP) is a lightweight client-server protocol for accessing directory services, specifically X.500-based directory services. LDAP runs over TCP/IP or other connection-oriented transfer services. LDAP is defined as RFC2251.

A directory is similar to a database, but it tends to contain more descriptive, attribute-based information. The information in a directory is generally read much more often than it is written. Directories are tuned to give a quick response to high-volume search operations. They may have an ability to replicate information widely in order to increase availability and reliability, while reducing response time. When directory information is replicated, temporary inconsistencies between the replicas may be considered acceptable as long as they eventually get synchronized.

There are many different ways of providing a directory service. Different methods allow different kinds of information to be stored in the directory; place different requirements on how that information can be referenced, queried and updated; and how it can be protected from unauthorized access, etc. Some directory services are local, providing services within a restricted context (e.g., the finger service on a single machine). Other services are global, providing services within a much broader context.

2. How does LDAP work?

It is often convenient to share system information among workstations. Users, for example, like to be able to login to multiple machines with the same password; this requires that the machines share the data conventionally stored in /etc/passwd and /etc/shadow. Using NFS is usually not an option, since that will share all of /etc/, and you might want some elements configured differently on each machine. NIS used to be a common answer to this dilemma, but LDAP databases, being more flexible and scalable, have now become the preferred solution.

The LDAP directory service is based on a client-server model. One or more LDAP servers contain the data making up the LDAP directory tree, or the LDAP back-end database. An LDAP client connects to an LDAP server, and asks it a question. The server responds with an answer or with a pointer to where the client can get more information (typically, another LDAP server). No matter what 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 such as LDAP.

LDAP databases are object-oriented, as opposed to relational databases. An LDAP database is filled with objects, each of which has associated attributes. The following example is a typical object representing a user account.

dn: uid=abubakar,ou=people,dc=example,dc=com

cn: Abubakar Shoaib

uid: abubakar

uidNumber: 1001

gidNumber: 100

homeDirectory: /home/abubakar

loginShell: /bin/bash

objectClass: top

objectClass: posixAccount

Each object has a unique Distinguished Name (DN) attribute for identification purposes. Each object is a member of one or more object classes, which determine which attributes it may and must have according to a well-defined schema. Objects in an LDAP database are organized into a tree hierarchy, based on their DN.

By tradition, the organization example.com uses dc=example,dc=com for its root object (but nothing enforces this tradition). Below the root are objects representing different organizational units, such as people or hosts. The children of these objects are the people and hosts themselves.

3. LDAP back-ends, objects and attributes

The LDAP server daemon is known as Slapd. It supports a variety of different database backends which you can use.

These include the primary choice BDB, a high-performance transactional database back-end; LDBM, a lightweight DBM-based back-end; SHELL, a back-end interface to arbitrary shell scripts; and PASSWD, a simple back-end interface to the passwd(5) file.

The BDB utilizes Sleepycat Berkeley DB 4. LDBM utilizes either Berkeley DB or GDBM. The BDB transactional back-end is best-suited for multi-user read and write database access, with any mix of read and write operations. BDB is used in applications that require:

·      Transactions, including making multiple changes to the database atomically, and rolling back uncommitted changes when necessary

·      An ability to recover from system crashes and hardware failure without losing any committed transactions

A file format known as the LDAP Data Interchange Format (LDIF) is typically used in order to import and export directory information between LDAP-based directory servers, or to describe a set of changes which are to be applied to a directory. An LDIF file stores information in object-oriented hierarchies of entries. The LDAP software package comes with a utility to convert LDIF files into the BDB format.

A common LDIF file looks like this:

dn: o=TUDelft, c=NL o: TUDelft objectclass: organization dn: cn=Qandeel Aslam, o=TUDelft, c=NL cn: Qandeel Aslam sn: Aslam mail: qaslam@yahoo.com objectclass: person

As you can see, each entry is uniquely identified by a DN. The DN consists of the name of the entry, plus a path of names tracing the entry back to the top of the directory hierarchy.

In LDAP, an object class defines the collection of attributes that can be used to define an entry. The LDAP standard provides the following basic types of object classes:

1.     Groups in the directory, including unordered lists of individual objects, or groups of objects

2.     Locations, such as a country’s name and description

3.     Organizations in the directory

4.     People in the directory

An entry can belong to more than one object class. The entry for a person, for example, is defined by the person object class, but can also be defined by attributes in the inetOrgPerson, groupOfNames, and organization objectclasses. The server's object class structure (its schema) determines the total list of required and allowed attributes for a particular entry.

Directory data is represented in the form of attribute-value pairs. Any specific piece of information is associated with a descriptive attribute.

The Common Name (CN) attribute is used to store a person's name. A person named Abubakar Shoaib can be represented in the directory as:

cn: Abubakar Shoaib

Each person entered in the directory is defined by the collection of attributes in the person object class. Other attributes used to define this entry can include:

givenname: Abubakar surname: Shoaib mail: ashoaib@airius.com

Required attributes include the attributes that must be present in entries using the object class. All entries require the objectClass attribute, which lists the object classes to which an entry belongs.

Allowed attributes include the attributes that may be present in entries using the object class. In the person object class, for example, the CN and SN attributes are required. The description, telephoneNumber, seeAlso, and userpassword attributes are allowed, but are not required.

Each attribute has a corresponding syntax definition, which describes the type of information provided by an attribute. Examples include:

1.     BIN binary

2.   CES Case Exact String (case must match during comparisons)

3.   CIS Case Ignore String (case is ignored during comparisons)

4.   TEL telephone number string (like CIS, but blanks and dashes "-" are ignored during comparisons)

5.   DN Distinguished Name

Note: Objectclass and attribute definitions generally reside on schema files, on the sub-directory schema, under the OpenLDAP installation home.

4. Step-by-step Configuration Guide

4.1. Scenario

·         A company wants a simple, secure, centralized login scheme for all its servers/clients.

·         It has decided to use the LDAP domain “tdomain.com” for its LDAP database, in which one Domain Component (DC) will be “tdomain”, and the other will be “com”.

·         The database will have only one organizational unit known as “People”, which is an LDAP default.

·         Each person will have attributes, such as a username (User ID or UID), password, Linux home directory, and login shell.

·         The Fedora Linux server known as Dman, with the IP address 192.168.2.79, will act as the LDAP server containing the database.

·         The Fedora Linux server known as smallfry will be used to test the system as the LDAP client. It has the IP address 192.168.2.69.

·         The server Dman has a special user account named ldapuser. It will be used to test the LDAP logins.

4.2. Downloading and Installing the LDAP Packages

Most Red Hat and Fedora Linux software products are generally available in the RPM format. When searching for the file, remember that the FreeRADIUS RPM's filename usually starts with “openldap”, followed by a version number, as in openldap-servers-2.1.22-8.i386.rpm.

4.2.1. Required LDAP Server RPMs

Ensure that the following packages are installed on your LDAP server:

1.     openldap

2.     openldap-clients

3.     openldap-devel

4.     nss_ldap

5.     openldap-servers

4.2.2. Required LDAP Client RPMs

Ensure that the following packages are installed on your LDAP client:

1.     openldap

2.     openldap-clients

3.     openldap-devel

4.     nss_ldap

4.3. Configuring the LDAP Server

The first stage of the project is to correctly configure the LDAP server. Create an LDAP database into which you will import the /etc/passwd file:

4.3.1. Create a database directory

Fedora LDAP defaults to putting all databases in the /var/lib/ldap directory. For the tdomain, create a dedicated tdomain.com directory owned by the user ldap. (The ldap user is always created during the RPM installation process):

[root@Dman tmp]# mkdir /var/lib/ldap/tdomain.com

[root@Dman tmp]# chown ldap:ldap /var/lib/ldap/tdomain.com

4.3.2. Create an LDAP "root" password

Only an LDAP root user can create, import, and export data into an LDAP database. This user requires an encrypted password. Create it with the slappasswd command, and use the result in the LDAP configuration file:

[root@Dman tmp]# slappasswd

New password:

Re-enter new password:

{SSHA}v4qLq/qy01w9my60LLX9BvfNUrRhOjQZ

[root@Dman tmp]#

4.3.3. Edit the slapd.conf file

The main LDAP server configuration file is /etc/openldap/slapd.conf. Update it with:

1.   A database of the default type ldbm, using the domain suffix tdomain.com, made up of the Domain Components (DCs) tdomain and com.

2.   The root user with a Common Name (CN), or nickname, of “Manager” who is a part of the tdomain and com DCs.

3.   An encrypted version of the LDAP root password, as well as the location of the LDAP database.

The configuration file syntax to do this is:

database          ldbm suffix                "dc=tdomain,dc=com" rootdn              "cn=Manager,dc=tdomain,dc=com" rootpw              {SSHA}v4qLq/qy01w9my60LLX9BvfNUrRhOjQZ directory           /var/lib/ldap/tdomain.com

4.3.4. Start the LDAP daemon

The service command uses the options “start”, “stop”, and “restart” to control the LDAP server's operation. Use the “start” option to load the contents of the slapd.conf file.

[root@Dman tmp]# service ldap start

Starting slapd: [ OK ]

[root@Dman tmp]#

4.3.5. Convert the /etc/passwd file into LDIF format

The data on the server's /etc/passwd file now needs to be converted into the LDAP Data Interchange Files (LDIF) format before it can be imported into the LDAP database. You do not need to import all of the usernames, only the ones you need.

4.3.6. Create the ldapuser test account

To create the ldapuser account you will use for testing, type:

[root@Dman tmp]# useradd -g users ldapuser

[root@Dman tmp]# passwd ldapuser

Changing password for user ldapuser.

New password:

Retype new password:

passwd: all authentication tokens updated successfully.

[root@Dman tmp]#

4.3.7. Extract the required records from /etc/passwd

Extract the ldapuser information from the /etc/passwd file using the grep command. Save it by appending the information to the /etc/openldap/passwd.ldapusers file, with the > character:

[root@Dman tmp]# grep ldapuser /etc/passwd > \

 /etc/openldap/passwd.ldapusers

[root@Dman tmp]#

If this is your first time creating an LDAP database, extract the information for the Linux root account from the /etc/passwd file to a new file known as /etc/openldap/passwd.root.

[root@Dman tmp]# grep root /etc/passwd > \

   /etc/openldap/passwd.root

[root@Dman tmp]#

4.3.8. Find the conversion script

The /etc/passwd conversion program is called migrate_passw.pl; find it by using the “locate” command. This utility updates its database every night, and might be unable to find newly-installed files. Use the locate command to update ahead of schedule:

[root@Dman tmp]# locate -u

[root@Dman tmp]# locate migrate

...

/usr/share/openldap/migration/migrate_passwd.pl

...

[root@Dman tmp]#

4.3.9. Convert the ".ldapuser" file

Convert the extracted /etc/passwd data into an LDIF, which will then be imported into the database. Give the file used by regular users the name /etc/openldap/ldapuser.ldif and the one for the root user the name /etc/openldap/root.ldif.

[root@Dman tmp]# /usr/share/openldap/migration/migrate_passwd.pl \

/etc/openldap/passwd.ldapusers /etc/openldap/ldapusers.ldif

[root@Dman tmp]#

[root@Dman tmp]# /usr/share/openldap/migration/migrate_passwd.pl \

/etc/openldap/passwd.root /etc/openldap/root.ldif

[root@Dman tmp]#

4.3.10. Modify the LDIF files

With your two new LDIF files, the next step is to import this data into the LDAP database. In order to prepare for this, you must do some editing, and create a new LDIF file that defines an organizational unit.

4.3.11. Edit the user LDIF file

The Fedora migrate_passwd.pl script creates users that are all a part of an organizational unit known as “People”, but everyone belongs to the padl.com domain. Edit both the LDIF files, and convert the string "padl" into "tdomain" in each record. A text editor is suitable for this purpose. For tdomain, at the vi editor's : prompt, use the following command to perform a global substitution of “tdomain” for “padl”:

%s/padl/tdomain/g

In the slapd.conf file, you gave the root user a Common Name (CN) of Manager. Add this information to the root LDIF file by inserting the following line under the UID line in the file:

cn: Manager

4.3.12. Create an LDIF file for the "tdomain.com" domain

The LDIF files which you have created from /etc/passwd refers to users only. The attributes of the tdomain.com domain, and the organizational unit known as “People”, have not yet been defined. This can be done using a third LDIF file known as /etc/openldap/tdomain.com.ldif, which should look like this:

dn: dc=tdomain,dc=com dc: tdomain description: Root LDAP entry for tdomain.com objectClass: dcObject objectClass: organizationalUnit ou: rootobject dn: ou=People, dc=tdomain,dc=com ou: People description: All people in organization objectClass: organizationalUnit

4.3.13. Import the LDIF files into the database

Use the LDAP add command to import all three LDIF files into the database, starting with the tdomain.com.ldif file, followed by root.ldif, and lastly by ldapusers.ldif.

When you are prompted, enter the LDAP root password you created:

[root@Dman tmp]# ldapadd -x -D "cn=Manager,dc=tdomain,dc=com" \

      -W -f /etc/openldap/tdomain.com.ldif

[root@Dman tmp]# ldapadd -x -D "cn=Manager,dc=tdomain,dc=com" \

      -W -f /etc/openldap/root.ldif

[root@Dman tmp]# ldapadd -x -D "cn=Manager,dc=tdomain,dc=com" \

      -W -f /etc/openldap/ldapusers.ldif

[root@Dman tmp]#

4.3.14. Test the LDAP database

View all the LDAP database entries all at once with the “ldapsearch” command; this test confirms that you have all the correct functionality:

[root@Dman tmp]# ldapsearch -x -b 'dc=tdomain,dc=com' \

    '(objectclass=*)'

[root@Dman tmp]#

4.4. Configuring the LDAP Client

Now that the LDAP server has been configured properly, you can begin to configure and test the clients.

4.4.1. Edit the ldap.conf configuration file

LDAP clients are configured using the /etc/openldap/ldap.conf file. Make sure that the file refers to the LDAP server's IP address for the domain tdomain.com. The file should look like this:

HOST 192.168.2.79 BASE dc=tdomain,dc=com

4.4.2. Edit the /etc/nsswitch file

The /etc/nsswitch.conf file defines the order in which the Linux operating system searches login databases for login information.

Configure it to first search its /etc/passwd file. If it does not find the user password information here, it goes to the LDAP server. Set this up by using the /usr/bin/authconfig command:

·         Run /usr/bin/authconfig

·         Select LDAP

·         Give the LDAP server's IP address, which is 192.168.2.79 in this case

·         Give the base DN as dc=tdomain,dc=com

·         Do not select TLS

·         Use MD5 and shadow passwords

The screen should look like this:

[*] Use Shadow Passwords

[*] Use MD5 Passwords

[*] Use LDAP                   [ ] Use TLS

                       Server: 192.168.2.79

                        Base DN: dc=tdomain,dc=com

When finished, look at the /etc/nsswitch.conf file, and make sure that it has references to LDAP.

4.4.3. Create Home Directories on the LDAP Client

You previously created a user known as ldapuser in the group users on server Dman. Ensure that this user has a home directory on the LDAP client smallfry. The tdomain in this section creates the directory, and makes ldapuser the owner. The server smallfry correctly gets its user information about ldapuser from Dman; the chosen command does not complain about ldapuser not existing in smallfry's /etc/passwd file.

4.4.4. Check if ldapuser is missing from the /etc/passwd file

Look for ldapuser by searching the /etc/passwd file with the grep command. There should be no response:

[root@smallfry tmp]# grep ldapuser /etc/passwd

[root@smallfry tmp]#

4.4.5. Create the Home Directory for ldapuser on the LDAP Client

Create the home directory, copy a BASH login profile file into it, and modify the ownership of the directory, and all the files, to user ldapuser.

Note: If the chosen command fails, it is probably because of an incorrect LDAP configuration, in which the LDAP client cannot read the user information from the LDAP server.

In some cases, you might want to use NFS mounts to provide home directories for your users, which will significantly reduce the need to perform this procedure:

[root@smallfry tmp]# mkdir /home/ldapuser

[root@smallfry tmp]# chmod 700 /home/ldapuser/

[root@smallfry tmp]# chown ldapuser:users /home/ldapuser/

[root@smallfry tmp]# ll /home

total 2

drwx------    2 ldapuser users        1024 Aug  4 08:05 ldapuser

[root@smallfry tmp]#

[root@smallfry tmp]# cp /etc/skel/.* /home/ldapuser/

cp: omitting directory `/etc/skel/.'

cp: omitting directory `/etc/skel/..'

cp: omitting directory `/etc/skel/.kde'

[root@smallfry tmp]# chown ldapuser:users /home/ldapuser/.*

[root@smallfry tmp]#

4.5. Testing

Login to smallfry using the username ldapuser.