Proper design of a Windows Server 2003 Active Directory structure is a critical component in the successful deployment of the technology. Mistakes made in the design portion of Active Directory can prove to be costly and difficult to correct. Many assumptions about basic Active Directory domain and functional structure have been made, and many of them have been incorrect or based on erroneous information. Solid understanding of these components is vital, however, and anyone looking at Windows Server 2003 should keep this point in mind.
Active Directory was specifically designed to be scalable. This means that theoretically organizations of every shape and size should be able to implement the technology. For obvious reasons, this means that the structure of the Active Directory forest will vary from organization to organization.
In Windows Server 2003’s Active Directory implementation, cross-forest trust capability has been added. This allows for the design of so-called federated forests, a new concept in Windows Server 2003. Federated forests are basically multiple forests with separate schemas and separate administrative teams joined via cross-forest transitive trusts. This allows for greater scalability and enables administrators to completely separate security boundaries within an organization.
In addition, several design decisions that were previously irreversible in Windows 2000, such as forest name and relative domain structure, have been updated to allow changes to take place. Now, an Active Directory domain structure can be renamed in the event of a merger or acquisition. The psychological factor alone of having to make a decision and not being able to change it has kept some organizations away from deploying Active Directory in the past. Now that those barriers have been removed, more organizations will be able to deploy Active Directory without fear of being painted into a corner later, so to speak.
This chapter focuses on best practices for Active Directory design, including a discussion of the specific elements that comprise Active Directory. Various domain design models for Active Directory are presented and identified with specific real-world scenarios. The domain rename procedure is outlined as well, to provide for an understanding of how the concept affects domain design decisions. In addition, step-by-step instructions are presented for several aspects of Windows Server 2003 domain design that have significantly changed since Windows 2000.
Before any domain design decisions can be made, it is important to have a good grasp of Active Directory’s domain structure and functionality. Windows 2000 administrators will recognize many of the key components, but some fairly major changes have been made in Windows Server 2003 that require a reintroduction to the domain design process. In addition, real-world experience with AD domain design has changed some of the assumptions that were made previously.
Windows Server 2003’s Active Directory domains can be linked to each other through the use of a concept known as trusts. A trust is essentially a mechanism that allows resources in one domain to be accessible by authenticated users from another domain. As many administers will recall, domain trusts in NT 4.0 were one way, and not transitive. In other words, any resource sharing between multiple domains required numerous multiple-trust relationships. Trusts in Active Directory take a different approach than this “connect everything with trusts” approach. In Windows Server 2003’s Active Directory, trusts are more powerful and simplistic at the same time. AD trusts take on many forms but typically fall into one of the four categories described in the following sections.
Transitive trusts are automatic two-way trusts that exist between domains in Active Directory. These trusts connect resources between domains in Active Directory and are different from Windows NT trusts in that the trusts flow through from one domain to the other. In other words, if Domain A trusts Domain B, and Domain B trusts Domain C, Domain A trusts Domain C. This flow greatly simplifies the trust relationships between Windows domains because it forgoes the need for multiple exponential trusts between each domain.
An explicit trust is one that is set up manually between domains to provide for a specific path for authentication sharing between domains. This type of trust relationship can be one way or two way, depending on the needs of the environment. In other words, all trusts in NT 4.0 could have been defined as explicit trusts because they all are manually created and do not allow permissions to flow in the same way as transitive trusts do. The use of explicit trusts in Active Directory allows designers to have more flexibility and to be able to establish trusts with external and down-level domains. All trusts between Active Directory domains and NT domains are explicit trusts.
A shortcut trust is essentially an explicit trust that creates a shortcut between any two domains in a domain structure. For example, if a domain tree has multiple subdomains that are many layers deep, a shortcut trust can exist between two domains deep within the tree, similar to the shortcut trust shown in Figure 5.1. This relationship allows for increased connectivity between those two domains and decreases the number of hops required for authentication requests. Normally, those requests would have to travel up the transitive trust tree and back down again, thus increasing overhead.
The example in Figure 5.1 shows how a shortcut trust could theoretically be used to reduce the overhead involved in sharing resources between the two sales subdomains in the companyabc.com tree. You can find more information on these trusts in the individual design model sections later in this chapter.
Cross-forest transitive trusts are essentially two-way transitive trusts that exist between two disparate Active Directory forests. While explicit trusts between separate AD domains in separate forests were possible in Windows 2000, the cross-forest trusts in Windows Server 2003 allow for two-way transitive trusts to exist between two separate forests. More information can be found about this new variety of trust later in this chapter.
The first step in the actual design of the Active Directory structure is the decision on a common domain name system (DNS) namespace that Active Directory will occupy. Active Directory revolves around, and is inseparable from, DNS, and this decision is one of the most important ones to make. The namespace chosen can be as straightforward as microsoft.com, for example, or it can be more complex. Multiple factors must be considered, however, before this decision can be made. Is it better to register an AD namespace on the Internet and potentially expose it to intruders, or is it better to choose an unregistered internal namespace? Is it necessary to tie in multiple namespaces into the same forest? These and other questions must be answered before the design process can proceed.
The simplest method of implementing an Active Directory structure is through the use of a single, common DNS namespace that reflects the company’s name and is registered on the Internet. Microsoft.com is an obvious example, and a myriad of other possibilities exist as well. Several advantages to a published namespace are that it is readily accessible from the Internet and there is less confusion on the end user’s part in regards to the location on the network and on the Internet. For example, a user named Peter Pham working for the CompanyABC Corporation will be represented in the network through its user principal name (UPN) as [email protected]. This name can be set up to exactly match his email address, limiting confusion for the end user.
The limitations to this type of namespace strategy are primarily security based. Publishing your Active Directory namespace leaves potential hackers with the name of your domain system and part of what is needed to compromise user accounts. Administering your firewall to block internal DNS queries also becomes less intuitive when the namespace is the same as the published Internet namespace for the organization. If the namespaces were separate, for example, a simple rule could be written to block any traffic to the internal domain structure. Another limitation would arise if an organization currently employs multiple namespaces to identify itself, and all those namespaces need to be joined into the same forest; in this case, a common namespace design is not an option. Mergers and acquisitions or even multiple business units within the same corporate parent can present these types of problems.
If desired or required by your organization, the namespace that the Active Directory structure inhabits can be internal, or not published to the Internet. Using internal namespaces adds a layer of complexity to your network because users’ UPNs are different from their email addresses. However, the increase in security that is realized from this design is also a factor that leads organizations to choose this route. Another factor that may influence your decision to choose an Internet namespace is that you are no longer limited to the Internic standard namespaces of .com, .net, .biz, .info, and so on. For example, many organizations use the .internal namespace, or some other namespace that is not used on the Internet.
Keep in mind that it is important to secure an internal namespace from registration anywhere on the Internet other than in your own network. In other words, if an organization registers internalnetwork.net, and another organization on the Internet registers the same domain name for its network, there could be naming conflicts with applications and other systems that perform DNS lookups against your forest. For example, if an application on a laptop usually attempts to access an internal namespace but then tries to access it remotely through an ISP, the ISP’s DNS will forward you to the registered DNS name on the Internet. In a nutshell, if you are going to design your domain with an unpublished namespace but use a standard such as .net or .org that someone else could theoretically register, it is best to register and reserve that domain but not point it anywhere. Another common tactic is to name your domain something that will never be published, such as a root with your company’s stock ticker symbol (for example, network.msft), or by utilizing the .internal suffix, which has been specifically reserved for internal use only.
Many administrators have already become accustomed to Active Directory design and are familiar with the basic layout and characteristics of the Active Directory structure in Windows 2000. Windows Server 2003 introduces some dramatic changes to Active Directory, which changes some fundamental components of Active Directory and allows for greater flexibility in domain design. Among these changes are the following:
Domain rename function—. The capability to rename a domain in a Windows Server 2003 forest has opened up a new field of possibilities for the design and potential redesign of Active Directory domain structures. Previously, stern caveats were issued about the inability to rename domains or change the overall structure of an Active Directory forest. With the domain rename functionality present in Windows Server 2003’s Active Directory implementation, these limitations are lifted, and designers can take heart in the fact that design changes can be made after implementation. Having this ability does not change the fact that it is still wise to plan out your domain design thoroughly, however. Not having to make changes to domain names or reposition domains in a forest is much easier than having to go through the domain rename process. Just knowing that such functionality exists, however, is a breath of fresh air for designers.
Cross-forest transitive trusts—. New in Windows Server 2003, the concept of cross-forest transitive trusts lessens domain designers’ connectivity worries. In the past, some administrators balked at the limitations of collaboration within Windows 2000 Active Directory structures. The cross-forest transitive trust capability of Active Directory negates those concerns because multiple Active Directory forests can now be joined via cross-forest trusts that are transitive, rather than explicit, in nature. The combination of these forests is known in the Microsoft world as federated forests.
Domain controller promotion from media—. The capability to promote remote servers to domain controllers via a CD image of the global catalog helps to limit replication traffic and the time associated with establishing remote domain controllers. There have been some recorded instances of DC promotions taking several days, and even up to a week, to replicate the initial global catalog information in Windows 2000. Windows Server 2003 solves this issue by providing you with the ability to save the global catalog to media (like a CD-ROM), ship it to a remote site, and finally run domain controller promotion (
dcpromo) and insert the data disk with the directory on it for restoration. Only the delta, or changes made since media creation, are then replicated, saving time and bandwidth. The effect of this on domain design creation is reflected in reduced setup times and increased flexibility of global catalog domain controller placement.Administrative enhancements—. New “headless” management functionality reduces the need to have local administrators present at each site. Essentially, Terminal Services Remote Administration has been built into all Windows Server 2003 installs, facilitating remote administration. Terminal Services users will note how easy it is to take control of remote machines and administer them as if they were at the keyboard. No more driving 300 miles to your Death Valley branch office to reboot a server. Because all domain controllers, member servers, application servers, and so on will have Terminal Services capability, designers will have more flexibility in arranging server layout.
There is a basic tenet to consider when designing the Active Directory domain structure. Start simple, and then expand only if expansion is necessary to address a specific need. This concept is, by and large, the most important concept to remember when you’re designing Active Directory components. In regard to domain design, this means you should always start the design process with a single domain and then add on to your design if your organizational concerns dictate that you do so. Following this basic philosophy during the design process will reduce headaches down the road.
When you’re designing the Active Directory, you must contemplate a common framework for diagrams. In Active Directory, for example, domains are often pictorially represented by triangles, as shown in Figure 5.2. So, when beginning your design, start with a single triangle.
In this example, the fictional company named CompanyABC has begun the process of domain design. Depending on its unique needs, CompanyABC may decide to expand upon that model or keep it simplistic. These decisions should be made with a detailed knowledge of the different domain design models and the environments in which they work best.
Active Directory was designed to be a flexible, forgiving directory services implementation. This is even more true with Windows Server 2003’s Active Directory implementation. Consequently, there are multiple design models available to choose from, depending on the individual needs of organizations. The major design models are as follows:
In reality, not all AD structures fall underneath these categories because the possibilities exist for numerous variations and mutations of AD structure. However, most domain structures either fall into these categories or are a hybrid model, possessing traits of two different models. Out of all these models, however, the single domain model is the most common design model and also happens to be the easiest to deploy.
The most basic of all Active Directory structures is the single domain model; this type of domain structure comes with one major advantage over the other models: simplicity. A single security boundary defines the borders of the domain, and all objects are located within that boundary. The establishment of trust relationships between other domains is not necessary, and implementation of technologies such as Group Policies is made easier by the simple structure. Many organizations that have lived with a multiple domain NT structure may think that they cannot consolidate on a single domain model. However, more organizations than not can take advantage of this design because Active Directory has been simplified and its capability to span multiple physical boundaries has been enhanced.
The single domain model is ideal for many organizations and can be modified to fit many more. A single domain structure possesses multiple advantages, first and foremost being simplicity. As any administrator or engineer who has done work in the trenches can confirm, often the simplest design works the best. Adding unnecessary complexity to systems’ architecture introduces potential risk and makes troubleshooting these systems more difficult. Consequently, consolidating complex domain structures such as NT 4.0 into a simpler single domain Active Directory structure can reduce the costs of administration and minimize headaches in the process.
Another advantage realized by the creation of a single domain is the attainment of centralized administration. Many organizations with a strong central IT structure want the capability to consolidate control over the entire IT and user structure. NT domains were notoriously lacking in their capability to scale to these levels, and the types of central control that organizations wanted were not available. Active Directory and, specifically, the single domain model allows for a high level of administrative control and the ability to delegate tasks to lower sets of administrators. This has proven to be a strong draw to Active Directory.
Not all Active Directory structures can be composed of a single domain, however, and some factors may limit an organization’s ability to adopt a single domain structure. If these factors affect your organization, you might need to begin expanding your domain model to include other domains in the forest and a different domain design. For example, the single security boundary formed by a single domain may not be exactly what your organization needs. Although OUs can be used to delegate administration of security elements, the domain itself is the security boundary in Active Directory structures. If the security lines within your organization need to follow exact boundaries, a single domain may not be for you. For example, if your HR department requires that no users from IT have access to resources within its environment, you will need to expand your domain structure to accommodate the additional security concerns.
Another disadvantage of the single domain model is that a single domain in a forest necessitates that the computer with the role of schema master is located in that domain. This places the schema master within the domain that contains all the user accounts. Although access to the schema master can be strictly controlled through proper administration, your risk of schema exposure is greater when the schema master role resides in a user domain. For example, members of the domain administrators group could override the security of the schema administrators group and add their account to that group. If this design model poses problems for you as an organization, design models that separate the schema master into a placeholder domain can do the trick. The placeholder domain model is described in more detail later in this chapter.
To illustrate a good example of an organization that would logically choose a single domain model, let’s consider fictional Company A. Company A is a 500-user organization with a central office located in Minneapolis. A few smaller branch offices are scattered throughout the Midwest, but all help desk administration is centralized at the company headquarters. Company A currently utilizes a single NT user domain and has multiple resource domains in various locations across the country.
The IT team in Minneapolis is designing an Active Directory structure and wants to centralize administration at corporate headquarters. Branch offices should have the capability to change passwords and clear print jobs locally, but should have no other form of administrative privilege on the network.
During the Active Directory design process, Company A started with a single Active Directory forest, domain, and namespace named companya.net. Organizational units for each branch office were added to delegate password-change control and print administration to those offices.
Current NT 4.0 domains were consolidated into the Active Directory structure, as shown in Figure 5.3. Company A could not justify the existence of additional domains because their security model was centralized, and it did not have any far-flung geographical locations with slow link speeds to the main office or any other similar constraints that required additional domains.
Delegation of password-change control and other local administrative functions was granted to individuals in each specific geographical OU, which gave those administrators permissions specific to only resources within their own group but maintained central administrative control in Minneapolis. A detailed discussion of organizational unit design is covered in Chapter 6, “Designing Organizational Unit and Group Structure.”
Several Active Directory sites were created to control the frequency of replication. A site was positioned to correspond with each separate geographical area, creating a site structure similar to the one shown in Figure 5.4.
Creating the separate sites helped to throttle replication traffic and reduce the load placed on the WAN links between the sites. For more details about site links and replication, see Chapter 7, “Active Directory Infrastructure.”
This type of single domain design is ideal for the type of organization described in this section and actually can be used for many other types of organizations, large and small. Because delegation of administration is now accomplished through the use of OUs and Group Policy objects, and the throttling of replication is accomplished through AD sites, the number of reasons for organizations to use multiple domains has been reduced.
For various reasons, organizations may need to add more than one domain to their environment but preserve the functionality that is inherent in a single forest. When this occurs, the addition of one or multiple domains into the forest is warranted. Domain addition should not be taken lightly, however, and proper consideration must be given to the particular characteristics of multiple domain models.
By default, two-way transitive trusts exist between subdomains and domains in Active Directory. Bear in mind, however, that this does not mean that resource access is automatically granted to members of other domains. A user in subdomain B is not automatically granted any rights in domain A; the rights need to be explicitly defined through the use of groups. Understanding this concept will help to determine the logistics of domain addition.
As previously mentioned, it is advisable to begin your Windows Server 2003 Active Directory design with a single domain and then add domains only when absolutely necessary. Adding child domains to an existing domain structure may become necessary if the following traits exist within an infrastructure:
Decentralized administration—. If different branches of an organization generally manage their own IT structure and there are no future plans to consolidate them into a centralized model, multiple interconnected domains may be ideal. Each domain acts as a security boundary for most types of activity and can be set up to disallow administration from escaping the boundaries of domains. This approach operates in much the same way as NT domains and inherits many of the limitations associated with them as well. In other words, it is better to try to centralize administration before deploying Active Directory because you will gain more of AD’s advantages.
Geographic limitations—. If extremely slow or unreliable links or great geographical distances separate different parts of your company, it may be wise to segment the user population into separate domains. This will help to limit replication activity between domains and also make it easier to provide worktime support for distant time zones. Keep in mind that slow links by themselves do not necessitate the creation of multiple domains, as Windows Server 2003 Active Directory uses the concept of Active Directory sites to throttle replication across slow links. The main reason that might exist for domain creation for geographical reasons is administrative flexibility. In other words, if there is a problem with the network in Japan, a Japanese administrator will have more power to administer the Asia domain and will not need to call the North American administrator in the middle of the night.
Unique DNS namespace considerations—. If two organizational entities want to use their Internet-registered namespace for Active Directory but use a common forest, such as
hotmail.comormicrosoft.com, those domains must be added as separate domains. This type of domain model is described more fully in the section “Multiple Trees in a Single Forest Model” later in this chapter.Special password policies—. Because password policies are set on a domain level, if any specific password policies must be set differently between domains, separate domains must be set up to segregate those policies. This is rarely a real-life design issue that by itself creates a new domain, but knowledge of this limitation will help in the design process.
Enhanced security concerns—. Depending on the needs of your organization, separating the schema master role into a domain separate from your users may be applicable. In this case, the single domain model would not be applicable, and a model such as the peer-root or placeholder domain would be more appropriate.
When contemplating additional domains, remember the mantra “Simplicity is best.” However, if during the design process, the specific need arises to add domains, proper design is still warranted, or your environment will run the risk of looking like the type of messed-up NT domain structure that’s best avoided.
The following example illustrates an organization that would have grounds to establish multiple domains. Company B is an engineering company based in York, Pennsylvania. Administration for all branch locations is currently centralized in the home office, and OUs and Group Policies are used for delegation of lower-level tasks. Recently, the company acquired two separate companies named Subsidiary A and Subsidiary B; each contains its own IT department and operates in separate geographical areas. Company B decided to implement Active Directory as part of a Windows Server 2003 implementation and wanted to include the two acquired companies into a single common forest.
Because each acquired company possesses its own IT department and there are no immediate plans to consolidate those functions centrally, Company B decided to deploy an Active Directory structure with two subdomains for Subsidiary A and Subsidiary B, as shown in Figure 5.5.
This design model allowed for a certain degree of administrative freedom with the newly acquired subsidiaries but also allowed for a common forest and schema to be used and kept the domains within the same DNS namespace.
This design model has the particular advantage of being politically easier to implement than consolidation of existing domains. Branch offices and subsidiary companies can keep their own domain structure and security boundaries, and their IT teams can retain a greater deal of administrative autonomy.
Be warned, however, that consolidation of NT domains into fewer domains is a key feature of Active Directory, so the addition of domains purely for political reasons adds complexity and potentially unnecessary infrastructure. It is therefore very important to consider the alternatives before deciding on this design model.
Let’s say that your organization would like to look at Active Directory and wants to use an external namespace for your design. However, your environment currently uses multiple DNS namespaces and needs to integrate them into the same design. Contrary to popular misconception, integration of these namespaces into a single AD forest can be done through the use of multiple trees that exist in one forest. One of the most misunderstood characteristics of Active Directory is the difference between a contiguous forest and a contiguous DNS namespace. Many people do not realize that multiple DNS namespaces can be integrated into a single Active Directory forest as separate trees in the forest. For example, Figure 5.6 shows how Microsoft could theoretically organize several Active Directory domains that share the same forest but reside in different DNS namespaces.
Only one domain in this design is the forest root, in this case microsoft.com, and only this domain controls access to the forest schema. All other domains, including subdomains of microsoft.com and the other domains that occupy different DNS structures, are members of the same forest. All trust relationships between the domains are transitive, and trusts flow from one domain to another.
If an organization currently operates multiple units under separate DNS namespaces, one option may be to consider a design such as this one. It is important to understand, however, that simply using multiple DNS namespaces does not automatically qualify you as a candidate for this domain design. For example, you could own five separate DNS namespaces and instead decide to create an Active Directory structure based on a new namespace that is contiguous throughout your organization. Consolidating your Active Directory under this single domain could simplify the logical structure of your environment while keeping your DNS namespaces separate from Active Directory.
If your organization makes extensive use of its separate namespaces, you may want to consider a design like this. Each domain tree in the forest can then maintain a certain degree of autonomy, both perceived and real. Often, this type of design will seek to satisfy even the most paranoid of branch office administrators who demand complete control over their entire IT structure.
To gain a greater understanding of the times an organization might use this particular design model, examine the following AD structure. City A is a local county governmental organization with a loose-knit network of semi-independent city offices such as the police and fire departments that are spread out around the city. Each department currently uses a DNS namespace for name resolution to all hosts and user accounts local to itself, which provides different email addresses for users located in the fire department, police department, and other branches. The following namespaces are used within the city’s infrastructure:
citya.orgfiredeptcitya.orgpoliceofcitya.orgcityalibrary.org
The decision was made to merge the existing network environments into a single Active Directory forest that will accommodate the existing departmental namespaces but maintain a common schema and forest root. To accomplish this, Active Directory was established with citya.org as the namespace for the root domain. The additional domains were added to the forest as separate trees but with a shared schema, as shown in Figure 5.7.
The individual departments were able to maintain control over their individual security and are disallowed from making changes in domains outside their control. The common forest schema and global catalog helped to increase collaboration between the varying organizations and allow for a certain amount of central administration.
This type of domain design is logically a bit messier but technically carries the same functionality as any other single forest design model. All the domains are set up with two-way transitive trusts to the root domain and share a common schema and global catalog. The difference lies in the fact that they all utilize separate DNS namespaces, a fact that must also be reflected in the zones that exist in DNS.
A new feature of Windows Server 2003’s Active Directory implementation is the addition of cross-forest transitive trusts. In essence, this allows you to establish transitive trusts between two forests with completely separate schemas that allow users between the forests to share information and to authenticate users.
The capability to perform cross-forest trusts and synchronization is not automatic, however, because the forest functionality of each forest must be brought up to Windows Server 2003 functionality levels. What this means is that all domain controllers in each forest must first be upgraded to Windows Server 2003 before any cross-forest trusts can be established. This can prove to be a difficult prospect for organizations already deployed with Windows 2000. Consequently, the federated forest design model is easier to consider if you do not currently have an Active Directory structure in place.
The federated forest design model is ideal for two different situations. One is to unite two disparate Active Directory structures in situations that arise from corporate acquisitions, mergers, and other forms of organizational restructuring. In these cases, two AD forests need to be linked to exchange information. For example, a corporate merger between two large organizations with fully populated Active Directory forests could take advantage of this capability and link their two environments, as shown in Figure 5.8, without the need for complex domain migration tools.
In this example, users in both forests now can access information in each other’s forests through the two-way cross-forest trust set up between each forest’s root.
Note
Windows Server 2003 R2 introduced the concept of Active Directory Federation Services (ADFS), which effectively makes it easier to administer and provision users in disparate forests. More information on ADFS can be found in Chapter 8, “Integrating Active Directory with Novell, Oracle, Unix, and NT4 Directories.”
The second type of scenario in which this form of forest design could be chosen is one in which absolute security and ownership of IT structure are required by different divisions or subsidiaries within an organization, but exchange of information is also required. For example, an aeronautics organization could set up two AD forests, one for the civilian branch of its operations and one for the military branch. This would effectively segregate the two environments, giving each department complete control over its environment. A one- or two-way cross-forest trust could then be set up to exchange and synchronize information between the two forests to facilitate communication exchange.
This type of design is sometimes precipitated by a need for the complete isolation of security between different branches of an organization. Since the release of Active Directory in Windows 2000, several inter-domain security vulnerabilities have been uncovered that effectively set the true security boundary at the forest level. One in particular takes advantage of the SIDHistory attribute to allow a domain administrator in a trusted domain in the forest to mimic and effectively seize the schema admin or enterprise admin roles. With these vulnerabilities in mind, some organizations may choose separate forests, and simply set up trusts between the forests that are specifically designed to strip off the SIDHistory of a user.
In Figure 5.9, a one-way cross-forest transitive trust with SIDHistory-filtering enabled was set up between the civilian branch and the military branch of the sample aeronautics organization. In this example, this setup would allow only accounts from the military branch to be trusted in the civilian branch, in essence giving the military branch users the ability to access files in both forests. As with NT domains, cross-forest trusts are one-way by default. Unlike NT trusts, however, cross-forest trusts in Windows Server 2003 can be transitive if both forests are running at Windows Server 2003 functional levels. To set up two-way transitive trusts, you must establish two one-way trusts between the two forest roots.
The concept of federated forests greatly enhances the abilities of Active Directory forests to exchange information with other environments. In addition, organizations that were reluctant to implement AD because of the lack of a solid security boundary between domains can now take heart in the capability of the federated forest design to allow specific departments or areas to have complete control over their own forests, while allowing for the transfer of information between the domains.
To illustrate a good example of an organization that would choose a federated forest design model, let’s consider fictional Conglomerate A, which is a food distributor with multiple sites worldwide. It currently operates a Windows Server 2003 Active Directory implementation across its entire organization. All computers are members of the forest with a namespace of companyb.net. A root domain exists for conglomeratea.net, but it is not populated because all users exist in one of three subdomains: asia, europe, and na.
Conglomerate A has recently entered into a joint venture with Supplier A and would like to facilitate the sharing of information between the two companies. Supplier A also currently operates in a Windows Server 2003 Active Directory environment and keeps all user and computer accounts in an Active Directory forest that is composed of two domains in the suppliera.com namespace and a separate tree with a DNS namespace of supplierabranch.org that reflects a certain function of one of its branches.
The decision was made to create a cross-forest trust between the two forests so that credentials from one forest are trusted by the other forest and information can be exchanged. The cross-forest trust was put into place between the root domains in each forest, as shown in Figure 5.10.
Remember, that just as in NT 4.0, a trust does not automatically grant any permissions in other domains or forests; it simply allows for resources to be implicitly shared. Administrators from the trusting domain still need to manually grant access. In our example, administrators in both forests can decide what resources will be shared and can configure their environment as such.
The schema is the most critical component of Active Directory and should therefore be protected and guarded closely. Unauthorized access to the schema master domain controller for a forest can cause some serious problems and is probably the best way to corrupt the entire directory. Needless to say, segregation of the keys to the schema from the user base is a wise option to consider. From this concept was born the peer-root domain model, shown in Figure 5.11.
In short, the peer-root domain model makes use of an unpopulated forest root domain that exists solely to segregate the schema master function from the rest of the network.
In Figure 5.11, the companyabc.com domain is used for all user and computer accounts, whereas the abcschema.root domain is the peer-root domain that holds the schema master role for the company. Most users would not even be aware of the fact that this domain exists, which makes it even more secure.
The one major disadvantage to this design model lies in the hardware costs. Because a separate domain is necessary, at least one extra domain controller will be needed as part of the design plan, and preferably two for redundancy issues. This domain controller for the peer-root domain will not need to be the speediest machine because it will not perform much work, but it should definitely be made redundant, because the forest-specific FSMO roles will be handled by the machine.
Security needs vary from organization to organization. A company that performs topsecret work for the military is going to have drastically different security issues than a company that manufactures rubber duckies. Consequently, if the needs of your organization require a greater amount of security, the peer-root domain model may be the right one for you.
An additional advantage that this type of environment gives you is the flexibility to rename domains, add domains, and essentially move in and out of subdomains without the need to rename the forest. Although the domain rename tool exists in Windows Server 2003, undertaking this task is still complicated, and using the peer-root model can help to simplify changes. In a merger, for example, if your peer root is named root.network and all your resource domains are located in companyabc.com in the same forest, it becomes much easier to add companya.net into your forest by joining it to the root.network domain.
The beauty of the peer-root domain model is that it can be incorporated into any one of the previously defined domain models. For example, a large grouping of trees with published namespaces can have a forest root with any name desired.
The example shown in Figure 5.12 demonstrates how this type of environment could conceivably be configured. The flexibility of Active Directory is not limited by this design model because the options available for multiple configurations still exist.
Of course, many organizations often cannot justify the increased hardware costs, and this type of design model can prove to be more costly. Realistically, two domain controllers need to be established in the root domain to handle authentication requests and to provide for redundancy within the domain. Keeping these costs in mind, it is important to align your organization’s security requirements with the cost-benefit ratio of this design model.
Company D is a biomedical corporation centered in the San Francisco Bay area. Infrastructure security is highly important for the organization, and the company needs to ensure that directory information is safe and secure in the network environment. The IT organization is centralized, and most employees are located at the main headquarters building.
The administrators of Company D originally chose Active Directory and Windows Server 2003 to provide for robust security for their environment and to take advantage of the increased functionality. However, management was concerned about limiting access to vital components of the directory service such as the schema. Further investigation into the varying domain design models for Active Directory uncovered the peer-root domain model as a fully functional substitute to the single domain model, but with the added schema security that they desired. This resulted in a forest structure similar to the one shown in Figure 5.13.
Organizational units were created for each department and placed in the companyd.com domain. The only user account in the rootd.peer domain is the Administrator account for the forest. Access to this account was limited to a choice group of high-level administrators. This helped to control access to the schema root for the security-conscious organization and provided for the simplicity of a single domain environment for its users.
The placeholder domain model, also known as the sterile parent domain model, deserves special mention because of its combination of a single namespace/multiple domain model and the peer-root model. Simply put, the placeholder domain model, shown in Figure 5.14, is composed of an unoccupied domain as the forest root, with multiple subdomains populated with user accounts and other objects.
There are two distinct advantages to this design. First, as with the peer-root model, the schema is separate from the user domains, thus limiting their exposure and helping to protect the schema. Second, the namespace for the user accounts is consistent in the namespace, thus mitigating any potential political issues. In other words, because all users in all locations are at the same logical level in the domain structure, no one group will feel superior or inferior to another. This issue may seem trite, but the psychological nature of humans is finicky, and you may find that this design offers advantages for certain organizations.
Company E is an architectural firm with major offices located in New York, Chicago, Los Angeles, Sao Paulo, Rio de Janeiro, Berlin, Paris, London, Tokyo, Singapore, and Hong Kong. Administration is centralized in New York, but regional administration takes place in Rio de Janeiro, London, and Tokyo. The company has recently migrated to Active Directory and has chosen to deploy a placeholder domain model for its organization that looks similar to Figure 5.15.
All users authenticate to geographically centric subdomains. In addition, the administrators in New York have segregated the schema master function into the placeholder domain, limiting its exposure and have limited access to this domain to a small group of high-level administrators. Each domain is logically oriented as well, to give the impression of autonomy to each geographical unit.
A special-purpose domain or forest is one that is set up to serve a specific need. For example, your organization may set up a special-purpose domain to house outside contractors or temporary workers to limit their exposure to the main Active Directory forest. In addition, trust relationships could be established between this domain or domains to allow for resource access.
Generally, there has to be a good reason before additional domains are deployed in Active Directory. Overhead is increased with each domain that is added to an environment, and your logical network structure begins to look convoluted. However, in some unique cases, a special-purpose domain may become necessary.
Another possible use for a separate special-purpose domain structure is to house a directory service–capable application that requires itself, for security or other reasons, to have exclusive access to the schema. In other words, if your HR department runs an application that stores confidential employee information in an application that utilizes an LDAP-compliant directory, such as Active Directory, a domain could be set up for that application alone. A cross-forest trust relationship can be established to allow for the sharing of information between the two environments. This type of situation is rarer because most of these applications make use of their own directory, but it is possible. Because the Active Directory schema must be unique across the forest, this would preclude the use of a single forest if these applications require exclusive access or utilize common schema attributes. This type of functionality can be realized with the use of Active Directory in Application Mode (ADAM), which is further elaborated in Chapter 4, “Active Directory Primer.”
Company E is a computer consulting firm headquartered in Morioka, Japan. Most consulting work is performed by full-time Company E employees; however, some outside contractors are brought in from time to time to help on projects. The company had already deployed Active Directory for the internal organization, but was concerned about opening access to the forest for any non-employees of the company. Consequently, a single domain Active Directory implementation was created for the non-employees to use. A cross-forest transitive trust was established between this domain and the internal forest, and access to resources such as file and print were delegated and controlled by the central IT organization.
Users in the contractor domain can access resources in the main companye.com domain, but only those that they are specifically granted access to. In addition, the exposure that the main companye.com domain receives from non-employees is greatly reduced.
Active Directory in Windows Server 2003 gives domain designers the flexibility to rename their domain namespace and/or splice domains in a forest to different locations within a forest. This capability gives Active Directory great new functionality because design changes can be made because of corporate mergers or organizational changes.
Domain rename supports renaming either the Active Directory namespace (for example, companyabc.com) or the NetBIOS (NT) domain name or both. The procedure is a rather brute-force process, however, and should not be considered to be a routine operation.
The domain rename functionality in Windows Server 2003 is mainly a psychological factor because the prerequisites for deploying domain rename make it unlikely to be widely performed, at least in the initial stages of Windows Server 2003 adoption. Domain rename offers long-term answers to the previous barriers to Active Directory adoption, which revolved around the fact that organizations did not want to be locked in to any decisions that could not be changed. Because a Windows 2000 Active Directory namespace decision was irreversible, this effectively put many decision-makers on edge, as they did not want to “paint themselves into a corner,” so to speak. Domain rename removes this stipulation and makes Active Directory adoption much more palatable to decision-makers within an organization.
Domain rename has several limitations. It is important to understand the following restrictions before considering a domain rename operation:
Cannot reduce the number of domains in a forest—. The domain rename tool cannot be used to drop additional domains from a forest. For example, if a forest is composed of four domains, there must be four domains remaining after the procedure is complete. This type of domain consolidation role can be performed only through the use of other tools, such as the Active Directory Migration Tool, which is covered in detail in Chapters 16, “Migrating from Windows NT4 to Windows Server 2003,” and 17, “Migrating from Windows 2000 to Windows Server 2003.”
The current root domain cannot be demoted—. Although the domain rename tool can splice and transplant domains from one portion of an Active Directory namespace to another, it cannot fundamentally change the root domain in a tree. A root domain can be renamed, however.
Cannot transfer current domain names in one cycle—. A production domain cannot be named the same as another production domain that exists in a forest. You need to run the domain rename procedure twice to achieve this type of desired functionality.
In addition to the limitations of the domain rename tool, specific prerequisites for domain rename must be met before a domain can be renamed. These prerequisites are as follows:
The entire forest must be in Windows Server 2003 Functional mode—. One of the largest hurdles to overcome before renaming a domain is the fact that all domain controllers in the domain must be first upgraded or replaced with Windows Server 2003 and the forest functional level raised to Windows Server 2003 functionality. This reason alone will most likely be the biggest limiting factor, at least in the initial adoption period of Windows Server 2003.
New DNS zones must be created—. The DNS server(s) for a domain must have a zone added for the new domain namespace to which the domain will be renamed. The exception is if the domain rename procedure will be renaming only the NetBIOS domain.
Domain rename must run from a console server—. A member Windows Server 2003 computer (not a domain controller) must serve as the console server for the domain rename procedure. All domain rename operations are run from this one box.
Shortcut trust relationships may need to be created—. Any domains that will be “spliced” into a new location in the Active Directory forest will need to have a shortcut trust established between itself and the parent domain where it will be transplanted.
The domain rename procedure, from the back end, is not extremely complex. Most of the barriers to domain renaming, aside from the limitations and prerequisites listed in the preceding section, come in the form of the disruption to the forest that is caused by the reboots applied to all the computers in the forest.
After the prerequisites have been satisfied, the domain rename process can proceed. The entire domain rename process is accomplished through six basic steps. As previously mentioned, however, this routine is rather harsh on the network because it causes down-time to a network infrastructure and should not be considered to be a common operation.
The tool used for domain rename is known as Rendom (which, ironically, is automatically changed to Random in Microsoft spell-checkers). Rendom has several flags that are used in import and export operations. The first procedure run from the console server is rendom /list, which locates the domain controllers for a domain and parses all domain-naming information into an XML document named Domainlist.xml, as illustrated in Figure 5.16.
This XML document can easily be modified by any text editor such as Notepad and, as will become evident, is central to the domain rename procedure.
The XML file generated by the /list flag must be modified with the new domain-naming information. For example, if CompanyABC is changing its name to CompanyXYZ, all references to companyabc in the XML list illustrated in Figure 5.16 are changed to companyxyz. This includes the NetBIOS and DNS names.
After the XML document is updated with the new domain information, it can be uploaded to all domain controllers in a forest through the use of the rendom /upload command. This procedure copies the instructions and new domain information up to all domain controllers within a forest.
Domain rename is a thorough process because it is absolutely necessary that all domain controllers in a forest receive the update information. It is therefore necessary to run rendom /prepare to initiate a preparation process that checks to see if every single domain controller listed in Active Directory responds and signifies that it is ready for the migration. If every single domain controller does not respond, the prepare function fails and must be restarted. This precaution exists to keep domain controllers that are powered down, or not accessible across the network, from coming up at a later time and attempting to service clients on the old domain name.
After all domain controllers respond positively to the prepare operation, you can initiate the actual domain rename by running the rendom /execute command from the console server. Before the execute command is run, there are actually no changes made to the production environment. However, as the command is run, all domain controllers execute the changes and automatically reboot. You then must establish a method of rebooting all member servers, workstations, and other client machines and then reboot them all twice to ensure that all services receive the domain-naming change.
The final step in the Rendom task is to run the rendom /clean operation, which will remove temporary files created on the domain controller and return the domain to a normal operating state.
In addition to the cleanup tasks, you need to effectively rename each domain controller, to change its primary DNS suffix. Each domain controller needs to go through this operation, which you run via the netdom command-line utility. The following steps outline the renaming of a domain controller:
Open a Command Prompt window (choose Start, Run, and then type
cmd.exe).Type
netdom computername OldServerName /add:NewServerName.Type
netdom computername OldServerName /makeprimary:NewServerName.Restart the server.
Type
netdom computername NewServerName /remove:OldServerName.
You run all the preceding commands from the command line. Replace the generic designators OldServerName and NewServerName with the entire DNS name of the old server and the new server, such as server1.companyabc.com and server1.companyxyz.com.
With the advent of technologies such as domain rename and cross-forest trusts, mistakes in Active Directory design have become more forgiving than they were with Windows 2000. However, it is still important to thoroughly examine the political and technical aspects of any organization to design an infrastructure that aligns with its needs. Active Directory is very flexible in these regards and can be matched with the needs of almost any organization. Windows Server 2003 R2 expands upon this design flexibility even further, through the use of tools such as Active Directory Federation Services (ADFS), which allows for ease of administration and user provisioning across AD forests.
Fully understand the structure of Active Directory before designing.
Secure any external namespace chosen by registering it so that it cannot be used anywhere on the Internet.
Start a domain design by considering the single domain model first.
Consider using multiple domains for specific reasons only.
Consider using the federated forest design model when uniting two disparate Active Directory structures.
Control and optimize replication traffic by using sites.
Upgrade any down-level clients to reduce administration and maintenance.
Use domain rename sparingly, and only when faced with no other alternative.