Active Directory: Design Considerations for Delegation of Administration

Note

This article is based on an article in the Microsoft TechNet Library and is presented here to enable those outsides of Microsoft who are interested and knowledgeable on this topic to improve it. To read the official Microsoft topic on this subject, see Design Considerations for Delegation of Administration in Active Directory on the Microsoft TechNet Library.

 

Design Considerations for Delegation of Administration in Active Directory

Achieving Autonomy and Isolation with Forests, Domains, and Organizational Units

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.

Introduction

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.

Top of page

Delegation Concepts

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.

Reasons to Delegate Administration

Organizations typically delegate administration for three kinds of reasons:

• Organizational structure — Parts of an organization might participate in a shared infrastructure to save costs, but require the ability to operate independently from the rest of the organization.
• Operational requirements — One part of an organization or an application that leverages Active Directory might place unique constraints on directory service configuration, availability, or security. Examples are found in:
  • Military organizations
  • Hosting scenarios
  • Extranet or outward-facing directory scenarios
• Legal requirements — Some organizations have legal requirements that compel them to operate in a specific manner, such as restricting access to certain information. These requirements commonly apply to the following kinds of organizations:
  • Financial institutions
  • Defense contractors
  • Government organizations

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.

Service Management and Data Management

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.

• Service administrators — Active Directory service administrators are responsible for the configuration and delivery of the directory service. For example, service administrators maintain domain controller servers, control directory-wide configuration settings, and are responsible for ensuring service availability.
• Data administrators — Active Directory data administrators are responsible for managing data stored in Active Directory or on computers joined to Active Directory, and have no control over the configuration or delivery of the directory service. Data administrators include:
  • Administrators who control a subset of objects in the directory. Through inheritable, attribute-level access control, data administrators can be granted control of very specific sections of the directory, but have no control over the configuration of the service itself.
  • Administrators who manage member computers that are joined to the directory and data that is stored on those computers.
  • In many cases, the service configuration of the directory is determined by attribute values on objects stored in the directory. Consequently, service administrators in Active Directory are also data administrators.

Autonomy and Isolation

The delegation requirements of an organization generally fall into two categories: autonomy and isolation.

• Autonomy — Autonomy is the ability of the administrators of an organization to independently manage:
  • All or part of service management (service autonomy).
  • All or part of the data stored in the directory or on member computers joined to the directory (data autonomy).
• Isolation — Isolation is the ability of the administrators of an organization to prevent other administrators from:
  • Controlling or interfering with service management (service isolation).
  • Controlling or viewing a subset of data in the directory or on member computers joined to the directory (data 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.

Note

In many small to medium-sized organizations, it is not unusual for all service and data management in Active Directory to be under the control of a single IT group. Such organizations that have no specific autonomy or isolation requirements can use the single forest, single domain Active Directory designs and treats the procedures in this document as references only.

Top of page

Delegating Administration with Forests, Domains, and Organizational Units

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.

Forests, Domains and Organizational Units

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.

Facts about Directory Structures and Directory Structure Owners

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.

1. Domain owners cannot prevent forest owners from controlling their services and accessing their data. Although it is possible to remove access to a domain for Enterprise Admins, it is generally not possible to prevent the forest owner from gaining access to objects in non-root domains. For example, members of the Schema Admins group (which is controlled by the Domain Admins group of the forest root domain) can modify the default security descriptor on an object class to grant the Enterprise Admins group full control over newly created objects of that class. Consequently, organizations that participate in a forest must trust the forest owner.
2. Domain owners always maintain the right to access data stored in a domain or hosted on computers joined to a domain. The service administrators of a domain cannot be prevented from viewing or manipulating the data stored in a domain or on computers joined to a domain. This is a consequence of the following characteristics of Active Directory:
   • The Builtin\Administrators group on a domain controller can take ownership of any object in the domain and then read, modify or delete it, regardless of the previous ACL on the object. This feature gives service administrators a way to correct errors in ACLs on objects. Therefore, organizations that store data in OUs of a domain must trust the domain owner.
   • A service administrator can maliciously modify the system software on a domain controller to bypass normal security checks. A service administrator can use this procedure to view or manipulate any object in the domain, regardless of the ACL on the object. Consequently, organizations that store data in OUs of a domain must trust the domain owner.
   • A service administrator can use the Restricted Groups security policy to grant any user or group administrative access to any computer joined to the domain. This feature ensures that an administrator can always gain control over a computer joined to the domain, regardless of the intentions of the computer owner. Therefore, organizations that join computers to a domain must trust the domain owner.
   • If a user or group in a domain is granted access to data stored on a computer joined to the forest, the domain owner of the user's or group's domain might reset the user's password or manipulate the group's membership and by so doing gain access to the data. Consequently, organizations that join computers to a forest must trust every domain owner in the forest.
3. Domain owners cannot prevent other malicious domain owners from controlling their services and accessing their data. Due to the tightly coupled nature of an Active Directory forest, it is possible for domain owners to use malicious methods to gain access to other domains in the forest. For example, it is possible for a malicious domain owner to modify the system software on a domain controller, and by so doing interfere with the operation of any domain in the forest, view or manipulate forest configuration data, view or manipulate data stored in any domain, or view or manipulate data stored on any computer joined to the forest. Therefore, the forest owner must trust all domain owners in a forest and all domain owners in a forest must trust each other.
4. Domain Controllers within a forest cannot be isolated from one another. Due to the distributed nature of Active Directory, the breach of a single domain controller can have effects throughout a forest. For example, it is possible for an attacker who has physical access to a single domain controller to make offline changes to the directory database, and by so doing interfere with the operation of any domain in the forest, view or manipulate data stored anywhere in the forest or view or manipulate data stored on any computer joined to the forest. Consequently, physical access to domain controllers must be restricted to trusted personnel.

Trusting Service Administrators

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:

• Reasonably believe that service administrators look out for the organization's best interest. Organizations should not elect to join a forest or domain if the owners of the forest or domain might have legitimate reasons to act maliciously against the organization.
• Reasonably believe that service administrators follow best practices for service administrators and restriction of physical access to domain controllers. For more information about these practices, see "Best Practices for Service Administrators and Restricting Physical Access to Domain Controllers" later in this document.
• Understand and accept the risks to the organization associated with rogue administrators and coerced administrators.
  • Rogue administrators — It is always possible for normally trusted administrators to become rogue administrators, and abuse the power they have in the system.
  • Coerced administrators — Normally trusted administrators might be coerced or compelled to perform operations that breach the security of the system.

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.

Note

Previously published Active Directory documentation states that a domain is a security boundary, but does not provide specific details about the level of autonomy and isolation possible between domains in a forest. Although a domain is infact a security boundary when considering the management aspects of Active Directory, it does not provide complete isolation in the face of possible attacks by service administrators who maliciously modify the behavior of the system. For more information, see the Appendix to this document.

Selecting a Structure Based on Delegation Requirements

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:

1. Begin by placing all organizations in a single-domain forest.
2. For each organization with unique administrative requirements, use the decision process to determine the appropriate course of action.
3. When recording the justification for each decision, be sure to note:
   • Whether the delegation requirement is driven by one or more organizational, operational, legal, or other requirements.
   • Whether the requirement is for delegation of service management, data management, or both.
   • Whether the requirement is for autonomy, isolation, or both.

The decision process for delegation of administration is illustrated in Figure 1 and discussed in detail in a series of scenarios following the figure.

https://technet.microsoft.com/en-us/bb727032.addldm01_big(en-us,technet.10).gif

Figure 1: Process for Determining Delegation Requirements for Your Organization

Scenario 1: Creating Forests for Service Isolation

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:

• A manufacturing company might have a mission-critical Active Directory-enabled application that controls equipment on the factory floor. If this company considers the operation of factory equipment to be its highest priority, it might choose to create a single company-wide forest for normal administrative functions and a separate forest for each critical factory. This allows critical factories to continue operation regardless of the state of the company-wide forest and the state of other factories.
• A navy might require that the capture of a single ship not have the potential to compromise service delivery for an entire battle group or the entire navy. To contain the impact of the capture of a single ship to the ship itself, the navy might create a separate forest for each ship.
• A hosting company might want to place domain controllers on a client customer's premises. Because the breach of a single domain controller can affect service delivery in the rest of a forest, it might create a separate forest for each client that requires domain controllers on the premises. Otherwise, one malicious client with physical access to a domain controller on their premises might be able to interfere with the operation of the directory for other clients in the same forest.

Special considerations for service isolation forests include the following:

• Forests created for service isolation can trust domains from other forests, but must not include users from other forests in administrative groups. If users from other forests are included in administrative groups of the isolated forest, then a breach of the other forest might lead to a breach of the isolated forest.

• Although creating a separate forest can provide service isolation, it is important to note that as long as domain controllers are accessible on a network, they are subject to attacks (such as denial of service attacks) from computers on that network. Organizations that decide that the risk of attack is too high, or that the consequence of an attack or breach is too great, can do the following:

  • Carefully consider the trustworthiness of the networks that host domain controllers.
  • Limit access to the network(s) hosting the domain controllers.

  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.

Scenario 2: Creating Forests for Forest-Level Service Autonomy

A forest consists of a set of domains with a shared schema container and configuration container. These containers are controlled by the forest owner.

• Schema: The schema of the forest determines what classes of objects can be created in the directory and what attributes are associated with those objects. Applications that leverage Active Directory can extend the schema to include application-specific data.
• Configuration: Data stored in the configuration container includes:
  • Data that defines the forest's site topology and replication topology.
  • Various forest-wide policy settings, such as site-based policy and forest-wide LDAP policy (for domain controllers).
  • Information that identifies the set of domains in the forest and the trust hierarchy. Each domain in the forest trusts all other domains in the forest. Through control of this configuration data, the forest owner controls the creation of new domains in the forest.
  • Active Directory-enabled applications may store forest-wide configuration data in the configuration container. An example of such an application is the Microsoft® Exchange 2000 Server.

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:

• A division of a company might want to install directory-enabled applications that extend the schema, without consulting other divisions of the company. Creating a separate forest trades the additional cost of managing a separate forest for autonomy at the forest level.

An operational requirement that drives forest-level service autonomy might be the following:

• A hosting company might want its clients to be able to install custom-built directory-enabled applications that extend the schema, but are not certified under the Windows Logo program for software to meet schema best practices. Because other clients are unlikely to accept non-certified applications, this client needs autonomous control over the schema. To do this, the hosting company must assign them a separate forest.

A special consideration for creating forests for forest-level service autonomy is the following:

• Organizations that justify the creation of a separate forest using organizational structure requirements must be aware that multiple-forest deployments involve balancing costs and benefits. Although an organization might prefer autonomous service operations, it might be more cost-effective to concede responsibility for service delivery to a central, trusted IT group. In this way, the organization's IT group can participate in data management in the forest, but eliminate the cost of obtaining specialized directory service management expertise. For more information about balancing costs and benefits in this scenario, see the Best Practice Active Directory Deployment series at http://technet.microsoft.com/en-us/library/bb727085.aspx.

Scenario 3: Delegating Domains for Domain-Level Service Autonomy

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:

• Service availability — The domain owner has the ability to create, remove, backup, and restore domain controllers in order to meet a desired level of service availability.
• External trust — The domain owner can determine which domains in other forests to trust.
• Domain user account policy — Certain policies governing domain user accounts can only be controlled at the domain level. Those policies are:
  • Password policy
  • Account lockout policy
  • Kerberos ticket lifetime policy

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:

• As a consequence of the facts about Active Directory discussed in earlier in this document (see "Facts about Directory Structures and Directory Structure Owners"), a forest owner must only delegate a domain to an organization if the forest owner and all domain owners trust the domain owner in the delegated organization. Based on this requirement, it is a best practice to centralize forest and domain service ownership in a single organization that is responsible for the forest, and use domains only for geographic partitioning of replication. Because all service administrators are trusted, delegation can be safely done entirely at the OU level.
• Domains provide domain-level service autonomy, but do not provide data isolation from the forest owner or other domain owners. Create separate forests if an organization requires data isolation from service owners. For more information, see "Scenario 4: Creating Forests for Data Isolation from Service Owners", later in this document.
• In a large organization, it is possible for the IT organization that owns the forest to be different from the IT organization that manages all other directory operations. In this situation, it is a best practice to create a dedicated forest root domain. The forest root domain owner controls the dedicated forest root domain, and the operational IT organization is granted ownership of one or more child domains. This allows the operational IT organization to autonomously manage service availability, but not control the membership of the Enterprise Admins and Schema Admins groups in the forest root domain. Note that a dedicated forest root only provides protection against accidental or unintended misuse of privilege; owners of non-root domains can still use malicious methods to attempt to manipulate groups in the root domain.

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 .

Scenario 4: Creating Forests for Data Isolation from Service Owners/strong>

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:

• A financial institution might be required by law to limit access to data belonging to clients in a particular jurisdiction to users, computers, and administrators located in that jurisdiction. Although the institution might normally trust service administrators that work outside the protected jurisdiction, breaching the access limitation might cause the institution to lose its ability to do business in that jurisdiction.
• A defense contractor might be required by law to limit access to defense project data to a specified set of users. Although the contractor might normally trust service administrators who control computer systems related to other projects, the consequence of a breach by these service administrators might be loss of the ability to do business with the government.

Special considerations for creating forests for data isolation from service owners include the following:

• Forests created for data isolation can trust domains from other forests, but users from other forests should not be included in any of the following groups:

  • Groups responsible for service management, or groups that can manage the membership of service administrator groups
  • Groups with administrative control over computers that store protected data
  • Groups that have access to protected data, or groups responsible for the management of user or group objects that have access to protected data

  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.

• Although creating a separate forest allows data isolation, it is important to note that as long as the domain controllers of the isolated forest and computers that host protected information are accessible on a network, they are subject to attacks launched from computers on that network. Organizations that decide that the risk of attack is too high, or that the consequence of an attack or breach is too great, should do the following:

  • Carefully consider the trustworthiness of networks that host either domain controllers or computers containing protected data
  • Limit access to the network(s) hosting the domain controllers and computers hosting protected data by using technologies such as firewalls and IPSEC

Scenario 5: Delegating OUs for Data Autonomy and Isolation from Non-Service Owners

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:

• A business unit in a company might require the ability to independently create, modify, and delete user accounts for its employees. If the business unit has no requirement to isolate these user accounts from service owners, then it is safe for this business unit to accept a delegated OU.

An operational requirement that justifies using OUs for delegation is the following:

• A hosting company that maintains all service ownership in a forest and limits physical access to hosting company personnel can delegate OUs to clients. These clients can manage their directory data autonomously, and might also choose to have their data hidden from other clients that share the same infrastructure.

A special consideration for delegating OUs is following:

• A delegated OU is appropriate only if the organization is satisfied that all service owners in the forest are trustworthy, and all domain controllers in the forest are physically secure.

Top of page

Best Practices for Service Administrators and Restricting Physical Access to Domain Controllers

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:

• Any group that can legitimately change directory configuration settings
• Any group that can install domain controllers
• Any group that can install or modify software on domain controllers
• Any group that can modify the membership of another service administrator group

For the Windows 2000 version of Active Directory, these groups include:

• Groups controlled by a forest owner
  • Domain Admins (forest root domain)
  • Enterprise Admins
  • Schema Admins
• Groups controlled by a domain owner
  • Domain Admins
  • Builtin\Administrators
  • Builtin\Server Operators
  • Builtin\Backup Operators

To reduce the chance of attack by service administrators or through physical access to domain controllers, the following best practices are recommended:

• Minimize the number of members in service administrator groups
• Allow only other service administrator groups to modify the membership of service administrator groups
• Do not include users or groups from external trusted forests into service administrator groups in your forest unless the service administrators from the external forest are as trusted as your forest's service administrators
• Audit changes to service administrator group memberships
• Log on using service administrator credentials only when absolutely necessary; provide alternate user accounts to administrators for day-to-day work
• Allow only service administrator groups to manage workstations used by service administrators
• Restrict physical access to domain controllers to service administrators; do not place domain controllers in locations that cannot be secured
• Restrict physical access to domain controller system state backups to service administrators; do not store system state backups in locations that cannot be secured
• Minimize the software that runs on domain controllers
• Prepare and practice a forest-wide business recovery plan
• Educate service administrators on the importance of observing the best practices

Top of page

Conclusion

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.

Top of page/a>

Appendix – Background for Service Administrator Trust Requirements and Domain Controller Physical Access Requirements

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.

Security Implications of Service Administrator Access and Physical Access

Active Directory includes security features that are defined by the following two core system components:

• The system software that makes up an Active Directory domain controller — This software handles authentication processes, builds and transmits the data structures that define a user's identity (also called authorization data), enforces policies, and restricts access to objects in the directory based on per-object, per-attribute permissions.
• The directory database stored on domain controllers — The Active Directory database stores information such as user passwords, group memberships, and Access Control Lists that govern access to objects.

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:

• Service administrators — Service administrators need the ability to modify system software on domain controllers. For example, service administrators must be able to apply software patches, install service packs, install operating system upgrades, and connect debuggers, all of which are actions that can modify system software. Through this legitimate access, a service administrator might install software that makes malicious modifications to the behavior of the system.

• Persons with physical access to domain controllers — A person with physical access to a domain controller can attack the system in the following ways:

  • By modifying or replacing system binaries on the physical disk that hosts the domain controller's system software.
  • By using offline access to the directory database. An attacker who can gain offline access to the directory database can read data without ACLs being enforced, might be able to crack passwords stored in the database, and might be able to make changes to the database that change the behavior of this or potentially other domain controllers if the off line database is returned to the system.

  These attacks can be accomplished by:

  • Accessing physical disks by booting a domain controller to an alternate operating system.
  • Removing (and possibly replacing) physical disks on a domain controller.
  • Obtaining and manipulating a copy of a domain controller system state backup.

Note

The SYSKEY feature of Active Directory can provide additional protection for passwords stored in the Active Directory database by encrypting them with a system key stored on a floppy disk. To crack passwords in the database, the attacker needs physical access to both the Active Directory database and the floppy disk with the system key.

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.

Vulnerabilities from System Modification

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:

• All Kerberos Key Distribution Centers (KDCs) are considered equally trustworthy.

  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.

• Data stored in the shared schema and configuration partitions on all domain controllers and data stored in partial domain partitions on all global catalog servers is considered equally trustworthy.

  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:

  • Downstream domain controllers accept these changes as legal replicated updates
  • Directory-enabled client software accepts this data as legal data

  Security-sensitive software stored in these partitions includes the following:

  • Schema — The default security descriptor for an object class. An attacker might change the default security descriptor for an object class to grant access to users or groups under their control. This would grant the attacker access to newly created objects of that class.
  • Configuration — Site-based policy. An attacker might alter site-based policy to cause users in remote domains to execute attacker-defined logon scripts.
  • Partial domain partitions — Memberships of universal groups. An attacker might alter the membership of a highly privileged administrative universal group, such as Enterprise Admins, to include users specified by the attacker.

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:

• The configuration of the forest
• The configuration of any domain in the forest
• Any application that relies on data stored in any domain of the forest or in the configuration container of the forest
• Any computer that is joined to the forest, including data stored on those computers or services running on those computers
• Any resource in any domain outside the attacked forest that trusts a domain inside the attacked forest, and to which users in the attacked forest have been granted access

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.

Note

The above two characteristics of Active Directory cannot be used to launch attacks between domains in different forests if the proper precautions are observed:

• To protect against authorization data spoofing attacks, use the SID filtering feature on external trust links between domains in different forests. For more information about SID filtering, see article 309172 in the Microsoft Knowledge Base at http://search.support.microsoft.com/.
• No data partitions are shared or replicated between domain controllers in different forests. Users and administrators from externally-trusted domains in remote forests can only update security-sensitive data in a forest if they are specifically granted write access to that data. Do not grant access to security-sensitive data to users from externally trusted domains unless those users and the service administrators of the remote domain are as trusted as the service administrators of your forest.

Other Languages

This article is available in other languages, including Italian.

• Active Directory: Passaggi fondamentali per l'upgrade di Active Directory (it-IT)
• Considerazioni sulla progettazione della delega dell'amministrazione in Active Directory (it-IT)
• Consideraciones de diseño para la delegación de administración de Active Directory (es-ES)