It's common in many organizations for colleagues to share workspaces. Keeping users updated and registered to a central server farm has quickly become a top priority for administrators. Additionally, various network services, such as Apache web server or the email server Postfix, require their own user management. Maintaining multiple user accounts on different computers can result in organizational difficulties and security risks when, for example, no longer authorized users have been forgotten on some computer accounts.

LDAP

Implementing a directory service allows a user to centrally manage all users. The Lightweight Data Access Protocol (LDAP) is an example of such a service. This directory service will provide you with data about users and devices across computers and platforms. With LDAP, you can also have telephone data and address data available through authentication.

LDAP was developed in 1993 to gain access to DAP databases, which were created in the 1980s, via TCP/IP. Back then, they used a X.500-Standard, which covered all seven layers of the OSI reference model and made it difficult to implement. Originally, the developers conceptualized LDAP for proxies to make DAP more easily accessible on various systems. Later, it received its own database back end and thus worked without the DAP database. LDAP builds its structures hierarchically, so they can be mapped out easily on a tree. Thanks to its object-oriented design, LDAP lets you easily use heredity and polymorphism in the management of data stored in tree directory entries.

The structure of the LDAP directories is similar to read accesses of data directories in that there are rooted container objects (Organizational Unit or OU) and leaf objects. The OUs can contain and structure additional objects, such as a Directory Information Tree (DIT). Most LDAP implementations do not allow further objects below a leaf object. Each object in the DIT uses a unique name (Distinct Name or DN) and certain properties/attributes. These determine the object classes and schemas.

Depending on the definition, you can assign attributes (some mandatory and others optional) as objects. A mandatory attribute for each object is called the Common Name, which LDAP recognizes and manages within the DIT. As an example, the object classification posixAccount (Listing 1) provides posixAccount (Listing 1), in which you must assign attributes cn , uid , uidNumber , gidNumber , and homeDirectory , whereas userPassword , loginShell , gecos and description are optional.

objectclass (1.3.6.1.1.1.2.0 NAME 'posixAccount'
  DESC 'Abstraction of an account with POSIX attributes'
  SUP top
  AUXILIARY
  MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory )
  MAY ( userPassword $ loginShell $ gecos $ description )
)

LDAP administers attributes separately from objects. The latter has unique object identifiers (OID) and names within the DIT. Furthermore, you will get a description (DESC), an indication of the equality (EQUALITY), and a syntax description in OID format.

Listing 2 displays an example of the attribute uidNumber , which is also used in the object classification posixAccount . All OIDs can be found on Harald Alvestrand's website [1] or in the OID repository [2]. If you need custom attributes and object classifications, because you would like to manage more with LDAP then user accounts, then please register your own OID (Private Enterprise Number) for free with IANA [3]. The Private Enterprise Number is formulated like this:

iso.org.dod.internet.private.enterprise (1.3.6.1.4.1.x).

attributetype ( 1.3.6.1.1.1.1.0 NAME 'uidNumber'
  DESC 'An integer uniquely identifying a user in an \
  administrative domain'
  EQUALITY integerMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )

If you do not have one specific OIC, problems will eventually occur when you combine multiple LDAP trees with their own object classifications. You can find a manual of how the LDAP schema is built in the from RFCs 4510 to 4519 [4].

OpenLDAP

Multiple solutions are available to manage LDAP directories, such as Novell's eDirectory, Microsoft's Active Directory, or the popular Linux version, OpenLDAP [5]. Kurt Zeilenga created the latter in 1998. Howard Chu came along shortly thereafter and together they developed release 2.0 – the code base for which was developed on a LDAP server at the University of Michigan. Today, the OpenLDAP Foundation administers the project, which is chaired by the project founder. The software is now in version 2.4.39.

Server Installation and Configuration

OpenLDAP can be found in repositories of all major distributions and can be installed with the appropriate package tool under Ubuntu using the following command:

$ sudo apt-get install slapd ldap-utils

The installer will ask for the LDAP administrator's password (Figure 1). To change data at a later date, run dpkg-reconfigure slapd . The ldap-utils package contains some command-line programs that you will need to manage the directory entry. The slapcat command provides the initial DIT (Figure 2), which, outside of the organization and the LDAP-Admin, does not contain very much.

Figure 1: With distribution package tools, such as apt-get, you can install the OpenLDAP server in a matter of minutes. The setup, on the other hand, proves to be rather tricky.

Figure 2: Slapcat shows the initial DIT, allowing the container objects and leaf objects to grow into a tree over time.

Files in Lightweight Database Interchange Format (LDIF) will help remedy this. In the LDIF files, you can create new container objects or leaf objects and assign values to them based upon object classifications and attributes. Listing 3, for example, shows an organization with departments, the OUs, as well as the management board, administration, and a user.

# structure.ldif
# Board
dn: ou=board,dc=cubed,dc=local
ou: board
objectclass: top
objectclass: organizationalunit
# Management
dn: ou=gf,dc=cubed,dc=local
ou: gf
description: Management
objectclass: top
objectclass: organizationalunit
# user Karl
dn: uid=karl,ou=board,dc=cubed,dc=local
uid: karl
cn: Karl Aschnikow
givenName: Karl
sn: Aschnikow
userPassword: {SSHA}lv6ZgRfpIVmBWjps/7B1LoPeZLdyjV7q
loginShell: /bin/bash
uidNumber: 1001
gidNumber: 100
homeDirectory: /home/karl
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: organizationalPerson
objectClass: person

An object always begins with the DN, followed by attributes and object classes. You can gain access to the password hash with slappasswd -s <privatepassword> . LDAP string objects are saved as Base64-code so that you need not worry about crackers when finding descriptions and password hashes.

$ ldapadd -x -D "DN" -W -f LDIF-Data

The contents of structure.ldif from Listing 3 will help you find your way into the LDAP directory if you use the following command:

$ ldapadd -x -D "cn=admin,dc=cubed,dc=local" -W -f structure.ldif

LDIF files, and some scripts, thus make is possible to create any number of objects automatically.

Since version 2.3, OpenLDAP has supported a dynamic configuration that most distributions automatically activate. This means you can save the complete configuration parameters in a LDAP tree and modify them using a LDIF file. Thanks to this feature, you can quickly make changes to your LDAP implementation without restarting your server. The static configuration in slapd.conf acts as an override and can be ignored.

The following command will display the entire configuration tree (Figure 3):

Figure 3: The dynamic configuration takes control of parameters in an LDAP tree without needing to restart the server.

$ ldapsearch -Y EXTERNAL -H ldapi:/// -b "cn=config"

Here a disadvantage of the dynamic configuration pops up. The configuration is obviously more difficult than editing a simple textbox. The user identification should inherently still function with all distributions.

Client Setup

To benefit from central user management, you only need to take a few steps. Linux uses both PAM and Name Service Switch (NSS) for authentication to read user data from databases. For Ubuntu, you will need to install libnss-ldapd , libpam-ldapd and, if you would like to permit users to query the LDAP directory, ldap-utils . The installation routine will retrieve all of the necessary dependencies. All you have to do is make sure this matches the information of the server.

When users log in, you can signal the NSS to retrieve queries from the LDAP server. To do this, you add lines beginning with passwd , group , and shadow in the /etc/nsswitch.conf before ldap (Figure 4). To send LDAPSearch queries and similar requests to the server, you must also adjust the TLS_CACERT and URI parameters in /etc/ldap/ldap.conf .

Figure 4: By using /etc/nsswitch.conf, you are informing the system that it should also search for user data in an LDAP directory as well.

Now, you can log in. If this does not work, you can take a look at, for example, tail -f /var/log/auth.log , which is responsible for the logging of authentication events. It may be that no home directory exists on the LDAP client for users to log into. To create these automatically, add the following line to /etc/pam.d/common-session :

session required pam_mkhomedir.so skel=/etc/skel/ umask=0027

If your users use multiple computers, and you would you like to keep all of their data synchronized, you might want to consider using a NFS server that supplies the home directory.

Secure Connections

To prevent someone from picking up passwords transmitted in the clear from users on the network, it is important to secure the connection using TLS. In doing so, you'll create keys and certificates for the server (Listing 4) and divulge them by using an LDIF file (Listing 5):

$ ldapmodify -Y EXTERNAL -H ldapi:// -f tls.ldif

# Install Gnutls
apt-get install gnutls-bin
mkdir /etc/ldap/certs ; cd /etc/ldap/certs
# ca Key
certtool --generate-privkey --outfile ca.key
# ca certificate
certtool --generate-self-signed \ --load-privkey ca.key --outfile ca.crt
# Server key
certtool --generate-privkey --outfile \ server.key
# Server certificate
certtool --generate-certificate \ --load-privkey server.key \ --load-ca-certificate ca.crt \ --load-ca-privkey ca.key \
--outfile server.crt
chown openldap:openldap *
chmod 444 *

# tls.ldif
dn: cn=config
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ldap/certs/ca.crt
-
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ldap/certs/server.crt
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ldap/certs/server.key
-
# tls erzwingen
add: add: olcSecurity
olcSecurity: tls=1
-
add: olcSecurity
olcSecurity: ssf=256

Record and specify the client's CA certificate and instruct them to use TLS. You can apply the changes in /etc/nslcd.conf commenting out the option ssl , adding start_tls , and entering the path to the CA certificate behind tls_cacertfile . Once this is complete, restart Nslcd. Before the LDAP traffic can run encrypted and smoothly, the entries URI and TLS_CACERT in /etc/ldap/ldap.conf may require some attention.

Using LDAP

Once you have done this, you can take a look at the users within the selection from the first line of Listing 6. The -ZZ parameter provides encryption, -x cancels the SASL connection to a specific user, and -LLL withholds requests for comment.

$ ldapsearch -ZZ -x -LLL "uid=karl"
$ ldapsearch -DD -x -LLL objectClass=posixAccount

With the input from the first line of Listing 7, you set a new password for a user, for example, karl from the board department. If Karl then wants to change his own password, he can do so with the command from the second line.

$ ldappasswd -ZZ -D "cn=admin,dc=cubed,dc=local" "uid=karl,ou=board,dc=cubed,dc=local" -W -S
$ ldappasswd -ZZ -D "uid=karl,ou=board,dc=cubed,dc=local" -W -S

Changes take place either interactively or by means of the aforementioned LDIF files. If you would like to change just one attribute, this can be done as in Listing 8, which adds attributes such as location, mailing address, and zip code to the user information. You should always consider using LDIF files for multiple attributes and objects, especially because you can also easily iron out mistakes later on.

ldapmodify -ZZ -D "cn=admin,dc=cubed,dc=local" -W
dn: dc=cubed,dc=local
changetype: modify
add: l
l: Potsdam
-
add: postcode
postcode: 14482
-
add: postalAddress
postalAddress: New Street 9 [Ctrl]+[d]

You can get rid of messages with ldapdelete . An example query for the user karl can be seen in Listing 9.

$ ldapdelete -ZZ -D \ "cn=admin,dc=cubed,dc=local" \
"uid=karl,ou=board,dc=cubed,dc=local" -W"

If you would like to manage OpenLDAP directories via a graphical user interface, check out the LDAP Account Manager [6], GOsa [7], or JXplorer [8].

Conclusion

OpenLDAP offers incredible potential in regard to managing central structures. The centralized directory service demonstrates its strongest points in the central user management, as there are hardly any other applications or programming languages without LDAP interface. Whether you are deploying an email server, CMS, blog, or ERP system, LDAP directories can manage the authentication nearly everywhere. Additionally, LDAP is also set up to manage devices, addresses, inventory, and much more.

Because the complex directory service is not self-explanatory, however, you may need a weekend or two to get familiar with its features. Doing so is definitely worth it if you administer networks with more than five computers.