In this Chapter
Implementing Active Directory is a fairly straightforward task. Just install Windows 2003, tell the Configure Your Computer Wizard that you want to be a domain controller and vòila! You have Active Directory. Although technically this is true, if administrators were to do this, they’d quickly find themselves unhappy with the environment they created. There is no single best way to implement Active Directory. A properly designed Active Directory takes into account the business requirements, the technical requirements, and the political requirements of a company and designs a structure that will support the current environment and allow for flexibility of growth. A design should never be complex simply for the sake of being complex. A wise administrator realizes that there is beauty in simplicity and that unneeded complexity only adds more work down the road.
This chapter examines some of the typical and atypical needs of companies and will show how Active Directory can be tailored to support those needs. The goal is to start simple and add complexity if and only if the situation requires it. Topics such as forest design, domain design, LDAP integration, site design, and domain controller placement will be discussed showing the pros and cons of various decisions to give administrators greater insight into planning their own Active Directory environments.
The safest rule for Active Directory design is to first gather all the major players in the company and get them to agree to a list of goals for the implementation. After you have reached a consensus from everyone on the core goals they can serve as a focal point for decisions. When there is dissention among the ranks on a decision, you can always go back to the core goals for the project and see which decision supports those goals.
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.
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 CompanyABChabbate 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.
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.
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. |
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.
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.
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.
Although it might seem that domains and OUs are fairly permanent objects, the truth of the matter is that objects can be moved pretty freely within a forest. Although this freedom is very valuable it should not be used as a crutch for a poor initial design. Moving objects around can drastically affect application of Group Policy Objects as well as make it difficult for other administrators to find objects that have been relocated. Moving objects to another domain could result in those objects no longer having a local domain controller and an increase in WAN traffic would result.
In an environment with multiple domains there will invariably be situations in which you need or want to move objects from one domain to another. This might be due to domain consolidation or reorganization within the company. Windows 2003 provides a tool for this function called MoveTree. MoveTree.exe is a command-line utility that enables you to move Active Directory objects such as organizational units, users, or groups between domains in a single forest. Although MoveTree can move Active Directory objects between domains, not all objects can be moved in this manner. Potentially, there might be associated data such as profiles or login scripts that are not moved. Computer objects are not moved during a MoveTree operation; they require the use of the Active Directory Migration Tool (ADMT). Not unlike ADMT, MoveTree requires that the target domain be in Native mode.
When objects are moved via MoveTree, they are first copied to the Lost and Found container in the source domain and then they are moved to the destination domain. A file named MoveTree.log tracks all objects that are moved. This file also contains all error messages that are recorded during the move. Objects that cannot be moved to the target domain remain in an orphan container in the Lost and Found container of the source domain. Domain global and local groups cannot be moved during a MoveTree operation. However, group memberships remain intact so that security is not compromised.
Usage of the MoveTree utility is as follows:
MoveTree /start /s Server1 /d Server2 /sdn OU=SourceOU,DC=Dom1 /ddn OU=DestOU,DC=Dom2 /u Dom1administrator /p *
The source and destination servers must be the RID masters for each domain. Otherwise an error will be logged stating “ERROR: 0x2012 The requested operation could not be performed because the directory service is not the master for that type of operation.”
In the case of moving organizational units to another domain, you should be aware that although the GPO link moves with the OU and continues to function, the GPO is actually linked to the source domain. This can result in a degradation of performance. It is strongly recommended that the GPO either be re-created or exported via the Group Policy Management Console and imported into the target domain.
Moving objects between Organizational Units is a simple way to keep a domain organized. Administrators are the only people in the network who can see OU structures, so administrators can build and modify OU structures without concern for how it will look to end users. Moving an object from one OU to another is as simple as right-clicking the object in Users and Computers and choosing Move. This will prompt you for the destination OU or container. Multiple objects can be moved at the same time.
Because OUs are often used to delegate control of objects and for the application of GPOs, you should be aware of the implications of moving objects. Objects that had explicit permissions assigned directly to them will retain those permissions after the move. Permissions that were inherited from the previous container or OU will no longer affect the object. The object will inherit permissions set on the new OU or container.
The Knowledge Consistency Checker and the Inter-Site Topology generator work together to determine the most efficient way to replicate information across the forest and within sites. These programs determine replication paths for both Active Directory replications and file replication. When a forest is upgraded to the Windows Server 2003 functional level, the new Windows Server 2003 spanning tree algorithm is enabled. This updated algorithm allows for improvements in both efficiency and scalability. For example, Windows 2000 spanning tree algorithm allowed one domain to contain up to 300 sites. The new Windows Server 2003 algorithm allows one domain to have up to 3,000 sites. The Windows Server 2003 algorithm uses a randomized selection process for bridgehead server selection via the inter-site topology generator. This process allows for more evenly distributed bridgehead replication workload among domain controllers in a site. The result is improved efficiency that only gets better as additional domain controllers are added to a site. The default behavior is for this randomized selection process to occur only when new connection objects are created in a site. Optionally, a Windows Resource Kit tool, called adlb.exe, can be run to redistribute the load each time changes occur in the topology or when the number of domain controllers in the site changes. In addition, adlb.exe can stagger the replication schedules so that the outbound replication load for each server is spread out more evenly across time.
In Active Directory, a site is a group of computers that are connected by 10MB or faster connections. The easiest way to look at this is any LAN separated by a WAN link is more often than not a site. Sites and subnets are used by Active Directory to find the “closest” object of a particular type. This could be a printer, a DFS replica or a domain controller. In some environments, it is not necessary to follow the strict definition of sites. If a site will never have a domain controller it will always be adopted by another domain controller. As such, by summarizing sites you can ensure that certain locations are serviced by a particular domain controller. As the number of domains and sites grows it is harder and harder for the Knowledge Consistency Checker (KCC) to maintain the topology. By reducing the number of sites you can lower the load on the KCC and leverage it longer as the environment grows.
As an example, let’s say that CompanyABC has 40 small sites in Japan and 50 small sites in the United States. Each site consists of a single subnet. The largest office in Japan is in Tokyo. It has a pair of domain controllers. The largest site in the U.S. is in San Jose. It has two domain controllers as well. The two choices would be to either create 90 sites, 90 subnets, and 90 site links or create two sites, 90 subnets, and two site links.
If all 90 sites were defined, the KCC would process site link costs for all 90 site links to determine which Domain Controllers should adopt which sites. DNS would hold site records for all 90 sites to list _gc, _ldap, and _kerberos SRV records. If the Domain Controllers in Tokyo happened to be busy when the KCC was processing links, sites in Japan could be adopted by the DCs in San Jose and WAN traffic would increase as authentication, login scripts, and GPO application happened across the WAN.
Simplification of Site Management via Site Summarization Could Backfire
The simplification of site management via site summarization could backfire if you plan to implement distributed technologies that are based on Active Directory sites. SMS 2003 is an example of this. If each location were to get its own distribution server, which was previously managed by SMS Sites in SMS 2.0, and if the sites were summarized into two sites, there would be a very good chance that client machines would go to the wrong distribution server; their local site would not exist in SMS 2003. SMS 2003 eliminates its own Site database and leverages the Sites and Subnets area of Active Directory.
If, on the other hand, the sites were summarized into only two sites, each holding the appropriate subnets, the KCC would perform much less work and sites could not be adopted by the wrong domain controllers as they would have local domain controllers. The DNS structure would be greatly simplified and administrative tasks would be reduced.
Site adoption occurs when a site is defined and it contains no domain controllers. Messages will appear in the event viewer such as “Site 'siteB' does not have any Domain Controllers for domain 'CompanyABC'. Domain Controllers in site 'closest_site' have been automatically selected to cover site 'siteB' for domain 'CompanyABC' based on configured Directory Server replication costs.". At the same time, the _sites records in DNS will populate with the new site and records pointing to the DCs in the site that adopted the site in question.
The Directory Server replication cost refers to the cost associated with the site links traversed to get from one site to another. These values default to a cost of 100 but can be manually configured to further control site adoption. This can be especially useful with multihub and spoke replication topologies where you want everyone’s second choice of DCs to be a particular site.
To set the cost on a site link follow these steps:
Choose Start, All Programs, Administrative Tools, Active Directory Sites and Services.
Expand Sites.
Expand Intersite Transports.
Click IP and right-click the site link in the right column.
Select Properties.
The cost of the site link and the replication schedule can be modified here.
Another way to control authentication for a particular site via a specific domain controller or group of domain controllers is through DNS. By maintaining DNS manually, specific records can be placed in _dc/_sites/_site in question/_tcp for the following:
_kerberos SRV
_ldap SRV
Use Manual Control of DNS as a Last Resort
Although disabling dynamic updates to DNS gives you greater control over DNS it also results in greatly increased administration of DNS. You should use manual control of DNS as a last resort to control authentication choices of hosts.
This forces the hosts in the site to always use a particular DC as their first choice for authentication. This can be useful if local DCs are to be dedicated to an application that places a very high load on the DC for either authentication or LDAP queries. To enable manual control of DNS, simply disable dynamic updates on the DNS zone. If the DNS is Windows 2003 DNS this can be accomplished by the following:
Windows 2003 introduced two new concepts in the use of forests; cross-forest authorization and cross-forest authentication. Cross-forest authentication allows users secure access to resources in another forest. This feature enables users to securely access resources in other forests, using either NTLM or Kerberos. This allows access without sacrificing single sign-on or the benefits of having a single user ID and password maintained in the user’s home forest. Cross-forest authorization allows you to select users and groups from trusted forests for use in local groups or ACLs. This is a similar concept to domain trusts that were used in NT 4.0 domains. This feature retains the forest’s role as a security partition while still allowing trust between forests. It allows the trusting forest to enforce restrictions on what security identifiers (SIDs) will be accepted when users from trusted forests attempt to access protected resources.
To create a cross forest trust, perform the following steps:
Choose Start, All Programs, Administrative Tools, Active Directory Domains and Trusts.
Right-click the domain for which you want to establish the trust and select Properties.
Click the Trusts tab and click New Trust. This will launch the New Trust Wizard. Click Next.
At the prompt shown in Figure 10.1, type the name of the domain, forest, or Kerberos realm for this trust. Because this will be a forest trust, enter a fully qualified domain name (FQDN) and click Next.
Select the appropriate trust type, in this case, Trust with a Windows Domain. Click Next.
When prompted with the screen shown in Figure 10.2, select the direction for the trust and click Next.
Choose whether to create the trust on one or both sides. Click Next. This will depend on your rights in the other forest.
Caution Should Be Exercised in the Use of Cross-Forest Trusts
Although the capability to restrict usage of cross-forest authorization reduces exposure to potential elevation of rights attacks through SID history from a trusted forest, the potential for intrusion is not eliminated. Administrators don’t have complete knowledge of security practices of administrators of other forests. Caution should be exercised in the use of cross-forest trusts.
Choose domainwide or selective authentication when prompted with a screen similar to the one shown in Figure 10.3. Click Next. This will determine if some or all resources will be made available.
Input the appropriate trust passwords. Click Next.
This completes the trust creation. Click Next, Next, confirm the trust, Next, Next, and then Finish.
With the ability to now support trusts between forests, many previously unavailable Active Directory architectures become available. Forests can be built to support a single Active Directory–aware application. Schema changes to that application would be independent of the schema supporting the account forest. Resource forests could be brought up to allow developers or QA groups to work in environments that look identical to production without the fear of changes to the schema affecting production users.
Back in the days of NT 4.0 domains, company mergers or acquisitions were fairly easy to handle from a domain point of view. With the simple creation of a trust, resources could be ACLed with user information from the other company. When Windows 2000 and Active Directory came along, this scenario became a lot more challenging. Now with Windows 2003 and the support for cross-forest trusts, the fairly simple days of granting access to a resource via a trust have returned.
Although a cross-forest trust should not be considered a long-term solution for company acquisition or mergers, it is an excellent tool to get immediate access to resources. Companies in this situation should look back to their original Active Directory design and make determinations as to how best to integrate the new resources; either as a new domain in the forest or collapsing them into a single domain potentially as an OU. If the requirements of the partner are sufficient to warrant a separate forest, the trust could be maintained long term.
Having the capability to connect forests via trusts makes an administrator realize that there were things that were taken for granted in a single forest model. Address lists for Exchange don’t automatically list all the users in the other forests. Applications that fed their own databases from Active Directory won’t automatically know about the objects in the other forest either. Additional tools will be needed to keep these multiple directories in sync.
The new version of Microsoft Metadirectory Services, 3.0, now called Microsoft Identity Integration Server, contains a simplified method for keeping the Global Address Lists of multiple forests in sync. GALSync replicates e-mail–specific attributes of user objects and distribution groups between forests to maintain a homogenized view of mail users from multiple forests.
Active Directory Migration Tool (ADMT) is a simple and free way to move objects into an Active Directory. ADMT enables you to move users into a new domain without breaking access to their files in the old domain. ADMT can automate the process of moving multiple computer objects into a new domain. ADMT will even go as far as to remotely reboot the computers if you want. Depending on the situation in which it is used, there are many tricks to making ADMT work its best and many security implications that must be understood.
ADMT version 2.0 offers the capability to migrate passwords along with the users. This feature was unavailable in version 1.0. To migrate the password, you must also set up the Password Export Server. Follow these steps:
Create a key that encrypts the password list.
Run ADMT.exe from the command line using the key option. The syntax for this command is
ADMT.exe key Source_Domain_Name folder: [Password].Set the value of the AllowPasswordExport Registry entry (located in HKLMSYSTEMCurrentControlSetControlLsa on the PES) to 1. You can disable a PES from supporting password migration by setting the value to 0.
Add the Everyone group to the Pre-Windows 2000 Compatible Access group on the target domain. This will prevent ADMT from logging an Access Denied error.
In the Active Directory Users and Computers snap-in, verify that permissions on the PES server object are set to allow the Pre-Windows 2000 Compatible Access group to Read All Properties on the following object:
CN=Server,CN=System,DC=<domain_name>If you are running ADMT on a server running Windows Server 2003, add ANONYMOUS LOGON to the Pre-Windows 2000 Compatible Access group on the target domain to prevent an Access Denied error.
This will allow the migrate password option in ADMT 2.0 to work properly.
Next you should install the pwdmig.exe password migrator.
After those are in place, the ADMT itself can be run. Simply select the wizard for the type of migration desired.
The Active Directory Migration Tool is covered in more depth in Chapter 14, “Migrating from Windows NT 4.0.”
SID History is a field stored in a user’s account that references previous identities. SID History is a field used by the ADMT to allow newly migrated users to access previously accessible resources. In addition to the primary SID for an account, all previous SIDs for that account are stored as well.
When a user attempts to access a resource the system checks Access Control Lists on the resource and compares this to the SID value on the account trying to access the resource. If the SID has been granted access, the account will be able to use the resource. This is the standard behavior of Windows. SID history complicates this process slightly in that both the primary SID and the SID history are checked to see if they have rights. A clever administrator could use this feature to elevate their rights from a separate domain. ADMT checks to see if a SID already exists before it will migrate an account. If a domain were disconnected from the other domains and Global Catalogs, ADMT would not know that a SID was a duplicate. By creating accounts in an NT 4.0 domain an administrator could modify the domain SID prefix on the domain and generate accounts until a SID matched the SID of an administrator in another domain. NT 4.0 generates SIDs sequentially. This account could then be migrated into the administrator’s domain via ADMT. The domain could then be reconnected to the rest of the forest and the newly migrated account would have a SID History entry that matched an administrator in another domain. This migrated account would have the same administrative privileges as the real administrator whose account was essentially cloned.
If a user object is moved via ADMT it keeps a History of previous SIDs. Administrators can protect their networks by not allowing accounts with SID history to access resources. Because many legitimate accounts will be migrated and have a SID history, it is necessary to be able to remove the SID history from the accounts after their old resources have new ACLs applied to them that reference the primary account SID. Microsoft offers a Visual Basic Script that is designed to do just this.
Windows Server 2003 shipped with version 2.0 of the ADMT. This version offered several improvements over the version that came with Windows 2000. Perhaps the single most useful improvement is the ability to migrate the user’s password along with the user object. This prevents confusion or insecurity by not requiring the user to learn a new password or resetting all passwords to be the same value. This function involves setting a permission on a Registry key on the PDC in the source domain and running an agent that gathers the passwords to move along with the account.
When Active Directory designs encompass multiple forests or when the design has to account for mergers and acquisitions, the Microsoft Metadirectory Services (MMS) tool can be invaluable in keeping directories in synch. MMS, now called Microsoft Identity Integration Server 2003 (MIIS 2003), enables you to integrate and manage identity information across multiple directories. These directories can be different systems or platforms. MIIS 2003 adds functionality to Active Directory by providing enhanced interoperability capabilities. These capabilities include integration with a various identity repositories, synchronizing identity information across multiple systems, managing changes of identity information by automatically detecting updates and passing the changes across systems as well as managing passwords. Prudent use of MMS enables you to keep an entire enterprise of various directories in sync by managing them through a single authoritative source.
Microsoft Identity Integration Server 2003 (MIIS) was built with four primary features in mind; centralization of identity information, managing identity information, managing changes to identity information, and broad connectivity.
In most companies, identity information is stored in various data sources. This can and usually does result in the duplication of identity information. Data stored in incompatible formats requires you to have access to multiple connected data sources, often with multiple clients.
To solve these issues, MIIS 2003 can do the following:
Combine the data for a specific object in the metadirectory, creating a single entry that contains all or some subset of the identity information from each separate data source.
Present a single, unified view of some or all of the attributes from the separate data sources even if the connected data sources are incompatible.
Provide a single authoritative location from which administrators, users, or even applications can read or manage the identity information for a given object.
Disparate directories usually contain dissimilar identity information on the same person or resource. Invariably, the group that owns and manages the data in a specific data source believes that its data is accurate and authoritative compared to similar data that is owned and managed by another group. In these cases, identity data owners are often opposed to relinquishing control of the data.
To solve the issues resulting from conflicting identity information, MIIS 2003 can do the following:
Manage the flow of data between identity information stores to resolve conflicts in identity data throughout the enterprise.
Determine what identity data should be imported from each data source.
Create rules to determine which identity data store contains the authoritative value for a specific attribute in the metadirectory and pass that authoritative value to other data stores.
An organization’s identity data is often located in different data sources. As such, a change made to data in one source is not automatically made in the other data sources. Propagating the change throughout the enterprise often requires you to manually update the data in each information store. Failure to properly manage identity data can cause the data to become disorganized and out of synch across the enterprise.
To solve issues resulting from changes to identity data, MIIS 2003 can do the following:
MIIS 2003 excels in the area of connectivity capabilities. MIIS 2003 ships with connectivity to most Network Operating Systems, e-mail systems, popular databases, directories, applications, and even flat-files.
MIIS 2003 ships with the “Management Agents” required to integrate with many various types of repositories, including the following:
Microsoft Windows NT
Active Directory
Active Directory in Application Mode
Novell eDirectory
SunONE/iPlanet Directory
X.500 systems
Lotus Notes and Domino
Microsoft Exchange 5.5
PeopleSoft
SAP
ERP
Telephone switches
XML- and DSML-based systems
Microsoft SQL Server
Oracle
IBM DB2
Informix
Sybase
OLE/DB-based systems
DSMLv2
LDIF
CSV
One of the biggest questions in an Active Directory design session is on the placement of Domain Controllers. In NT 4.0 domain controllers were often used as a Band-Aid for poor network performance. By placing local backup domain controllers at every site, users were assured of having authentication and login scripts available in case of a WAN failure. Maintenance and management of remote domain controllers quickly became a major issue for large companies.
In Windows Server 2003 there have been great improvements in replication traffic, replication topologies, and the reduction of single master operations over NT 4.0. As such, many companies take the upgrade to Active Directory as an opportunity to reduce the number of domain controllers in the environment as well as to centralize them to reduce administrative costs.
One of the most popular arguments in favor of domain controllers at each location is that of authentication traffic across the WAN. Most network administrators cringe at the thought of users authenticating across the WAN instead of locally. In reality, user authentication is only a few KB of data per authentication. Although domain controllers might not be local, login script locations can be.
In large companies, domain controllers can spend a lot of bandwidth replicating changes to objects that occur in other parts of the network. Users, on the other hand, rarely authenticate more then once per day. As such, it is not uncommon to see replication traffic take up more bandwidth then authentication traffic. Many companies have found that domain controllers placed in smaller sites that were intended to reduce bandwidth usage actually increased it. Removing those domain controllers freed up precious bandwidth.
A simple test is to enable monitoring on a WAN connection of a remote office and temporarily unplug its domain controllers. Their site will be adopted and another set of DCs will handle its authentication. Place a replica of login scripts on its local file server and make sure the users in that site point to that location for their scripts. If login scripts reference a DFS share, this will be unnecessary. Monitor the WAN connection for a day and compare it to the same day of the week from the previous week. This will provide the objective data needed to make a decision about the cut off point for the size of office that should maintain local domain controllers.
One of the most important considerations when looking at removing domain controllers from a site is determining exactly what the benefits are of having a local domain controller. Although being able to authenticate seems like a requirement for a site, if there are no resources locally that would be accessed via a local authentication, there is only minimal benefit. If all resources are remote and the domain controllers are also located remotely, a failure of the WAN would make local domain controllers pointless. If an office has local resources, most users could still access the resources via locally cached credentials if there was a WAN failure and no local domain controllers. These types of scenarios must be considered to determine if local domain controllers would add value to a site.
In many situations WAN traffic is more about replication than it is about authentication. But it is still important that client computers are able to reach domain controllers. If there is a WAN failure and there are no local domain controllers, users will only be able to reach resources for which they have cached credentials. But if there are local domain controllers, the users in the location are still limited to accessing only the local resources. In this type of situation it is often better to spend your budget on redundant network connections as opposed to spending the money on additional domain controllers. The redundant WAN links will not only ensure the users within a site will be able to authenticate properly with an available domain controller, but it will improve the users’ connectivity to resources throughout the enterprise.
Many companies have literally removed all domain controllers from all remote sites and placed a much lower number of domain controllers in a central location. In this way, all the domain controllers are centrally located and centrally managed. Additional domain controllers are placed in a recovery site with connectivity between the two primary locations. Remote sites are given WAN connections to both locations for redundancy. The result has been improved overall performance and reliability along with a significant reduction in costs for managing the remote systems.
Paralleling the question of where to place the domain controllers is the question of which domain controllers should be the main global catalog servers. The typical rule of thumb is that each site that has domain controllers should have at least one Global Catalog.
A global catalog is a kind of index for Active Directory. Every directory object in the entire enterprise is represented in the global catalog, but only a subset of the properties of each object is stored in the catalog. The properties stored for each object are those most likely to be used as search attributes, such as the user’s first or last name. You can specify storing additional object attributes in the catalog if desired. Having the global catalog store only a subset of an object’s attributes in Active Directory improves the performance of search queries against Active Directory.
Any changes in Active Directory will show up on the Global Catalog servers when Active Directory replication occurs. Because this is only a subset of the entire Active Directory, replication traffic will be relatively light. This load will increase with the number of domains because Global Catalogs contain objects from all domains in the forest. As such, Global Catalog placement in a forest with a low number of domains can benefit from mirroring Domain Controller placement.
When a user authenticates against an Active Directory domain controller, the domain controller must be able to contact a global catalog to determine if the user is a member of any universal groups. If a domain controller fails to contact a global catalog, the user’s logon will fail. As such, if a domain controller is going to be placed in a remote site in order to ensure local access to local resources in an office where many users might not have locally caches credentials, it is important to make the domain controller a global catalog as well.
For extremely large sites, this additional global catalog traffic might be excessive if it must be placed on every domain controller in the enterprise to protect logons for remote sites. Optionally, you can disable this requirement for contacting a global catalog in order to authenticate a user successfully. Doing the following disables this function:
From the
runcommand, launch Registry Editor (Regedt32.exe).Drill down to the following key in the Registry:
HKEY_LOCAL_MACHINESystem
CurrentControlSetControlLsa
On the Edit menu, click Add Key, and then add the Registry key IgnoreGCFailures. After adding the Registry key, the Registry Editor screen will look similar to Figure 10.4.
Exit the Registry Editor.
Restart the domain controller.
Only Use This Feature If It Is Unavoidable
You should only use this feature if it is unavoidable to have local domain controllers that are not global catalogs. If this key is enabled and a user is a member of a universal group, if that universal group is denied access to a resource, the user might still be able to access the resource. This is because the key turns off enumeration of universal groups so the universal group SID will not be added to the user’s token.
This will enable sites with local Domain Controllers that are not Global Catalogs to still authenticate users if a Global Catalog server is not available.
Windows Server 2003 allows an Active Directory Architect more freedom in the placement of domain controllers across the enterprise. This is because Windows Server 2003 has improved the behavior of replication. At the most basic level, Windows Server 2003 has changed the model for replication. Windows 2000 Active Directory replicated changes object by object. Windows 2003 Active Directory takes this concept one step further by replicating changes attribute by attribute. The net result is an overall reduction in replication traffic.
One of the biggest differences between Active Directory and NT 4.0 is the introduction of multi-master domain controllers. This is to say that domain controllers all contain read/write copies of the account data. In NT 4.0, only the Primary domain controller was able to write to the SAM database. This meant that all Backup Domain Controllers had to get their SAM updates directly from the PDC. This hub and spoke replication resulted in large amounts of traffic, much of which had multiple conversations going across the same WAN connection. In Windows 2000 and 2003 Active Directory, domain controllers are able to determine their own replication topology and create meshed replication paths to make replication as efficient as possible. Rather then have all DCs in a site talk to the same DC for replication, a bridgehead server can replicate with a remote server and then replicate the same information locally among other domain controllers in the same site. This results in a significant decrease in domain controller replication traffic.
Windows Server 2003 introduces a new concept called Active Directory Functional Levels. These levels occur at both a domain and forest level. Domain level functionality levels include the following:
Windows 2000 mixed (default)—Allowing Windows NT 4.0, Windows 2000, and Windows Server 2003 domain controllers
Windows 2000 native—Allowing Windows 2000 and Windows Server 2003 family domain controllers
Windows Server 2003 interim—Allowing Windows NT 4.0 and Windows Server 2003 domain controllers
Windows Server 2003—Allowing only Windows Server 2003 domain controllers
Forest level functionality levels include the following:
Some advantages of going to the Windows 2003 functionality level at the domain level are the capability to rename domain controllers without demoting them, support for time stamping of object logons, user passwords on InetOrgPerson objects, group nesting, and the capability to convert security groups to distribution groups.
At the forest level, Windows 2003 functionality level offers improvements in Global Catalog replication, the capability to deactivate schema classes, support for forest trusts, the capability to rename a domain, and improved Active Directory replication.
To raise the functionality level of a domain, follow these steps:
Open Active Directory Domains and Trusts.
In the console tree, right-click the domain for which you want to raise functionality, and then click Raise Domain Functional Level.
In Select an available domain functional level, do one of the following:
Click Windows 2000 Native as shown in Figure 10.5, and then click Raise to raise the domain functional level to Windows 2000 native.
Click Windows Server 2003, and then click Raise to raise domain functional level to Windows Server 2003.
This chapter has touched on many of the important design decisions that must be made to build a stable and scalable Active Directory. It has shown that companies have multiple options available to them and it has shown the importance of keeping the design as simple as possible. Each variation on the design offers additional flexibility but always at a cost of complexity. Complexity equals added management which increases cost of ownership. You must carefully weigh the costs of a design before embarking on a design that might prove difficult to manage.
You’ve seen that Windows 2003 has further improved in the area of Active Directory in terms of replication, security, and interoperability with foreign forests. These improvements make more complex designs more scalable and easier to support.
This chapter has touched on the benefits of Microsoft Identity Information Server and how it is able to tie multiple directories together to allow companies to better leverage their data stores. New capabilities such as renaming domain controllers without demotion and renaming a domain give you powerful new tools for the management and rearchitecting of existing forests and domains.
You’ve also seen that the old philosophy of placing domain controllers at every location just isn’t necessary anymore. Often times, investing the budget in WAN connectivity and redundancy will pay larger dividends.
Careful planning of the Active Directory is the easiest way to avoid problems down the road. A well thought out Active Directory is easy to scale and is flexible enough to accept change. Always take the opportunity to design a network the right way the first time. Be flexible in allowing changes but only if they meet a legitimate business need. Never let a change go undocumented. The original design should be a living document that captures the current state of the enterprise. As a map, it will be invaluable in assisting with any troubleshooting that might occur in the future.