Once you've completed planning, the process of implementing Active Directory is similar whether you are installing Active Directory for the first time or extending your existing Active Directory infrastructure. In either case, you need to take the following steps:
Install the necessary domain controllers and assign any other needed roles to these servers
Create the necessary organizational units (OUs) and delegate administrative control over these OUs as necessary
Create any necessary user, group, and computer accounts as well as the resources that are required for use in a domain
Use group policy and local security policy to set default settings for user and computer environments in any domains and OUs you've created
Create the necessary sites and configure those sites for use and replication
In this chapter, I examine the steps for installing domain controllers, creating OUs, and delegating administrative control. Chapter 37, discusses creating user, group, and computer accounts as well as related group policy. Chapter 38, discusses managing group policy and local security policy. Chapter 39, discusses creating sites and managing replication.
Whenever you work with a Microsoft Windows component as complex as Active Directory, you should take time to carefully consider the physical implementation. As with the installation of Microsoft SQL Server, Microsoft Exchange Server, or Microsoft Internet Information Systems (IIS), you should evaluate hardware requirements, plan for the system's backup needs, and consider how the system will be used.
Every domain controller is essentially a database server with a complex replication system, and as such, when you select hardware for and configure domain controllers, you should use all the care and attention that you'd give to one of your mainstay database servers. The hardware you choose for the domain controllers should be as robust as the hardware for your database servers.
The following guidelines should be taken into consideration:
Processor The CPU for a domain controller needs to be relatively fast. As soon as you install the second domain controller in a forest, a process called the knowledge consistency checker (KCC) begins running on every domain controller. The KCC is responsible for generating the replication topology and dynamically handling changes and failures within the replication topology. By default, the KCC on every domain controller recalculates the replication topology every 15 minutes. The more complex the replication topology, the more processing power it takes to perform, and, in many cases, even in small domain environments, the calculations performed by the KCC will cause the CPU to go to 100 percent utilization. This is acceptable for short durations. However, if the domain controller doesn't have a fast enough CPU, generating the replication topology in a complex environment could take several minutes rather than several seconds, which would severely affect the performance of all other processes running on the server.
Multiprocessing Some installations may benefit from having domain controllers with multiple CPUs. With multiple processors, you may see significant performance improvements. However, rather than having a single beefy domain controller, it is better to have multiple domain controllers placed appropriately.
Memory Domain controllers may use more memory than other servers. In addition to running standard processes, domain controllers must run special processes, such as storage engine processes, knowledge consistency checking, replication, and garbage collection. Therefore, most domain controllers should have at least 512 megabytes (MB) of RAM as a starting point. Be sure to monitor memory usage and upgrade as necessary.
Disks The data storage capacity you need depends entirely on the number of objects related to users, computers, groups, and resources that are stored in the Active Directory database. The initial installation of Active Directory requires only about 25 MB of available space. By default, the database is stored in the Ntdis.dit database file on the system volume, as are related log files. When the database and log files are stored together, the storage volume should have free disk space of at least 20 percent of the combined size of the database and log files. When the database and log files are stored separately, each storage volume should have free disk space of at least 20 percent of either the database or the log files, as appropriate.
Data protection Domain controllers should use fault-tolerant drives to protect against hardware failure of the system volume and any other volumes used by Active Directory. I recommend using a redundant array of independent disks (RAID), either RAID 1 or RAID 5. Hardware RAID is preferable to software RAID.
As part of the hardware configuration, you should consider where you will install the files used by Active Directory. Active Directory database and log files are stored by default in the %SystemRoot%NTDS folder, while the Active Directory system volume (Sysvol), which is created as a shared folder, and contains policy, scripts, and other related files, is stored by default in the %SystemRoot%SYSVOL folder. These locations are completely configurable during installation; some consideration should be given to whether you want to accept the defaults or store the files elsewhere. You'll get much better scalability and performance if you put the database and log files on different volumes, each on a separate drive. The Active Directory Sysvol can remain in the default location in most cases.
Note
If you decide to move the Sysvol, it must be moved to an NTFS-5 volume. Because of this requirement, a volume formatted under Microsoft Windows NT is not acceptable. For security reasons, the database and log folders should be on NTFS-5 volumes as well, but this isn't a requirement.
Active Directory is dependent on network connectivity and the Domain Name System (DNS). Domain controllers should be configured to use static Internet Protocol (IP) addresses and have the appropriate primary and secondary DNS servers set in their Transmission Control Protocol/Internet Protocol (TCP/IP) configuration, as discussed in Chapter 24. If DNS isn't available on the network, you have the opportunity to make DNS available during the installation of Active Directory. Implement DNS as discussed in Chapter 26 and Chapter 27, and be sure to configure the DNS server to use itself for DNS resolution. If you previously deployed Microsoft DNS, as discussed in Chapter 26 and Chapter 27, the DNS environment should already be set to work with Active Directory.
If you are using a Domain Name System (DNS) server that does not use the Windows DNS, you can verify that the DNS server will work properly with Active Directory by using the Domain Controller Diagnostic Utility (Dcdiag.exe). This utility is included as part of the Windows Support Tools. Once you've installed the Support Tools, you can run Dcdiag and test the DNS configuration by typing the following command at the command prompt:
dcdiag /test:dcpromo /dnsdomain:DomainName /newforestwhere DomainName is the name of the DNS domain in which the domain controller is located. Consider the following example:
dcdiag /test:dcpromo /dnsdomain:cpandl.com /newforest
Here, you run a test of the Active Directory Installation Wizard (Dcpromo.exe) to see if the DNS domain cpandl.com is compatible for creating a new forest. Any errors in the output of the test would need to be examined closely and resolved.
Domain controllers are backed up differently than other servers are. To back up Active Directory, you must back up the System State. A backup of the System State includes the Active Directory database and log files, the Sysvol, the Registry, system boot files, and the COM+ registration database. These items must be backed up as a set and cannot be divided. To keep the System State intact when you place the volumes related to Active Directory on a Storage Area Network (SAN), you must also place the operating system (system and boot volume) on the SAN. This means that you must then boot from the SAN.
Booting from a SAN and configuring Active Directory so that the related volumes are on a SAN enables several fast recovery scenarios—most of which make use of the Volume Shadow Copy service (VSS). For instance, a domain controller is using the C, D, and E volumes: C for the operating system and Sysvol, D for the Active Directory database, and E for the Active Directory logs. Using a third-party backup utility that makes use of the Volume Shadow Copy service, you may be able to use that backup software to create shadow copies of the System State on separate Logical Unit Numbers (LUNs) on the SAN.
On the SAN, let's say that volumes C, D, and E correspond to LUNs 1, 2, and 3 and that the current shadow copy of those volumes is on LUNs 7, 8, and 9. If Active Directory were to fail at this point, you could recover by performing the following steps:
Use the DiskRAID utility to mask the failed LUNs (1, 2, and 3) so that they are no longer accessible.
Use the DiskRAID utility to unmask the shadow-copied LUNs (7, 8, and 9) so they are usable.
You would then boot the domain controller to BIOS, set the boot device to LUN 6, and then reboot.
You've now recovered Active Directory. When the domain controller starts, it will recover the Active Directory database and synchronize with the rest of the domain controllers in the organization through regular replication.
Network clients connect to Active Directory for logon and authentication and to perform Lightweight Directory Access Protocol (LDAP) lookups. In a standard configuration of Active Directory running on Microsoft Windows Server 2003, communications between clients and servers are secure and use either Server Message Block (SMB) signing or secure channel encryption and signing. Secure communications are used by default because the default security policy for Windows Server 2003 has higher security settings than the security policies for previous versions of Windows.
Windows clients running versions earlier than Microsoft Windows 2000 do not natively support either of these secure communications methods. Therefore, these Windows clients cannot log on or authenticate in a Windows Server 2003 domain until you update them.
To allow Microsoft Windows 95 and Microsoft Windows 98 clients to securely communicate with Active Directory, you need to install the Directory Services Client on these systems.
To allow Windows NT clients with Service Pack 3 and earlier to securely communicate with Active Directory, you need to install the Directory Services Client or Service Pack 4 or later on these systems.
Windows clients running Windows 2000 or later do not need to have a separate client installed. These clients all natively support SMB signing, secure channel encryption and signing, or both.
Note
Note that Microsoft Windows for Workgroups does not support secure communications in this way and cannot be updated. This means that you'll need to upgrade any clients running Windows for Workgroups.
Inside Out: Secure communications for domain controllers
One reason for configuring secure communications by default is to prevent certain types of security attacks. Secure communications specifically thwarts man-in-the-middle attacks, among others. In this attack, a third machine gets between the client and the server and pretends to be the other machine to each. This allows the man-in-the-middle machine to intercept and modify data that is transmitted between the client and the server. That said, if you must disable secure communications, you can do so. Remember that disabling the secure communications requirement won't allay the need to install an Active Directory client on Windows clients running versions earlier than Windows 2000—they'll still need a client, but there is an unsecured client for Windows for Workgroups as well as Windows NT 4 clients with Service Pack 3 and earlier.
To disable the secure communications requirement, follow these steps:
Start Active Directory Users And Computers. Right-click Domain Controllers in the console tree, and then select Properties.
In the Properties dialog box, select the Group Policy tab, and then click Edit.
In the Group Policy Object Editor, expand Computer Configuration, Windows Settings, Security Settings, Local Policies, and Security Options.
Under Security Options, right-click Domain Member: Digitally Encrypt Or Sign Secure Channel Data (Always), and then select Properties.
In the Properties dialog box, select Disabled, and then click OK.