S 2.403 Planning the use of directory services

Initiation responsibility: Head of IT, IT Security Officer

Implementation responsibility: Head of IT, Administrator

Errors in the design of a directory service can only be corrected with considerable time and effort once the installation has been completed. For this reason, the use of directory services must be planned carefully.

Before a directory service is introduced, it is necessary to decide for what purpose the directory service will be used. Among other things, the considerations relating to the structure of the directory service depend on the intended use. The data stored in the directory service also has a decisive influence on the type and scope of the planning required. Depending on the complexity of the directory service, the time required for the planning and conception of the directory service may be several months, and could even extend to over a year. The security policies to be defined depend on the planned operational scenario.

The following aspects are examples of the possible uses of a directory service:

• address book for telephone numbers, mail addresses, etc.
• integration into e-mail systems
• digital certificates, public key infrastructures (PKIs)
• network-wide configuration information for IT systems and applications
• uniform, centralised, location-independent user management
• authentication of people and processes to enable them to log in to IT systems in the network.

The examples provided illustrate a possible selection of the types of usage for a directory service and vary in terms of their type, size, and variant. The option of combining different applications is not only conceivable, but also one of the strengths of directory services. At the same time, combined use also increases the complexity of the directory service, which requires its use to be planned with the corresponding care.

Additional questions relating to planning arise when specifying whether or not the directory service or parts of it should be accessible from outside the intranet run by an organisation.

• How is access to the directory service from the outside protected?
• How should access to the data of the directory service be secured?
• Which authentication mechanisms are needed?
• Which data should be accessible to external anonymous users?
• Which data should be accessible after successful authentication?
• Which cryptographic methods need to be used to protect the confidentiality and integrity of the data transmitted?

Design of the tree structure

First, the requirements placed on the directory service need to be analysed and documented. In addition to specifying the use of the directory service, it is also necessary to develop a model consisting of object classes and attribute types that meets the requirements arising from the intended use.

A top element, the root element, must be selected first to design the tree structure in the directory information tree (DIT). In principle, all further objects can then be placed directly below this root. For a directory of the employees of an organisation or of the users in a network, though, it makes sense to structure the tree by department. The usual object class for modelling such organisational units is "organizationalUnit".

Afterwards, every single person and every user must be modelled as objects in the directory tree. There are already numerous schemas available that may have already been installed with the directory service or can be integrated and that provide different classes depending on the required level of detail of the information.

The simplest object class is "person", which is basically only used to store information such as the name of the person, their telephone number, and a password.

Unencrypted passwords should never be stored in the "userPassword" attribute. It is recommended to only store one hash value here. It is even better not to store passwords or their hash values in an area of the directory service that can be read by all and to store them in a special area only intended for use during authentication instead.

The "organizationalPerson" class can then be derived from these classes. It contains various addresses and telephone numbers as well as the departments to which the person belongs in order to describe how people belong to an organisation. The "inetorgPerson" class from the schema of the same name is then derived from this, and it also offers attributes for additional telephone numbers, mailing addresses and e-mail addresses, and even automobile license plate numbers. This class can be used to describe people beyond how they belong to the organisation internally, for example for the use of Internet services.

Figure: Example of a tree structure

The schemas typically delivered with directory services already contain about one thousand object classes and attributes. The elements suitable for use by the directory service are then selected based on the preceding requirements analysis. In general, the predefined classes are sufficient for this purpose. However, it could also be useful to use an existing attribute in another context and to give it a different meaning without changing its name. This option should only be used, though, when it has been ensured that confusion can be avoided and that the object cannot be used improperly.

If existing object classes and attribute types are not sufficient for the intended purpose, it is possible to extend an existing schema. It must be noted in this case that every schema object has an object ID (OID) by means of which it can be clearly identified. OID name spaces are managed by the Internet Assigned Numbers Authority (IANA) and are permanently assigned to a single owner. For this reason, changes to existing schemas belonging to someone else should be avoided in general.

It is also possible to request your own name space from www.iana.org in order to create your own schema objects. Several branches can be defined below the master OID number assigned.

If the directory service is used primarily for the administration of IT resources, then it should be properly taken into account when designing the tree structure that the structure also needs to be designed based on administrative conditions. The model of the organisational structure in the tree structure should not be too detailed, because this can lead to problems in the administration of the directory service.

A tree structure that is too flat should not be selected, so that parts of the directory tree can be separated, stored on different partitions, and then distributed among the various servers in the network. This also has the advantage that replication between the directory service servers will not have any impact on the tree. Additional aspects relating to the design of a distributed directory service are described in S 2.409 Planning of partitioning and replication in the directory service.

If directory services are used for different purposes, then the directory data should be stored in separate areas in the directory service structure according to their protection requirements, if possible. Having areas with different protection requirements makes it easier to perform data backups and to configure the access protection settings correctly. Furthermore, no data that should be hidden from the outside world should be stored on a directory service server which has a direct connection to the Internet.

The following aspects need to be taken into account in the framework of planning the directory service:

• Which purpose and which tasks should be fulfilled by the directory service and which information should it contain?
• How will the locations, organisations, organisational units, and other objects be divided up and organised?
• Which object classes are needed and which mandatory or optional attributes should they have?
• Which access rights to the information should be granted to the users by the various directory service interfaces?
• Which safeguards, for example signing LDAP packets, are planned to effectively prohibit the unauthorised collection of data from the directory service?

In general, the planned directory service structure must be fully documented. This contributes significantly to the stability, consistent administration of the system, and therefore to the security of the system. The following aspects in particular should be documented:

• Which object classes are used in which manner and, in particular, which attributes are used for which content?
• Which extensions to the schema were added and for what reasons?

The following aspects should be documented for every directory service object:

• name and position in the directory service tree, for example "SiteBonn", parent object: OU "BSI",
• which purpose the object serves, for example as a printer in the network,
• which administrative access rights should be assigned for the object and its attributes, for example administered entirely by "Admin1", and
• how the inheritance of directory service rights should be configured, for example by blocking or filtering the rights inherited.

Personal data in the directory service

In general, the organisation's Data Protection Officer should be involved when planning the use of a directory service that also contains personal data so that data protection issues relating to the right to informational self-determination are taken into account at an early stage. The employee representatives in the form of the personnel board or supervisory board also need to become involved in a timely manner.

Just like for the other data in the directory service, for the personal data it is also necessary to guarantee that the directory service entries are adequately protected in terms of their confidentiality and integrity as well in terms of their availability and currency.

Beyond the basic safeguards, it is also necessary to take the following into account when using directory services:

• Personal entries in the directory service should be limited to the specifications necessary for the particular usage or purpose. For an internal directory service, this could include e-mail addresses, telephone numbers, fax numbers, or public keys, for example. No information such as the tasks performed by the person, their working hours, or where they work should be entered in a directory service integrated into an external network unless this information is needed to perform a specific task. To avoid spam, serious consideration should be given to whether or not, and if so, in which form, e-mail addresses will be entered in directory services.
• It must be ensured in general that access to information in entries containing personal data is restricted to the minimum level necessary to perform the particular task at hand.
• If the directory service will be used as a basis for personnel information systems or will be extended accordingly, then the personnel representative must be involved.
• If a directory service or parts thereof are offered outside the Intranet of an organisation, for example to provide data to other organisations or business partners, then the general data protection regulations must be taken into account.

The planning of the directory service administration and administrative model used is an important task. A summary of recommendations in this regard can be found in safeguard S 2.407 Planning the administration of directory services.

In terms of planning the deployment of personnel, it is necessary to determine how many employees are needed for the installation and operation of the directory service and what qualifications they must possess. If there are not enough trained employees available, then the necessary training measures (see S 3.62 Training on the administration of directory services) must be initiated in due time.

Review questions:

• Was the directory service planned carefully?
• Was the exact context of every object in the directory tree specified during planning?
• Were the personnel representative and the Data Protection Officer involved in the planning of the directory service?
• Has an authorisation concept for the directory service been designed that meets the corresponding needs?
• Is documentation of the planned directory service structure available?
• Are safeguards planned to effectively prohibit anyone from collecting data from the directory service without authorisation?
• Are there rules applying to the handling of the personal data stored in the directory service?