How to configure OPENLDAP and perform LDAP administration tasks

Provide: Zstack Cloud Content Introduction

If you are not familiar with the system configuration or know how to get the necessary critical information, then the management task of the OPENLDAP system is indeed a headache. In this tutorial, we'll explore how to query for key information in the OPENLDAP server and how to adjust the system in operation. Prerequisites

You should first have a set of installed and configured to complete the OPENLDAP system, the specific content see this article. In addition, you need to master the basic terminology of the LDAP directory service and refer to this tutorial for more information. OpenLDAP Online Configuration

The LDAP system uses the so-called Direcotry information treesor hierarchical structure to realize data storage management, referred to as DIT. Since version 2.3, the actual configuration of the OPENLDAP server is the responsibility of a special set of DIT, whose entries are often referred to as cn=config.

This configuration system is also referred to as OpenLDAP online configuration, or simply OLC. Unlike the original configuration method, this scenario reads the configuration file when the server is started, and the OLC-oriented modifications are immediately available and do not require the service to be restarted.

The OLC system validates and executes modifications using the standard LDAP method. Because of this, regular management of LDAP is often seamless because it uses the same knowledge, skills, and tools as the DIT data. However, for friends who have just contacted LDAP, it is often difficult to get started because they do not understand how to use the LDAP tool to complete the configuration.

In this tutorial, we will explore how to complete the OpenLDAP basic management tasks from scratch, thus helping you to master the prerequisite knowledge of further learning. Access Root DSE

First, let's talk about Root DSE, which is responsible for hosting all the DIT on the server. We use it as an underlying entry to further manage the DIT that the server can identify.

What exactly is DSE.

DSE are all called "DSA-specific entries," which belong to administrative or control entries in the LDAP server. The DSA represents the Directory system Agent, which means the directory server that is responsible for implementing the LDAP protocol.

To query root DSE, we first need to do a blank (null) search and limit the search scope to "base", which means that the system will only return entry results. Generally speaking, we can narrow down the search depth, but when we manipulate root DSE, this restriction becomes necessary (you cannot return results if you select a different range).

The specific commands are as follows: Ldapsearch-h ldap://-x-s base-b ""-lll "+"

We assume that you are based on the LDAP server itself executing the above command and that no access restrictions are set, the result should look like this:

Root DSE Output

dn:
structuralobjectclass:openldaprootdse
configcontext:cn=config
namingcontexts : dc=example,dc=com
supportedcontrol:2.16.840.1.113730.3.4.18 ...

Supportedldapversion:3
supportedsaslmechanisms:gs2-iakerb
supportedsaslmechanisms:gs2-krb5
Supportedsaslmechanisms:scram-sha-1
supportedsaslmechanisms:gssapi
supportedsaslmechanisms: DIGEST-MD5
supportedsaslmechanisms:ntlm
supportedsaslmechanisms:cram-md5
Entrydn:
Subschemasubentry:cn=subschema

Here we analyze the output results. You can first see the important metadata associated with the LDAP server.

Where-h ldap://is used to specify an unencrypted LDAP query on the localhost. -X requires that the server receive an unknown connection without any authentication information. The role of the-s Base-b "" is to specify the search scope and set the search object to null. We use-lll to remove excess output. Finally, "+" is responsible for specifying some of the default hidden run properties that we want to see (we'll find the information we need here). Locate the DIT for the target server

For the purposes of the tutorial, we only emphasize the specific DIT required by the LDAP server configuration. With the above output, you can see the Namingcontexts Run property value.

If we only need this part of the information, you can use the following command to make a more specific query: ldapsearch-h ldap://-x-s base-b "-lll" namingcontexts "

Here, we also looked at a different value to look at. Each dit on the server can be viewed through the Namingcontexts property. This is an operational attribute, usually hidden, but can be viewed explicitly by calling.

The above commands can exclude other unnecessary information, so the output is as follows:

Namingcontexts Search

dn:
namingcontexts:dc=example,dc=com

As you can see, this LDAP server has only one (unmanaged) DIT as an entry for Dc=exmaple,dc=com's proprietary name (DN). If the server is also responsible for managing other dit, then more than one value may be returned here. configuration dit found

The DIT that can be used to configure the OPENLDAP server is not returned when searching for namingcontexts. The root entry for the configuration dit is actually stored in another proprietary attribute, the Configcontext.

To understand the underlying DN of this configuration dit, you need to explicitly query this property: Ldapsearch-h ldap://-x-s base-b "-lll" Configcontext "

The returned results are as follows:

Configcontext Search

dn:
configcontext:cn=config

The DN of this configuration dit is called Cn=config. Since it may exactly match the configuration dit for everyone, we will continue to use it in the next tutorial. If you configure DIT differently, make a corresponding change. Access configuration dit

The location of the DIT now configured is clear, and the next query is to understand its current settings.

Because the DIT can be used to make changes to the LDAP system settings, it sets the access control mechanism. Only root or sudo users are allowed to access the default conditions.

The specific commands are as follows: sudo ldapsearch-h ldapi://-y external-b "Cn=config"-lll-q

Where sudo is responsible for declaring permissions, you need to replace-X in the previous Ldapsearch command with-y external to specify that we need to use the SASL authentication method. In addition, we need to change the protocol from ldap://to ldapi://to send the request based on the UNIX socket. In this way, OpenLDAP can verify the operating system users and assess whether they meet the permissions requirements. Next, use the Cn=config entry as the basis for your search.

The result returned is a long list of settings. We need to page to see: sudo ldapsearch-h ldapi://-y external-b "Cn=config"-lll-q | Less

You can see that it contains a lot of information. This command outputs a complete configuration tree. To get a clearer idea of how information is sorted and stored, the following outputs only the entries Dn:sudo ldapsearch-h ldapi://-y external-b "cn=config"-lll-q DN

The output at this point is more manageable because it displays the title (DN) rather than the full content:

Cn=config entry DNs

dn:cn=config

dn:cn=module{0},cn=config

dn:cn=schema,cn=config dn:cn={0}core

, Cn=schema,cn=config

dn:cn={1}cosine,cn=schema,cn=config

dn:cn={2}nis,cn=schema,cn=config

dn:cn={3} Inetorgperson,cn=schema,cn=config

dn:olcbackend={0}hdb,cn=config

dn:olcdatabase={-1}frontend,cn=config

dn:olcdatabase={0}config,cn=config

Dn:olcdatabase={1}hdb,cn=config

These entries represent different configuration areas in the LDAP system. Let's start by looking at exactly which areas each entry corresponds to:

A top-level entry contains some global settings that work on the system as a whole (unless it is limited to a specific context). You can view its contents using the following command: sudo ldapsearch-h ldapi://-y external-b "Cn=config"-lll-q-S base

The most common are the global authentication settings, log level settings, pointers to the process PID file locations, and SASL authentication information.

Each entry under this configuration is more specific to a particular area of the system. Let's start by looking at the items that might be required. Find Admin Entry

In the Cn=config dit, you can find all the rootdn of the DIT on the system, and RootDN basically belong to the management entries. We can also find password (usually hashed) for account logins.

To find the rootdn for each DIT, use the following command: sudo ldapsearch-h ldapi://-y external-b "cn=config" olcrootdn=* olcsuffix Pw-lll-q

The output results are as follows:

RootDN information

dn:olcdatabase={1}hdb,cn=config
olcsuffix:dc=example,dc=com
olcrootdn:cn=admin, Dc=example,dc=com
OLCROOTPW: {ssha}aoadkatwbqb0sjvbghciayf+epzqjmw+

If everyone's system has multiple dit, it can be aggregated for viewing. Here, we find that the admin entry for the dc=example,dc=com dit is cn=admin,dc=example,dc=com. We can also view the hash password. View schema Information

The LDAP schemas is responsible for defining objectclassess and attributes that apply to the system. Schemas can be added to the system at run time to implement different object types and attributes. However, there are also some specific attributes that have been placed inside the system. View the built-in schema

We can view the built-in schema under the Cn=schema,cn=config entry, with the following commands: sudo ldapsearch-h ldapi://-y external-b "cn=schema,cn=config"-s Base-l Ll-q | Less

Unlike other schemas, these built-in schemas do not need to be added to the system for additional use. View other schemas

We can also add other schemas through the traditional LDIF method, which will take effect as a child of the Cn=schema entry.

It is usually named by adding braces and numbers to the schema name, such as Cn={0}core,cn=schema,cn=config. Curly braces plus numbers represent the order in which the schema is read by the system. When added, numbers are generally automatically added by the system.

To view other schemas that are already loaded in the system, use the following command: sudo ldapsearch-h ldapi://-y external-b "cn=schema,cn=config"-S one-q DN

The output will display the names of the child entries:

Additional schemas

dn:cn={0}core,cn=schema,cn=config

dn:cn={1}cosine,cn=schema,cn=config

dn:cn={2} Nis,cn=schema,cn=config

Dn:cn={3}inetorgperson,cn=schema,cn=config

The allocation of each schema and its serial number may differ from the above results. In addition, you can further view the schema content of interest. For example, if we want to view Cn={3}inetorgperson, you can use the following command: sudo ldapsearch-h ldapi://-y external-b "cn={3}inetorgperson,cn=schema,cn= Config ' s base-lll-q | Less

If you want to output all other schemas, then: sudo ldapsearch-h ldapi://-y external-b "cn=schema,cn=config"-S One-lll-q | Less

If you want to output all schemas, including built-in schemas, sudo ldapsearch-h ldapi://-y external-b "Cn=schema,cn=config"-lll-q | Less module, backend and database setup

There are other elements to be concerned with configuring DIT, including modules and various storage technology setup mechanisms. Module

Modules are used to extend the functionality of the OPENLDAP system. These entries can be used to point to and load a module to apply its functionality. The actual configuration is implemented through other entries.

The entries that are used to load the module begin with cn=module{#}, where the numbers in the curly braces are responsible for sorting the module loads while distinguishing between different entries.

You can use the following command to implement the dynamic loading of the module: sudo ldapsearch-h ldapi://-y external-b "cn=config"-lll-q "Objectclass=olcmodulelist"

After running, you can find the modules that are already loaded in the current system:

Loaded modules

dn:cn=module{0},cn=config
objectclass:olcmodulelist
cn:module{0}
Olcmodulepath:/ Usr/lib/ldap
olcmoduleload: {0}back_hdb

This example contains only one module to help us use the HDB back-end module. back end

The backend entry is used to specify the storage technology responsible for processing the data store.

Use the following command to view the active back-end in the system: sudo ldapsearch-h ldapi://-y external-b "cn=config"-lll-q "Objectclass=olcbackendconfig"

The results of the operation are as follows:

OpenLDAP Active backends

dn:olcbackend={0}hdb,cn=config
objectclass:olcbackendconfig
olcbackend: {0} Hdb

Database

The actual configuration of these storage systems is implemented separately by each database entry. Each dit should have a database entry. Its properties will depend on the actual backend used by each database.

To view all database entries in the system: sudo ldapsearch-h ldapi://-y external-b "cn=config"-lll-q "olcdatabase=*" DN

The output is the DN of each database:

Database Entries

dn:olcdatabase={-1}frontend,cn=config

dn:olcdatabase={0}config,cn=config

dn: Olcdatabase={1}hdb,cn=config

The following explains its contents: Olcdatabase={-1}frontend,cn=config: This entry is used to define the functionality of a particular "frontend" database. This is a set of pseudo-database to define global settings that apply to all other databases, unless specifically specified. Olcdatabase={0}config,cn=config: This entry is used to define the Cn=config database settings that we are currently using. In most cases, it is mainly responsible for access control settings and replication configuration. Olcdatabase={1}hdb,cn=config: This entry defines setting a specific type of database (HDB in this example). It is generally responsible for defining access control, data storage details, caching and buffering, root entries for DIT, and management details.

The numbers in curly braces represent index values. It is typically created automatically by the system. You need to replace it with the actual assignment of the entry to implement the reference.

View the details of these entries: sudo ldapsearch-h ldapi://-y external-b "Entry_to_view"-lll-q-S base | Less

Complete the actual entry DN returned by the above command to the Entry_to_view field. Operational properties of output entries (metadata)

Here, we've been dealing with cn=config dit. Next, we will touch the other common dit.

Each entry that has an operational attribute can be implemented as a management metadata operation. We can look at the entries in any DIT to see the important information in them.

To output all of the operational attributes for a single purpose, you can specify the "+" attribute after the entry. For example, to output the operational attributes of an entry in dc=example,dc=com, we can: Ldapsearch-h ldap://-x-s base-b "dc=example,dc=com"-lll "+"

It will output all of the operational properties, as follows:

[List operational attributes]
dn:dc=example,dc=com
structuralobjectclass:organization
entryuuid:cdc658a2-8c3c-1034-8645-e30b83a2e38d
creatorsname:cn=admin,dc=example,dc=com
createtimestamp:20150511151904z
ENTRYCSN: 20150511151904.220840z#000000#000#000000
modifiersname:cn=admin,dc=example,dc=com
modifyTimestamp: 20150511151904Z
entrydn:dc=example,dc=com
subschemasubentry:cn=subschema
hassubordinates:true

With the above information, we can see who created or modified an entry at what time. using Subschema

Subschema represents the available classes and attributes. The information displayed is similar to the schema entry, but it also contains additional information. It can be used for normal, non-configured DIT, and therefore can be accessed without root permissions. Find Subschema

To find a purpose Subschema, you can query all the operational attributes under the entry, or search for specific attributes that define the entry Subschema (subschemasubentry): ldapsearch-h ldap://-x-s base-b "Dc=example,dc=com"-lll subschemasubentry

The above command outputs the Subschema entry associated with the current entry:

[List Subchema entry]
DN:DC=CHILIDONUTS,DC=TK
Subschemasubentry:cn=subschema

Each entry under the same tree structure often shares the same subschema, so it is not always necessary to repeat the search for each entry. Show Subschema

To see the contents of the Subschema entry, we need to query based on the scope base we found before. All of the important information is stored in the operational attribute, so we need to use the "+" selector again.

Command is: ldapsearch-h ldap://-x-s base-b "<^>cn=subschema"-lll "+" | Less

It can output all the content under the Subschema entry. On this basis, we can find the necessary information through filtering.

To view the LDAP syntax definition, you can filter: ldapsearch-h ldap://-x-s base-b "Cn=subschema"-lll ldapsyntaxes | Less

To see how the search mechanism matches the entry between the entries, then: ldapsearch-h ldap://-x-s base-b "Cn=subschema"-lll matchingrules | Less

To see which matching rules are available, then: ldapsearch-h ldap://-x-s base-b "Cn=subschema"-lll matchingruleuse | Less

To view the available attribute type definitions, then: ldapsearch-h ldap://-x-s base-b "Cn=subschema"-lll attributetypes | Less

To view the objectclass definition, then: ldapsearch-h ldap://-x-s base-b "Cn=subschema"-lll objectclasses | Less Summary

Although the operation of the OpenLDAP server seems difficult, the next step is relatively simple, knowing how to configure the DIT and how to find the metadata within the system. Modifying the Cn=config dit with the LDIF file can immediately affect the system in operation. In addition, the DIT configuration system enables us to set up remote management mechanisms using each LDAP tool. In this way, you can split LDAP management and server management to separate the processing.

This paper originates from Digitalocean Community. Configure OpenLDAP and perform administrative LDAP Tasks by Justin Ellingwood

Translation: DIRADW