Using OpenLDAP for Remote Authentication

LDAP (Lightweight Directory Access Protocol) provides a standard way of accessing directories that can contain hierarchical information for anything from address books to authentication data. OpenLDAP, the open source implementation of LDAP, is robust and competitive with commercial products such as Microsoft’s Active Directory. If you’d like to see some of its benefits for yourself, here’s an introduction to the software and instructions on how to implement OpenLDAP as an authorization server.

OpenLDAP is designed to work with data that does not change frequently. Its default database back end, Berkeley DB, is optimized for searches and reads, and utilizes caching. OpenLDAP supports other database back ends, such as MySQL, but they cannot compete in terms of performance with Berkeley DB.

Before you work with OpenLDAP, you need a basic understanding of its terminology. RFC 4519 describes LDAP’s object attributes in detail, and this glossary is another good reference, but here are a few concepts that will help you get started.

In the root of LDAP’s directory is the DSA-Specific Entry (DSE), a.k.a. RootDSE. This is the top-level entry, which holds the base information about the server, such as its domain and capabilities.

Every entry in the LDAP directory is uniquely identified by a Distinguished Name (DN), which is a combination of strings that uniquely identifies the entry. The server also assigns an Unambiguous Identifier (UUID) to each entry, because a DN may change – for instance, when a DN includes the family name of a female employee who marries and changes her name. In such situations, the connection to the DN would have been lost if there was no UUID. A Relative Distinguished Name (RDN) comprises an entry’s attributes followed by the DN of the parent entry.

Server Installation and Configuration

To set up an OpenLDAP server, start with a minimal installation of your operating system; we’ll use CentOS 6. Run yum install openldap-clients openldap-servers to install the required client and server software and their dependencies. You must also allow LDAP connections from outside through your firewall. To do that, edit the file /etc/sysconfig/iptables and add the line -A INPUT -p tcp -m state --state NEW -m tcp --dport 389 -j ACCEPT before the REJECT statements. This simply allows all incoming connections to TCP port 389, the LDAP port.

Most of OpenLDAP’s server configuration is specified through files in the directory /etc/openldap/slapd.d/cn=config. First, edit the file olcDatabase={1}bdb.ldif, which contains all of the database configuration entries. Change the following:

• olcSuffix: dc=openlogic,dc=com
• olcRootDN: cn=admin,dc=openlogic,dc=com
• olcRootPW: {SSHA}doXfLBll8U/bwswvkCxp4krXcyJbx5m. By default there is no olcRootPW directive; add it after olcRootDN. This is the administrative password. Even though you could specify a clear text password, it’s a bad idea from security point of view. Use the Linux command slappasswd to generate the string for a sample password, in our case “open_pass.”

Next, edit the file olcDatabase={2}monitor.ldif, which defines the access to the directory. Specify your admin user – in our example, admin@openlogic.com:

olcAccess: {0}to *  by dn.base="cn=admin,dc=openlogic,dc=com" read  by * none

In order to avoid warnings about low performance of the database, you should copy a default database config file from the official OpenLDAP documentation that contains settings for the caching and the transaction log. To do so, run the command cp /usr/share/doc/openldap-servers-2.*/DB_CONFIG.example /var/lib/ldap/DB_CONFIG.

To start the LDAP server, run the command service slapd start. To ensure it is automatically started after server reboots, add it to system’s runlevels 2 through 5 with the command chkconfig slapd on.

Working with OpenLDAP

Many people administer OpenLDAP with phpLDAPadmin, which provides an intuitive and powerful web-based interface for configuring OpenLDAP, but you should think twice about doing so if security is a top concern – and it should be, considering that OpenLDAP may hold sensitive information such as users’ login IDs. phpLDAPadmin requires a web server with server-side scripting (PHP). This by itself presents a serious security challenge. Second, phpLDAPadmin has its own vulnerabilities, such as this recent one.

Console tools for administering OpenLDAP are not as intuitive and user-friendly as phpLDAPadmin, but they are powerful and secure. In this article we’ll work with such tools only.

The openldap-clients package installs a shell command called ldapmodify that provides switches for adding, modifying, and deleting objects. This command can interpret LDAP Data Interchange Format (LDIF) files, which are simple text files that contain information about OpenLDAP objects, and which are OpenLDAP’s directory core information units. Let’s look at some examples that show how to use ldapmodify to administer OpenLDAP entries.

The first thing you should do is add the DSE object using an LDIF text file and a text editor. The text file organization.ldif contains:

dn: dc=openlogic,dc=com
changetype: add
dc: openlogic
objectClass: dcObject
objectClass: organization
organizationName: Openlogic

Note the directive changetype. It instructs the OpenLDAP server to add a new object. You can also use modify and delete for modifying and deleting objects.

Now use the ldapmodify command to apply the changes in the LDIF file from above:

ldapmodify -xD "cn=admin,dc=openlogic,dc=com" -W -f organization.ldif

This command means that simple authentication will be used with the admin DN specified by the xD parameters. The parameter W defines that the password will be given in the following password prompt. The argument f defines that the next statements will be in the specified file that follows. Even though it’s not a requirement, it’s a good practice to give .ldif extensions to LDIF files in order to distinguish them from other files.

A useful argument for ldapmodify is n. When added to the argument list it prints what would have been done if the command were executed without it. This is especially helpful when you are getting started with OpenLDAP, or LDIF syntax is new to you, or you are about to perform complex changes.

To verify that the entry has been added correctly to the LDAP directory, use the command slapcat as root. It will show all entries in LDIF format. Examine the output to see that your changes are now present.

Once you have added the DSE as the root of your directory tree you can proceed with adding other objects. First, add an organizational unit (OU) for all users called People. You can use exactly the same syntax as above but with a different LDIF file:

ldapmodify -xD "cn=admin,dc=openlogic,dc=com" -W -f people.ldif

The file people.ldif contains:

dn: ou=People, dc=openlogic,dc=com
changetype: add
ou: People
objectclass: organizationalUnit

Next, add the first member to People OU from the file user.ldif:

dn: uid=user1,ou=People,dc=openlogic,dc=com
changetype: add
uid: user1
cn: user1
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword: {SSHA}yiuMHOjmORel1put+ImEgzBdHYRFqIsd
shadowLastChange: 15318
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 500
gidNumber: 100
homeDirectory: /home/user1

The above file contains all the necessary information for a standard Unix account. Even though this account exists only in the directory service, it is regarded as local for any OpenLDAP client node. This is important because we will be using this user to authenticate to an OpenLDAP server.

It is easy to migrate local Linux users to OpenLDAP. Available migration tools generate all the necessary LDIF files.

You should now have the hang of adding objects to the directory. We now have an organization (openlogic.com), an organizational unit (People), and a member (user1).

Next, let’s see how to remove and edit entries. To delete the above user entry you need to specify only the DN. Thus you can use the following LDIF:

dn: uid=user1,ou=People,dc=openlogic,dc=com
changetype: delete

Modifying entries requires you to first specify an action for an attribute – for example, replace: mail. Follow that with the new attribute value, as in the following example:

dn: uid=user1,ou=People,dc=openlogic,dc=com
changetype: modify
replace: gidNumber
gidNumber: 500

You can also use add followed by an attribute’s name to add a new attribute to an object. The attribute’s value has to be specified on the next row, similarly to the way you replace a value. You can also delete attributes by using delete followed by the attribute’s name.

Clients’ Integration With OpenLDAP

You can integrate OpenLDAP with any application that requires directory services. This can be anything from a simple address book for mail clients to more complex solutions such as an Apache DAV/LDAP file server. One common use is for authenticating users to systems; that’s the scenario we’ll cover next.

First, install the needed software with its dependencies by running yum install openldap-clients pam_ldap nss-pam-ldapd. Among their dependencies this will install nscd, which is a caching daemon that allows users’ information to be cached locally instead of querying the remote server every time it is needed.

To configure the client, use the command-line tool authconfig-tui. When you run it, a text-mode wizard appears with the following sections:

• User Information – select Cache Information (nscd) and Use LDAP.
• Authentication – select Use Shadow Passwords, Use LDAP Authentication, and Local authorization is sufficient.
• LDAP Settings – for Server, specify the address of the OpenLDAP server: e.g., ldap://10.5.5.1/. Base DN in our case is dc=openlogic,dc=com.

That’s all you need to allow sample user user1 to be authenticated on remote systems by the OpenLDAP server.

To be perfectly candid, I oversimplified this scenario to make it easy to demonstrate OpenLDAP. You wouldn’t want to create such a simple implementation because it’s not secure enough; anyone can query your LDAP information, and data is transferred unencrypted over the network. To avoid this in real life, use secure LDAP (ldaps) and deny non-authorized querying of the database. Still, this example shows how practical and powerful OpenLDAP can be.

Share this post:

Related posts:

1. Simplify Administration with Directory Services
2. Using Apache as a File Server with DAV and LDAP
3. What’s New in CentOS 6
4. Instant Messaging in the Enterprise with Openfire
5. Supercharge WordPress, Part 1

Related Open-Source Packages