A key capability of the Active Directory® directory service in Microsoft® Windows® 2000 is a delegation of administration. Through delegation of administration, you can design a directory infrastructure that spans multiple organizations, allowing you to meet specific requirements for structural and operational independence.
In Active Directory, administrators can delegate both service management and data management. Management can be delegated to achieve autonomy between organizations, or isolation between organizations. This white paper discusses Active Directory design considerations and security implications when using forests, domains, or organizational units for delegation of administration.
A key capability of the Active Directory directory service in Microsoft® Windows® 2000 is the delegation of administration. Through delegation of administration, a directory infrastructure can be designed to span multiple organizations that have unique management requirements. In particular, the delegation of administration in Active Directory can help organizations meet specific requirements for structural and operational independence.
In Active Directory, administrators can delegate both service management and data management. Management can be delegated to achieve autonomy between organizations, or isolation between organizations. This document discusses Active Directory design considerations and related security implications when using forests, domains, or organizational units for delegation of administration.
The discussion assumes the reader knows the concepts and procedures associated with planning and deploying Active Directory. For more information about Active Directory planning and deployment, see the Best Practice Deployment document series at: http://technet.microsoft.com/en-us/library/bb727085.aspx.
To understand how to delegate administration in Active Directory, we must first understand why organizations might delegate administration and the different types of administrative responsibility that can be delegated.
Organizations typically delegate administration for three kinds of reasons:
For such reasons, an organization might need to delegate control over service management, data management, or both. Depending on the organization's specific needs, the object of such delegation might be to achieve isolation, autonomy or both. An important first step in Active Directory design is to precisely define the needs of an organization based on the concepts of service management, data management, autonomy, and isolation. These concepts are defined below.
Administrative responsibilities that are delegated in Active Directory can be separated into two kinds: responsibility for the delivery of the directory service (service management) and responsibility for content stored in or protected by the directory service (data management). Administrators with these responsibilities are service administrators or data administrators.
The delegation requirements of an organization generally fall into two categories: autonomy and isolation.
Autonomy is less constrained than isolation. Administrators who require only autonomy accept that other administrators of equal or higher privilege in the system have equivalent or overriding control. Administrators who require isolation specifically seek to block other administrators from viewing or controlling their portion of service or data management. Because autonomy is less constrained than isolation, it is generally less expensive and more efficient to delegate autonomy in Active Directory.
The combination of service management, data management, autonomy, and isolation requirements determines which Active Directory structure to use to delegate control to an organization.
Top of page
Three different structures can be used to delegate administration in Active Directory: forests, domains, and organizational units (OUs). The following section briefly describes the characteristics of each structure, and when it is appropriate to select a structure based on specific delegation requirements.
For more information about Active Directory design, see the Best Practice Deployment document series at: http://technet.microsoft.com/en-us/library/bb727085.aspx.
To understand the discussion of the delegation that follows, it is helpful to briefly review the definitions and management characteristics of Active Directory forests, domains and organizational units.
A forest is a collection of domains with a shared configuration and schema, represented by a single logical global catalog, and connected by a spanning tree of transitive trusts. A forest is represented by a forest root domain. The default administrative owner of a forest is the Domain Admins group of the forest root domain. The Domain Admins group of the forest root controls the membership of the Enterprise Admins and Schema Admins groups, which by default have control over forest-wide configuration settings. Because the forest owner controls domain controllers, the forest owner is a service administrator.
A domain is a partition in an Active Directory forest. The default administrative owner of a domain is the Domain Admins group of the domain. Because the domain owner controls domain controllers, the domain owner is a service administrator. All non-root domain owners in a forest are peers, regardless of their domain's position in the naming hierarchy; the owner of a non-root parent domain has no default administrative control over a child domain.
An organizational unit (OU) is a container within a domain. Control over an OU and the objects in an OU is determined entirely by the Access Control Lists (ACLs) on the OU and on the objects in the OU. Users and groups that have control over objects in OUs are data administrators.
The greater the number of organizations that can participate in a forest, the greater are the possible benefits from collaboration and cost savings. For this reason, it is a best practice to minimize the number of forests in an Active Directory deployment. However, there are situations in which delegation requirements make deployment of multiple forests entirely appropriate.
For example, in organizations where administrative control is highly distributed, it can be impractical to expect all organizations to participate in the same infrastructure. In these situations, the cost of managing an additional forest is traded off to satisfy this practical requirement.
The following facts about Active Directory structures and their administrators are important when choosing a directory structure for a delegation. For an application of these facts in a simple structure-picking procedure see, "Selecting a Structure Based on Delegation Requirements", later in this document.
To summarize the consequences of the facts about directory structures and directory structure owners, for an organization to join a forest or domain infrastructure, it must choose to trust all service administrators in the forest and in all domains. In this context, to trust service administrators means to:
Some organizations might accept the risk of security breaches by rogue or coerced service administrators from other parts of the organization. Such organizations might determine that the collaborative and cost-saving benefit of participating in a shared infrastructure outweighs the risk. However, other organizations might not accept this risk because the consequences of a security breach are too severe.
Figure 1 illustrates the decision process for determining if an organization's specific delegation requirements justify delegating control of a separate forest, domain, or OU to that organization. To use the process, perform the following conceptual exercise:
The decision process for delegation of administration is illustrated in Figure 1 and discussed in detail in a series of scenarios following the figure.
An organization that needs service isolation requires that no administrator outside of the organization can interfere with the operation of the directory. Service isolation is typically driven by operational or legal requirements. To provide service isolation, create a new forest for the organization.
Operational requirements that drive service isolation might include the following:
Special considerations for service isolation forests include the following:
Access can be limited using technologies such as firewalls and IPSEC. For more information about limiting access by using firewalls and IPSEC, see the Windows 2000 Server Resource Kit at http://www.microsoft.com/technet/prodtechnol/comm/comm2000/reskit/default.mspx.
A forest consists of a set of domains with a shared schema container and configuration container. These containers are controlled by the forest owner.
If an organization requires the ability to independently manipulate the schema or configuration container, it requires its own forest. This requirement is typically driven by organizational structure or operational requirements.
An organizational structure requirement that drives forest-level service autonomy might be the following:
An operational requirement that drives forest-level service autonomy might be the following:
A special consideration for creating forests for forest-level service autonomy is the following:
An organization might agree to allow forest-wide configuration to be determined by the forest owner, but might still want to have domain-level service autonomy. The following elements of the service are controlled independently at the domain level:
To delegate the ability to autonomously control these aspects of the service, a forest owner can delegate a domain to the organization. Special considerations for delegation of a domain include the following:
For more information about the geographic domain partitioning and dedicated forest root domain design best practices, see the Best Practice deployment series at http://technet.microsoft.com/en-us/library/bb727085.aspx .
Because data stored in Active Directory and on computers joined to Active Directory cannot be isolated from the service administrators of the directory, the only way for an organization to achieve complete data isolation is to create a separate forest. This situation might occur in an organization where service administrators are normally trusted, but the consequences of an attack by a rogue or coerced administrator can have a grave impact on the organization. This type of requirement for data isolation is typically driven by legal requirements.
Legal requirements that drive a need for data isolation from service owners include the following:
Special considerations for creating forests for data isolation from service owners include the following:
If users from another forest are included in any of these groups, then a breach of the other forest might lead to a breach of the isolated forest and to disclosure of protected data.
An organization can allow service ownership at the forest and domain level to be controlled by a separate, trusted organization but retain autonomous control over its data by placing it in an OU. Permissions can be placed on the data so that it is visible only to specific users. This allows an organization to isolate its data from other, non-service owner organizations that control OUs in the same domain or the same forest.
An organizational structure requirement that justifies using OUs for delegation is the following:
An operational requirement that justifies using OUs for delegation is the following:
A special consideration for delegating OUs is following:
Because service administrators must be highly trusted, it is important to understand which administrative groups in Active Directory are service administrators, and what best practices these groups must follow.
Service administrators in Active Directory include:
For the Windows 2000 version of Active Directory, these groups include:
To reduce the chance of attack by service administrators or through physical access to domain controllers, the following best practices are recommended:
Active Directory provides an infrastructure that enables collaboration between people and organizations. When designing for delegation of administration, planners must precisely define their delegation needs, understand the security implications of the delegation, and be aware of the tradeoffs between collaboration, autonomy and isolation in a directory infrastructure.
To enable the maximum collaboration with the least management cost, an organization can deploy a single forest design with a single IT organization owning all forest and domain service management, and delegate data autonomy or isolation to other organizations by using OUs. Each participating organization must trust the service owner before joining the forest.
SSome organizations have specific autonomy or isolation requirements that make trusting a central service owner impractical or unwise. These organizations can deploy multiple forest designs, and enable inter-forest collaboration through additional management systems such as Microsoft Metadirectory Services (MMS).
For more information about MMS, see http://www.microsoft.com/windows2000/technologies/directory/MMS/default.asp.
The design procedures in this document assume that any organization that participates in a forest trusts all service administrators in the forest (both the forest owner and domain owners), and is satisfied with the physical security of domain controllers. The following discussion describes why this is necessarily the case.
Active Directory includes security features that are defined by the following two core system components:
If an attacker modifies the system software or directory database of a domain controller, it is possible for the attacker to disable security features in Active Directory, or modify them to behave in a way that is otherwise advantageous to the attacker. The following people have the capacity to launch such attacks:
These attacks can be accomplished by:
It is important to note that SYSKEY does not encrypt the entire database. An attacker who can obtain a physical copy of the database can still read or modify unencrypted data in the database without ACLs being enforced. For more information on the SYSKEY feature, see the Windows 2000 Server Resource Kit at http://www.microsoft.com/technet/prodtechnol/comm/comm2000/reskit/default.mspx.
Attacks that modify system software are not limited to changing the behavior of security features. For example, the system normally enforces a requirement that schema updates only be written on the domain controller holding the schema master role. By using a malicious system software modification, it is possible for an attacker to defeat the schema master role check and update the schema on the modified domain controller.
Although system software attacks and physical modifications to the directory database appear difficult, only one highly sophisticated attacker needs to build tools for the attack. Once the tools are created, they can be distributed to any administrator.
In a distributed system, the breach of a single computer can impact many computers or even the entire system. An Active Directory forest is a tightly coupled distributed system. An attacker who can modify system software on a domain controller or gain physical access to a domain controller can exploit the tight coupling of the system in order to extend the attack to other computers in the forest. In particular, the attack might exploit the following characteristics of Active Directory:
When a user logs on, the KDC software on a domain controller builds the authorization data that describes the user's identity. This authorization data contains the Security Identifiers (SIDs) for the user and for the groups of which the user is a member. When a user accesses a resource in another domain, the user's KDC sends authorization data to the KDC in that domain as a representation of the user's identity.
In order for features such as SID History and universal groups to operate, KDCs in each domain must accept the validity of user authorization data that includes SIDs from outside the user's home domain.
An attacker can exploit this feature by modifying KDC software or the directory database to insert SIDs into a user's authorization data. In this way, an attacker can authenticate to a modified domain controller and use the inserted SIDs to masquerade as any user in the forest, or to become a member of any group in the forest (including administrative groups). This attack is known as an authorization data spoofing or SID spoofing attack.
When domain controllers replicate changes to the shared schema and configuration partitions, they consider all copies of the partition on all domain controllers to be equally trustworthy. A domain controller accepts replicated updates to these partitions from any domain controller in the forest. In addition, Active Directory-enabled software on client computers assumes that schema and configuration partitions on all domain controllers are equally trustworthy, and accepts query responses for this information from any domain controller in the forest.
When domain controllers configured as global catalog servers replicate changes to partial domain partitions, they can select as a replication partner either a domain controller with a full copy of the partition or another global catalog server from any domain in the forest. Also, Active Directory-enabled client software treats all global catalog servers in a forest as equally trustworthy, and accepts query responses from any global catalog server in the forest.
These assumptions allow domain controllers to optimize the flow of replication between domain controllers based on a forest's site topology. This avoids replicating the same data more than once over a slow network link. These assumptions also allow clients to query a global catalog server or the configuration or schema containers of a domain controller in the same site as the client, regardless of the domain membership of the server. This avoids limiting clients to global catalog servers and domain controllers from the same domain as the client, which may not be located in the same site as the client.
Vulnerability is introduced because, either through system software modification or physical access to the directory database, an attacker can modify security-sensitive data stored in the schema partition, configuration partition, or any partial domain partition on a breached domain controller and cause either or both of the following:
Security-sensitive software stored in these partitions includes the following:
By exploiting these features in the ways described, an attacker can extend the impact of a single domain controller attack to include one or more of the following:
For the reasons discussed here, organizations that participate in a forest cannot be isolated from any service administrator in the forest, and must trust all personnel that have physical access to domain controllers. As a result, these organizations must take steps to mitigate or limit the vulnerabilities that result from the requirement to trust service administrators and the potential for unauthorized access to domain controllers.
This article is available in other languages, including Italian.