LDAP-enabled user management for Linux

Due to their ever increasing size, management of computer networks and providing users with easy access to them has become a daunting task. Many of the problems inherent to large networks can be solved with a centralized user management. The following sections show which requirements would be posed to a centralized user management and how such a system was implemented using directory technology during the course of this thesis.

Requirements

A typical organization that runs a pool of Linux PCs would require the following services to make use of a central directory:

R1.85

Basic operating system functions for user and group look-up.

R1.86

User authentication for console logins, secure remote shells (SSH), email submission and retrieval (SMTP and IMAP), as well as for web pages access.

R1.87

A white-pages service in the form of an organization wide address book.

R1.88

An MTA to determine email routing information.

In the outlined network, the directory service is a mission critical application. It must therefore:

R2.89

be highly available,

R2.90

still allow for system maintenance of the workstations without network connectivity.^9.1

The idea of R1.2 is to provide the user with a unified login environment. His username and password will be the same for all accessed services. This requires some special precautions to be taken:

R3.91

Passwords must not be send over the network in clear text.

R3.92

A password policy, which defines password complexity and renewal requirements, should be enforced.

R3.93

To further simplify the login process, authentication should be a Single Sign-On operation.

Implementation

Schema

User and group information were made available to the operating system by means of nss_ldap (see ). [23] defines the schema items to use with this module:

The auxiliary ``posixAccount'' object class includes attributes for the user's unique identifier and number (``uid'' and ``uidNumber''), his primary group (``gidNumber'') as well as his ``homeDirectory'' and ``loginShell''.

The auxiliary ``shadowAccount'' object class adds attributes, which are used to manage account and password expiration.

This fulfilles requirements R1.1 as well as R1.2 since pam_ldap, which is used to handle password verification (see ), relies on the same schema items as nss_ldap.

[23] suggests the ``account'' object class as the structural class for a user's entry. With respect to R1.3, ``inetOrgPerson'' has been chosen as structural object class instead. ``inetOrgPerson'' [86] is a descendant of ``organizationalPerson'' and ``person''. It includes all the attributes that are required to build a state of the art white-pages service. Role accounts, which do not map to a real world person, would still created with ``account'' as structural object class.

Sendmail (see ) was used as the MTA in this thesis. By default, it makes use of the schema items specified in [53]. i.e. for an incoming email, the MTA tries to find an entry that has a matching ``mailLocalAddress'' and then forwards the mail to the value stored in ``mailRoutingAddress''. To avoid redundant storage of information in order to meet requirement R1.4, the ``mail'' attribute from ``inetOrgPerson'' was used instead of ``mailLocalAddress''. The final recipient, which would normally be retrieved from ``mailRoutingAddress'', would now be determined from the ``userId'' attribute.

Directory Service

For the directory service to be highly available (R2.1), directory servers must be run redundantly on more than one host. The data can be automatically synchronized between the different hosts by the servers' replication mechanism. Clients can make use of such redundant server pool in a number of different ways:

In Round Robin DNS, multiple IP addresses are assigned a to hostname. However, a failing LDAP server will require manual intervention since the DNS server does not check if the LDAP servers are actually accessible.

Two servers can be configured as a Cold Standby Cluster^9.2. The passive server regularly checks that the active server is still alive. If this heartbeat check fails, the passive server reconfigures itself with the IP addresses used by the active server (IP Take-over) and starts the services. As LDAP servers need to be running to allow for replication, this solution does not fit well for a directory service.

Another possible scenario would be to set up load balancing with Linux Virtual Server^9.3. A host called director would redirect incoming requests to a number of back-end servers based on a scheduling algorithm. This software would also regularly check the back-end servers' availability and configure the redirection process accordingly. To avoid a single point of failure, a back-up for the director is required. This solution offers the best performance and fault-tolerance but would require at least four hosts.

The first three options described here allow for redundancy that is implemented transparently to the clients. If one has access to all involved clients, another solution is possible. In most LDAP client libraries, the ldap_init function can take a list of hosts as argument. If one server is down, the SDK will automatically try to connect to the next one.^9.4

In this thesis, the latter option was chosen to implement redundancy.

To fulfil requirement R2.2, system accounts are kept local and are not included in the directory. Both NSS and PAM should therefore be configured to first look at the local files (e.g. /etc/passwd) and to fall back to LDAP if no match is found. For example, PAM could be set up like this by stacking the pam_pwdb and the pam_ldap module.^9.5

Authentication Considerations

To prevent passwords from being sent over the network in clear text, the connection between the client running pam_ldap and the directory server must be encrypted. In a similar vein, the replication traffic among directory server must also be protected. In both instances, SSL or TLS can be employed to guarantee privacy protection. However, all these precautions in the authentication back-end are useless if unprotected passwords are transmitted by front-end protocols, e.g. in Telnet or by using the IMAP login command without a security layer.

If password changes are only initiated by the Linux passwd command, the pam_pwcheck module can be used to enforce a password policy. Some directory servers can also check the quality of a password themselves. If password changes can originate from other sources than passwd, a product offering such a feature (see ) should be used.

Single Sign-On

LDAP is an access protocol to general-purpose directory services. While it can be conveniently used as an authentication backend, it was not designed as an authentication service and its application in this regard is sometimes seen as an abuse of the system. LDAP works well for networks, where plain text passwords need to be centrally verified (and managed), to allow unified logins. However, LDAP does not provide the necessary semantics to implement a Single Sign-On (SSO) system (requirement R3.4). In an SSO system the user logs in only once at the beginning of a session--usually by entering his username and password; for advanced security, a hardware token might be required additionally. During the initial logon process, the user obtains a set of credentials that are used in all further authentication events. These operations are handled transparently by the SSO framework so that the user can seamlessly move from one application to another.

The design presented here uses Kerberos 5 (see Section ) as authentication system to provide an SSO environment. It is based on the design which can be found in Windows 2000. In Windows 2000, Microsoft has integrated the KDC with an LDAP server. This retains the possibility to verify a plain text passwords through an LDAP bind attempt while at the same time providing an advanced SSO environment.

In fact, the system that was implemented uses a Windows 2000 Server to provide the KDC functionality. A second server has been set up, so that the service is still accessible in case the first server becomes unavailable. Due to its redefinition of standard attributes from multi-valued to single-valued, Active Directory cannot fully support the schema specified in [23]. It was therefore decided to use Active Directory for authentication purposes only, and to keep OpenLDAP as repository for application specific data.

All programs that use PAM to verify plain text passwords with an LDAP server by means of pam_ldap can easily be migrated to Kerberos. pam_krb5 is the respective PAM module that uses Kerberos as authentication back-end. This module verifies the user's password by requesting an initial Kerberos ticket. If this operation is successful, the ticket is stored in the user's credentials file for further use. To switch from LDAP to Kerberos password checking, the administrator only has to replace pam_ldap with pam_krb5 in the authentication section of the PAM configuration files. The other sections remain unchanged. To enable a user to change his password, support for the Active Directory specific password change mechanism has been added to pam_ldap (see Appendix ).

To make use of the SSO functionality, applications need to support Kerberos--either directly or via GSSAPI. On the server side, the following implementations exist:

Active Directory.

OpenLDAP, Sendmail and Cyrus IMAPD. All these programs link with the Cyrus SASL library and can therefore make use of its GSSAPI plug-in.

University of Washington IMAP server.

SSH and OpenSSH. For OpenSSH to support Kerberos, an additional patch is required^9.6.

Concurrent Version System (CVS).

Kerberos has also been added to the Telnet and FTP servers that are included in the MIT and Heimdal Kerberos distributions.

All of the Unix applications listed above support Kerberos in their command line or console applications. However, support for Kerberos in GUI applications is not very widespread. Mulberry^9.7is a notable exception. This IMAP client supports the SASL GSSAPI mechanism in IMAP and SMTP. Its LDAP client is still LDAPv2 and therefore only supports simple binds.