When you are potentially storing millions of objects in Active Directory, each object has to be uniquely locatable and identifiable. To that end, objects have a globally unique identifier (GUID) assigned to them by the system at creation. This 128-bit number is the Microsoft implementation of the universally unique identifier (UUID) concept from Digital Equipment Corporation. UUIDs/GUIDs are commonly misunderstood to be guaranteed to be unique. This is not the case; the number is just statistically improbable to be duplicated before the year 3400 AD. In the documentation for the GUID creation API function, Microsoft says, “To a very high degree of certainty, this function returns a unique value.” The object’s GUID stays with the object until it is deleted, regardless of whether it is renamed or moved within the directory information tree (DIT). The object’s GUID will also be preserved if you move an object between domains within a multidomain forest.

Although an object’s GUID is resilient, it is not very easy to remember, nor is it based on the directory hierarchy. For that reason, another way to reference objects, called a distinguished name (DN), is more commonly used.

dc=mycorp,dc=com

dc=mydomain,dc=mycorp,dc=com

cn=Administrator,cn=Users,dc=mycorp,dc=com

cn=Administrator

cn=Keith Cooper,ou=Northlight IT Ltd,dc=mycorp,dc=com

ou=Pre-Sales,ou=Sales,dc=mycorp,dc=com
ou=Post-Sales,ou=Sales,dc=mycorp,dc=com

cn=Richard Lang,ou=Pre-Sales,ou=Sales,dc=mycorp,dc=com
cn=My Group,ou=Pre-Sales,ou=Sales,dc=mycorp,dc=com
cn=PC1,ou=Pre-Sales,ou=Sales,dc=mycorp,dc=com

Active Directory’s logical structure is built around the concept of domains. Domains were introduced in Windows NT 3.x and 4.0. However, in Active Directory, domains have been updated significantly from the flat and inflexible structure imposed by Windows NT. An Active Directory domain is made up of the following components:

A domain controller (DC) can be authoritative for one and only one domain. It is not possible to host multiple domains on a single DC. For example, Mycorp has already been allocated a DNS domain name for its company called mycorp.com, so it decides that the first Active Directory domain that it is going to build is to be named mycorp.com. However, this is only the first domain in a series that may need to be created, and mycorp.com is in fact the root of a domain tree.

The mycorp.com domain itself, ignoring its contents, is automatically created as the root node of a hierarchical structure called a domain tree. This is literally a series of domains connected together in a hierarchical fashion, all using a contiguous naming scheme. If Mycorp were to add domains called Europe, Asia, and Americas, then the names would be europe.mycorp.com, asia.mycorp.com, and americas.mycorp.com. Each domain tree is called by the name given to the root of the tree; hence, this domain tree is known as the mycorp.com tree, as illustrated in Figure 2-2. You can see that in Mycorp’s setup we now have a contiguous set of domains that all fit into a neat tree. Even if we had only one domain, it would still be a domain tree, albeit with only one domain.

Figure 2-2. The mycorp.com domain tree

Trees ease management and access to resources, as all the domains in a domain tree trust one another implicitly with transitive trusts. In a transitive trust, if Domain A trusts Domain B and Domain B trusts Domain C, this implies that Domain A trusts Domain C as well. This is illustrated in Figure 2-3. Put much more simply, the administrator of asia.mycorp.com can allow any user in the tree access to any of the resources in the Asia domain that the administrator wishes. The user accessing the resource does not have to be in the same domain.

Figure 2-3. The mycorp.com domain tree

Now that you understand what a domain tree is, we can move on to the next piece of the Active Directory structure, the forest. Where a domain tree was a collection of domains, a forest is a collection of one or more domain trees. These domain trees share a common Schema and Configuration container, and the trees as a whole are connected together through transitive trusts. As soon as you create a single domain, you have a forest. If you add any domains to the initial domain tree or add new domain trees, you still have one forest.

A forest is named after the first domain that is created, also known as the forest root domain. The forest root domain is important because it has special properties.

As we continue with Mycorp, we find that it has a subsidiary business called Othercorp. The DNS domain name allocated to and used by Othercorp is othercorp.com. In Othercorp’s case, all you would need to do is create the root of the othercorp.com tree as a member of the existing forest; othercorp.com and mycorp.com can then exist together and share resources, as shown in Figure 2-4. The forest containing the mycorp.com and othercorp.com domain trees is known as the mycorp.com forest, in which mycorp.com is the forest root domain.

Figure 2-4. Transitive trusts illustrated

Individual companies often implement their own forests. If Othercorp elected to deploy its Active Directory as a separate forest, you would need to employ a forest trust between Mycorp and Othercorp to provide seamless resource access between the two companies.

A forest trust allows an administrator to create a single transitive one-way or two-way trust between two forest root domains. This trust allows all the domains in one forest to trust all the domains in another forest, and vice versa.

If you have business units that are independent and, in fact, wish to be isolated from each other, then you must not combine them in a single forest. If you simply give each business unit its own domain, these business units are given the impression that they are autonomous and isolated from each other. However, in Active Directory, this level of autonomy and isolation can be achieved only through separate forests. This is also the case if you need to comply with regulatory or legal isolation requirements. Finally, some organizations choose to deploy Microsoft Exchange in a separate resource forest in order to handle separate administrative structures and requirements.

Having covered the large-scale (domains, trees, and forests) view of Active Directory, we’ll now talk about the small scale. When you look inside an Active Directory domain, you will see a hierarchical structure of objects. This hierarchy is made up of objects that can act as containers and objects that cannot. The primary type of container that you will create to house objects is called an organizational unit (OU). Another type of container, which is actually called a container, can also be used to store a hierarchy of objects and containers.

Although both can contain huge hierarchies of containers and objects, an organizational unit can have group policies applied to it. (For more information on Group Policy, see Chapter 11.) For this reason, OUs are often used almost exclusively for building object hierarchies within a domain.

Let’s illustrate this with an example. Imagine that you are the administrator of the asia.mycorp.com domain from Figure 2-2. You have 500 users and 500 computer accounts in the domain. Most of the day-to-day account and machine management is very simple, but the manufacturing section is currently undergoing restructuring and an extensive recruitment program; people keep being transferred in or hired from the outside. You would like to be able to give this group limited autonomy over user objects by allowing one of the senior administrators to manage its own section of the tree. Complete segregation of security is not needed, and the manufacturing tree isn’t large enough to justify creating another domain to manage along with the associated domain controllers. You can instead create an organizational unit in your hierarchy called Manufacturing. You then give the senior engineer authority over that organizational unit to create and delete accounts, change passwords, and create other organizational units within the Manufacturing OU. Obviously, the permissions that the senior engineer would be given would be properly tailored so that he had control over only that organizational unit and not the asia.mycorp.com domain tree as a whole. You could do this manually or delegate control using the Delegation of Control Wizard, discussed in more depth in Chapter 16.

When you install an Active Directory domain, a number of default containers and organizational units are created automatically, including the Users and Computers containers and the Domain Controllers OU. If you try to create a new container, you will find that there is no option to do so from within the Active Directory Users and Computers (ADUC) MMC snap-in. This also applies to Organization, Locality, and Country container objects. This is intentional; in almost all cases, you would want to create an organizational unit instead of a container. It is possible to create the other types of containers from within scripts and other LDAP tools, but generally it is not necessary. So, throughout this book, whenever we advocate creating hierarchies within domains, we always recommend that you use organizational units. After all, an organizational unit is just a superset of a container. There is nothing a container can do that an organizational unit cannot.

The Global Catalog (GC) is a very important part of Active Directory because it is used to perform forest-wide searches. As its name implies, the Global Catalog is a catalog of all objects in a forest that contains a subset of attributes for each object. The GC can be accessed via LDAP over port 3268 or LDAP/SSL over port 3269. The Global Catalog is read-only and cannot be updated directly.

In multidomain forests, typically you first need to perform a query against the GC to locate the objects of interest. Then you can perform a more directed query against a domain controller for the domain the object is in if you want to access all the attributes available on the object.

The attributes that are available in the Global Catalog are members of the partial attribute set (PAS). You can add and remove attributes to and from the PAS by using tools such as the Active Directory Schema snap-in or by modifying the attributeSchema object for the attribute directly in the schema.

Even though Active Directory is a multimaster directory, there are some situations in which there should only be a single domain controller that can perform certain functions. In these cases, Active Directory nominates one server to act as the master for those functions. There are five such functions that need to take place on one server only. The server that is the master for a particular function or role is known as the Flexible Single Master Operator (FSMO, pronounced “fizmo”) role owner.

Of the five roles, three exist for every domain, and two apply to the entire forest. If there are four domains in your forest, there will be 14 FSMO roles:

The number of different role owners can vary greatly depending on whether you have domain controllers serving multiple roles, as is often the case.

The different FSMO roles are the following:

FSMO roles can be transferred between domain controllers. You can transfer the domain naming FSMO with the Active Directory Domains and Trusts snap-in, the schema FSMO with the Active Directory Schema snap-in, and the RID, infrastructure, and PDC emulator FSMOs using the Active Directory Users and Computers snap-in or with Windows PowerShell. Alternatively, you can use the ntdsutil utility to perform transfers from a command line. For more information on using NTDSUTIL to transfer FSMO roles, see Chapter 18.

Although the AD snap-ins and NTDSUTIL can trivially transfer a role from one server to another while both servers are available, there will be some cases in which a FSMO role owner becomes unavailable without the role previously being transferred. In this case, you have to use NTDSUTIL to force an ungraceful transfer of the role to a server, known as “seizing” the role. When you seize a FSMO role, you should not bring the original role owner back online. Instead, you should perform a metadata cleanup and then rebuild the domain controller. For more information on using NTDSUTIL to seize FSMO roles, see Chapter 18.

If you lose one of the FSMO role holders for a domain, you should always make sure that you are in control of the situation and are promoting a new DC to be the relevant role holder, forcibly moving the role to an existing DC or swiftly bringing back the DC that is the relevant role holder.

Many Active Directory administrators spend a great deal of time worrying about the well-being of their FSMO role owners and the “what-if” scenario of scrambling to bring them back into service if one of the role holders goes offline. It is worthwhile to consider just how important the immediate availability of each FSMO role owner is to your environment:

CN=NTDS Settings, CN=MYSERVER1, CN=Servers, CN=My Site,
CN=Sites, CN=Configuration, DC=mycorp, DC=com

Active Directory is highly dependent on all of the domain controllers and domain members having synchronized clocks. Kerberos (which is the underlying authentication protocol for Active Directory clients) uses system clocks to verify the authenticity of Kerberos packets. By default, Active Directory supports a tolerance of plus or minus five minutes for clocks. If the time variance exceeds this setting, clients may be unable to authenticate and, in the case of domain controllers, replication will not occur. Newer versions of Windows can handle time skew without impacting Kerberos, as discussed in this article.

Fortunately, Active Directory and Windows collectively implement a time synchronization system based on the Network Time Protocol (NTP) that ensures that every machine in the forest has a synchronized clock. The w32time service implements time synchronization on every Windows 2000 or newer machine in the forest. The time synchronization hierarchy is outlined in the following list, and one possible effective hierarchy is shown in Figure 2-5:

You should not need to configure the w32time service on any domain joined machine other than your root domain’s PDC emulator. While it is permissible to do so, our experience has been that many organizations that elect to use a different time sync hierarchy (such as using local routers or dedicated NTP servers) end up suffering from Kerberos issues later. For information on how to configure the w32time service on the PDC emulator, see the upcoming sidebar Configuring W32Time on the PDC Emulator.

w32tm /config /update 
  /manualpeerlist:"0.pool.ntp.org,1.pool.ntp.org,2.pool.ntp.org" 
  /syncfromflags:manual /reliable:YES
w32tm /resync /rediscover /nowait

Figure 2-5. Sample time synchronization hierarchy

For the Windows Server 2003 release of Active Directory, Microsoft expanded on the domain mode concept by introducing functional levels. Whereas the domain modes applied only to domains, functional levels apply to both forests and domains. Like the domain mode, functional levels dictate what types of operating systems can assume the role of a domain controller in a domain or forest. Each functional level also has an associated list of features that become available when the domain or forest reaches that particular functional level. We cover many of the features that are available for each functional level in Appendix A.

Like domain modes, functional levels can be set via the Active Directory Domains and Trusts snap-in. For the Windows Server 2003 and Windows Server 2008 functional levels, once the functional level is “elevated” to a higher status, it cannot be rolled back. Windows Server 2008 R2 introduced the ability to roll back the functional level through the introduction of optional features that are enabled independently of functional levels.

Table 2-3 and Table 2-4 show the operating systems that are supported by the various domain and forest functional levels.

Active Directory supports three group scopes: domain local, domain global, and universal. Groups in each of these scopes behave slightly differently based on the domain and forest functional levels. To complicate matters further, each group scope can have two types: distribution and security.

The type is the easiest piece to define. If the type is distribution, the group’s SID is not added to a user’s security token during logon, so it cannot be used for Windows security purposes. Distribution groups are generally used as a messaging list (a set of users that you can mail or send instant messages to all at once), though it is possible to use them for security groups for LDAP-based applications or for other applications that don’t use the standard Windows security model. Microsoft Exchange represents distribution lists with Active Directory distribution groups. Security groups, by contrast, are enumerated during logon, and the SIDs of any groups of which the user is a member are added to the user’s security token. Security groups can also be leveraged by Exchange as distribution lists.

All Windows editions that support Kerberos will encounter problems if security principals are members of too many groups. The issue is that the token of the security principal becomes too large for Windows to handle, and users may experience authentication or other Kerberos issues. This phenomenon is often referred to as token bloat. For more information on token size issues, reference this link. The three different scopes of mailing lists and security groups result from the legacy of Windows NT and the introduction of the GC. Global groups and domain local groups are the direct descendants of Windows NT groups; the membership of these groups is only available from domain controllers of the domains in which they are created. Universal group membership is available both from the domain controllers of the domains in which they are created in and from all Global Catalogs in the forest. Universal and global groups can be used in access control lists (ACLs) on any resource in the forest or in trusting domains. Domain local groups can only be used in ACLs in the domain in which they are created.

In order to help you fully understand how groups work in Active Directory, we will explain the following items in this section:

To start with, let’s take a look at what rules govern nesting of groups within a domain. Table 2-6 shows which types of groups can be nested within other types of groups.

Although this table is fine, there is one other complicating factor that needs to be taken into account: cross-domain group membership.