Defining Active Directory Namespace Candidates

Now that we have gathered a great deal of information about your organization relevant to the Active Directory domain design, we need to take that information and put it to use. After a brief review of Active Directory domains and trees, we will look at some of the design decisions necessary to construct a sound domain topology.

A Few Active Directory Basics

Active Directory is a distributed system that is made up of a directory database, which includes a schema, transaction logs, and all the other necessities that come with a database, and a directory service. The directory service is the process (or processes) that makes use of the information stored in the directory database.

Active Directory provides directory services geared toward the enterprise. This means that Active Directory services need to provide additional functionality and availability, such as

• Scalability —Active Directory domains are logical security boundaries around a set of objects. A domain can contain a varying number of objects ranging from the hundreds to the millions. Domains can be added and deleted as necessary.

• Extensibility —As previously mentioned, the Active Directory database uses a schema. The schema is the definition of all the objects that can be created in Active Directory, along with their attributes. The schema can be modified, allowing for new objects or modified attributes on existing objects. In addition, new object classes can be added to the schema to support directory-enabled applications.

• Internet Standards —Microsoft is starting to move away from proprietary protocols and methods. They would rather sponsor RFC drafts, which support naming that adds their desired functionality (which is good for us all). Subsequently, name resolution and the directory access and security protocols are basic Internet standard protocols.

• Single Seat Administration —Administrators can administer any portion of the directory from a single location in the organization (with the right permissions, of course).

• Fault Tolerance —Each DC in the domain has a complete copy of that domain's directory, making Active Directory a multi-master directory. Each DC has a writable copy of the domain partition. If one DC fails, the other DCs are still able to satisfy requests for Active Directory services.

• Security —The access control lists (ACLs) control who has permission to access directory data.

• Interoperability —Active Directory, being based on an X.500 directory and using Internet standard protocols, is able to interact with other X.500 based directory services.

Naming and Name Resolution

Every object that represents information or resources in Active Directory must have a name unique to Active Directory. Additionally, Active Directory must support several of the common naming conventions that clients might use. The name is a X.500 style distinguished name (DN) that describes the object's location in the directory. The relative distinguished name (RDN) is the portion of the DN that makes the object unique. If you have two Ed Brovicks in your organization, as long as they are in different OUs, or have different RDNs, they will have unique DNs. For example, there could be two Ed Brovicks in two different OUs because the OU made the DN unique. If there are two Ed Brovicks in the same OU, they would have to have different RDNs, such as CN=ebrovick and CN=ebrovick1, so that they are unique DNs.

• Name resolution—is the process that takes the DN and translates it into an object or into information that the DN represents.

• Active Directory—is a collection of objects. What these objects are and their definitions are as follows:

  • Object classes—are the types of objects that can be created in the directory. Object classes have attributes associated to them, which compose the object class. Users, for example, are a class of objects. First Name and Last Name are examples of attributes associated with the Users object class.

  • Objects—are the instances of the object classes that you create. When you create a user object, it is based on the object class.

  • Attributes—are the characteristics, or fields, that make up the object class. The attributes that each object has, as well as the values that they can contain, are defined in the object classes. Attributes can be mandatory or not. Again, when a user object is created, there are attributes on that object that are populated. Examples of such attributes are First Name, Last Name, and Display Name.

  • Schema—contains all the Active Directory object classes and attributes. The dictionary defines what is in the Active Directory database.

Active Directory Logical Structure

Objects in Active Directory are organized in containers. A container itself is a directory object that holds other objects. The types of containers Active Directory uses to organize objects are:

• Organizational Units (OUs)—contain objects for organizing those objects. Objects within an OU can be treated as a collection of objects when Group Policy Objects are associated with an OU.

• Containers—are different from OUs in that although they are built into Active Directory, they can't have GPOs associated with them. The Users container is an example of a container.

• Domains—are containers that also define a security context. This means that Active Directory is written to treat all objects within a domain by the same rules.

• Trees—are a collection of one or more domains that share a common namespace. Although all domains trust one another, the tree relationship is defined by the namespace that is necessary to support the domain structure. The root domain of wadeware.net can have two sub-domains named backoffice.wadeware.net and office.wadeware.net. This relationship between the root domain and the two child domains is what forms a tree.

• Forest—is a collection of one or more trees. Trees within the Forest share the same Active Directory but do not need to share the same namespace. Therefore, you can have two organizations, such as wadeware.net and wadeco.net, which are contained in a single Active Directory; they share the same configuration, GC, and schema partitions; but they have different namespaces.

• Global Catalog (GC)—is a central source for all directory objects. Not all the attributes from each object is stored in the GC but just enough to make it useful for searching the entire Active Directory. This is because objects replicate among the other DCs within their domain only. That means that a user looking for an object in another domain is not be able to find that user's object from his or her DC. Therefore, the user would query the GC server and find the DN for the object. The user could then locate the object in Active Directory.

• Trust relationships—are logical links that combine two or more domains into one administrative unit. This allows permissions to be associated from one domain to another, because one domain trusts that the other domain has authenticated its users, and they are who they say they are.

• Namespace—is the DNS type namespace that represents domains. Active Directory is dependent on DNS and the DNS namespace. This makes it important to design your domain topology in a DNS-friendly way and to provide clients with reliable DNS services.

Physical Structure

If the logical components aren't difficult enough to keep straight, the physical components only add to the mix:

• Sites—are groupings of computers (or subnets) that share high-speed, high- bandwidth, and connectivity. A subnet can only be associated with a single site. Sites only contain resource objects, such as computers. A site definition is stored as a site object in Active Directory. Multiple site objects construct a site topology, which is different from the logical topology of the network. This means that you can have one domain across more than one site, and you can have one site that contains multiple domains. Therefore, sites ignore domains and namespaces. They define how and, perhaps, when replication between DCs occurs and which DC a user's computer contacts for authentication. A site can also have a group policy imposed upon it. Lastly, clients are associated with a site based on the subnet that the client is on. Clients should first try to contact DCs within their site.

• Domain Controllers (DCs)—are servers that provide Active Directory services to clients and users. The DC stores a complete copy of the domain's objects, along with the Active Directory schema and configuration in what are called partitions or naming contexts. Remember, the DC only stores domain partition information for the domain to which it belongs, but it stores schema and configuration partition information for the entire Active Directory. Each DC can write to Active Directory. Active Directory uses a multi-master replication model where every DC is equal. There are DCs within the Forest that play an additional role in Active Directory. Flexible Single Master of Operations (FSMO) is a role that some DCs play, which must be performed by a single DC in the domain or Forest. The Primary Domain Controller (PDC) emulator is an example of a FSMO. Each domain, when running in mixed-mode, can only have a single PDC emulator. By default, the first DC in the domain assumes this role.

• Global Catalog (GC)—a DC that also hosts a partial replica of every other domain in the Forest. That is, a GC server contains all the objects and their attributes for the domain which it is a member, in addition to all the objects for the other domains in the Forest. However, these objects from other domains in the Forest do not include all their attributes. This way, a GC server in a domain can provide basic object information about users and computers in other domains. The GC is only replicated to DCs that have been designated as GC servers.

Active Directory Operations

Now that we've reviewed the basics of what is what in Active Directory, we'll review how it works. Understanding the relationships between DCs is important when designing an Active Directory topology.

Information Is Replicated to DCs

If a change is written to Active Directory, the DC has to replicate the change to all other DCs in the domain. Also, if a new DC joins the domain, the Active Directory partitions are replicated to the new server. This might seem like a lot of replication every time a change is made to Active Directory, but the benefits of fault tolerance and end user performance are worth the added traffic. Also, remember that the domain partition is only replicated between DCs in the same domain, and that replication can be scheduled with sites.

GC Server in the Physical Structure

As mentioned earlier, the GC is a partition that is only replicated to DCs that are configured as GC servers. The location of GC servers in your organization is an important design decision because clients require access to GC servers when they log on. Universal group membership is stored in the GC. Because universal groups can deny access to resources, a user's membership to the universal groups must be discovered during logon to build the logon access token. In addition, the GC server provides clients to view objects outside their own domain.

Partitions

Partitions are physical storage containers that contain a specific type of data for Active Directory. For each Active Directory, there is a schema partition, a configuration partition, and a domain partition for each domain. The Active Directory domain partitions segment each domain's directory information. The objects in each domain partition are identified by their DN. The GC hosts all objects within the Forest but not all their attributes. The GC has the DN of each object, and therefore, it has enough information to locate a replica of the partition that holds the object.

Naming Context

The naming context, not to be confused with the namespace, represents a contiguous subtree of the directory and is a unit of replication. A partition is a naming context and is therefore replicated. In Active Directory, a single server always holds at least three naming contexts:

• Configuration —This naming context contains physical data for sites, services, and partitions.

• Domain —This naming context is the default unit of replication and contains domain directory data.

• Schema —This naming context contains the schema for the entire Active Directory.

When DCs replicate, each of these naming contexts is replicated between the appropriate DCs.

Naming Context Replication

Naming contexts replicate between DCs so that each DC has up-to-date directory information for its clients. It is important to remember, however, that not all naming contexts replicate between all DCs. Remember that the domain naming context only replicates between DCs within a domain, and the GC only replicates between GC servers.

Intra-Site Replication

Naming context replication within a site uses RPC replication (referred to as IP in the user interface). All DCs within a site replicate using RPCs and are unschedulable. The RPCs used during replication require a certain level of available network bandwidth. This means that the DCs within a site must be well connected to the network. If the available bandwidth between DCs becomes limited, the RPCs might fail causing replication failures. Hence, it is important to define a site architecture that groups DCs together on a network with adequate available network bandwidth.

Inter-Site Replication

After a domain structure is divided into sites, those sites must be connected using site link connectors. There are two transports that site link connectors can use: SMTP and RPC.

The IP (RPC) site link connector suffers from the same limitations as RPCs within a site, which is that RPCs are not reliable across unstable links. Therefore, sites with limited or unstable network connections between them should use SMTP as the transport for the site link connector. Site link connectors also use compression, which makes inter-site replication more efficient. One important caveat in choosing a protocol for your site link connector is that the domain naming context cannot be replicated between sites using the SMTP transport. Therefore, sites and domains need to be defined so that all DCs within a site have adequate available network bandwidth. A domain can still be divided up into multiple sites, for purposes of client connectivity, but those sites must use the RPC transport between sites. This means that domain boundaries have to be evaluated depending on the available bandwidth between sites.

The SMTP transport, which is asynchronous and streams data between DCs, is more stable and reliable across networks with unreliable network connections.

Security

Active Directory is a secure directory. Four security features provide a secure application that serves as the security subsystem for the Windows 2000 operating system.

• Discretionary ACL—determines the type of access an authenticated user or group of users has on an object.

• Delegation—allows administrative authority to be delegated to groups of administrators to manage a specific container or subtree.

• Access rights—can be granted or denied to authenticated users or groups of users on containers, objects, or classes of objects.

• Trust relationships—allow users in one domain to gain access to resources and information throughout the Forest. Transitive trusts are created by default between a new domain and the root domain, regardless of the location of the domain within a domain tree. A transitive trust means that the new domain trusts all other domains trusted by the root domain. Explicit trusts can be manually created between two domains. Explicit trusts can be created to improve LDAP referrals between two domains that are in different domain trees.

GC Services

The GC is a service that provides an efficient way for clients to locate objects beyond the local domain. The GC hosts a portion of each domain partition—enough for the client to locate domain objects not found in the local domain. This means that if the data contained in the GC changes, those changes must be replicated to all the GC servers in Active Directory. GC servers are DCs that not only host the domain, schema, and configure partitions, but the GC partition as well.

As previously mentioned, each client must have access to a GC server for a logon access token to be created. This means that the placement of GC servers in the organization is important. It is recommended that each site has at least one GC server. Those sites that are split between two or more physical locations might need a GC server at each physical location in case the WAN connection between the physical location fails. With a GC server at each physical location within a site, clients would still have access to it, even if a WAN connection were to fail.

Why not make all DCs GC servers? Making all DCs GC servers increases the amount of GC server replication and requires additional resources on all DCs. To reduce the amount of replication and resources required for DCs, strategically place GC servers throughout the organization so that all clients and servers have a GC server available on the LAN.

Number of Forests

If possible, you should have only one Forest. Multiple Forests are not something that you should build to accommodate a single organization. Multiple Forests limit Active Directory's functionality at the enterprise level, and this can make administration difficult.

Multiple Forests typically arise if two organizations merge or participate in a joint venture. This might be necessary if the two organizations do not trust one another or cannot agree on a change-control policy. There is one Enterprise Administration and Schema Administration group within a Forest. Both organizations must agree on a central group of users who are members of these groups. If they cannot, multiple Forests might be warranted.

To allow access between Forests, the simplest method is to create explicit one-way trusts between the domains that must trust one another. Explicit trusts are not transitive. Therefore, in a multi-tree, multi-domain Forest, the creation of explicit trusts can be complex. For this reason, it is important to keep it simple by limiting the domains that trust one another.

Number of Trees

Although multiple Forests in an organization are usually not feasible, multiple trees are. Trees provide an additional level of separation between domains that must still share resources. Multiple trees also allow multiple namespaces to coexist in a single directory.

If you have multiple trees in a Forest, each tree has its own root domain name.

In Figure 7.5, you can see that each organization can maintain their identity while still benefiting from having a unified directory service across the entire organization.

Does having multiple trees reduce replication? No, the schema, GC, and configuration partitions are replicated to all DCs in the Forest. The domain partitions are only replicated within the domain.

Does having multiple trees require explicit trusts? No, a logical transitive trust exists between root domains. This means that each domain in the Forest trusts the others.

You should only use one tree, unless you have specific reasons for multiple namespaces in your organization.

If you are planning for multiple trees in a Forest, identify the areas of the organization that are included in each namespace, confirming that every area falls into one namespace or another. After the organization has been divided up into separate namespaces, the next step is to design the domain structure of each tree.

Defining the Domain Hierarchy

In a tree, domains represent an administrative boundary, a replication boundary, a security boundary, and a namespace boundary. Domains are also a way to organize objects and apply GPOs. It is important to note, however, that OUs are also a means of object organization and GPO application. So, when should you use domains, and when should you use OUs? Well, there are some specific reasons for creating multiple domains. Such reasons include

• Administrative Model —This model might require an administrative boundary between various parts of the organization. There might be departments within an organization that require individual control over the security for that organization. Unlike two organizations that don't have a trust with each other, these departments are part of a unified organization that can decide on a change control policy and a group of administrators that have enterprise-wide permissions. By having multiple domains in an organization, you can draw distinct lines between groups and users and the permissions they have. Furthermore, if your administrative model is decentralized to the departmental or physical location level, multiple domains are a way of providing this decentralized administration.

• International Model —This model usually influences the administrative model. Traditionally, international organizations are managed and administered by a separate group of administrators from that of the North American organization. This organizational model might call for separate domains. International organizations might also have language, currency, and other localization requirements that require multiple domains.

• Network Limitations —These limitations could also be overcome using multiple domains. Make no mistake, the first means of solving network bandwidth limitations is to purchase additional bandwidth. The second means of managing bandwidth limitations is to use Active Directory sites. Remember , that whether you have one site or many, the domain partition is replicated between all the DCs in the domain. Designing an Active Directory domain topology based on available network bandwidth might diminish the return on investment for Active Directory because the design is not defined by business requirements but rather network requirements. However, if the network bandwidth between physical locations is limited, creating domain boundaries can keep the domain partitions from replicating between those physical locations. It is important to remember that the configuration, schema, and GC still replicate to all DCs in the Forest, regardless of domain boundaries despite domain and site boundaries.

• Independent OU Structures —These can be created in each domain. If different portions of an organization require different OU structures, domains provide for varying OU organization.

• Security Policies —Different policies for various parts of the organization might also require different domains. Separate password policies and group definitions are examples of security policies that might cause multiple domains.

The First Domain

The first domain in Active Directory is special. The Active Directory Forest is established with the first domain. This domain contains two Forest-wide groups, the Enterprise Administration and the Schema Administration group. The first domain, or root domain, must always exist, because these groups cannot be recreated in another domain. Hence, it is important to choose this domain wisely.

If your Active Directory has only a few domains in a single namespace, the first domain is considered a permanent domain. However, if your Active Directory has multiple namespaces, you want to make sure the domain you install first, which contains these critical groups, is one that is permanent and one in which these groups can be managed. This means that if there are different entities within one organization, each with individual namespaces, one entity will host these enterprise-wide groups.

In cases where organizations support more than one namespace in Active Directory, it might be prudent to create an empty root domain. As seen in Figure 7.6, the root domain would not be part of an entity's namespace; membership and management of the root domain could be done at the enterprise level, and the replication of this domain to DCs spread across the enterprise would then be possible because of its limited number of objects.

Defining the OU Hierarchy

For many, the OU design is where the rubber meets the road. OUs are object containers that host Active Directory objects. Administrative tasks can be delegated to various groups of administrators based on OUs. Furthermore, group policies can be applied to OUs.

What this means is that a compromise between administrative requirements and group policy requirements might need to be struck. If delegation of the administration of computers, users, printers, groups, and other resources is a paramount requirement, steer your OU design toward meeting your administrative requirements. On the other hand, if your group policy delegation requirements are paramount, steer your OU design toward an OU structure that best meets your group policy delegation requirements.

As previously mentioned, each domain can have its own OU structure. This does not mean that they must be different. For ease in administration, it might be wise to make them the same, but it is possible to vary which set of requirements is satisfied in the same way that they vary across your organization.

Some tips for designing your OU structure are

• Layout your administrative and group policy requirements, and decide which leads the way in designing your OU structure.

• Review your administrative model, mapping the requirements of the administrative model to the OU structure, where appropriate.

• Create multiple OU structures that can be tested in the lab. Create some that satisfy all the requirements of your administrative model, others that satisfy all requirements of your group policy strategy, and still others that compromise between administrative and group policy requirements. Take these OU structures into the lab, test them out, and see for yourself how they work and whether they provide the level of functionality you need.

• Choose OU names relevant to your organization. In addition, it is important to remember that users are able to see the OU structure if they browse the directory. Microsoft believes that the searching mechanism built into Windows 2000 clients is used to locate objects more than to browse; however, it is important to remember that LDAP is not the only method of accessing the directory.

OUs can be nested within other OUs. If an OU is nested, it inherits the properties of the parent OU by default. It is best to limit the number of OU levels. Many levels of OUs might increase the administrative burden and confuse both administrators and users. Another reasons for limiting the level of OUs is performance. When a user logs on, the policies that user is subjected to have to be built by interrogating the OU hierarchy. Therefore, the number of OU levels and the number of policies a user is subjected to might impact logon performance.

Top Level OU

It might be that you only have one level of OUs, which is simple and easy to manage. However, if you are going to nest OUs, choose names for your top level OUs that are general and static in nature. This minimizes the need to have to rename these OUs because of reorganizations within your organization.

Lower Level OUs

The remaining OU levels should have distinct purposes, and they should have been created for the sake of creating multiple levels of OUs. Some considerations when creating multiple levels of OUs include

• How do you delegate administrative responsibility? Based on departments, administrative function, or types of administration?

• Does the parent OU host objects that can be divided into child OUs? For example, if you create an OU for your engineers, are there different types of engineers that could be further segregated into child OUs? Say you have civil engineers, mechanical engineers, and apprentice engineers. If each type of engineer requires a different group policy or if each is administered by different administrative groups, segregating the engineering OU into child OUs, one for each type of engineer, might make sense.

• Remember that group policies can also be applied to domains. If you have a GPO that you want to apply to everyone in the domain, apply the GPO to the domain rather than one or all OUs.

• Remember that group policies can also be applied to sites. If you have defined each physical location as a site and have a group policy that you want to vary based on physical location, apply that GPO to the site rather than creating an OU for each physical location.

• Remember that OUs inherit the group policies of their parent OU by default. This means that a hierarchy of OUs, built to satisfy group policy requirements, should have the most global group policies applied near the top of the hierarchy. This way a group policy that is meant for all engineers would be applied on the engineers' OU, and group policies meant for civil engineers only would be applied to the civil engineers' OU only. Therefore, civil engineers would have both the engineers' and civil engineers' group policy applied to them when they logged on.

The Administrative Delegation Model

An example of an OU hierarchy that primarily satisfies administrative delegation requirements has two levels of OUs. The first level categorizes resources in the organizations. As new types of resources are added to the directory, new OUs can be added to this top-level hierarchy. The second level of OUs is based on geographic location, as seen in Figure 7.7.

With this OU structure, it is possible to grant the centralized IS group permissions on the top level OUs while granting local IS groups limited permissions on the objects in their respective OUs. Because permissions are inherited down the OU hierarchy, the centralized IS group's permissions located on the top level OUs are inherited down to each location's OU, as seen in Figure 7.8.

It would also be possible to swap these OU levels. The OU structure in Figure 7.8 is less centralized than in Figure 7.7. With this OU structure, each local IS group has permissions on their own OU. It is then possible to grant administrative permissions on specific second-level OUs to specific groups within each local IS group. For example, the Seattle IS group could have a group of administrators that can only reset passwords for users in the users OU.

The Group Policy Model

An example of an OU hierarchy that primarily satisfies the group policy application requirements is one that again has two levels of OUs, as seen in Figure 7.9. The first level categorizes objects by departments. The second level categorizes objects by roles within each department.

With this structure, objects in each department can have GPOs applied that provide applications or enforce policy based on department. Policies can be further applied based on job function in the second tier of OUs. All users might have a core set of applications they have permissions to run. This group policy would be set at the domain level. Then, because additional applications are necessary, those applications could be added to GPOs on specific OUs. Engineers have application requirements beyond the core applications. These applications would be added to a GPO on the engineers' OU. Structural engineers might have application requirements that could be added to a GPO on the structural engineers' OU. By locking down the workstation and providing applications to users based on the OU they are in, an organization decreases maintenance and increases user efficiency.

This model could also be applied with a geographic level of OUs, as seen in Figure 7.10.

This would support a decentralized administrative model while still allowing Group Policy Objects to be applied at the department model. This model might be stretching the limits of complexity that you want to design in an OU model. However, as with any design, you would want to take this design and others into the lab and test for functionality and performance.

It is also important to note that sites can have GPOs applied to them. Therefore, if site lines were drawn around geographic locations, it might not be necessary to create an OU level dedicated to geographic location. Rather, geographic group policies could be applied to each geographic location's site.

Physical Sites and the Network Affect Domain Structure

When designing your domain and OU model, you must also define sites. The best way to design a site structure is discussed in Chapter 10, "The Physical Topology: Sites and Replication," but it is an important component to the domain structure. Sites are a physical representation of the domain structure. They mitigate domain replication traffic within a domain and the preferred DCs for clients within the same site. The domain and OU hierarchy should not be affected by the site design, but the site design should consider the domain hierarchy.

Defining DCs and GC Servers

Another important part of the site design is the location of DCs, GC servers, and domain name servers. A client must have access to each of these services to logon. Therefore, at least one (and probably two) of each of these services should be available to clients in each location. To eliminate WAN outages as a potential point of failure, it might be prudent to locate these services at each physical location.

Namespace in Domain Structure

The namespace is represented in the domain structure. Top-level domain names, especially if there are multiple domain names being used in an organization, affect the domain design. However, if an organization has a single domain name and the domain design calls for multiple Active Directory domains, the namespaces are built below the top-level domain.