S 2.229 Planning Active Directory

Initiation responsibility: IT Security Officer, Head of IT

Implementation responsibility: Head of IT, Administrator

A basic prerequisite for the secure use of an Active Directory is appropriate advance planning. An Active Directory can be planned in several steps. In this case, a basic concept for the structure of the domain is created first, and then the details of each sub-aspect are specified. Not only do the aspects classically associated with the term "security" need to be planned, but also normal operating aspects that may lead to requirements in the area of security. Safeguard S 3.64 Introduction to Active Directory provides information on the design and the basic structure of an Active Directory.

The following aspects need to be taken into account in the framework of planning an Active Directory:

• Which Active Directory structure should be selected with respect to its distribution in domains and how should the domains be organised into trees and forests?
• Which users and computers should be compiled in which domains?

The following decisions must be made for each domain:

• Which OU objects should exist, how should they be arranged hierarchically, and which objects should each domain contain?
• Which security groups are needed and how will they be compiled in the OUs?
• Which administrative model will be implemented (central or local administration)?
• Whether or not and to whom should the administrative tasks be delegated?
• Which security settings should apply to the different types of computers and user groups?
• Which group policy settings are required and according to which concept will the group policies will be distributed (see S 2.231 Planning of group policy under Windows and S 2.326 Planning the Windows XP, Vista and Windows 7 group policies)?
• Which Windows Server trust relationships will be generated automatically and which other trust relationships (to NT domains or external Kerberos realms, for example) need to be set up?
• Which Active Directory information is allowed to be accessed using the various Active Directory interfaces (e.g. ADSI, LDAP) and by whom?
• Which Active Directory objects should be placed in the Global Catalog that can be accessed globally in a forest?
• In which mode does the domain have to be operated? If Windows NT backup domain controllers (BDCs) need to be operated in a domain, then the domain must be operated in the "mixed mode". If there are no BDCs in the domain, then it can be operated in the "native mode".

In general, the Active Directory structure planned must be documented, since this contributes significantly to stability and consistent administration, and therefore to the security of the system as well. It is especially recommended to document which changes were made to the schema. The reasons for the changes should also be documented in this case.

The following aspects should be documented for every Active Directory object:

• name and position in the Active Directory tree (e.g. "BerlinOffice", parent object: OU "Offices in Germany")
• which purpose the object serves (e.g. the group of users with RAS access to RAS Server 1)
• which administrative access rights should be assigned for the object and its attributes (e.g. administered completely by "Admin1")
• how the inheritance of Active Directory rights should be configured or if the inheritance of rights should be blocked, for example (see also S 2.230 Planning of Active Directory administration and S 3.27 Training to Active Directory administration)
• which group policy objects have an effect on this object (see S 2.231 Planning of group policy under Windows)

The planning of the Active Directory administration and of the administrative model used is an important task. A summary of planning recommendations can be found in safeguard S 2.230 Planning of Active Directory administration.

The core aspects of Active Directory planning that relate to security are summarised below:

• Domains limit the administrative powers of administrators. This means that the administrators can only perform administrative tasks in a single domain so that their administrative privileges do not extend beyond the boundary of the domain by default. This applies especially in a system with several domains (tree, forest), which means the commonly expressed reservation that it is possible for administrative authorisations to extend beyond the boundaries of a domain due to the use of the standard transitive trust model can be eliminated for normal administrator accounts (see Enterprise Admins below, though).

• Access which crosses domain boundaries requires the user accessing one domain from another domain to have explicit access authorizations in the target domain. It is therefore impossible to obtain access which crosses domain boundaries by default.
  
  This means that an administrator in domain "A" of a tree or forest will only have administrative access to some other domain "B" when the domain administrator of domain "B" explicitly grants the administrator of domain "A" authorisation to access domain "B"(see Enterprise Admins below, though).

• The members of the Enterprise Admins group have a special status because they possess administrator rights to the Active Directory throughout the entire forest. Specifically, the access rights to Active Directory objects are ignored when they are accessed by Enterprise Admins. Membership in the group of the Enterprise Admins must therefore be granted restrictively and strictly controlled. It should be noted that it is necessary to have an Enterprise Admin, for example to create sub-domains.

• Administrative delegation is achieved by granting access rights to Active Directory objects and their attributes. The access rights must be distributed according to the administrative model used. Highly complex authorisation structures can be designed using the access right mechanisms in the Active Directory (inheritance, controlling inheritance, effective range of access settings). The assignments can quickly become too complex and impossible to administer, and the resulting misconfigurations in the Active Directory can open up security gaps. The authorisation structure used should be as simple as possible for this reason.

• Schema changes are critical operations and must only be performed by authorised administrators after careful planning.

Finally, it must be pointed out that errors made in the Active Directory planning phase and in the underlying concepts can only be corrected after installation is complete with extensive time and effort. Changes to the Active Directory structure after installation, for example when organising the domains into trees and forests, can make it necessary to completely reinstall the domains under some circumstances.

Review questions:

• Has an authorisation concept for the Active Directory been designed that meets the corresponding needs?
• Are administrative delegations assigned restrictive rights which meet the corresponding needs?
• Has the Active Directory structure planned, including any schema changes, been documented in a comprehensible manner?