Directory Services and LDAP

Directory

Directory is a database (hierarchical structure) in which information about named objects on the network is stored, organized, and grouped. Examples include computers, printers, services, domains, or user accounts. A directory differs from a relational database; it is designed for frequent reading and searching and only occasional writing. In a directory, we can store data of various types, such as text, digital certificates, or images. We can restrict access to records using ACL (Access Control List).

Directory Service

Directory service (DS) is an application or group of applications that store and organize information about users and resources in a computer network. A directory service accesses a directory, sometimes referred to as a directory repository. The directory service also functions as a central authentication authority, enabling (secure) authentication of resources (users, services, computers).

Directory service provides information from the directory to administrators, users, applications, etc. The directory service creates a physical network topology and protocols to make everything transparent to users. A directory service can be part of an operating system or an application (e.g., email). Most network operating systems use directory services.

Directory services are very suitable for certain purposes that are in the style of a card index, such as managing users, phone numbers, and similar data. The authentication feature is equally widely used. On the other hand, compared to classic relational databases, they have some disadvantages, such as data control (referential integrity, etc.), complex queries, and extensive modifications.

A widespread example of a directory service is Microsoft's Active Directory (AD). AD uses LDAP (like most directory services) and complies with the LDAP v3 standard described in RFC 3377.

LDAP

LDAP stands for Lightweight Directory Access Protocol, which is an application protocol for querying and modifying directory services over TCP/IP. In the 1980s, a group of X.500 standards (DAP, DSP, DISP, DOP) was created, covering directory services. LDAP was created by simplifying the X.500 standard and focusing on TCP/IP.

LDAP uses LDAP Data Interchange Format (LDIF), which is a standardized text format for data exchange. During transmission, data is encoded using Lightweight Basic Encoding Rules (LBER), but this is not for security reasons but due to the heterogeneity of the environment, so it is very easy to decode the data.

LDAP is described using four models:

• information model - schema - describes the structure of information (attributes) in the directory
• naming model - describes how information is organized and referenced
• functional model - describes what can be done with the information
• security model - how information is protected

Information Model - Schema

Information in the directory is stored in a tree structure, which is referred to as the Directory Information Tree (DIT). The root of the directory tree is rootDSE, which contains global information about the directory and has no name or class. The information model is based on records that contain information about some object (something specific), such as a user or computer. In Active Directory, LDAP records are called objects. Objects are composed of a group of attributes, which always have a type and one or more values.

The implementation of the information model is called a schema, which is a set of objects that define the structure and content of each object that can be created in the directory service. The schema thus defines all possible object classes and attributes. Default schemas for a particular directory can be extended; an example is adding an Exchange server to AD, which extends the schema with additional attributes needed for mail services.

Object classes are categories of objects that can be created in the directory. In LDAP, the term objectClass is used, and it can be, for example, user, computer, organizationalUnit, domain, container, group. Object classes are categorized into one of three categories: Structural, Abstract, and Auxiliary.

Note: An object can be classified into multiple classes at once. For example, a user in AD is classified into the classes top, person, organizationalPerson, and user. Or a computer is in top, person, organizationalPerson, user, computer.

Because an object is often classified into several objectClasses, searching is less efficient and may not be precise (for example, when searching by objectClass=user, computers will also be found). Therefore, we can use searching by object category, i.e., the attribute objectCategory. Unlike objectClass, objectCategory has only one value (it's a classSchema object), which should refer to the most specific class in the object class hierarchy. It can be, for example, user, computer, group, organizationalUnit.

Note: Each classSchema object has a defaultObjectCategory attribute, which for most classes is the class itself. When searching, if we specify objectCategory = X, X is the ldapDisplayName of the class. LDAP automatically expands this expression to objectCategory = defaultObjectCategory of class X. The objectCategory attribute is stored in the form of a distinguished name, and LDAP automatically converts to this form.

Object attributes are characteristics (properties) of objects. An attribute can contain one or more values, for example, first name, last name, email. Certain attributes belong to a certain object class, and the schema also defines which values must be filled and which are optional. The schema also determines what types of values an attribute can have, for example, text string, integer.

Depending on where the object is located in the tree structure, it is either a leaf (leaf object, has no descendants) or a container (container object). A container can contain one or more objects.

The following table shows several common attributes used in AD.

Naming Model

Distinguished Name - DN

To identify objects, a Distinguished Name (DN) is used, which is a unique identifier of the object and contains the full path to the record (position in the tree). The DN consists of the object name and the names of individual containers and domains that contain the object, separated by commas. Individual items contain the attribute name and the assigned attribute value, for example ou=employees.

The following image shows an example of part of an AD directory for the domain company.com. In the container (organizational unit) employees, there is a user John Smith, for whom DN = cn=John Smith,ou=employees,dc=company,dc=com.

Sometimes we don't need to specify the entire path to the object, and we can then use a Relative Distinguished Name (RDN), which is relative and unique in the given container. It is the last part of the DN; for our user, it is RDN = cn=John Smith.

Other Identification Options

A common identification of an object in LDAP and also in AD is using DN, but there are other methods specifically for Active Directory.

We can use OID (Object Identifiers), which is a hierarchical, unique identifier, composed of decimal digits separated by dots. It is the same identifier as in SNMP. It is common in X.500.

In Active Directory, each object is assigned a unique 128-bit number, which is called GUID (globally unique identifier). This number is permanent and does not change when the object is moved within the forest.

Active Directory also uses a variation of DN, which is referred to as AD canonical name, and an example is the notation company.com/employees/John Smith.

Naming Attributes

Each part of DN is expressed using attribute_type=value. The attribute type used to describe RDN is referred to as a naming attribute. Each class has an assigned naming attribute, for example, User has cn. The following table shows naming attributes for LDAP and their equivalent for AD.

Functional Model

The Functional Model of LDAP defines what can be done with the information in the directory. It consists of 9 operations that are categorized into 3 functional areas.

Note: Active Directory supports several other operations that are not defined in the RFC.

Queries using LDAP

The search operation has a number of input parameters. One of them is the search base, which determines the container from which the search will be conducted. Another important parameter is the filter.

In filters, we can use mathematical operations equals (attribute=value), greater than or equal to (attribute>=value), less than or equal to (attribute