About LDAP

First a little bit of etymology

We will first dissect this acronym, Lightweight Directory Access Protocol.

First, Lightweight: for any person who has already been exposed to the thing, we would think that leightweight would rime with simplicity. In reality, as incredible as it may seem, the LDAP norm is a simplified version of the X500 norm that nobody was able to implement. The vocabulary in the LDAP world is very flowerey and reminds the strength of the psychotropic substances available in the early 1990s on the east coast of the United States.

Then Directory: an LDAP server is not a database server like any other. Unlike an SQL server, where the structure is given by database schemas, tables, constraints and relationships between tables, the LDAP database takes a completely different approach based on a hierarchical structure. An LDAP database is a bit like file sharing. There is a root (sharing), directories and files, all in a tree format. Tree databases have become popular again recently with the NoSQL trend (e.g. MongoDB). We’ll come back to all this a little later.

And finally Access Protocol: the LDAP standard does not define an implementation, but a communication protocol. You can implement your LDAP as you wish, in C, Python, Perl or OCaml, with a storage base BDB, TDB, EDB, etc., as long as the server speaks the LDAP protocol, it will be a LDAP directory!

LDAP structure

In the introduction we pointed out that an LDAP does not have a structure similar to that of an SQL database. To avoid it becoming a mess, some basic rules had to be defined. By the way, what does it look like?

Here the root of the tree is DC=test,DC=lan. Why is it like this? Because would be the best answer. There are many possible options to name the root of a LDAP tree (for example O=tranquilit, the parameter “O” meaning organization here). However, since most of the LDAPs deployed worldwide are Active Directory, Microsoft was the obvious choice. Microsoft has chosen to use the following scheme: if your domain is test.lan, the LDAP root will be DC=test,DC=lan, if the domain is ad.tranquil.it, the root will be DC=ad,DC=tranquil,DC=it. It has become a de facto standard, there’s not much more to understand.

Each element can be named in an absolute way by giving its complete path from the root. It’s called the Distinguished Name, or more simply DN. In the example above, my account is in the “directory” ou=Nantes, my DN will then be CN=dcardon,OU=nantes,DC=mydomain,DC=lan. We find the DN name when we configure applications to authenticate on the LDAP, and quite often we will talk about Bind DN. In LDAP, one does not connect, one “binds” (it would be too simple otherwise). You were warned that the vocabulary around LDAP was full of flowers!

And what is an OU? OU stands for Organizational Unit. In the LDAP, it corresponds to a directory that will allow to sort the different stored objects. We can have OUs to sort geographically (OU=nantes, OU=paris, etc.), OUs to sort by department (OU=accounting, OU=computers, etc.), or any other type of classification that will help system and network administrators sort their things.

Why is the entry dcardon named CN=dcardon. Again, this is a Microsoft choice, it could have been UID=dcardon, but Microsoft chose the attribute CN.

CN, OU, DN, what are these things? These are attributes. As mentioned above, there is no SQL schema like in the usual databases to structure the LDAP tree. So to keep things in a decent state, each LDAP object must respect a structure defined by LDAP schemas:

  • A schema contains ObjectClass.

  • An ObjectClass contains one or more attributes. An ObjectClass can be Structural or Auxiliary, but it is not very important here, unless you want to extend your Schema (see below on this subject).

  • An attribute (CN, givenName, sAMAccountName, etc.) defines a value that can be given to a LDAP object. An attribute has a type, a search type, and possibly indexes. For example, the object CN=dcardon has the following attributes (the list is truncated).

Active Directory comes with a fairly large number of LDAP schemas. When you come from the OpenLDAP universe, you are used to integrating new schemas (for example to store DHCP, DNS, etc). In practice, ObjectClass and suitable attributes are almost always found in existing schemas and it is not necessary to extend LDAP schemas in Active Directory.

A little more vocabulary. The leftmost part of the DN CN=dcardon,OU=nantes,DC=test,dc=lan, which is here CN=dcardon is called the RDN.

The 5 root partitions in Active Directory

In this chapter, we had said that a LDAP database had only one root, in our example: DN=mydomain,DC=lan. However, in Active Directory and for the purpose of optimizing replications, there is not only one root, but five!

Each of these roots is called a partition in Active Directory dialect, or a NC in LDAP dialect.

As we can see here, the same thing can have two different names depending on the context, depending on whether we are talking about an AD domain or an LDAP.

The five partitions / Naming Context are as follows:

  • DC=mydomain,DC=lan;

  • CN=Configuration,DC=mydomain,DC=lan;

  • CN=Schema,CN=Configuration,DC=mydomain,DC=lan;

  • DC=DomainDnsZones,DC=mydomain,DC=lan;

  • DC=ForestDNSZones,DC=mydomain,DC=lan;

From an external point of view, the partitions are all located below the root DC=mydomain,DC=lan, but in the implementation, in the replication part, and when you connect with an LDAP client, you can see these five partitions individually.

The default LDAP port is 389 / tcp. Warning: an Active Directory also opens port 389 / udp for the CLDAP protocol. The protocol CLDAP is used when starting a workstation to find out which site (in the AD sense) it is located on. The CLDAP protocol shares with LDAP the name, port, format of the first connection but that’s about it. Microsoft engineers needed a port for the CLDAP, they took the 389 / udp.

To view LDAP content, it is best to use Apache Directory Studio, it is the best all purpose LDAP tool on the market. To open a connection to an AD, Apache Directory Studio will ask you for the IP or server name.

STARTTLS vs LDAPS: the STARTTLS extension allows you to negotiate a SSL / TLS connection on the same port as the unencrypted port of a standard protole. So an LDAP connection with STARTTLS occurs on the same port 389 / tcp. The LDAPS 636 / tcp port provides a secure SSL / TLS connection by default. Unlike a Microsoft AD, Samba enables STARTTLS and LDAPS by default. For this purpose, a self-signed certificate is generated when the domain is created. It is obviously recommended to replace these self-signed certificates with certificates recognized by client devices on the domain. However, it is important to note that it is not necessary to have a SSL certificate to have a functional AD network: indeed, the authentication information between the workstations and the AD is encrypted (Kerberos or NTLM) by default.

Ports used by LDAP

Port

Usage

389

TCP and UDP

636

LDAPS

3268

Global Catalog

3269

Global Catalog SSL