Central Register

Authentication

First, create the LDAP RootDN password. RootDN is the top node in an LDAP directory and can basically change all the nodes below it – it's practically the root user of the LDAP system.

The password can be generated using the slappasswd command. The following command sets the password to secret and returns the SHA hash of the password at the command line:

$ sudo slappasswd -s secret
{SSHA}f0pv70XFFox5UqKc6A4Uy39NcxkqcJbc

The complete line returned will be needed later for the configuration file, so copy it to a temporary editor window.

At the present time, the slapd daemon still has a very rudimentary configuration and cannot fulfill any meaningful tasks. Nevertheless, looking at the directory information tree in its current form can be educational. Once the LDAP server is running, you can formulate a search query using the ldapsearch command and send it to the server:

$ sudo ldapsearch -b cn=config -Y EXTERNAL -H ldapi:// '(objectClass=olcDatabaseConfig)' olcDatabase

The ldapsearch command uses a socket (ldapi) to connect to the LDAP server and start a search. The first part of the server's response looks like this:

SASL/EXTERNAL authentication started
SASL username:
gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth

The authentication method is specified by the -Y EXTERNAL option. It tells the LDAP server not to authenticate against the data on the LDAP server, but to make the decision on the basis of the user ID or other criteria. A standard for this form of authentication is already pre-configured in OpenLDAP, and that standard is used here.

The user with the user ID 0 and the GroupID 0 can log on (i.e., the root user). This is why the command needs a sudo prefix. Right now, this is the only way to log on to the LDAP server.

The other lines of output provide information about the search and the type of output:

# extended LDIF
# LDAPv3
# base <cn=config> with scope subtree
# filter: (objectClass=olcDatabaseConfig)
# requesting: olcDatabase

The extended LDIF format is the default in LDAP protocol version 3. The base line indicates where the search started. In this case, the node with the common name (cn) config was searched.

The scope (i.e., the search area) provides information about the depth of the search. The subtree keyword indicates a search for everything below the base. The search filter was set to an objectClass – in this case, olcDatabaseConfig. An object class in LDAP is a data container that is filled with attributes.

Additionally, you can see the two most interesting databases in the output:

# {0}config, config
dn: olcDatabase={0}config,cn=config
olcDatabase: {0}config
# {2}bdb, config
dn: olcDatabase={2}bdb,cn=config
olcDatabase: {2}bdb

The first element is the configuration database, then comes the ({2}bdb) database, which will later take the user data. The response to the request is rounded off by some statistics on the search and the results:

# search result
search: 2
result: 0 Success
# numResponses: 5
# numEntries: 4

Basic Configuration

Now that the LDAP server is running, it's time for the actual configuration to make it really usable. The configuration in this example is divided into two parts: the configuration server and the configuration for the later LDAP data. There is a strict demarcation between the different management tasks for the LDAP server. The administrator of the Linux system can manage the configuration of the LDAP server; the administrator of the LDAP directory (the "Manager") only has rights for these data.

A demarcation of this kind is often useful in production operation, because a clear distinction is made between the different tasks. Thus, it is possible to delegate application support for the LDAP server to another department without sacrificing the integrity of the server in terms of security.

The first step is to configure the LDAP services. The configuration file is a text file in LDIF format; the ldapmodify command parses it. The structure of the file, which is shown in Listing 1, references the entry to be changed within the LDAP branch, specifies the type of change, and concludes with the new value.

01 dn: olcDatabase={0}config,cn=config
02 changetype: modify
03 replace: olcAccess
04 olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" \
  write by dn.base="cn=manager,dc=acme-services,dc=org" read by * none
05
06 # replace: olcRootDN
07 dn: olcDatabase={2}bdb,cn=config
08 changetype: modify
09 replace: olcRootPW
10 olcRootPW: {SSHA}f0pv70XFFox5UqKc6A4Uy39NcxkqcJbc
11 -
12 replace: olcAccess
13 olcAccess: {0}to attrs=userPassword by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" \
  write by dn.base="cn=manager,dc=acme-services,dc=org" \
  write by anonymous auth by self \
  write by dn="uid=syncrepl,ou=systems,dc=acme-services,dc=org" \
  read by * none
14 olcAccess: {1}to * by self write by users read by * none
15 -
16 replace: olcSuffix
17 olcSuffix: dc=acme-services,dc=org
18 -
19 replace: olcRootDN
20 olcRootDN: cn=manager,dc=acme-services,dc=org
21
22 dn: olcDatabase={1}monitor,cn=config
23 changetype: modify
24 replace: olcAccess
25 olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" read by dn.base="cn=manager,dc=acme-services,dc=org" read by * @KE:

The initial configuration file references the entry points for the changes with the DN, the distinguished name. It always corresponds to the full path of the OpenLDAP server within the DIT and must therefore be unique. An overview of the different abbreviations and their meanings can be found in Table 1.

The initial configuration performs a variety of settings. For example, it allows the application administrator (manager) to access the information tree on the OpenLDAP server, which means the configuration can be read but not modified by this user. This approach has proven useful for troubleshooting, because you do not need to jump back and forth between different rights. The second block defines the password for the manager user, which was generated earlier with slappasswd. In this configuration example, the password is secret; for production use, you would want to replace this with something more meaningful.

Access Rules

The third block contains the rules for access. They allow write access for the root user via system authorization and for the manager user. Additionally, each user is allowed to authenticate and then change their own data and view all data – except for the user password attribute.

The fourth block sets the suffix for the LDAP server. It is usually made up of the server or company domain components. Dots act as separator characters between the parts of the domain component (DC). The suffix from the example, dc=acme-services,dc=org, therefore corresponds to the acme-services.org domain. However, it has only an organizing function and must be a unique identifier. It is not necessary to use the LDAP server's real domain.

The fourth block contains the internal OpenLDAP service monitor. It can be used later to retrieve status information for the server. After all the parts of the configuration have been modified, you can parse the configuration file:

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

Again, you need to be root for this.