S 2.408 Planning the migration of directory services

Initiation responsibility: Head of IT, IT Security Officer

Implementation responsibility: Head of IT, Administrator

In most cases, organisations will not build a directory service completely from scratch. Instead, they will have individual directory services already available in their network, but these services will only support certain applications, be configured only for specialised procedures, or only provide their services in a certain subnetwork. The latter is particularly true when previously autonomous parts of an organisation are united because separate networks were combined to form one large network. Migration of a directory service can also become necessary when moving the server landscape to new hardware or a new operating system or when updating the operating system to a newer version.

In any case, careful planning is required for the migration of a directory service because security gaps can be opened up during migration.

• The integrity of the data must be protected. No undesired changes should be made to the data of the affected directory services as a result of migration. If migration is planned, then all objects in the directory services must be completely migrated.
• The confidentiality of the data must be guaranteed. It must be ensured that it is impossible to access the data without authorisation both during migration and after migration has been completed.
• Finally, it is also essential to maintain the availability of the directory services during migration to the extent necessary until the directory service can be put into normal operation after successful migration.

There are various migration procedures available for the migration of a directory service. They differ primarily in terms of their need for additional hardware:

• Updating the directory service: In this type of migration, an update of the directory service is installed on the existing computers. No additional hardware is necessary in this case. One disadvantage, though, is that the computers affected by the migration cannot be used during migration.
• Completely new installation: Migration is performed by creating a parallel directory service infrastructure. After installation and configuration, the new directory service is transferred to live operations. This has no effect on the existing system, and it can still be used during this time. However, additional hardware is needed when this procedure is used.
• Rolling migration: This procedure is especially useful when the directory service is divided hierarchically into substructures (partitions). A parallel partition is created first for the partition in question, and this parallel partition is then used once it has been created.
  
  The hardware that is now free to use can then be used to create the next parallel partition.

It is impossible, though, to provide a general recommendation to use one of the procedures to migrate a directory service, because a suitable procedure depends greatly on the corresponding prevailing conditions and must be adapted to meet the needs of the organisation.

It is also possible to perform migration in two phases. In the first phase, the existing directory service structures are copied one-to-one. In the proper sense, this only entails updating the software or operating system on the corresponding directory service servers. A disadvantage of this procedure is that numerous shortcomings will still exist and that it is still necessary to configure the directory service from a security perspective.

In a second phase, the directory service is restructured. This usually corresponds to the full reorganisation of the directory service structures. An advantage of this procedure is that old structures that are difficult to administer can be replaced by new structures. In addition, it is possible to adapt the directory service to reflect any changes made to the organisation accordingly. It must be noted in this case, though, that great time and effort are required for the planning and implementation of the new structure.

Migration concept

Due to the complexity of the migration of a directory service, it is necessary to create a corresponding migration concept in advance. The following points in particular should be taken into account in this concept:

• In the framework of migration, should the directory service be operated in a heterogeneous structure with different software versions and/or operating systems?
  
  In this case, it is necessary to specify if mixed operations are only possible for a defined transition period or if they will be allowed permanently. In mixed operations, it must be ensured that the individual components of the directory service are mutually compatible in order to guarantee availability. Furthermore, it is important for the security mechanisms used to authenticate the users of the directory service or to protect the confidentiality and integrity of the data in the directory or when queried to be adequate and to meet the requirements defined for directory services.
• Should the clients also be migrated when performing the overall migration?
  
  Depending on the scope of the directory service migration, it may be necessary to change the authentication protocol used by the clients for the directory service, for example. It may even be necessary to migrate the clients in order to be able to use the new security features offered by the directory service.

• Should changes be made to the partitions and replication parameters of the directory service?
  
  If the changes have a deep impact, then it is essential to plan the restructuring process according to need, especially if the changes are intended to improve the performance of the directory service.

Plan and document the migration

Every step of the migration must be planned in detail, the migration process aimed at must be documented, and this documentation must be made available to all parties involved. An overview of the steps to be taken in the context of the migration process is provided below:

• A realistic timetable for the migration must be created. The timetable will need to be updated in the course of planning the migration.
• The migration plan must define a strategy for the migration of the directory service server (see also the sections Updating, completely new installation and rolling migration).

• The order in which the directory service servers will be migrated must be specified. The role of the server that forms the root in the directory service hierarchy in particular must be taken into account.
• If the migration process will include simultaneous migration of the client computers, then the order in which they will be migrated must also be planned. If clients will be migrated prior to directory service servers, then it will be necessary as a general rule to reconfigure the clients after completing the migration of the directory service. Looking at it the other way round, it is also necessary to ensure the compatibility of the clients with the directory service so that its availability can still be guaranteed while ensuring that no security gaps are created in spite of the migration.

• If the administration of the users and user groups is based on the directory service to be migrated, then it must be taken into account that the migration can have an impact on access authorisations. If the authentication attributes of a user account are changed due to migration, for example when user names are changed, then it must be ensured that the access previously permitted are still allowed. On the other hand, it is also necessary to ensure that the users can still access resources using the old authentication attributes.

• During migration, it must be ensured that the trust relationships required between the various parts of the directory service are created correctly. It is necessary to plan which trust relationships should exist in which respective phase of the migration.

• Various migration tools are generally used when performing a migration. For this reason, the tools used for migration also need to be planned. The tools to be used in each step of the migration process must be specified.
• If more extensive authorisations need to be assigned for the purpose of migration in order to enable the tools used to access all information needed, then it must be noted that potential security gaps could be opened in this case.
  
  These additional authorisations therefore need to be withdrawn immediately after they have become unnecessary. Likewise, it is recommended to suitably monitor all access gained with these authorisations.
• People must be appointed to be responsible for performing the migration, and these people must be granted adequate authorisations, which are very extensive in many cases. It is therefore necessary in such cases to ensure that only trusted persons are assigned to perform these tasks. The migration concept should also specify which tasks may only be performed after applying the two-person rule.

• In any case, extensive analysis and test phases should always be planned for the migration of the directory service. An isolated test network should be planned and used to perform the actual tests.
• A full backup of the directory service data should be generated before starting the migration.
• A business continuity plan must be created that enables the directory service to be returned to its state before starting the migration so that it is possible to restore an operative system quickly in case of a failed attempt to migrate the directory service.

• It is recommended to compare the current actual state of all security settings to their target states after completing migration, and in particular the access authorisation settings for the directory service and the data stored in it.

Meta-directory service instead of migration

If it is determined while planning the migration of the directory service that migration would be too complicated or impossible to perform in the prescribed time frame, then consideration can be given to the use of a so-called meta-directory service.

A meta-directory service is used to collect the data from other existing directory services. This makes it possible to synchronise several different directory services. There are various approaches in order to implement a meta-directory service:

• The meta-directory, acting as an information broker, presents all directories connected to it as if they were a single directory. For this reason, it is also referred to as a virtual directory. The meta-directory service only offers a uniform view of the information it has collected from the various directories connected to it, and the various directories can still use their own schemas and name spaces. It must be noted that such a meta-directory depends on the continued existence of the connected directories and that it must be provided with enough communication connections to handle the expected number of requests and their corresponding replies.
• A meta-directory service that operates as a central information memory copies the selected information from the connected directory services to its own directory. Meta-objects are then created that contain the collective attributes of the underlying directory services.
  
  To enable synchronisation in this case, the objects of the meta-directory service are associated with the original directories. It must be noted that this synchronisation must be event-based or executed with a sufficiently high synchronisation rate in order to guarantee the up-to-dateness of the data in the meta-directory service.

The aspects listed here serve as a guide for similar and more extensive questions that need to be addressed in the framework of the migration concept. It must be noted that a migration plan always needs to be adapted to the specific situation and must reflect the corresponding local migration requirements.

Review questions:

• Is there a concept according to which migrations of directory service are performed?
• Were the schema changes made to the directory service documented?
• Were the wide-ranging authorisations granted to perform the migration of the directory service reset after migration was completed?