OpenLDAP Workshop
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.
Listing 1
initial.ldif
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.
Table 1
LDAP Keywords
Abbreviation | Full Name | Meaning |
---|---|---|
DIT | Directory information tree | Information tree on LDAP server |
CN | Common name | Attribute of an object in the LDAP tree |
DN | Distinguished name | Complete path of an object within the LDAP tree |
DC | Domain component | Component of a top-level node in the LDAP tree |
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.
Buy this article as PDF
(incl. VAT)
Buy ADMIN Magazine
Subscribe to our ADMIN Newsletters
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Most Popular
Support Our Work
ADMIN content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.
![Learn More”>
</a>
<hr>
</div>
</div>
<div class=](https://www.admin-magazine.com/var/ezflow_site/storage/images/media/images/learn-more/211417-1-eng-US/Learn-More.png)