Chapter 15: Designing a Secure Active Directory Infrastructure

Chapter 15 continues the discussion on Windows security automation by focusing on the mechanisms that exist to apply the group policy settings covered in Chapter 14. Microsoft has incorporated a fair amount of flexibility in Active Directory and group policy objects (GPOs). This flexibility is often described as confusing complexity by administrators beginning their first forays into securing computers with group policy. This chapter covers the different parts of Active Directory, describes the different mechanisms available to apply security policy, and makes best practice recommendations. Readers finishing this chapter will be able to maximize the effectiveness of group policy, keeping Windows computers secure, while minimizing the system performance delays caused by ineffective planning.

Active Directory Introduction

Active Directory is an X.500 directory service introduced by Microsoft with Windows 2000. A directory service is simply a namespace distributed database used to name, store, and locate resources. A namespace is a collection of objects with a common naming convention and format. Within each namespace, each object or resource must have a unique name and can only exist once. Many different namespaces are used today, both in computer form and non-computer form. An example of a non-computer namespace would be a phonebook. Within each phonebook, each phone entry has its unique address and phone number.

Popular computer namespaces, besides Active Directory, include DNS, WINS, Novell's eDirectory, OpenLDAP, and IBM's SNA. DNS is one of the world's largest namespaces, and no object within DNS shares a name or location. For instance, nobody else in the world is allowed to have my e-mail address of [e-mail]. By ensuring that all objects have unique names and locations, the directory service can always assist objects and processes in finding other objects.

Note 

Active Directory uses the DNS namespace to name and locate many resources.

All X.500 directory services follow a common structure and naming convention. For instance, the collection of all the locations in a single instance of a directory service is called the tree. The top of the point, the origination point, is called the root. Objects are stored directly off the tree or in subdivisions of the tree called containers or organizational units (OUs).

Note 

Organizational units and containers are essentially the same thing. An OU is an Active Directory container object and there are other types of container objects in Active Directory besides OUs (some other container types are covered below).

Active Directory comes with a default set of OUs, but administrators can make their own. Table 15-1 discusses the default OUs shown in the Active Directory Users and Computers console.

Table 15-1

Container Name	Description
Saved Queries	Blank container object by default, introduced in W2K3. Can be used to create and store custom LDAP queries. No GPOs can be linked here.
Built-In	Contains many of the built-in security groups present in any domain. All built-in security groups were shown in Table 3-4 in Chapter 3. No GPOs can be linked here.
Computers	Contains all computer object accounts either joined or imported to the domain. No GPOs can be linked here. Computer objects can, and should, be moved out of this container so that custom GPOs can be linked.
Domain Controllers	Contains all domain controller computer accounts for the domain. Should only contain domain controllers, and the domain controller computer accounts should not be removed from this OU. The default domain controller's GPO is linked here and custom GPOs can be linked.
Foreign Security Principals	Contains user, group, and computer objects (actually, their SIDs) from external, trusted domains. In single domain forests, contains no objects. GPOs cannot be linked here.
Users	Contains all new and imported user accounts for the domain, plus many built-in user accounts as shown in Table 3-3 in Chapter 3. No GPOs can be linked here. User account objects can, and should, be moved out of this container so that custom GPOs can be linked.
Table 15-1 shows the built-in OUs in Active Directory displayed by default. More "behind-the-scenes" OUs can be viewed if the View, Advanced Features (under the console menu) setting is enabled in the Active Directory Users and Computer menu. These additional containers are not discussed in Table 15-1, because they are rarely manipulated by administrators to enhance security.

An OU is the smallest container object to which a GPO can be attached. Administrators cannot apply a GPO directly to a user or computer object. In order to affect a computer or user with a GPO, the administrator must link the GPO to the OU in which the user or computer is located.

Although an administrator cannot attach new GPOs to many of the built-in OUs, GPOs linked at the domain or site level can still be inherited by the user or computer objects inside those containers. This is an important point. Either existing users and computers should be moved out of the existing built-in OUs into a custom OU container and GPOs linked directly, or inherited GPOs must be configured correctly to apply the correct policy to objects in the built-in containers.

Custom-made OUs can follow any structure and naming strategy the administrator wants to implement. Later in this chapter, the section "Efficient Active Directory Security Design" covers a structure optimized for security. However, the administrator can shape any structure that best organizes and manages the organization. OUs are essentially created for two reasons only:

• To organize and manage environment objects in a logical, organized method

• To apply security settings via group policy in a logical and structured way

If new to Active Directory organizations and group policy, administrators should structure their directory to mimic their entity's physical locations. A location-based tree structure will minimize Active Directory replication issues and allow the administrator to organize security along geographic boundaries.

Top Active Directory Containers

Every Active Directory environment is made up of one or more forests, domains, and sites.

Forests

The top Active Directory container able to be managed by a single security administrator is the forest. A forest is one or more domains. The forest is the highest container at which a single group policy or security setting can be applied. Most administrators set the majority of security settings at the domain level to make them more manageable, to improve speed, and because Microsoft didn't make managing security above the domain level easier.

Note 

The forest name is the same as the name of the first domain in the forest.

Domains

A forest contains one or more domains, and every forest starts with a single domain. Domains are called by both a NetBIOS and DNS name. All domains in the same forest share the same common parent root name (e.g., south.contoso.com and north.contoso.com are two different child domains under the parent contoso.com domain). Most domains have two or more domain controllers to store the local domain's users, computers, groups, and other resource information. When computers and users log on to the domain, they can connect to any domain controller in the domain to authenticate — usually the one that responds the fastest to their logon request. Every domain controller (DC) in the same domain has a nearly identical copy of the domain Active Directory database, which contains the domain's user, computer, group, and other objects.

Each domain has its own domain administrators group called Administrators. This is an unfortunate name because Administrators is also the name of the local admin group on each Windows computer, and the naming convention doesn't follow the forest example of Enterprise Admins group (one would expect the domain admin group to be called Domain Admins). However, any member of the domain-level Administrators group has full permissions and privileges to all users, computers, and other resources in the domain.

The domain is often incorrectly called the Windows security boundary, even though it is really the forest level that deserves the boundary distinction. The error is common because most security policies are set at the domain level or lower. Some security policies (i.e., Password and Account Lockout policies) must be set at the domain level.

Forest Root Domain

The first domain in a forest (called the forest root domain) is the most powerful domain in the forest because it is the only one with the Enterprise admins and Scheme admins forest groups. Only the administrators in this domain can add new members to those two very powerful accounts. Members of the Enterprise admins group are automatically members of each domain's Administrators group, which gives them local Administrator rights to all users, computers, and GPOs in the domain. Of course, any hacker gaining access to the forest root domain has an opportunity to gain control of every resource in the forest.

Trusts

Domains were introduced with Windows NT 4.0. In Windows NT 4.0 networks, trusts had to be set up between every domain that wanted access to another's objects. The trusting domain had the resources that the trusted (or user) domain wanted to access. Every trust between two domains had to be set up manually. With Windows 2000 and later forests, every domain in the same forest automatically has a two-way, transitive trust. With transitive trusts, if domain A trusts domain B and domain C trusts domain B, domain C will also trust domain A.

Every domain having a two-way transitive trust has huge implications on the forest. Every user in the forest will have the same security permissions as the domain-specific Everyone and Authenticated Users group has in its own domain. This also means that if a hacker breaks into any domain in a forest as an authenticated user, then they have the same access as the Everyone and Authenticated Users group has in any domain in the forest. Of course, the default behavior (of all domains trusting each other) can be modified to limit the damage from a security intrusion.

Windows 2003 forests can also have forest trusts with other forests. Cross-forest trusts are always made between a domain in one forest and a single domain in another forest, and cross-forest trusts are not transitive.

Forests trusts can be constrained by a feature called selective authentication. If enabled, even though users crossing from their home forest to the remote forest are added to the remote forest's Authenticated Users group, an additional security check is performed that will prevent the home forest user from accessing objects in the remote forest until administrators in the remote forest specifically allow access. If a cross-forest trust is utilized, strongly consider creating the trust with selective authentication to prevent remote users from being added to the local forest's Authenticated Users group automatically.

While GPOs and security policies cannot be inter-forest, a forest trust (one-way, two-way, transitive, or non-transitive) can allow security principals in one forest to access resources in another external forest. There are other trusts types, such as external or realm trusts, that can be made from one domain to another type of resource entity (i.e., an NT 4.0 or Kerberos domain), but they don't involve any significant security differences that have not already been discussed. It's important to understand that any trust will allow users from one domain to become an authenticated user in the other domain.

Another security implication to consider is that of the Windows trust password. A password must be supplied with every Windows trust created. The password must be identical on both the trusting and trusted domain. After it is initially set and the trust confirmed on both sides, Windows handles changing the trust password thereafter. During the initial setup, the Windows trust password should be long and complex.

For more information on Windows trusts, see http://support.microsoft.com/default.aspx?scid=kb;EN-US;128489.

Depending on the version of Windows, the type of trust created, and whether the domain controller involved is in the trusting or trusted domain, the trust password hash is stored in either the LSA secrets cache, Active Directory, or a SAM database. During trust establishment operations, the trust password hash is cached locally on the domain controller. Regardless of the location, each Windows trust password is an additional password that might be recovered and broken. Practically, trust passwords have not been attacked much, but the risk is always there.

Forest Single Master Operations Roles

Even though most of the DCs in a forest only have a copy of the objects in their own domains, some DCs have additional domain- and forest-level roles. Some operations require a single master server to maintain ultimate ownership of the transaction. The five Active Directory Forest Single Master Operations (FSMO) roles and their descriptions are shown in Table 15-2.

Table 15-2

FSMO Role Name	Description
Domain Naming Master	Keeps track of domain names. Needed when creating, deleting, or renaming new domains in a forest. Usually only one per forest.
Relative Identifier Master	In charge of creating and handing out new Relative Identifiers (RIDs), the ending portion of the SID. Hands out new RIDs to DCs. RIDS are given to new users, groups, and computer objects. Usually one per domain.
Infrastructure Master	Keeps track of groups and group memberships. Usually one per domain.
PDC Emulator	PDC Emulator will communicate to NT 4.0 domain DCs. Keeps track of passwords and password changes, and is the time synchronizer for the domain. Usually one per domain. Hackers may want to infiltrate this DC to change the time to hide activities or to download the most current copy of all domain user and computer password hashes.
Schema Master	Keeps track of schema design (i.e., Active Directory database fields). Usually only one per forest. Although not exploited to date, it is essentially the most powerful DC in the forest.

Along with these FSMO roles, usually one or more DCs in each domain contain a Global Catalog (GC). All DCs within a common domain have a nearly identical copy of all the objects, rights, and permissions in the domain (there are always transient differences that they each replicate to each other, such as LastLogonTime field data indicating when a user logs on to a specific DC). Any DC with a GC also has a list of all Active Directory objects in the forest (although not a full list of object attributes). Essentially, a GC is an Active Directory index file. When an object or process looks for an Active Directory object, it often queries the GC for the location. For instance, when a newly booted Windows client attempts to log on, it will query the GC to find DCs with which to authenticate.

Sites

Sites define physical locations for Active Directory replication. Essentially, a site is a logical collection of subnets that contain domain controllers that can talk to each other over relatively fast and constant network connections. In large environments, if all DCs within a domain were to constantly, and immediately, communicate every database change and update to each other the instance it happened (as occurs with all DCs in the same domain within the same site), it could cause traffic congestion problems or cause inefficient economic costs.

By defining some subnets (and thus, some domain controllers) as belonging in the same site, and others as not, replication traffic and costs can be managed by physical location. Domain controllers within the same domain frequently replicate information to each other without any form of encryption. Intersite DCs are configured to replicate at certain times and for certain intervals. When intersite replication occurs, security changes must be transmitted between sites first (bridgehead server to bridgehead server), and then the site's bridgehead DC transmits the changes to the local site's DCs, which then communicate the changes or updates to the users or groups within the domain. In practice, this means that security settings and applied GPOs may not take effect at intersite DCs for a longer period of time than happens intrasite.

By default, Active Directory contains one site, called the Default-First-Site object. It contains all DC objects and subnets unless otherwise defined. Sites can be viewed, managed, created, and deleted using the Active Directory Sites and Services console (see Figure 15-1). One or more group policy objects can be applied at the site level (the creator must be an Enterprise admin), using the Active Directory Sites and Services tool or GPMC, but sites are not often the optimum location of GPO security settings because of the potential intrasite replication issues. Enterprises needing security policies applied across a large geographic intrasite location often choose to use domain or OU GPOs instead. However, if the site is smaller in size than the domain, or if the organization has a lot of roaming issues (e.g., IPSec, printers, proxy servers, etc.), it may make sense to set a more granular site-level policy.

Figure 15-1

Partitions

Starting with Windows Server 2003, Active Directory allows directory (also called application) partitions to be defined on one or more DCs. Once a partition is initially created, it can be replicated to one or more other DCs. Only the predefined DCs will replicate partition information to each other and only applications that are specifically written to write information to a partition can. Partitions are not normally used to spread security setting information, but they may be an additional factor in some environments.

LDAP

X.500 directory services are often accessed using a protocol called Lightweight Directory Access Protocol (LDAP). Yes, there was a superset of the protocol called Directory Access Protocol (DAP), but the subset of LDAP has most of the features that administrators, programmers, and users need. Unfortunately, if you've ever done any LDAP programming or queries, the protocol format isn't the friendliest language. Following are two sample LDAP strings:

 cn=Roger Grimes,o=Contoso.com,c=US dc=apppartition,dc=contoso,dc=com,dc=server1 

The former example might identify a user account or e-mail address. The latter represents an object, in this case an application partition, in the Contoso.com domain on a DC called server 1.

Fortunately, most users and administrators never need to interact with Active Directory except through the graphical user interfaces and other types of programs. Most Active Directory manipulations and queries are done using the Active Directory Users and Computers console. Sites are manipulated through the Active Directory Sites and Services console. Forests and trusts are manipulated using the Active Directory Forests and Trusts console. Microsoft also includes dozens of tools to manipulate Active Directory (graphical, command-line, and additional Resource Kit utilities).

LDAP is ripe for hacker exploitation but has so far escaped popular attention. There have been a few attacks specifically coded to exploit Active Directory and its operations, but none that spread beyond a few sites or theoretical discussions. If history proves any guide, when Microsoft releases a next-generation platform security change, like the NT kernel, and now Active Directory, it takes the hackers three to five years to catch up.