4.3 Configuring a Domain Controller
Installing Active Directory
Before installing the Active Directory on your Windows 2000 server, you must have a plan. Unlike using Windows NT 4.0, you need a lot more information than just knowing if the server you are installing will be a Primary Domain Controller or a Backup Domain Controller. With Windows 2000, you must know exactly how this Domain Controller fits into your enterprise. Principally, you need to know the following about this Domain Controller:
Will it be in a new Domain or a replica of an existing Domain?
Will it be in a new tree or in an existing tree within your enterprise?
Will it be in a new forest or an existing forest?
A New Domain Versus a Replica of an Existing Domain
In Windows NT 4.0, this would be the same as asking whether this server will be a Primary Domain Controller or a Backup Domain Controller. Choosing to create a replica of an existing Domain is the same as creating a BDC in a Windows NT 4.0 environment. However, because Windows 2000 allows multi-master updates of the accounts database, there are no Primary Domain Controllers and Backup Domain Controllers, just Domain Controllers. The term replica simply means that the Domain name context will be duplicated from another Domain Controller in the same Domain.
A New Tree Versus an Existing Tree Within Your Enterprise
A tree simply defines a hierarchical naming context. For each child in the tree, there exists exactly one parent. There are three rules that determine how trees function in Windows 2000:
A tree has a single unique name within the forest. This name specifies the tree's root. Be aware that tree names cannot overlap. If mycompany.com is a tree, Europe.mycompany.com cannot exist as a separate tree in the forest. It can exist only as a child Domain within mycompany.com.
The tree has a contiguous namespace. This means that children Domains are directly related to the Domains above and below themselves.
Children Domains inherit the naming from their parent. For example, if mycompany.com is a tree, europe.mycompany.com and asia.mycompany.com would be children within that tree.
A New Forest Versus an Existing Forest
A forest in Windows 2000 is the group of one or more Active Directory trees. All Domains in the forest share a common schema and configuration-naming context. However, it is important to note that separate trees in a forest do not form a contiguous namespace, even if peer trees are connected through two-way transitive trust relationships.
Table 4.3.1 provides a list of other critical information needed before installing the Active Directory on a Windows 2000 server.
Table 4.3.1 Information Needed Before Installing the Active Directory
Item |
Description |
DNS server(s) IP address(es) |
If you plan on installing DNS services on this DC, you will use this server's IP address. Otherwise, you need the IP addresses of your existing DNS servers. |
|
This should be configured in the Network Properties prior to installing the Active Directory. |
Domain's DNS name |
Based on the role of this DC in the enterprise, you may inherit part of this name from the Domain's parent. |
|
Example: mycompany.com |
|
Example: europe.mycompany.com |
Domain's NetBIOS name |
A NetBIOS name for the Domain is required to maintain down-level compatibility. |
|
Example: MYCOMPANY |
Enterprise Administrator name and password |
This is necessary for all scenarios, except for creating a new forest to ensure that you have the appropriate rights to join the forest. |
Level of security compatability |
Some Windows NT 4.0 services (for example, Remote Access Services) are not compatible with native Windows 2000 security. If you need to run these Windows NT 4.0 services against Windows 2000 accounts, make sure you specify that in the Active Directory Wizard (DCPROMO.EXE). |
After you have gathered all the necessary information, you are ready to install the Active Directory. There are three main ways to install the Active Directory on a Windows 2000 server:
The Active Directory Installation Wizard will be automatically launched upon upgrading a Windows NT 4.0 Domain Controller.
From Configure Your Server Wizard, select the Active Directory Tab. Follow the instructions to launch the Active Directory Installation Wizard.
From the Start menu, click Run and execute DCPROMO.EXE.
If you have gathered the necessary information prior to running the Active Directory Wizard, you should be able to follow the prompts provided. Upon completion, the Active Directory will be installed on your server.
Can I Move the Domain?
If you decide that you need to move this Domain to another location within your forest, Microsoft has provided a tool.
For more information, see "Going Deeper: Restructuring Domains" later in this chapter.
Configuring Active Directory Replication
The first Domain Controller that you install in your enterprise will automatically be placed in the Windows 2000 site Default-First-Site-Name. If you do not configure sites and subnets in Windows 2000, all subsequent Domain Controllers will also be added to that site. If you are installing Windows 2000 on a single Local Area Network (LAN) or on a group of LANs connected with high-speed links, no further configuration is necessary.
However, if your implementation includes multiple locations that are connected with less than a T1, you will want to configure Windows 2000 sites. Windows 2000 sites not only allow you to control how the Active Directory replicates and where clients seek authentication services, but you can effectively utilize site-aware client server applications—for example, the Windows 2000 Distributed File System (DFS).
There are two types of Active Directory replication in Windows 2000. Each one has its own set of rules and behaves very differently from the other. In order to configure Active Directory Replication, you need to understand the following:
Replication within a site
Replication between sites
How to use the Active Directory Sites and Services MMC snap-in
Replication Within a Site
Replication within a site is optimized to reduce the time it takes changes to reach other Domain Controllers. To do this, the Knowledge Consistency Checker (KCC) creates a bi-directional ring of connections between all other Domain Controllers in that site. However, as the number of DCs in a site grows, the replication latency continues to be increased. To solve this problem, Microsoft implemented an algorithm, ensuring that all updates are fewer than three hops from the source of the change to the destination. During the initial creation of this replication topology, it is possible for duplicate or unnecessary replication paths to exist. However, the KCC is smart enough to detect these redundant connections and remove them. Finally, it is important to note that replication within a site cannot be configured nor have a schedule applied to it.
Replication Between Sites
Replication between sites is configured to optimize the amount of data sent over the network, given your implementation's tolerance for latency. Each group of sites is connected with a site link. Each of these site links has a relative cost (that you assign). The KCC then generates a least-cost spanning tree, as calculated by the relative cost of the site links. To further optimize the data sent, replication between sites is compressed. Although this causes slightly higher utilization on the target and destination servers, it allows you to more efficiently use your physical connections. Inter-site replication can also be configured to store changes and replicate from a minimum of every 15 minutes to a maximum of every 10,080 minutes. Finally, this type of replication has a configurable schedule of one-hour blocks. For example, you can configure replication to only occur between 5:00 p.m. and 8:00 a.m., if necessary.
For more information on the algorithms used by Active Directory Replication, see the Microsoft White Paper, "Active Directory Architecture."
Using Active Directory Sites and Services
Active Directory Sites and Services is the MMC snap-in that allows you to configure Active Directory replication. Specifically, you can do the following:
Create sites
Create subnets
Create IP site links
See Figure 4.3.1 for an example of using the Active Directory Sites and Services MMC snap-in.
Figure 4.3.1 Configuring sites, subnets, and site links using the MMC snap-in.
You can launch the Active Directory Sites and Services MMC snap-in from the Administrative Tools program group on the Start menu.
For more information on configuring and installing Administrative tools, see Chapter 3.3, "Using Administrative Tools."
Leave the Default Site and Site Link in Place
Do not rename or delete Default-First-Site-Name and DEFAULTIPSITELINK in the Active Directory. A Catch-22 situation exists between sites and site links. When you create a site, you must select a site link that it uses. Also, when you create a site link, you must select at least two sites that it connects. Leaving the defaults in place provides you with a staging area when adding sites and site links.
Creating Sites
Creating a site within the Active Directory Sites and Services MMC snap-in is quite easy. You simply right-click your mouse on the Sites container and select New. Type in the name of your new site and select a site link that it will use to connect it with other sites in your enterprise.
Knowing when to create a site is more difficult. There are only two requirements for creating sites:
All subnets within the site should be "well-connected." The physical links connecting these subnets should always be available. You do not want a site to contain subnets that are linked with a dial-up connection or a connection that is available only a few hours each day.
All subnets within the site should be connected via LANs. If you have multiple LANs connected with high-speed links, they are also good candidates for inclusion in a single site. Microsoft recommends that all subnets within the site be connected with links greater that 64 Kbps.
Based on your infrastructure and the needs of your organization, you should attept to find the correct balance between one site and many sites. Table 4.3.2 goes over some of the basic pros and cons of small versus large sites.
Table 4.3.2 Small Number of Sites Versus Large Numbes of Sites
Scenario |
Pros |
Cons |
Small number of sites |
Less site and site link administration. Replication latency and complexity is minimized. |
Large number of DCs in each site will impact DC performance. |
|
|
Less control over which DCs a client will select. |
Large number of sites |
Greater optimization of the usage of physical links is possible. |
Greater replication complexity. |
|
Greater control over which DCs a client will select. |
Higher level of administration and maintenance of sites and site links. |
Create site names from general to specific. For example, USA-AZ-Phoenix. Because sites are sorted alphabetically, this allows you to find them more easily in the Active Directory Sites and Services MMC snap-in.
Creating Subnets
In Windows 2000, a site is a collection of subnets. Also, subnets allow clients and servers to know what site they are in. For example, if you install a new Domain Controller, and the DC's subnet is already identified, that DC will be installed in the site that the subnet belongs to.
To create subnets in Windows 2000, do the following:
Run the Active Directory Sites and Services MMC snap-in.
Right-click the Subnet container and select New Subnet.
Enter the address of the subnet and the subnet mask.
Select the site that this subnet belongs to.
If your company groups subnets together at a physical location, you do not need to create subnet objects for every physical subnet. This can greatly simplify the subnet object maintenance in Windows 2000. For example, if the Boston office exclusively uses subnets beginning with 10.1.0.0, you can define a single subnet for that location. You do this by entering 10.1.0.0 as the subnet address and 255.255.0.0 as the subnet mask. This way, you can define one subnet for the entire location, rather than manually entering each physical subnet (10.1.1.0, 10.1.2.0, and so on).
Creating IP Site Links
After you decide that you need to implement multiple Windows 2000 sites, you need to plan how those sites will be connected. Inter-site transports, or site links, connect your sites and control replication and site coverage (if a Domain controller does not exist at a site).
Table 4.3.3 shows the items used to configure site links and their acceptable items.
Table 4.3.3 Configurable Items in IP Site Links
Item |
Description |
Range |
Cost |
The relative priority that is given to one link over another Given the choice, the lowest-cost link will be chosen. Used to calculate the replication topology and identify "closest" sites. By default, the cost of a site link is 100. |
Min: 1 Max: 32,767 |
Schedule |
The times that the link is available for replication. By default, the link is always available. |
Configurable in one-hour blocks |
|
Example: Use this to force replication to occur only during off-peak hours. |
|
Replication Interval |
The period between the start of replication cycles. By default, sites replicate with each other every 180 minutes. |
Min: 15 minutes Max: 10,080 minutes (7 days) |
To create site links in Windows 2000, do the following:
Run the Active Directory Sites and Services MMC snap-in.
Select the Inter-Site Transports container to expand it.
Right-click the IP container and select New Site Link.
Enter the name of the site link and select at least two sites that will use this link.
Site links do not need to simply be point-to-point connections. It is possible for a site link to contain more than two sites. This is useful for reducing the number of site links that need to be created and managed. For example, if your company has three sites, each connected to one other with a T1, you can set up a single site link in which all three sites are members. This greatly simplifies the number of links that need to be created for large implementations.
Site Coverage
Not all sites in the Active Directory need to contain a Domain Controller. This is because of an important feature known as site coverage. By default, all Windows 2000 Domain Controllers will examine the sites and site links in the enterprise. The DC will then register itself in any site that does not already have a DC for that Domain.
This means that every site wil have a DC defined, by default, for every Domain in the enterprise, even if that site does not physically contain a DC for that Domain. The DCs that are published will be those from the "closest site" defined by the replication topology.
It is also possible to manually configure a DC to register in another site, regardless of the replication topology. This can be done by manually updating a Registry value on the Domain Controller that you want to register in another site. This is implemented with the SiteCoverage:REG_MULTI_SZ value in HKEY_LOCAL_MACHINE\ System\ CurrentControlSet\ Services\ Netlogon\ Parameters\.
Set this value to the name of the site or sites that you want this DC to register in. The site names exactly match the site names created in the Active Directory Sites and Services MMC snap-in. Within the SiteCoverage value, there must be only one site on each line.
Best Practices for Designing Your Active Directory Replication
Create sites based on collections of high-speed networks. You need to decide what determines a "high-speed" network, based on your needs.
Put DCs into those sites based on authentication and authorization needs. In some sites, it may be acceptable to use Domain Controllers in remote locations. However, be sure to assess the impact of a WAN outage.
Configure links based on the logical WAN to optimize replication between DCs.
Modifying the Active Directory Schema
The schema is the set of class and attribute definitions that exist in the Active Directory. All Domains in the enterprise share the schema. You should make schema modifications only when absolutely necessary.
In most implementations of Windows 2000, it is very likely that manual schema extensions will never be required. Consequently, three deliberate safety features protect the schema.
To allow updates to be made to the schema, you must do the following:
Configure your client to run the Active Directory Schema Manager MMC.
Use the Active Directory Schema MMC snap-in to change the Schema Operation Master to allow schema updates.
Be designated as a member of the Schema Administrators Global Security Group, which is located in the forest root.
Schema Modifications Are Permanent!
Schema modifications cannot be reversed and have serious implications throughout the Active Directory. After a class or attribute is added to the schema, it cannot be deleted, although it can be disabled.
Configure Your Client to Run the Active Directory Schema MMC Snap-in
The Active Directory Schema MMC is not installed by default on either Windows 2000 Professional Edition or Windows 2000 Server. To install the snap-in on Windows 2000 Professional, simply install the Administrative tools.
For instructions on installing the Administrative tools, see Chapter 3.3, "Using Administrative Tools."
On the Windows 2000 server family, you must enable the snap-in by registering the Schema Management Dynamic Linked Library (DLL). To do this, you need to run regsvr32.exe schmmgmt.dll from a command prompt.
After the Administrative tools are installed and enabled on your computer, you can then run MMC.exe and add the Active Directory Schema Console. Figure 4.3.2 shows an example of the Active Directory Schema MMC snap-in.
For more information on configuring the MMC console, see Chapter 3.2, "Using MMC Consoles."
Figure 4.3.2 Modifying the Windows 2000 schema using the MMC snap-in.
Use the Active Directory Schema MMC Snap-in to Change the Schema Operation Master to Allow Schema Updates
By default, all Domain Controllers prevent modifications on the schema. To modify the schema, you must configure the Schema Operations Master to allow updates. You accomplish this by executing the following steps:
Run the Active Directory Schema MMC snap-in.
Right-click the Active Directory Schema container.
Select Operations Master.
At the bottom of the Change Schema Master dialog box, select the checkbox to enable the option The Schema may be modified on this Domain Controller.
You will be able to do this only if you are a member of the Schema Admins Global Security group in the forest root.
The schema is also protected by a Windows 2000 Access Control List. By default, only members of the Schema Admins Global Security Group can make changes to the schema.
Where Should the Schema Admins Group Exist?
Because the Schema Admins group is a Global group, your account must exist in the forest root Domain. If your forest root Domain is in Windows 2000 Native mode, you can change this group to a Universal group, which can contain users from outside the local Domain.
For more information on Windows 2000 Groups, see Chapter 4.5, "Creating and Managing Groups."
Common Examples of Changes You Might Need to Make to the Schema
Although it is not recommended that you extend the schema (for example, add classes or attributes), it is sometimes necessary to change the properties of existing attributes. Even though these types of changes can be reversed, you should still plan carefully prior to making these changes.
There are two main types of schema changes that might be desirable to make:
Mark attributes for inclusion in the Global Catalog
Index attributes in the Active Directory
Mark Attributes for Inclusion in the Global Catalog
Sometimes, it might be necessary to include certain user attributes in the Global Catalog (GC) that are not included in the GC by default. For example, one common practice among large companies is to mark the user attribute, employeeID, for GC replication. Now, an Active Directory Enabled application could query the GC for an employeeID and get the resulting user object.
To mark an attribute for inclusion in the Global Catalog:
Run the Active Directory Schema MMC snap-in.
Select the Attributes container.
Right-click the attribute you want to modify and select Properties.
Enable the Replicate this attribute to the Global Catalog checkbox.
Index Attributes in the Active Directory
The second type of change that may be desirable is to index attributes in the Active Directory. Doing so should increase the speed with with your Active Directory-enabled application can search that attribute.
To index an attribute in the Active Directory, do the following:
Run the Active Directory Schema MMC snap-in.
Select the Attributes container.
Right-click the attribute you want to modify and select Properties.
Enable the Index this attribute in the Active Directory checkbox.
Going Deeper: Restructing Domains
No matter how much planning and effort you put into your implementation of the Active directory, it will be necessary to modify parts of the design at some point in time. To be able to restructure Domains in your Active Directory, Microsoft has provided some tools in Windows 2000. Specifically, there are tools that will help you do the following:
Move objects within a Domain
Move objects between Domains in the forest
Restructure entire Domains
Move Objects Within a Domain
Moving objects within a Domain is the simplest of all restructuring activities. This functionality is built into the the Active Directory Users and Computers MMC snap-in. To move an object, right-click the object and select All Tasks; then choose Move. You will be presented with a list of containers within the Domain. Simply select the appropriate destination. Other MMC snap-ins also have this functionality for the objects they manage. For example, you can move Domain Controllers between sites in the Active Directory Sites and Services MMC snap-in.
Move Objects Between Domains in the Forest
To make it possible to move objects or collections of objects from one Domain in the forest to another, Microsoft provides the MOVETREE.EXE utility in the Windows 2000 Resource Kit.
MOVETREE.EXE commands can be quite complex. A complete list of parameters can be found by running MOVETREE.EXE /? or checking the Windows 2000 Resource Kit online documentation.
Before attempting to use MOVETREE.EXE, there are a couple of things that you need to do in advance. First, the destination Domain must be in Native mode. Second, the immediate parent of the object you are moving must exist. In the following example, the OU Executives must exist in the Domain mycompany.com.
Example of a Movetree Command
Situation: You need to move a single user object John Q. Public in the OU Finance from the Domain eur.mycompany.com to the OU Executives in the Domain mycompany.com:
Restructure Entire Domains
In Windows 2000, it is not possible to prune and graft Domains, either within a forest or between forests. However, it is possible to achieve the same end result with a little effort.
To make it possible to restructure Domains and to aid in the migration to Windows 2000, Microsoft has jointly developed the Active Directory Migration Tool (ADMT). This tool makes it possible to move all or part of a Domain to another location. For example, you can split Domains, consolidate Domains, or effectively move Domains by executing the following steps:
Create the target Domain in your forest.
Use the ADMT to migrate the objects from the source to the target.
Decommission the source Domain.
Create the Target Domain In Your Forest
One drawback of the ADMT is that you cannot perform an intact Domain move. The target Domain must exist in the Windows 2000 forest as a Native mode Domain. Follow the steps described earlier in this chapter to create the new Domain. This Domain will now be the destination for the objects that you are moving.
Note: This step is not necessary if you are consolidating Domains and at least one of them is in the Windows 2000 forest. Simply pick one of the Windows 2000 Domains in your forest as the target and migrate the other Domains' objects to that Domain.
Use the ADMT to Migrate the Objects from the Source to the Target
The ADMT provides major benefits over utilities such as MOVETREE when doing major Domain restructuring or migrations. These benefits include the following:
Task based MMC snap-in. The tool looks and behaves like other Windows 2000 tools.
Provides reporting and modeling tools. You have the ability to simulate migrations and view reports. Reports are saved as HTML files to allow them to be posted to your intranet.
Provides group synchronization. Without this tool, you would be required to migrate an entire closed set. Closed sets are collections of users and groups that can be moved without cloning. It is possible that the smallest closed set is the entire Domain. For example, due to the rules of group membership, you cannot move a Global group until all members of that group are in the destination Domain. Also, you cannot move users without moving their Global groups.
ADMT continues the operation, even if there are individual failures. This prevents a single failure from causing the entire operation to fail.
For more information on the ADMT, see the Microsoft Web site at http://www.microsoft.com/.
Decommission the Source Domain
If desired, you can decommission the source Domain. If this Domain is part of your Windows 2000 forest, you need to run the Active Directory Wizard on each of the Domain Controllers to uninstall the Active Directory. On the last Domain Controller (preferably the one that owns the PDC FSMO), you will specify that this is the last DC in this Domain. This will remove all references of that Domain from the Active Directory.
This step is not necessary if you are splitting Domains and the source Domain is in the Windows 2000 forest. For example, if you want to split a Domain in half, you could migrate half of the objects to the new Domain and leave half in the current Domain.