Autonomy and Isolation in Active Directory

In Microsoft Windows NT, members of the Domain Admins group have complete control
over all objects in their own domain but no inherent control over any objects in a trusting
domain. Similarly, changes made to one domain do not affect trusting or trusted domains.
Furthermore, within the domain, the primary domain controller (PDC) owns the only
writeable copy of the Security Accounts Manager (SAM). For these reasons, domains are
considered discrete security boundaries in Windows NT.
Unlike Windows NT, Active Directory domains are not security boundaries because they are
not fully autonomous and isolated from each other. Understanding how this affects an
Active Directory forest is a key stepping-stone to designing and deploying a secure Active
Directory. When discussing autonomy and isolation, we need to separate the rights and
permissions of two types of administrative capabilities: Active Directory service
administrators and Active Directory data administrators.
Active Directory service administrators are responsible for the configuration and
management of the directory service itself. This includes tasks such as maintaining domain
controller servers and managing directorywide configuration settings. Active Directory
service administrators are also generally data administrators because of the rights and
permissions required to allow them to be Active Directory service administrators.
Active Directory data administrators are responsible for managing data stored in Active
Directory objects or on computers joined to Active Directory, but they have no authority
over the configuration or management of the directory service itself. Active Directory data
administrator roles include the following functions:
The management of a subset of objects in Active Directory, such as user accounts in a
specific OU
The management of data that is stored on computers joined to the domain
When designing Active Directory, you must consider your organizations security
requirements for autonomy and isolation of authority in relation to Active Directory services
and Active Directory data management. Your security requirements will have a significant
effect on how you design Active Directory to facilitate delegation of authority and
administrative responsibility.
Autonomy of authority means that Active Directory services and data administrators can
independently manage all or part of the resources over which they have authority. Isolation
of authority means that accounts and people not authorized for Active Directory services
and Active Directory data management are prevented from controlling or interfering with
service management (services management isolation), or from controlling or viewing a
 subset of data in the directory or on member computers joined to the directory (data
management isolation).
Designing Forests for Active Directory Security
The forest is the largest management unit of Active Directory as well as the ultimate unit of
autonomy and isolation of authority. Active Directory design begins with answering the
question, How many forests will my organization require? The answer to this question is
based on security considerations for autonomy and isolation of authority. Characteristics of
forests and security considerations that can affect your design include the following:
Enterprise administration boundaries
Default permissions and schema control
Global Catalog boundaries
Domain trust requirements
Domain controller isolation
Protection of the forest root domain
Enterprise Administration Boundaries and Isolation of Authority
The forest is the boundary of enterprise administration. The built-in Administrator account
in the forest root domain is the forest owner because this account, along with members of
the Enterprise Admins and the forest root Domain Admins security groups, has ultimate
authority over all objects in all domains in the forest. Collectively, members of the
Enterprise Admins and forest root Domain Admins groups are known as enterprise
administrators. Enterprise administrators control the Active Directory objects in the
configuration container that do not belong to any one domain, including Enterprise
Certification Authority objects and other configuration data that affects all domains in the
forest. Needless to say, these accounts have high security requirements.
Because enterprise administrators have authority over all domains in the forest, the domain
administrators in each domain must trust the enterprise administrators. You cannot truly
restrict enterprise administrators from managing objects in any domain in the forest.
Enterprise administrators can always regain control over objects. Some organizations with
political challenges, such as those frequently encountered in mergers and acquisitions,
might find the scope of this enterprise authority too great and require more than one forest.
If your organization requires strict isolation of authority between domains, you will need to
deploy multiple forests with manually created trusts between domains in the different
forests. These are similar to the structures commonly used in Windows NT domains.
Default Permissions and Schema Control
Each Active Directory forest has one collection of object classes and attributes defined in
the Active Directory Schema container and used as templates for objects created in the
directory. Object classes in the schema can be instantiated in any domain in the forest. The
default permissions on all objects created in the forest are derived from the schema. Thus,
alterations or extensions to the schema affect the security of the entire forest, and
permissions to make changes to the schema must be restricted. The only user accounts that
can make changes to the schema of a forest are members of the Schema Admins security
group, which is created by default in the forest root domain and contains only the built-in
Administrator account for the forest root domain. Only enterprise administrators (members
of the forest root domain Administrators, Domain Admins, and Enterprise Admins groups)
can modify membership in the Schema Admins group. If your organization employs multiple
groups that require autonomy and isolation of object classes or default security on objects,
you will need to create multiple forests.
Global Catalog Boundaries
The Global Catalog contains a read-only listing of all objects and a subset of attributes from
every object in every domain in the forest. The Global Catalog is used by applications to
locate objects and look up attributes of objects. The Global Catalog also provides a
boundary of searchable objects that can be accessed by all security principals in the forest.
Therefore, if objects that should not be universally searchable exist, your organization will
require multiple forests. Similarly, Microsoft Exchange 2000 Server uses the Global Catalog
to populate the global address list (GAL) for internal e-mail recipients, with a single
Exchange organization mapping to a single forest. Thus, creating multiple forests impacts
your organizations Exchange design as well.
Domain Trust Requirements
In Active Directory, all domains are connected by Kerberos trusts. Kerberos trusts are two-
way and transitive in nature. This differs from Windows NTstyle trusts, which are one-way
and intransitive. Each child domain trusts its parent domain, and each tree root trusts the
forest root domain. Thus, the forest root domain is the key to transitive trust in the forest.
Removal of the Kerberos trusts between domains in the forest will destroy Active Directory
functionality. In Windows NT, it was common to create a domain that trusted logons from
another domain that itself did not trust logons from the trusted domainin other words,
implementing one-way trust relationships was common.
In Active Directory, however, all Kerberos key distribution centers (KDCs) in the forest are
trusted equally and implicitly. Therefore, credentials from a compromised KDC and a
legitimate KDC are indistinguishable by other KDCs and will be implicitly accepted. If your
organizations security requirements dictate that domains must have only one-way trusts
with other domains in your organization or isolation of Kerberos KDCs, the domains must
be created in separate forests. The only external Kerberos trust relationships that can be
created in Windows 2000 are trusts between a Windows 2000 domain and an MIT Kerberos
realm. You can create Windows NTstyle trusts between Active Directory domains in a
 different forest, but those trusts cannot be used by other domains in either forest. If you
require trusts between multiple domains in different Windows 2000 forests, each trust must
be created manually between each of the domain pairs.
Domain Controller Isolation
In Active Directory, each domain controller holds replicas of at least three logical partitions
in the Active Directory database: the schema container, the configuration container, and the
domain naming context for the domain controllers domain. The first two containers are
replicated among all domain controllers in the forest, and the latter is replicated among all
domain controllers for the same domain. Because all domain controllers replicas of the
Active Directory database are writeable and can replicate shared information to domain
controllers in other domains, compromise of a single domain controller can affect the entire
forest.
For example, it is possible for an attacker who has physical access to any domain controller
to view or manipulate data stored anywhere in the forest or on any computer in the forest.
That attacker can even make offline changes to forestwide partitions in the directory
database, thus compromising the entire implementation. Consequently, physical access to
all domain controllers must be restricted to trusted personnel. Similarly, any account with
Active Directory service administrator privileges in a domain can potentially hijack a domain
controller under its control to compromise the entire forest, either by data manipulation or
denial-of-service attack. If your organization requires complete isolation of domains, even
from other domain administratorsas is commonly seen in large holding corporations or
hosting solutionsyou must deploy multiple forests.
Protection of the Forest Root Domain
Regardless of how many forests your organization implements, you must protect the forest
root domain. This is because compromise of this domain could have catastrophic effects on
your network. You must protect the two main components of a forest root domain shown
below.
Enterprise administrative accounts
Physical security of forest root domain controllers
Enterprise Administrator Accounts
The forest root domain contains the built-in Administrator account for the root, which by
default is the only member of the Enterprise Admins, Schema Admins, and Administrators
security groups. If an attacker compromises this account or any accounts placed into these
groups, the attacker can gain complete control over the entire forest. You can build several
safeguards into your Active Directory design to protect these accounts and security groups.
The following list describes these safeguards:
Limit the number of enterprise administrators.
 Make only the accounts that require enterprise authority members of the Enterprise Admins,
Domain Admins, and Schema Admins security groups. In most organizations, this should
amount to less than five people. You should use these accounts only when absolutely
necessary.
Use Restricted Groups.
You can use Restricted Groups in the Group Policy security settings to limit membership in
built-in Administrators, Enterprise Admins, Domain Admins, and Schema Admins security
groups. Restricted Groups, by default, are enforced every 5 minutes on each domain
controller.
Perform all administration locally.
Restrict the enterprise administrator accounts to logging on interactively to forest root
domain controllers. This will prevent enterprise administrator accounts from being attacked
on nondomain controllers.
Use smart cards.
For accounts that require enterprise administrator rights or permissions, require the use of
smart cards for interactive logon and enable the smart card removal behavior to lock the
computer if the smart card is removed from the reader. Before enabling the option to
require a smart card for interactive logon, be sure to change the password on the account
to a strong password. Ideally, this password should be random and longer than 50
characters to prevent brute force attacks.
Use strong passwords.
For the built-in Administrator account, which cannot be disabled or required to use smart
card logon, create a password with a minimum of 15 characters. This will prevent a LAN
Manager (LM) password hash from being created. Ideally, use a longer password.
Provide physical security over the forest root domain controllers.
If the physical security of a forest root domain controller is compromised, all accounts in
the forest root domain are vulnerable, including enterprise administrative accounts.
Remember, even if strong passwords are employed, any password can be broken, given
adequate hardware resources and time.
Physical Security of Forest Root Domain Controllers
In a multiple domain forest, the forest cannot function without the presence of the forest
root domain. For example, suppose your organization houses all the domain controllers
from the forest root domain in a single facility and that facility is destroyed by a natural
disaster such as a tornado or hurricane. If the forest root domain cannot be recovered by
using backup media, your organizations Active Directory must be completely rebuilt.
Similarly, the physical compromise of a domain controller can lead to the exposure of Active
Directory account password hashes. The password hashes can then be attacked offline.
As previously discussed, the physical compromise of a domain controller can compromise
the entire forest if an attacker exploits a domain controllers ability to write data to other
domain controllers in the forest, or if the attacker utilizes implicit and equal trust given to
all KDCs by other KDCs to attack other domains. You must design Active Directory with the
location and physical security of domain controllers in mind, and you might need to
implement multiple forests to isolate sensitive accounts or operations.