Implementations Small and Large

There are many decision points that are common to both large and small environments that are moving to Active Directory. The simplest one to start with is determining if one is happy with the current domain design. A move to Active Directory is a perfect opportunity to change the basic architecture of a network if the administrator is unhappy with the current one. If multiple resource domains were created out of necessity to delegate control to various administrative groups, those domains could be brought back into a single domain due to the ability to delegate administrative tasks within Active Directory. Environments with multiple trusts can be simplified by using transitive trusts within a single forest. Another key factor is the stability of the current environment. It is difficult to consider an in-place upgrade of an NT domain to Active Directory if the domain is unstable. The creation of a pristine forest would allow an administrator to move user and computer objects into Active Directory and leave behind a corrupted SAM database. The following sections will offer suggestions for designs for several different scenarios.

Single Domain In-Place Upgrade

The simplest situation to design an Active Directory for is one in which the company is moving from a single NT domain. All user accounts and computer accounts exist in a single NT 4.0 domain, for example, CompanyABC. CompanyABC is a prime candidate for a single forest/single domain model. By performing an in-place upgrade on the domain all the objects are moved to Active Directory with their native SID in tact. This means that resources will not have to have new ACLs (Access Control Lists) applied to them. Resources such as users and computers could be placed into organizational units if there was a need to manage different groups of objects in different manners. For example, computer and user objects that were located in a separate physical location that had their own administrator might be placed into a specific OU so that administrative control of that OU could be delegated to that administrator. To delegate access in this manner, click Start, All Programs, Administrative Tools, Active Directory Users and Computers.

Within the Active Directory Users and Computers tool, expand the domain and right-click the OU that will have its administration delegated to another user or group. Choose Delegate Control and the Delegation of Control Wizard will start. Click Next and then add the user or group that will receive administrative control. Click Next and check the appropriate rights to be granted to the user or group over the OU. Click Next and then Finish and the rights will be applied.

Optionally, CompanyABC could have chosen to create a pristine Active Directory forest and migrate all the user and computer objects into the new domain. This would have the advantage of being a completely clean environment without the possibility of corrupt information from the prior domain moving forward.

To perform this type of an upgrade, the new forest would be built with a NetBIOS name other then CompanyABC. This would prevent name conflicts with the existing domain. A trust relationship would be established between the old and new domains. The new domain would have to be in Native Mode for the administrator to be able to use the Active Directory Migration Tool to move the objects. Promoting a domain to Native Mode is performed within the Active Directory Domains and Trusts menu. Choose Start, All Programs, Administrative Tools, Active Directory Domains and Trusts.

Right-click the domain in question and select Raise Domain Functional Level. Choose Windows Server 2003 as the functional level. Having this domain in Native Mode would not be an issue because there would be no NT 4.0 Backup Domain Controllers in a pristine Active Directory domain.

Using ADMT would allow you to migrate over the users, groups, and computers within the NT 4.0 domain. ADMT 2.0, which comes with Windows 2003, offers significant improvements over the version that shipped with Windows 2000. By placing an agent on the NT 4.0 domain, ADMT 2.0 is able to migrate the user's passwords along with their account information. This greatly simplifies the ability to perform a secure and transparent migration. ADMT will even rejoin the workstations to the new domain and remotely reboot them.

Numerous Tools Available

There are numerous tools available to modify SID information in NT 4.0. Domain SIDs can be forged using these tools. An environment that supports SID history from migrated accounts is susceptible to Elevation of Rights attacks from forged SID information placed in the SID History field of an account.

Users that are migrated in this way will have accounts with multiple SIDs. This is to ensure that their old and new identities still exist. This enables them to still access legacy resources that have not yet been migrated to the Active Directory domain. User accounts will have their friendly name listed from the old domain. This is to say that if connectivity to the old NT 4.0 domain is lost, the SID lookup of a user will fail. For example, resources that were ACLed to CompanyABC\habbate would show up as something like ?Account Unknown(S-1-5-32-547). Administrators should use GetSID and SubinACL to flip the SID listed in the ACLs to reflect the SID provided by Active Directory.

Multiple Domains ”Child

In NT 4.0, domains were viewed as security partitions. This is much less the case in Active Directory. Multiple domain models address basically two functions. Password policies can only be set at a domain level. If a company wants to enforce industry best practice security settings on account behavior and needs to support developers who need to never have to change passwords, multiple domains could accomplish this. The second issue that multiple domains address is political. Administrators who used to be domain administrators want to remain domain administrators. Although they could be granted full control over an OU and even block administration from above, many groups will insist that they have their own domain.

When a company decides on a multiple domain model, the biggest question that comes up is one of naming. Most administrators assume that AD domain naming must map directly to DNS domain structures. This actually isn't the case. Although it makes management easier and troubleshooting simpler, it is not an Active Directory requirement.

One primary consideration for a multiple domain model is integration with LDAP. If a company needs to support recursive LDAP queries, Active Directory must be configured with Child domains with a common parent. So CompanyABC might have CompanyABC.com as a parent domain that is nearly empty with only domain controllers in that domain with NA.CompanyABC.com, EU.CompanyABC.com, and AP.CompanyABC.com below it. These domains would serve North America, Europe, and Asia/Pacific, respectively. By having a parent domain anchoring them, they would be able to pass LDAP queries up and down the tree to find the information they need. They could each control their own DNS zones with forwarders back to DNS in CompanyABC.com while CompanyABC.com would hold the NS records that delegate control to each of the subdomains. Important to note is that all four domains share the same schema. A clever administrator would note that domain administrators of the child domains have no ability to modify the schema. This allows a corporate headquarters to maintain top level control of the forest and still give remote offices full control of their domains.

Multiple Domains ”Discontinuous

Another way to implement multiple domains is to make their namespace discontinuous. For example, AD.NA.CompanyABC.com, AD.EU.CompanyABC.com, and AD.AP.CompanyABC.com would be three distinct domains that have discontinuous namespace. Even if there were a CompanyABC.com domain that anchored the forest, the three domains would not be child domains. This situation can arise when a company is trying to match Active Directory to an existing DNS hierarchy. Although this is perfectly acceptable from an Active Directory point of view, it is important to point out that this will break recursive LDAP lookups. If a query made against a Domain Controller in AD.AP.CompanyABC.com and the answer lives on a Domain Controller in AD.NA.CompanyABC.com, the answer will not be found. The LDAP query would have to ask each domain individually. Global Catalog queries would still be able to span the discontinuous domain. So although multiple domains are more administrative effort than a single domain, they do have their applications. Table 10.1 lists some advantages and disadvantages of implementing multiple domains.

Table 10.1. Advantages and Disadvantages of Multiple Domains

Advantages	Disadvantages
Defined security boundaries for settings such as password requirements.	Increased administrative overhead from managing a number of domains.
Reduce domain controller database size.	Increased Global Catalog (GC) size.
Reduced File Replication System traffic.	Moving users from one domain to another is more administrative effort than moving them from one Organizational Unit (OU) to another.
Reduced domain network traffic due to fewer changes that need to be replicated.	Increased GC replication due to increased number of domains.
Group policies, security, and delegation only have to be defined once.	Group policies, security, and delegation have to be defined in each domain.
Smaller impact if a domain suffers a failure.	Added cost of multiple domain controllers for each domain.

Consolidating Domains

Many companies are taking advantage of the capability to delegate administrative powers over an OU to replace legacy resource domains. This is to say that they are collapsing resource domains back into the account domain. The account domain is the logical domain to upgrade in place to Active Directory to avoid the need for SID history and to avoid having to modify ACLs on resources to eliminate the legacy SID information. The goal for this type of consolidation is to try to reduce the overall number of domains that are supported. This feeds back into the previous decision of single domain versus multiple domains. Although a company might have literally hundreds of resource domains and a few account domains, the resource domains can be collapsed back into the account domains, which are in turn collapsed into a simpler structure of either a single or a small number of child or discontinuous domains.

ADMT 2.0 offers numerous features that make domain consolidation simple. Perhaps the best feature is the capability to move users and only the groups to which users belong. This is a great way to eliminate unused groups. Member servers can be moved to another domain and be rebooted remotely so that no human interaction is required. Service accounts can also be migrated via ADMT so that if a server had services that were running under accounts from a resource domain, that account can be moved into the new domain and the service reconfigured automatically to run under the migrated account.

Migrating domain controllers is a slightly trickier task. The two most popular methods are to either retire the domain controller or to upgrade it to Windows 200x. If the domain controller did not host shares or applications that need to be migrated, it should simply be retired and the hardware redeployed. If the system holds resources that are still needed, an upgrade to Windows 200x allows you to use the DCPROMO utility to demote the server to a member server. Now ADMT can be used to migrate the server to the new domain.

Always Get a Good System Backup First

Although Microsoft doesn't provide any tools or utilities that can convert an NT 4.0 domain controller to a member server, numerous third-party software developers do. Products like uPromote can be run on a BDC or a PDC to make it an NT 4.0 member server. Although these utilities have been around for several years and used with good results, care should be taken in using them. Always get a good system backup first.

Understanding Multiple Forests

One of the most unusual Active Directory designs is the use of multiple forests. Multiple forests in Windows 2000 were extremely restrictive in their ability to share resources between forests. The best way to think of a multiple forest design is to look at a forest that is anchored by a domain called CompanyABC.com that is built in a lab and think about its connectivity to Microsoft's internal Active Directory environment. CompanyABC.com has no ability to add Microsoft accounts to its ACLs and the reverse is true as well. CompanyABC.com administrators, although Schema Administrators, can't touch Microsoft's schema. Exchange servers in CompanyABC.com can't provide e-mail address information for Microsoft's users. For all intents and purposes, they are completely disparate and disconnected networks. Now place those two networks on the same LAN. Nothing changes; they are still completely disparate. Although at first this might seem somewhat useless, it does offer some characteristics that might be required by a company. The greatest offering of the multiple forest design is that each forest has its own schema. Schema administrators in one forest can't affect the schema in the other forest. This is a perfect situation for developers who are working on Active Directory applications in a development environment. If these developers needed access to the corporate forest, they would need separate accounts in the corporate forest. They would attach to the resources they need and be prompted for their login information in the target domain.

Windows 2003 has extended the functionality of forests by creating the concept of cross-forest trusts. Not unlike domain trusts of NT 4.0, this allows environments that were completely independent to share resources without sharing a common schema. This concept will be explained in greater detail in the section "Using Cross Forest Trusts Effectively" later in this chapter.

Using a Placeholder Root Domain

Layered on top of the domain options discussed previously is the concept of the Placeholder Root Domain. A Placeholder Root Domain is the first domain created in a forest. It is built with a neutral name and it contains only domain controllers. As the anchor of the forest, it holds the schema along with the Enterprise Administrators group and the Schema Administrators group. The user domain would be built as a peer domain or a new domain tree in an existing forest. An example is the single domain model with CompanyABC.com being an in-place upgrade; the Placeholder Root would be built first to establish the forest and the CompanyABC NT 4.0 domain would be upgraded to CompanyABC.com as a new tree in the existing forest. This offers two very compelling benefits:

• Forest Name Neutrality. By giving the forest a generic name like Corp.root the forest is not tied to the identity of the company. If the company later wanted to rename or rebrand itself, it would be able to do so without having to rebuild the forest or live with the legacy name. Although renaming a domain is a fairly straightforward task, there is no mechanism to rename a forest.

• Schema Isolation. By placing the Schema Administrators group in a separate domain, administrators in the account domain have no capability to modify the schema. To perform schema modifications an administrator would have to log out of the normal use domain and log into the Corp.root domain. Because the Corp.root account would have no access to file shares or e-mail, the administrator would have no reason to stay logged in as the Schema Administrator account beyond the task of the schema modification. This drastically reduces the exposure of the Schema Administrator account. As viruses and Trojan Horses become more mature their most likely target in corporate environments will be the Active Directory schema. By preventing Domain Administrators from being to modify the schema the risk of accidental or malicious modification to the schema is greatly reduced.

A Placeholder Root Domain can be added to any of the scenarios mentioned here. The placeholder root gets built first to anchor the forest and an in-place upgrade would upgrade the domain as a domain in an existing forest.

For Redundancy...

it is recommended that the Placeholder Root Domain consist of three domain controllers. These domain controllers should be located at different physical locations if possible. Two should be configured as Global Catalog (GC) servers. The Domain Controller holding the Infrastructure Master FSMO role should not be configured as a GC.