Centralized authentication using OpenLDAP

This guide introduces the basics of LDAP and shows you how to setup OpenLDAP for authentication purposes between a group of computers.

What is LDAP?
LDAP stands for Lightweight Directory Access Protocol. Based on X.500 it encompasses most of its primary functions, but lacks the more esoteric functions that X.500 has. Now what is this X.500 and why is there an LDAP?

X.500 is a model for Directory Services in the OSI concept. It contains namespace definitions and the protocols for querying and updating the directory. However, X.500 has been found to be overkill in many situations. Enter LDAP. Like X.500 it provides a data/namespace model for the directory and a protocol. However, LDAP is designed to run directly over the TCP/IP stack. See LDAP as a slim-down version of X.500.

I don't get it. What is a directory?
A directory is a specialized database designed for frequent queries but infrequent updates. Unlike general databases they don't contain transaction support or roll-back functionality. Directories are easily replicated to increase availability and reliability. When directories are replicated, temporary inconsistencies are allowed as long as they get synchronised eventually.

How is information structured?
All information inside a directory is structured hierarchically. Even more, if you want to enter data inside a directory, the directory must know how to store this data inside a tree. Lets take a look at a fictional company and an Internet-like tree:

Organisational structure for GenFic, a Fictional Gentoo company

Since you don't feed data to the database in this ascii-art like manner, every node of such a tree must be defined. To name such nodes, LDAP uses a naming scheme. Most LDAP distributions (including OpenLDAP) already contain quite a number of predefined (and general approved) schemes, such as the inetorgperson, a frequently used schema to define users in for form of posixAccount which Unix/Linux boxes can use.

Interested users are encouraged to read the OpenLDAP Admin Guide.

So... What can it be used for?
LDAP can be used for various things. This document focuses on centralised user management, keeping all user accounts in a single LDAP location (which doesn't mean that it's housed on a single server, LDAP supports high availability and redundancy), yet other goals can be achieved using LDAP as well.


 * Public Key Infrastructure


 * Shared Calendar


 * Shared Addressbook


 * Storage for DHCP, DNS, ...


 * System Class Configuration Directives (keeping track of several server configurations)


 * Centralised Authentication (PosixAccount)



OpenLDAP Server Configuration
The domain genfic.com is an example in this guide. You will of course want to change this. However, make sure that the top node is an official top level domain (net, com, cc, be, ...).

Let's first emerge OpenLDAP. Ensure the USE flags berkdb, crypt, gnutls, ipv6, sasl, ssl, syslog and tcpd are used.

OpenLDAP has a main user "rootdn" (Root Distinguished Name) password this is generated with the below command and needs to be replaced in the as noted later on.

Now edit the LDAP Server configuration in. The provided is from the original openLDAP source. Below is a sample configuration file one can use to replace it with to get things started.

/etc/openldap/slapd.conf

For a more detailed analysis of the configuration file, we suggest that you work through the OpenLDAP Administrator's Guide.

Verifying the configuration
After customising the file you can check it with the following command.

Vary the debug level (the "-d 1" above) for more info. If all goes well you will see config file testing succeeded. If there's an error,  will list the line number to which it applies (of the  file).

Note that OpenLDAP can store its configuration in two places. One in the original and also in. The second is the new place and designed not be edited with a text editor but generated from the using   in the following manor in. It is not required to convert the configuration and use for now support will be removed in future versions.

Running this command will transfer and translate the configuration. Once this has been run successfully the command needs to be run every time the is updated. The directory and all subdirectory contents need to be owned by the ldap service account.

For more instructions read the in-line comments of the generated files.

The below line will enable the configuration method.

/etc/conf.d/slapd

Finally, create the structure:

Start slapd:

If it does not start then increase the loglevel variable in to 4 or more, and look in  for more information.

Configuring the OpenLDAP Client tools
Edit the LDAP Client configuration file. This file is read by ldapsearch and other ldap command line tools.

You can test the running server with the following command:

If you receive an error, try adding  to increase the verbosity and solve the issue you have.

Client Configuration for Centralised Authentication
There are numerous methods/tools that can be used for remote authentication. Some distributions also have there own easy to use configuration tool. Here are some in, general order, of security and popularity. Its possible to combine local users and centrally authorised accounts at the same time. This being important because if the LDAP server cannot be access one can still login as root for example.


 * SSSD (Single Sign-on Services Daemon). Its primary function is to provide access to identity and authentication remote resource through a common framework that can provide caching and offline support to the system. It provides PAM and NSS modules, and in the future will D-BUS based interfaces for extended user information. It provides also a better database to store local users as well as extended user data.


 * Use the pam_ldap to login to the LDAP server and authenticate. Passwords are not sent over the network.


 * NSLCD (Name Service Look up Daemon). Similar thing to above, can be used, but is older.


 * NSS (Name Service Switch) using the traditional pam_unix module to fetch password hashes over the network. To permit user to update their password this has to be combined with the pam_ldap method.

The first two are demonstrated below with the minimum necessary configuration options to get working.

Client PAM configuration SSSD Method
However, here is the more direct method. The three files that are required to edit are below.

{{Code|/etc/sssd/sssd.conf| [sssd] config_file_version = 2 services = nss, pam domains = genfic debug_level = 5

[nss] filter_users = root,ldap,named,avahi,haldaemon,dbus,radiusd,news,nscd

[domain/genfic] id_provider = ldap auth_provider = ldap ldap_search_base = dc=genfic,dc=com ldap_tls_reqcert = never ldap_uri = ldap://X.X.X.X,ldap://X.X.X.X
 * 1) primary and backup ldap servers below [first server and],[second server]

Add sss to the end like below to enable the look up to handed to the sssd system service. Once you have finished editing start the sssd daemon. {{Code|/etc/nsswitch.conf| passwd:    files sss shadow:    files sss group:     files sss

netgroup:  files sss automount: files sss sudoers:   files sss

The last file is the most critical open a few extra root windows as a backup before editing this. The lines in bold have been added to enable remote authentication.

{{Code|/etc/pam.d/system-auth| auth       required      pam_env.so auth        sufficient    pam_unix.so nullok try_first_pass auth       requisite     pam_succeed_if.so uid >= 500 quiet auth       sufficient    pam_sss.so use_first_pass auth       required      pam_deny.so
 * 1) %PAM-1.0
 * 2) This file is auto-generated.
 * 3) User changes will be destroyed the next time authconfig is run.

account    required      pam_unix.so account     sufficient    pam_localuser.so account     sufficient    pam_succeed_if.so uid < 500 quiet account    [default=bad success=ok user_unknown=ignore] pam_sss.so account    required      pam_permit.so

password   requisite     pam_cracklib.so try_first_pass retry=3 password   sufficient    pam_unix.so md5 shadow nullok try_first_pass use_authtok password   sufficient    pam_sss.so use_authtok password   required      pam_deny.so

session    required      pam_mkhomedir.so skel=/etc/skel/ umask=0077 session    optional      pam_keyinit.so revoke session    required      pam_limits.so session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session    required      pam_unix.so session     optional      pam_sss.so

Client PAM configuration the pam_ldap Module Method
First, we will configure PAM to allow LDAP authorization. Install so that PAM supports LDAP authorization, and  so that your system can cope with LDAP servers for additional information (used by ).

The last file is the most critical open a few extra root windows as a backup before editing this. The lines in bold have been added to enable remote authentication.

/etc/pam.d/system-auth

Now change to read:

/etc/ldap.conf

Next, copy over the (OpenLDAP) file from the server to the client so the clients are aware of the LDAP environment:

Finally, configure your clients so that they check the LDAP for system accounts:

/etc/nsswitch.conf

If you noticed one of the lines you pasted into your was commented out (the   line): you don't need it unless you want to change a user's password as superuser. In this case you need to echo the root password to in plaintext. This is DANGEROUS and should be chmoded to 600. What you might want to do is keep that file blank and when you need to change someone's password that's both in the ldap and, put the pass in there for 10 seconds while changing the users password and remove it when done.

Migrate existing data to ldap
Configuring OpenLDAP for centralized administration and management of common Linux/Unix items isn't easy, but thanks to some tools and scripts available on the Internet, migrating a system from a single-system administrative point-of-view towards an OpenLDAP-based, centralized managed system isn't hard either.

Go to http://www.padl.com/OSS/MigrationTools.html and fetch the scripts there. You'll need the migration tools and the script.

Next, extract the tools and copy the script inside the extracted location:

The next step now is to migrate the information of your system to OpenLDAP. The script will do this for you, after you have provided it with the information regarding your LDAP structure and environment.

At the time of writing, the tools require the following input:

The tool will also ask you which accounts and settings you want to migrate.

If you need high availability
If your environment requires high availability, then you need to setup replication of changes across multiple LDAP systems. Replication within OpenLDAP is, in this guide, set up using a specific replication account which has read rights on the primary LDAP server and which pulls in changes from the primary LDAP server to the secondary.

This setup is then mirrored, allowing the secondary LDAP server to act as a primary. Thanks to OpenLDAP's internal structure, changes are not re-applied if they are already in the LDAP structure.

Setting Up Replication
To setup replication, first setup a second OpenLDAP server, similarly as above. However take care that, in the configuration file,


 * the sync replication provider is pointing to the other system


 * the serverID of each OpenLDAP system is different

Next, create the synchronisation account. We will create an LDIF file (the format used as data input for LDAP servers) and add it to each LDAP server:

OpenLDAP permissions
If we take a look at you'll see that you can specify the ACLs (permissions if you like) of what data users can read and/or write:

/etc/openldap/slapd.conf

This gives you access to everything a user should be able to change. If it's your information, then you got write access to it; if it's another user their information then you can read it; anonymous people can send a login/pass to get logged in. There are four levels, ranking them from lowest to greatest:.

The next ACL is a bit more secure as it blocks normal users to read other people their shadowed password:

/etc/openldap/slapd.conf

This example gives root and John access to read/write/search for everything in the the tree below. This also lets users change their own 's. As for the ending statement everyone else just has a search ability meaning they can fill in a search filter, but can't read the search results. Now you can have multiple acls but the rule of the thumb is it processes from bottom up, so your toplevel should be the most restrictive ones.

Maintaining the directory
You can start using the directory to authenticate users in apache/proftpd/qmail/samba. You can manage it with phpldapadmin, diradm, jxplorer, or lat, which provide easy management interfaces.

Acknowledgements
We would like to thank Matt Heler for lending us his box for the purpose of this guide. Thanks also go to the cool guys in #ldap @ irc.freenode.net

Acknowledgements
We would like to thank the following authors and editors for their contributions to this guide:


 * Benjamin Coles


 * swift


 * Brandon Hale


 * Benny Chuang


 * jokey


 * nightmorph