S 3.61 Introduction to directory service basics

Initiation responsibility: IT Security Officer

Implementation responsibility: IT Security Officer, Specialists Responsible

More and more organisations are using local, distributed, or even global computer networks to implement distributed applications and to exchange the information needed in the context of their business operations, specialised tasks, or procedures. In this case, the data, but also the internal and external applications, need to be protected against misuse.

It is highly important when exchanging data in such network to provide large amounts of information on the various communication partners, users, and resources in the network to the users and applications that need this information. It must be ensured when exchanging data that only authorised users and applications have access to this information, such as certificates, attributes, etc. In addition, it must guaranteed that it is impossible to manipulate or compromise the information because this is the only way to ensure that communication connections can only be established with trusted partners and that the data exchanged is sufficiently protected.

This data must be administered effectively and efficiently, especially when it is necessary to provide the same types of information to a large number of different procedures. If this data is called up frequently but seldom changed, then a directory service should be integrated into the network to organise the information in a uniform manner while simultaneously offering standardised interfaces for use.

Furthermore, directory services support single sign-ons, which are procedures that allow a user to access additional resources in the network after authentication without requiring the user to log in again.

Modern directory services can be traced back to the X.500 standard for directory services developed by the International Telecommunication Union (ITU). The X.500 standard was adopted as ISO 9594. Current directory services have adopted most of the essential internal design elements from this standard in terms of their name and data structures.

One disadvantage of the X.500 standard, though, is the complexity of the access protocol of the directory service, the Directory Access Protocol (DAP), which is also based on a complete ISO/OSI protocol stack. The Lightweight Directory Access Protocol (LDAP) was developed as a practical alternative. It simplifies access to directory services, which then also contributed to its popularity. LDAP implements a smaller range of functions and data types than DAP and is based on the TCP/IP stack.

In the meantime, LDAPv3 has become an industry standard and is defined in RFC 4511 (formerly RFC 2251) as an Internet standard. Practically all directory services today offer an LDAP interface, even in cases where other proprietary protocols and interfaces are used.

Due to the use of the protocol, computer administrators also occasionally refer to directory service servers as LDAP servers.

Directory services are organised like a hierarchical database. The objects are organised hierarchically in the form of a tree, whereby the individual nodes of the directory tree consists of container objects which can in turn contain other objects. The leaf objects (or simply leaves) represent the end points of the directory tree. The objects (entries) form the directory information tree (DIT). Every object in this case has a unique name that is referred to as the distinguished name (DN).

Example: "cn=Max Smith, l=Bonn, ou=BSI, o=Federal, c=DE"

Objects in the same level are differentiated using their relative distinguished names (RDN), e.g. "cn=Max Smith".

The objects in turn contain attributes. Values are then assigned to the attributes, for example: "mail: max.smith@bsi.bund.de".

Every entry in the directory information tree (DIT) is assigned at least one object class (objectClass), for example "objectClass inetOrgPerson". There are object classes that can be used as "containers" for additional entries, and others that are located at the ends of the branches in the DIT tree structure as leaf objects. The directory information tree in the directory service structure represents a border that limits the influence of the administrators, and therefore a border of the directory service itself.

Attributes are defined in the object classes that are available for entering the corresponding values. The attributes assigned to the object classes control which attributes will be available for the corresponding entries. There are some attributes that need to contain a value and others that can be left empty. For example, the "mail" attribute declared in the object class "inetOrgPerson" can remain empty.

There are also dependencies between object classes. In order to be able to use the commonly used object class "inetOrgPerson", it is necessary to declare the object class "organizationalPerson", which in turn needs the object class "person", which again in turn needs the object class "top". The object class "inetOrgPerson" defined in RFC 2798 is one of the most commonly used classes for representing people in their organisational environments in LDAP.

The definitions of the object classes are stored in a schema. Every schema defines object classes together with their mandatory and optional attributes. Schemas are stored in files referred to as schema files. The object class "inetOrgPerson", for example, is described together with its attributes in the file "inetorgperson.schema". The installation packages delivered with a directory service will already contain a large number of schema files. In spite of this, it may still be necessary to expand these schemas or develop your own schemas.

If the definitions of individual object classes are changed, for example by adding corresponding sets of attributes, then the changes are made by changing or extending the schema. For this reason, schema changes are some of the most sensitive operations that can be performed on a directory tree. Such changes have an impact on the entire tree, which means it is necessary to reconsider the previous design of the tree. The administration of the directory service schema therefore requires a high level of competence in the subject of directory services as well as a very high level of awareness for security.

Even though the data of a directory service is stored in a database, directories have some attributes that differentiate them from other databases, and especially from relational databases (see M 5.7 Databases):

• Directory services are organised in a hierarchical manner by storing the objects together with their attributes as entries. The objects of a directory service reflect the real objects (e.g. users or computers) of a network. The relationships between the objects are reflected in the tree structure formed by their entries.
• Directory services use a certain standardised structure that can be expanded when necessary. The structure is defined by the schema used. Every schema defines object classes together with their mandatory and optional attributes. These attributes can also be multivalent, meaning they can take on multiple values.
• Directory services provide a quick and easy way to process simply structured search and read requests. Network protocols are used to contact a directory service. Most directory services support the lightweight directory access protocol (LDAP) for this purpose, but proprietary protocols and software interfaces are also frequently used for this purpose.
• Directory services provide a highly detailed security model. Access rights can be defined for an entry, for example, and then passed on to all entries below it in the directory tree.
• Directory services are databases, but they do not support any type of distributed transactions or roll-back operations. They do not allow objects to be locked to make changes to the object or its attributes in order to provide a higher level of availability in a distributed environment. This means it is necessary to accept temporary inconsistencies between database replicas in this case.

In contrast to hierarchical databases such as those typically used for directory services, relational databases offer the following features, among others:

• The SQL query language possesses more complex types of operations, for example "Aggregation" for counting and "Join" for linking.
• The data is available in a standardised form, and there are no attributes with multiple values.
• Relational databases are suitable for combined and concurrent write operations due to the use of locking mechanisms and transactions.

Directory services are predestined for short connections and simple queries, for example to check if a resource exists, read the values of attributes, or read entire objects.

The comparison therefore points out that directory services should not be used for personnel administration even though numerous attributes of the people in the organisation will be made available by the directory service. Attributes made available by the directory service include the telephone numbers of users, their email addresses, and their departments, but also their login names, passwords, or certificates, for example. Other attributes such as their salary bracket, account number, number of days of annual holiday, or work hour agreements are data that belong in the personnel administration and should not be part of a directory service.

This means that individual pieces of data that are relevant for the directory service will need to be maintained as well as data in other relational databases of the organisation, as illustrated in the example above of the database for administration of the personnel data. This can create dependencies between the database of the directory service and other databases. It is therefore necessary when backing up data and during the contingency planning phase to determine which entries from other databases are used by the directory service.

Access rights and inheritance

Every single object and every object class of a directory service can be granted access rights to the individual attributes of the object. These rights are granted explicitly by entering the corresponding user in the access control list (ACL). The rights granted can range from those for a supervisor, i.e. full administration rights, down to those for browsing, in which case the user is only allowed to browse through the corresponding branch of the directory tree. The access rights to the objects are inherited by default in the tree hierarchy from the top to the bottom. Filters can be used to modify the process of inheritance, and such filters can also be used to explicitly prohibit automatic inheritance.

Effective rights

Finally, the effective rights of a user or user group also have an impact on access to the directory service. The effective rights are calculated dynamically in this case for every single access and are based on the rights assigned to the user or user group.

Authentication

The users access the directory service using suitable client software. The clients access the directory service using proprietary protocols. In this case, the private key of the user logging in is sent by the directory service to the client in encrypted form. The user password is included in the encryption operation. The client is then able to decrypt the private key if the user has entered the correct password. This means a challenge/response procedure is used between the client and the directory service server for authentication purposes. After successful authentication, the user possesses the access rights to the directory service that were specified for him/her.

LDAP access

Network applications and Internet users generally access the directory service using the Lightweight Directory Access Protocol (LDAP). LDAP offers various types of connections such as "anonymous bind" or "proxy user anonymous bind", for example. The default settings specify that the anonymous login has the same rights as the anonymous user. By default, this user has unrestricted read rights to the entire directory tree. Authentication is not required for the anonymous login, and this should be taken into account in any further considerations relating to security.

The password authentication procedure can be configured so that passwords are allowed or prohibited to be transmitted as plain text. Passwords should never be transmitted as plain text. The Secure Sockets Layer protocol (SSL protocol) can be used with one-factor or two-factor authentication to open a secure connection using the lightweight directory access protocol.

Certificate Server

A certificate server plays an important role when assigning rights, and therefore plays an important role in the system security. In the same manner, authentication in the network and the ability to open an encrypted channel using the Secure Sockets Layer (SSL) depend on the certificate management. For this reason, particular care must be taken when administering the certificate server.

Partitioning

To improve the scalability and performance of the directory service, it is recommended to distribute the directory database across partitions on several servers. A series of rules need to be followed when partitioning, for example the rules described in S 2.409 Planning of partitioning and replication in the directory service.

Replication

Directory services support various types of replication to increase their fault tolerance and system throughput. Aspects relating to replication are also described in safeguard S 2.409 Planning of partitioning and replication in the directory service.