User accounts with OpenLDAP's central administration

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.