Establishing Secure Domain Controller Build Practices
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2, Windows Server 2008, Windows Server 2008 R2
Secure domain controller build practices are essential to sustained network security. When domain controller builds are planned and implemented according to predictable and repeatable build practices, you can ensure a secure platform on which to run Active Directory. You can ensure predictability by setting a standard order for configurations. You can ensure repeatable builds by automating the build process. Automation adds a large measure of security because it minimizes the possibility of rogue programs, rogue services, and insecure configuration being introduced into the build process through manual intervention.
Automated Installation Processes
Automated installation processes can be categorized as image-based and answer-file-based:
An image-based installation is a method of copying, or "cloning," a preconfigured operating system and software applications from a master computer onto destination servers. For the purposes of this chapter, the term image-based installation refers to installations using the System Preparation tool (Sysprep) installation tool.
An answer-file-based installation uses a text file that contains setup instructions. These instructions include the following:
Answers to the questions that Windows Setup normally presents during an installation
Instructions for configuring operating system settings
Instructions for installing applications without user intervention
For the purposes of this guide, the term answer-file-based installation refers to the unattended setup tool Winnt32.exe and the Remote Installation Services (RIS) Setup (Risetup.exe) tool. It is important to note that to use RIS or to perform an installation by using Sysprep or unattended setup from a shared distribution directory, you need reliable, high-bandwidth network connections.
Because image-based installation encompasses all configuration settings, including service and registry settings, this method is recommended over answer-file-based installation methods, which do not ensure consistent and uninterrupted configuration of all services and registry settings.
Note
You cannot use RIS or Sysprep to upgrade an operating system. The only automated installation method that you can use to perform upgrades is unattended installation using Winnt32.exe.
Sysprep, RIS, and unattended setup are Windows Server 2003 technologies, and Table 5 provides a comparison of their characteristics. Automated setup software from other sources might have combinations of the features that are found in each of these technologies. For more information about automated setup software from other sources, see the documentation that accompanies the automated setup software.
Table 5 Comparison of Windows Server 2003 Automated Installation Methods
| Characteristics | Sysprep | RIS | Unattended Setup |
|---|---|---|---|
Provides image-based installations. |
Yes |
Yes |
No |
Accommodates a variety of hardware configurations from a single automation script or image. |
No |
Yes |
Yes |
Requires a high-bandwidth, well-connected network infrastructure. |
No |
Yes |
No |
Appropriate for datacenter deployments. |
Yes |
Yes |
No |
Appropriate for branch office deployments. |
Yes |
No |
Yes |
For more information about using Sysprep, RIS, and unattended setup, see "Overview of Choosing an Automated Installation Method" in Automating and Customizing Installations of the Windows Server 2003 Deployment Kit (or see "Overview of Choosing an Automated Installation Method" on the Web at https://go.microsoft.com/fwlink/?LinkId=4749).
Using an Image-Based Installation Process
To automate installation by using an image-based process, you first manually install a single server with all the appropriate settings for your deployment. Then you create an image of that server, which you can use to deploy multiple domain controllers automatically, so that they have the exact same configuration. As part of the image, you can configure setup to start Active Directory installation (Dcpromo.exe) automatically and to use an answer file for the installation.
The general steps for an image-based installation are as follows:
Install and configure Windows Server 2003 on a server, and create an image of the installed server. Use Sysprep to define a disk image of the installed server.
Use one of the following image-based installation technologies to deploy the image to the target computer:
Sysprep
RIS
Automated setup software from another source
After the image is deployed, restart the computer and complete any further setup steps that may be required by the image-based installation technology. For example, complete Sysprep mini setup.
After you complete the image-based installation and the computer restarts, log on to the computer. The Active Directory Installation Wizard starts up automatically, and it retrieves information from the answer file. However, because credentials are not provided in the answer file, you are prompted to enter valid credentials to install Active Directory.
After Active Directory installation is complete, the computer automatically restarts as a domain controller.
For more information about implementing image-based setup of Windows Server 2003, and before following the instructions in this guide, see "Designing Image-based Installations with Sysprep" and "Designing RIS Installations" in Automating and Customizing Installations of the Windows Server 2003 Deployment Kit (or see "Designing Image-based Installations with Sysprep" on the Web at https://go.microsoft.com/fwlink/?LinkId=4753 and "Designing RIS Installations" on the Web at https://go.microsoft.com/fwlink/?LinkId=4752).
Using an Answer-File-based Installation Process
The recommended process for secure automated domain controller installation is the image-based installation process. However, if you must use a non-imaged-based process, unattended setup using an answer file generally presents few security risks and provides consistent server configuration.
For more information about using unattended setup of Windows Server 2003, see "Designing Unattended Installations" in Automating and Customizing Installations of the Windows Server 2003 Deployment Kit (or see "Designing Unattended Installations"on the Web at https://go.microsoft.com/fwlink/?LinkId=4751).
Creating the Image for Windows Server 2003 Image-Based Installations
When you use the image-based process to install Windows Server 2003, perform the following tasks to prepare the image computer:
Perform a clean installation of Windows Server 2003, and configure server security as specified in the next section, Ensuring Predictable, Repeatable, and Secure Domain Controller Deployments.
Configure the computer registry to instruct the computer to run Dcpromo.exe when the computer starts for the first time. Configure the Active Directory installation answer file selections as described in Configuring the Automatic Installation of Active Directory.
Create an image of the installed computer. For information about how to create the image, see "Designing Image-based Installations with Sysprep" in Automating and Customizing Installations of the Windows Server 2003 Deployment Kit (or see "Designing Image-based Installations with Sysprep" on the Web at https://go.microsoft.com/fwlink/?LinkId=4753).
Ensuring Predictable, Repeatable, and Secure Domain Controller Deployments
Throughout the domain controller deployment process, there are security configuration settings that you need to apply to all domain controllers. To ensure that these security settings are applied uniformly to all domain controllers, implement a predictable, repeatable domain controller deployment process, such as the process specified below:
Install Windows Server 2003 with secure configuration settings and the latest service packs and hotfixes.
Create a strong Administrator password.
Disable NTFS automatic 8.3 name generation.
Run virus-scanning software on the server.
Enable only essential services.
Create a reserve file to enable recovery from disk-space attacks.
Installing Windows Server 2003 with Secure Configuration Settings, Service Packs, and Hotfixes
When you create the first master image of a Windows Server 2003 server to be used for installing and promoting multiple domain controllers, apply the configuration settings that are listed in Table 6 to enhance security.
In situations in which your domain controllers already exist, check the recommendations in Table 6 and then modify the domain controller configurations accordingly.
Table 6 Secure Configuration Settings for Windows Server 2003 Domain Controllers
| Setting | Rationale | |
|---|---|---|
|
Format all partitions as NTFS. |
NTFS provides a secure file system. |
|
|
Install only TCP/IP as the transport protocol. |
Limiting transport protocols reduces the attack surface on the domain controller. |
|
|
Do not install Simple Mail Transfer Protocol (SMTP) during Windows Server 2003 setup unless you are using it for mail-based, intersite Active Directory replication. |
SMTP is not required for normal domain controller operations unless it is used for mail-based, intersite replication. Excluding SMTP reduces the attack surface on the domain controller. By default, SMTP is not selected. |
|
|
Install DNS by selecting it in the Networking category during Windows Server 2003 setup. |
Installing DNS during Windows Server 2003 setup ensures that DNS is available in the master image. |
|
Note
In contrast to Windows 2000 Server installation, Internet Information Services (IIS) is not installed by default in Windows Server 2003 installation. IIS is not required on a domain controller, and eliminating IIS reduces the attack surface on the domain controller.
After you complete the installation of Windows Server 2003, obtain any additional security protections that may have been implemented for Windows Server 2003 by applying the most recent service packs and security-related hot fixes from the Microsoft Web site at https://go.microsoft.com/fwlink/?LinkID=7420.
Creating a Strong Administrator Password
Use a strong password for the computer local administrator account. The local administrator account becomes the domain Administrator account after the server is promoted to a domain controller. A strong password minimizes the threat of an attacker guessing (cracking) the password and acquiring the credentials of the administrator account (spoofing). A strong password includes all of the following characteristics:
Contains at least nine characters.
Does not contain an account name, real name, or company name.
Does not contain a complete dictionary word.
Is significantly different from previous passwords. Passwords that increment (Password1, Password2, Password3 ...) are not strong.
Contains at least one symbol in the first seven characters.
Contains characters from each of the groups listed in Table 7.
Table 7 Groups of Characters to Include in Strong Passwords
| Types of Characters | Examples | |
|---|---|---|
|
Uppercase letters |
A, B, C ... |
|
|
Lowercase letters |
a, b, c ... |
|
|
Numerals |
0, 1, 2, 3, 4, 5, 6, 7, 8, 9 |
|
|
Symbols found on the keyboard (all keyboard characters not defined as letters or numerals) |
` ~ ! @ # $ % ^ & * ( ) _ + - = { } | [ ] \ : " ; ' < > ? , . / |
|
Examples of strong passwords are Pf$sw0rR1 and J*p2leO4>F.
Disabling NTFS Automatic 8.3 Name Generation
Many viruses and utilities that are used by attackers are 16-bit applications that expect file names to be compatible with 8.3 automatic name generation. Secure domain controllers do not run 16bit applications locally. Therefore, disable 8.3 automatic name generation to prevent these viruses and utilities from compromising security on your domain controllers.
To disable automatic 8.3 name generation, set the following entry in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem:
Entry name: NtfsDisable8dot3NameCreation
Data type: REG_DWORD
Value: 1
Warning
Incorrectly editing the registry can have serious, unexpected consequences that might require you to restore the registry or to reinstall Windows. Before you edit the registry, create an emergency startup disk and back up any critical data. For more information, see the Registry Reference for Microsoft Windows Server 2003 at https://go.microsoft.com/fwlink/?LinkId=4543.
You can create a script that modifies this registry value on all domain controllers in the domain automatically by performing the following tasks:
Create the ComputerSearch.vbs script, and copy it to a computer that is a member of the domain.
For information about how to create the script, see "Identifying Computers to Receive New Registry Settings with ComputerSearch.vbs" in "Appendix B" of the Best Practice Guide for Securing Active Directory Installations and Day-to-Day Operations: Part II. To download this document, click the link under "Planning & Deployment Guides" on the Microsoft Web site at https://go.microsoft.com/fwlink/?LinkId=18591.
Create a list of domain controllers in the domain by typing the following command at a command prompt: Cscript computersearch.vbs /r:DC
Save this list as ComputerSearch-date-time**.csv**.
Create the ApplyReg.vbs script, and copy it to a computer that is a member of the domain.
For information about how to create the script, see Applying Registry Settings to a List of Computers with ApplyReg.vbs in the Best Practice Guide for Securing Active Directory Installations and Day-to-Day Operations: Part II, Appendix B (https://go.microsoft.com/fwlink/?LinkId=140260).
Create a .reg file for the following path, registry entry, and value:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Filesystem]
"NtfsDisable8dot3NameCreation"=dword:00000001
Save the file as Registryfile.reg. For information about how to create the .reg file, see "Creating a .reg File" in Appendix: Procedures section:
Apply the registry entry to the domain controllers by typing the following command at the command prompt:
Cscript ApplyReg.vbs /r:registryfile.reg /f:ComputerSearch-date-time.csv
This set of tasks applies the registry changes that are expressed in the file registryfile.reg to all computers that are listed in the file ComputerSearch-date-time.csv.
Running Virus-Scanning Software on the Server
After you install Windows Server 2003, but before you promote the server to a domain controller, install and run antivirus software on the server to ensure that no viruses have been introduced during the installation of Windows Server 2003.
When you use an image-based process for automating the installation of Windows Server 2003, make sure that you install the virus scanning software as part of the image. For other processes, install and run the virus scanning software immediately after installing Windows Server 2003.
The behavior of some antivirus software can interfere with the proper operation of your domain controllers. Some versions of antivirus software modify the security descriptor while scanning files. When the software scans the files that are stored in the SYSVOL folder, the modification of the security descriptor triggers the File Replication Service (FRS), and which creates high volumes of replication traffic unnecessarily.
For more information about using antivirus software on your domain controller, see Running Virus Scans on Domain Controllers later in this guide.
Note
If you are starting Dcpromo.exe automatically by using one of the RunOnce methods discussed later in this section, modify your scripts to run the virus scanning first and then start Dcpromo.exe.
Enabling Only Essential Services
Every service that is running on a domain controller provides a potential target for an attack that can compromise domain controller security. To reduce the surface area of attack, it is prudent to enable only those services that are essential to normal domain controller function.
Table 8 lists the services that are installed during Windows Server 2003 installation when you follow the security recommendations in the Installing Windows Server 2003 with Secure Configuration Settings, Service Packs, and Hotfixes section. Table 8 also provides the recommended startup type for each service.
Note
For new domain controller deployments, configure the startup types for these services before creating the master image for image-based deployments. For existing domain controllers, combine Table 8 and Table 9 to determine the recommended startup type of these services.
Table 8 Recommended Services to Install on a Windows Server 2003 Domain Controller
| Service Name | Default Startup Type | Recommended Startup Type | Comment | |
|---|---|---|---|---|
|
Alerter |
Disabled |
(No change) |
Notifies selected users and computers of administrative alerts. |
|
|
Application Layer Gateway Service |
Manual |
(No change) |
Provides support for application-level protocol plug-ins, and enables network/protocol connectivity. |
|
|
Application Management |
Manual |
(See comment) |
Provides software installation services for applications that are deployed by using Add or Remove Programs. On dedicated domain controllers, this service can be disabled to prevent unauthorized installation of software. |
|
|
Automatic Updates |
Automatic |
(See comment) |
Provides the download and installation of critical Windows updates, such as security updates or hotfixes. This service can be disabled when automatic updates are not performed on the domain controller. |
|
|
Background Intelligent Transfer Service |
Manual |
(See comment) |
Provides a background file transfer mechanism and queue management, and it is used by Automatic Update to automatically download programs (such as security updates). This service can be disabled when automatic updates are not performed on the domain controller. |
|
|
ClipBook |
Disabled |
(No change) |
Enables the Clipbook Viewer to create and share "pages" of data to be reviewed by remote users. |
|
|
COM+ Event System |
Manual |
(No change) |
Provides automatic distribution of events to Component Object Model (COM)+ components. |
|
|
COM+ System Application |
Manual |
(No change) |
Manages the configuration and tracking of components that are based on COM+. |
|
|
Computer Browser |
Automatic |
(See comment) |
Maintains the list of computers on the network, and supplies the list to clients that request the list. If you do not have earlier versions of applications or clients that use this feature, set the startup type for this service to Manual. |
|
|
Cryptographic Services |
Automatic |
(No change) |
Provides three management services:
|
|
|
DHCP Client |
Automatic |
(See comment) |
Required to update resource records by using dynamic update. If your organization does not use dynamic IP addresses for your domain controllers, the startup type for this service can be set to Manual. |
|
|
Distributed File System |
Automatic |
(No change) |
Manages logical volumes that are distributed across a LAN or wide area network (WAN). This service is required for the Active Directory SYSVOL share. |
|
|
Distributed Link Tracking Client |
Automatic |
Disabled |
Maintains links between NTFS v5 files within the domain controllers and other servers in the domain. Disable this service on dedicated domain controllers. |
|
|
Distributed Link Tracking Server |
Disabled Automatic * |
(No change) Disabled* |
Tracks information about files that are moved between NTFS v5 volumes throughout a domain. Disable this service on dedicated domain controllers. |
|
|
Distributed Transaction Coordinator |
Automatic |
(No change) |
Coordinates transactions that span multiple resource managers, such as databases, message queues, and file systems. |
|
|
DNS Client |
Automatic |
(No change) |
Provides resolution of DNS names. |
|
|
DNS Server |
Automatic |
(See comment) |
Required for Active Directory–integrated DNS zones. If the domain controller is not a DNS server, this service is Disabled. |
|
|
Error Reporting Service |
Automatic |
(See comment) |
Collects, stores, and reports unexpected application crashes to Microsoft. If you do notplan to report critical operating system and application faults to Microsoft for analysis, you can disable this service. |
|
|
Event Log |
Automatic |
(No change) |
Writes event messages that are issued by Windows-based programs and components to the event log files. |
|
|
Fax* |
Automatic* |
Disabled* |
Provides the ability to send and receive faxes through fax resources that are available on the domain controller and on the network. On dedicated domain controllers, this service can be disabled, because sending and receiving faxes is not a normal function of a domain controller. |
|
|
File Replication Service |
Automatic |
(No change) |
Enables files to be copied automatically and maintained simultaneously on multiple computers. This service is used to replicate SYSVOL among all domain controllers. |
|
|
Help and Support |
Automatic |
(No change) |
Enables Help and Support Center to run on this computer. Also used to collect historical machine data on a daily basis for Microsoft Product Support Services incident escalation. |
|
|
HTTP SSL |
Manual |
(No change) |
Implements the secure hypertext transfer protocol (HTTPS) for the HTTP service by using Secure Sockets Layer (SSL). |
|
|
Human Interface Device Access |
Disabled |
(No change) |
Enables generic input access to Human Interface Devices (HID), which activates and maintains the use of predefined hot buttons on keyboards, remote controls, and other multimedia devices. |
|
|
IIS Admin Service* |
Automatic* |
Disabled* |
Provides administration of Web and File Transfer Protocol (FTP) services through the IIS snap-in. IIS is not required for domain controller operations. Eliminating IIS on dedicated domain controllers reduces the attack surface. |
|
|
IMAPI CD-Burning COM Services |
Disabled |
(No change) |
Manages CD recording by using Image Mastering Applications Programming Interface (IMAPI). |
|
|
Indexing Service |
Disabled Manual* |
(No change) Disabled* |
Indexes content and properties of files on the domain controller to provide rapid access to the file through a flexible querying language. On dedicated domain controllers, disable this service to prevent users from searching files and file content if sensitive files and folders are inadvertently indexed. |
|
|
Internet Connection Firewall (ICF)/Internet Connection Sharing (ICS) |
Disabled Manual* |
(No change) Disabled* |
Provides network address translation (NAT), addressing and name resolution, and intrusion detection when connected through a dial-up or broadband connection. On dedicated domain controllers, disable this service to prevent inadvertent enabling of NAT, which would prevent the domain controller from communicating with the rest of the network. |
|
|
Intersite Messaging |
Automatic |
(No change) |
Required by Active Directory, Distributed File System (DFS), and Netlogon for intersite replication. |
|
|
IPsec Services |
Automatic |
(No change) |
Provides management and coordination of Internet Protocol security (IPsec) policies with the IPsec driver. |
|
|
Kerberos Key Distribution Center |
Disabled |
(No change) |
Provides the ability for users to log on by using the Kerberos V5 authentication protocol. Required on domain controllers. (See Table 9.) |
|
|
License Logging |
Disabled Automatic* |
(No change) Disabled* |
Monitors and records client access licensing for portions of the operating system, such as IIS, Terminal Services, and file and print sharing, and for products that are not a part of the operating system, such as Microsoft® SQL Server 2000 or Microsoft® Exchange 2000 Server. On a dedicated domain controller, this service can be disabled. |
|
|
Logical Disk Manager |
Automatic |
(No change) |
Required to ensure that dynamic disk information is up to date. |
|
|
Logical Disk Manager Administrative Service |
Manual |
(No change) |
Required to perform disk administration. |
|
|
Messenger |
Disabled |
(No change) |
Transmits net sends and Alerter service messages between clients and servers. |
|
|
Microsoft Software Shadow Copy Provider |
Manual |
(See comment) |
Manages software-based volume shadow copies taken by the Volume Shadow Copy service. Ntbackup.exe and other non-Microsoft backup applications can use this service to back up the domain controller by using Windows Server 2003 volume-shadow-copy capabilities. If you do not intend to back up the server, you can disable this service. |
|
|
Net Logon |
Manual |
(No change) |
Maintains a secure channel between the domain controller and other domain controllers, member servers, and workstations in the same domain and in trusting domains. |
|
|
NetMeeting Remote Desktop Sharing |
Disabled Manual* |
(No change) Disabled* |
Eliminates a potential security threat by allowing domain controller remote administration through NetMeeting. |
|
|
Network Connections |
Manual |
(No change) |
Manages objects in the Network Connections folder. |
|
|
Network DDE |
(Disabled) |
(No change) |
Provides network transport and security for Dynamic Data Exchange (DDE) for programs that are running on the domain controller. |
|
|
Network DDE DSDM |
(Disabled) |
(No change) |
Used by Network DDE. This service is disabled when Network DDE is disabled. |
|
|
Network Location Awareness (NLA) |
Manual |
(No change) |
Collects and stores network configuration and location information, and notifies applications when this information changes. |
|
|
NTLM Security Support Provider |
Manual |
(No change) |
Provides security to remote procedure call (RPC) programs that use transports other than named pipes, and enables users to log on using the NTLM authentication protocol. |
|
|
Performance Logs and Alerts |
Manual |
(See comment) |
Collects performance data for the domain controller, writes the data to a log, or generates alerts. The startup type for this service can be set to Automatic when you want to log performance data or generate alerts without an administrator being logged on. If you are not collecting performance logs, this service can be disabled. |
|
|
Plug and Play |
Automatic |
(No change) |
Required to automatically recognize and adapt to changes in the domain controller hardware with little or no user input. |
|
|
Portable Media Serial Number Service |
Manual |
Disabled |
Retrieves the serial number of any portable media player that is connected to this computer. A domain controller should not need a portable media player. |
|
|
Print Spooler |
Automatic |
(See comment) |
Manages all local and network print queues, and controls all print jobs. Can be disabled on dedicated domain controllers where no printing is required. |
|
|
Protected Storage |
Automatic |
(No change) |
Protects storage of sensitive information, such as private keys, and prevents access by unauthorized services, processes, or users. This service is used on domain controllers for the smart card logon process. |
|
|
Remote Access Auto Connection Manager |
Manual |
(See comment) |
Detects unsuccessful attempts to connect to a remote network or computer, and provides alternative methods for connection. This service can be disabled on dedicated domain controllers where no VPN or dial-up connections are initiated. |
|
|
Remote Access Connection Manager |
Manual |
(See comment) |
Manages VPN and dial-up connections from the domain controller to the Internet or other remote networks. This service can be disabled on dedicated domain controllers where no VPN or dial-up connections are initiated. |
|
|
Remote Desktop Help Session Manager |
Manual |
(No change) |
Manages and controls Remote Assistance. If you do not need the Remote Assistance feature on the domain controller, disable this service. |
|
|
Remote Procedure Call (RPC) |
Automatic |
(No change) |
Serves as the RPC endpoint mapper for all applications and services that use RPC communications. |
|
|
Remote Procedure Call (RPC) Locator |
Manual |
(See comment) |
Enables RPC clients that are using the RpcNs* family of application programming interfaces (APIs) to locate RPC servers and manage the RPC name service database. This service can be disabled if no applications use the RpcNs APIs. |
|
|
Remote Registry |
Automatic |
(No change) |
Enables remote users to modify registry settings on the domain controller, provided that the remote users have the required permissions. By default, only members of the Administrators and Backup Operators groups can access the registry remotely. |
|
|
Removable Storage |
Manual Automatic* |
(See comment) |
Manages and catalogs removable media, and operates automated removable media devices, such as tape autoloaders or CD jukeboxes. You can disable this service if you do notback up to tapes or optical disks that are physically attached to this server or if you do not use backup to create an Automated System Recovery (ASR) set. |
|
|
Resultant Set of Policy Provider |
Manual |
(No change) |
Enables a user to connect to a remote computer, access the Windows Management Instrumentation (WMI) database for that computer, and either verify the current Group Policy settings for that computer or check settings before they are applied. If you do notuse Resultant Set of Policy (RSoP) planning mode to simulate the application of Group Policy settings, you can disable this service. |
|
|
Routing and Remote Access |
Disabled |
(No change) |
Enables LAN-to-LAN, LAN-to-WAN, VPN, and NAT routing services. |
|
|
Secondary Logon |
Automatic |
(No change) |
Allows you to run specific tools and programs with different privileges than your current logon provides. |
|
|
Security Accounts Manager |
Automatic |
(No change) |
A protected subsystem that manages user and group account information. |
|
|
Server |
Automatic |
(No change) |
Provides RPC support for file, print, and named pipe sharing over the network. |
|
|
Shell Hardware Detection |
Automatic |
Disabled |
Provides notifications for Auto Play hardware events. The Windows Image Acquisition (WIA) service depends on this service. Because the WIA service is disabled, this service can also be disabled. |
|
|
Simple Mail Transfer Protocol (SMTP) * |
Automatic* |
Disabled* |
Transports electronic mail across the network. In the rare event that you are using mail-based intersite replication, you should enable this service. Otherwise, leave it disabled at all times. |
|
|
Smart Card |
Manual |
(No change) |
Manages and controls access to a smart card that is inserted into a smart card reader that is attached to the domain controller. |
|
|
Smart Card Helper* |
Manual* |
(No change)* |
Provides support for legacy, non-plug-and-play smart card readers. |
|
|
Special Administrator Console Helper |
Manual |
Disabled |
Allows administrators to remotely access a command prompt by using Emergency Management Services (EMS). Enable this service only if you want Windows command prompts for connections over out-of-band management hardware that uses the EMS special administration console. |
|
|
System Event Notification |
Automatic |
(No change) |
Monitors system events and notifies subscribers to the COM+ Event System of these events. |
|
|
Task Scheduler |
Automatic |
(No change) |
Provides the ability to schedule automated tasks on the domain controller. If you do not plan to run batch jobs on the domain controller, you can disable this service. |
|
|
TCP/IP NetBIOS Helper |
Automatic |
(No change) |
Provides support for the NetBIOS over TCP/IP (NetBT) service and network basic input/output system (NetBIOS) name resolution for clients. |
|
|
Telephony |
Manual |
(See comment) |
Provides Telephony API (TAPI) support of client programs that control telephony devices and IP-based voice connections. This service can be disabled on dedicated domain controllers where TAPI is not used by applications. |
|
|
Telnet |
Disabled Manual* |
(No change) Disabled* |
Enables a remote user to log on and run applications from a command line on the domain controller. Enable Telnet only when it is used for remote administration for branch offices or remotely administered domain controllers. Terminal Services is the recommended method for remote administration. |
|
|
Terminal Services |
(Manual) |
(See comment) |
Enables multiple remote users to be connected interactively to the domain controller, and provides display of desktops and the ability to run applications. To reduce the surface area of attack, disable Terminal Services unless it is used for remote administration for branch offices or remotely administered domain controllers. |
|
|
Terminal Services Session Directory |
Disabled |
(No change) |
Enables a user connection request to be routed to the appropriate terminal server in a cluster. |
|
|
Themes |
Disabled |
(No change) |
Provides user experience theme management. |
|
|
Uninterruptible Power Supply |
(Manual) |
(See comments) |
Manages an uninterruptible power supply (UPS) that is connected to the domain controller by a serial port. If you don’t have a UPS device that is connected to the domain controller, you can disable this service. |
|
|
Upload Manager |
Manual |
Disabled |
Manages the synchronous and asynchronous file transfers between clients and servers on the network. Driver data is anonymously uploaded from these transfers and then used by Microsoft to help users find the drivers they need. |
|
|
Utility Manager* |
Manual* |
Disabled* |
Provides faster access to some accessibility tools, such as Magnifier, Narrator, and On-Screen Keyboard, and also displays the status of the tools or devices that it controls. Disable Utility Manager unless you require these special accessibility tools. |
|
|
Virtual Disk Service |
Manual |
(No change) |
Provides software volume and hardware volume management service |
|
|
Volume Shadow Copy |
Manual |
(See comment) |
Manages and implements volume shadow copies that are used for backup and other purposes. Ntbackup.exe and other non-Microsoft backup applications use this service to back up this domain controller by using Windows Server 2003 volume shadow copy capabilities. If you do not intend to back up this server, you can disable this service. |
|
|
WebClient |
Disabled |
(No change) |
Enables Windows-based programs to create, access, and modify Internet-based files. |
|
|
Windows Audio |
Automatic Disabled* |
Disabled (No change)* |
Manages audio devices for Windows-based programs. |
|
|
Windows Image Acquisition |
Disabled |
(No change) |
Provides image acquisition services for scanners and printers. |
|
|
Windows Installer |
Manual |
(No change) |
Adds, modifies, and removes applications that are provided as a Windows Installer (.msi) package. |
|
|
Windows Management Instrumentation |
Automatic |
(No change) |
Provides a common interface and object model to access management information about the domain controller through the WMI interface. |
|
|
Windows Management Instrumentation Driver Extensions |
Manual |
(No change) |
Monitors all drivers and event trace providers that are configured to publish WMI or event trace information. |
|
|
Windows Time |
Automatic |
(No change) |
Sets the domain controller clock and maintains date and time synchronization on all computers in the network. |
|
|
WinHTTP Web Proxy Auto-Discovery Service |
Manual |
(No change) |
Implements the Web Proxy Auto-Discovery (WPAD) protocol out of process. Advantages of implementing WPAD out of process include isolating the execution of untrusted JavaScript to a low-privileged (Local Service) account, and also avoids loading the COM runtime into the client’s process. |
|
|
Wireless Configuration |
Automatic |
(See comments) |
Enables automatic configuration for IEEE 802.11 adapters. If this domain controller does not use a wireless network or does not use the 802.11 authentication protocol, this service can be disabled. |
|
|
WMI Performance Adapter |
Manual |
(No change) |
Provides performance library information from WMI providers to clients on the network. |
|
|
Workstation |
Automatic |
(No change) |
Creates and maintains client network connections to remote servers. |
|
|
World Wide Web Publishing Service* |
Disabled* |
(No change)* |
Provides Web connectivity and administration through the Internet Information Services Manager. |
|
* Services (or default settings) that are present when you upgrade a domain controller that is running Windows 2000 to Windows Server 2003 but that are not present when you perform a new installation of Windows Server 2003.
Note
The antivirus software installed earlier in the deployment process and described in this section might run as a service in Windows Server 2003. Do not change the default configuration of your antivirus software.
Table 9 lists the changes to the service startup configuration when a server running Windows Server 2003 is promoted to a domain controller. This table is provided as a reference, and you can combine it with the information in Table 8 to arrive at the final list of services to have running on your domain controller.
Table 9 Recommended Changes to Service Startup Type After Promotion to Domain Controller
| Service Name | Default Startup Type | Recommended Startup Type | Comment | |
|---|---|---|---|---|
|
Distributed Link Tracking Client |
Manual |
Disabled |
Maintains links between NTFS v5 files within the domain controllers and other servers in the domain. Disable Distributed Link Tracking Client on dedicated domain controllers. |
|
|
Distributed Link Tracking Server |
Disabled |
(No change) |
Tracks information about files that are moved between NTFS v5 volumes throughout a domain. Disable this service on dedicated domain controllers. |
|
|
File Replication Service |
Automatic |
(No change) |
Enables files to be automatically copied and maintained simultaneously on multiple computers. This service is required to replicate SYSVOL between all domain controllers. |
|
|
Intersite Messaging |
Automatic |
(No change) |
Required by Active Directory, DFS, and NETLOGON for intersite replication and automatic site coverage. |
|
|
Net Logon |
Automatic |
(No change) |
Maintains a secure channel between the domain controller and other domain controllers, member servers, and workstations in the same domain and in trusting domains. |
|
|
Remote Procedure Call (RPC) Locator |
Manual |
(See comment) |
Enables RPC clients using the RpcNs* family of APIs to locate RPC servers and manage the RPC name service database. This service can be disabled if no applications use the RpcNs* APIs. |
|
|
Windows Management Instrumentation |
Automatic |
(No change) |
Provides a common interface and object model to access management information about the domain controller through the WMI interface. |
|
|
Windows Time |
Automatic |
(No change) |
Sets the domain controller clock and maintains date and time synchronization on all computers in the network. |
|
The services that are recommended in Table 8 and Table 9 are only the services that are required to support a dedicated domain controller. Although it is recommended that you have dedicated domain controllers, if your domain controller serves other roles, such as file server or print server, you may need to enable other services for proper operation.
Creating a Reserve File to Enable Recovery from Disk-Space Attacks
Many security attacks attempt to consume the system resources of the targeted system. One of the commonly attacked system resources is available disk space. Available disk space can be exhausted by the addition of a large number of objects to the directory by a malicious user or administrator. You can delete the added objects, but Active Directory requires that deleted objects continue to exist in the directory as tombstones for an extended period of time to allow the deletion to replicate. Therefore, the disk space that is consumed by the deleted objects cannot be reclaimed until the tombstone lifetime has expired, which is 60 days by default.
You can mitigate the effects of this type of attack by implementing preventive measures. You can provide for a fast recovery by creating a reserve file on the same disk volume as the Active Directory database (Ntds.dit). A reserve file is simply a large file that takes up available disk space. In the event that an attacker exhausts all disk space by adding a large number of objects to the directory, you can delete the reserve file to quickly restore normal operation while the rogue objects inside Active Directory are identified and removed. For more information about performing this task, see "Creating a Reserve File" in the Appendix: Procedures section.
Note
The ability to assign object ownership quotas in Windows Server 2003 eliminates most of the risk associated with this threat, because administrators can assign a maximum value to the number of objects that a user can create (own). However, this threat is not totally eliminated by setting quotas, because quotas cannot be set to limit the size of an object. In addition, a malicious administrator can create an unlimited number of objects.
For information about how to recognize and delete illegally added objects, see "Finding and Deleting Rogue Objects" in the Best Practice Guide for Securing Active Directory Installations and Day-to-Day Operations: Part II. To download this document, click the link under "Planning & Deployment Guides" on the Microsoft Web site at https://go.microsoft.com/fwlink/?LinkId=18591.
Configuring the Automatic Installation of Active Directory
You can configure a server to automatically install Active Directory by including instructions to run the Active Directory Installation Wizard (Dcpromo.exe) the first time that the server starts after the automated installation of Windows Server 2003. If you automate Active Directory installation, always install the first domain controller in a domain manually, and then use an automated installation method for additional domain controllers in that domain.
Automatically running Dcpromo.exe ensures that the promotion to a domain controller occurs immediately after the installation of Windows Server 2003. This configuration reduces the potential for introducing unauthorized files or executables before the server is promoted. Just before making your image, use one of the following methods to configure the server to automatically start Dcpromo.exe:
When using non-Microsoft tools or RIS-based deployments, add the following entry under the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion
RunOnce:
Entry name: dcpromo
Data type: REG_SZ
Value: dcpromo.exe /answer:<answer file path>
Warning
Incorrectly editing the registry can have serious, unexpected consequences that might require you to restore the registry or to reinstall Windows. Before you edit the registry, create an emergency startup disk and back up any critical data. For more information, see the Registry Reference for Microsoft Windows Server 2003 at https://go.microsoft.com/fwlink/?LinkId=4543.
When using Sysprep, modify the [GuiRunOnce] section of the Sysprep.inf answer file before running Sysprep.
The following is an example of a Sysprep.inf answer file that is modified to start Dcpromo.exe automatically the first time the server starts:
[GuiRunOnce] Command0 = "dcpromo /answer:<answer file path>"If you are creating an image of a server that you plan to use for imaging multiple domain controllers, place the Dcpromo.exe answer file on a floppy disk, so that one image can be used to deploy all domain controllers. Also, make sure that the Dcpromo.exe answer file path designates the floppy disk drive.
Using Unattended Active Directory Installation
Automating Active Directory installation generally increases its predictability and consistency by eliminating the need for manual intervention. You can automate Dcpromo.exe by using an answer file. The resulting process is known as unattended installation.
The answer file that you use to install Windows has a [DCInstall] section for domain controller installation. If you set the registry to automatically start Dcpromo.exe following the installation of the operating system, or if you modify the [GuiRunOnce] section of the Sysprep.inf answer file before running Sysprep, the installation server will run the dcpromo command and use the specified answer file. Instructions for creating an answer file for an Active Directory installation are located in the Deploy.cab file in the Support\Tools folder on the Windows Server 2003 operating system CD. Inside the Deploy.cab file, open Ref.chm to access the Unattend.txt file. For the [DCInstall] portion of the Unattend.txt file, double-click Unattend.txt, and then double-click domain controllers. Create a separate file that contains the [DCInstall] contents, and save it as the answer file for Active Directory installation.
The command for unattended Active Directory installation is:
**dcpromo /answer:**answer file path
Because the answer file is stored on the floppy disk in plaintext, do not include an administrative account name or a password in this file. You must enter this information during the automated Active Directory installation process. The answer file automatically provides all other parameters.
For more information about installing Active Directory from an answer file or from backup media, see "Deploying Windows Server 2003 Regional Domains" in Designing and Deploying Directory and Security Services of the Windows Server 2003 Deployment Kit (or see "Deploying Windows Server 2003 Regional Domains" on the Web at https://go.microsoft.com/fwlink/?LinkId=9691).
Selecting Secure Active Directory Configuration Settings
During domain controller promotion, a number of configuration settings should be applied to the server to enhance security. These settings are specified in the Dcpromo.exe answer file, that is, in the [DCInstall] section of the Unattend.txt file.
Note
Many of the configuration settings that are required for domain controller promotion depend on whether you are installing the first domain controller or an additional domain controller in the forest or domain. For this reason, a best practice recommendation is to install the first domain controller in a forest or domain manually.
Specifying Locations for the Active Directory Database, Logs, and SYSVOL
By default, Dcpromo.exe places the database, log files, and SYSVOL folder on the system volume. During the promotion of a server to a domain controller, the Dcpromo.exe answer file can specify an alternative location for the Active Directory database (Ntds.dit), log files, and SYSVOL folder.
Table 10 provides recommended alternative drive locations for these Active Directory components for enhanced security and improved performance.
Table 10 Recommended Drive Locations for Active Directory Components
| Recommendation | Security Rationale | |
|---|---|---|
|
Place the database and SYSVOL folder on the same dedicated physical drive. This drive should not contain the system volume. |
The system volume is a common target of disk-space attacks, such as spooling large print jobs. Putting the database on a separate drive makes it immune to damage caused by attacks that target the system volume. Placing the database and SYSVOL in a location other than the default location reduces the likelihood of disk-space attacks. Attacks can be performed against IIS that allow unauthorized users to navigate the folder structure of its disk volume. Because Web sites are typically stored on the system volume, this increases the risk of information disclosure on this volume. Although dedicated domain controllers are recommended, this cannot always be adhered to in a branch office situation. This recommendation improves the reliability of Active Directory operations recovery after a disk-space attack. For more information, see Creating a Reserve File to Enable Recovery from Disk-Space Attacks. |
|
|
Place the log files on a dedicated physical drive that does not contain the system volume. |
This recommendation has no security implications, but it will improve performance. The system volume typically includes the paging file, which has high disk utilization. |
|
On existing domain controllers, move the Active Directory database, log files, and SYSVOL folder to a dedicated physical drive, for the reasons described in Table 10.
For information about:
Moving the database and log files, see "Moving the Directory Database Files to a Local Drive" in the Active Directory Operations Guide on the Microsoft Web site at https://go.microsoft.com/fwlink/?LinkId=18545.
Moving the SYSVOL folder, see "Moving SYSVOL Manually" in the Active Directory Operations Guide on the Microsoft Web site at https://go.microsoft.com/fwlink/?LinkId=18545.
Configuring Pre–Windows 2000 Compatibility (Anonymous Access to Active Directory) for New Domains
During the promotion of the first domain controller in a domain, one configuration setting that significantly affects Active Directory security is Permissions compatible with pre–Windows 2000 servers. This setting enables backward compatibility for certain applications that need to query the directory by using anonymous access.
Anonymous access to Active Directory is disabled by default when you create a new Windows Server 2003 domain. In this case, the default setting is Permissions compatible only with Windows 2000 or Windows Server 2003 servers. Unless your environment has servers or domain controllers that are running Windows NT 4.0 or earlier versions of Windows, this default setting is the recommended selection.
For information about disabling anonymous access to Active Directory, see the next section, Determining the Need for Anonymous Access to Active Directory Data.
Determining the Need for Anonymous Access to Active Directory Data
You need Pre–Windows 2000 compatibility if you have applications or services that gain access to the directory anonymously (as opposed to being authenticated) and that require Read permissions on user (or inetOrgPerson), computer, and group objects in the directory. By default, Active Directory does not grant explicit permissions on objects in the directory to the special identity Anonymous Logon, which represents anonymous connections. However, the group Pre–Windows 2000 Compatible Access is assigned Read permissions on the domain root, as well as on user, computer, and group objects. In Windows Server 2003 Active Directory, when you enable Pre–Windows 2000 compatibility, the special identity Anonymous Logon is added as a member of the group Pre–Windows 2000 Compatible Access. Therefore, applications and services that require anonymous access to Active Directory — basically, any user or service with network access — can read these objects.
Applications or services that require anonymous access to Active Directory on a domain controller that is running Windows Server 2003 are those that are running in the following security contexts:
Local System on a server that is running Windows NT 4.0 within the forest
Local System on a server that is running Windows NT 4.0, Windows 2000, or Windows Server 2003 in a domain that exists in a different forest and with which a local domain has an external trust relationship
NetworkService on a server that is running Windows Server 2003 in a domain that exists in a different forest and with which a local domain has an external trust relationship, and the authenticating domain has a domain functional level of Windows 2000 mixed
For example, Microsoft® SQL Server version 6.0 (in Mixed or Windows Integrated security modes) and Routing and Remote Access Service, both running on Windows NT 4.0, require anonymous access to Active Directory to authenticate users and enumerate their group memberships.
Use the following approach to managing anonymous Active Directory access:
Perform tests to determine whether any applications are using anonymous access to query Active Directory, as described in Testing for Anonymous Active Directory Access.
Eliminate anonymous access requirements, and disable anonymous access, as described in Eliminating the Requirement for Anonymous Active Directory Access.
For more information about pre–Windows 2000 compatibility, see articles 257942, "Error Message: Unable to Browse the Selected Domain Because the Following Error Occurred ..."; 303973, "HOW TO: Add Users to the Pre–Windows 2000 Compatible Access Group"; 240855, "Using Windows NT 4.0 RAS Servers in a Windows 2000 Domain"; 254311, "Enable Windows NT 4.0–Based RAS Servers in a Windows 2000–Based Domain"; and 266712, "SMS: Security Based on Global Groups Fails in Windows 2000 Domains," in the Microsoft Knowledge Base at https://go.microsoft.com/fwlink/?LinkId=4441.
Testing for Anonymous Active Directory Access
If you are installing a new domain and you want to determine whether anonymous access is required, prepare a test environment to determine whether any applications or services require anonymous access to Active Directory, as described below. If you already have a production domain in which pre–Windows 2000 compatibility is enabled, perform steps 3 through 5 to monitor and assess anonymous access to the domain.
When you deploy the first domain controller in the test domain, select the option Permissions compatible with pre–Windows 2000 servers.
In the test domain, include at least one instance of each application that is running in your organization.
Enable security monitoring for anonymous access on all domain controllers. For more information about performing this task, see "Enabling Monitoring for Anonymous Active Directory Access" in the Appendix: Procedures section.
Analyze the security logs for computers that initiate anonymous access to the directory. For more information about performing this task, see "Enabling Monitoring for Anonymous Active Directory Access" in the Appendix: Procedures section.
Identify the applications or services that are running on the computers from which anonymous access was initiated.
Eliminating the Requirement for Anonymous Active Directory Access
After you have determined the applications or services that require anonymous access, identify the applications or services that can be upgraded to versions that do not require anonymous access, and perform the following tasks:
Eliminate the requirement for anonymous access to Active Directory by upgrading the applications or services that initiate anonymous access.
Monitor the security logs for servers that initiate anonymous access to Active Directory for another 30 days.
After reviewing the security logs and ensuring that no application or service is gaining anonymous access to Active Directory, disable anonymous access to Active Directory data as described in "Disabling Anonymous Active Directory Access" below.
Typically, a newer version of the application or service (for example, Routing and Remote Access in Windows 2000 and Windows Server 2003) does not require anonymous access. Whenever possible, upgrade to a newer version of the application or service that is running under Windows 2000 or later operating systems so that you can disable pre–Windows 2000 compatibility.
Disabling Anonymous Active Directory Access
After you are certain that no applications or services are establishing anonymous connections to your domain controllers, you can disable anonymous access.
When you create a new Windows Server 2003 domain, simply accept the default option setting Permissions compatible only with Windows 2000 or Windows Server 2003 servers.
In an existing Windows Server 2003 domain that has pre–Windows 2000 compatibility enabled, you must remove the Everyone group and Anonymous Logon from the Pre–Windows 2000 Compatible Access group. To ensure that anonymous access is removed in the most efficient and timely manner, perform the following tasks:
On the domain controller that holds the primary domain controller (PDC) emulator operations master role, remove Everyone and Anonymous Logon from the Pre–Windows 2000 Compatible Access group, leaving Authenticated Users as the only member.
Either wait for changes to replicate to all domain controllers in the domain, or force replication by using the following command (switches are case-sensitive):
repadmin /syncall /d/e/P/q DNS_name_of_PDC_emulator_operations_master
On every domain controller in the domain, run the following command:
net session /delete
Running Virus Scans on Domain Controllers
Even after the domain controller is promoted, continue to run virus scans and to obtain regular virus signature updates from your antivirus software vendor. However, before initiating regular antivirus scanning, be aware that some antivirus software can interfere with the proper operation of domain controllers by:
Interfering with directory database and log file access by the Extensible Storage Engine (ESE).
Interfering with FRS database and log file access by ESE.
Causing excessive replication by FRS.
These issues with running antivirus software on domain controllers are addressed by the recommendations provided in the following three sections.
Preventing Interference Between Active Directory Database and Log File Access and Virus Scans
ESE, which underlies Active Directory, opens database and log files in exclusive mode. As a result, if antivirus software opens one of the database or log files, ESE fails when it tries to open the same file. Alternatively, the antivirus software cannot open these files for scanning if they have already been opened by ESE.
Furthermore, these database and log files have internal checksums that, when altered through file changes by the antivirus software, can either cause an access error to occur or cause the database to fail on restart or restore. In all cases, the result is that Active Directory fails on the domain controller.
To run antivirus software on domain controllers, administrators must configure the antivirus software to exclude from scanning the Active Directory database and log files that are specified in Table 11.
Table 11 Active Directory Files to Exclude from Antivirus Scanning and Registry Values Specifying Their Location
| Exclude from Scan | In HKLM\System\CurrentControlSet\Services\NTDS\Parameters |
|---|---|
Ntds.dit |
DSADatabaseFile |
Edb*.log, Edb*.log, Res1.log, and Res2.log |
DatabaseLogFilesPath |
Temp.edb and Edb.chk |
DSAWorkingDirectory |
Excluding the files in Table 11 from regular virus scanning does not increase a domain controller’s vulnerability to a virus attack. Viruses tend to attach to files that are executed, such as binaries or scripts, rather than to data files. Dedicated domain controllers with no user-modifiable content are therefore less vulnerable to common virus attacks.
Preventing Interference Between FRS Database and Log File Access and Virus Scans
The exclusive mode in which ESE operates causes interference with scanning the FRS database and FRS log files, in the same manner as described for Active Directory database and log files in the Preventing Interference Between Active Directory Database and Log File Access and Virus Scans section.
To run antivirus software on domain controllers, administrators must configure the antivirus software to exclude from regular virus scanning the FRS directory and log files that are specified in Table 12.
Table 12 FRS Files and Folders to Exclude from Virus Scanning and Registry Values Specifying Their Location
| Exclude Files from Scan | In HKLM\System\CurrentControlSet\Services\NtFrs\Parameters |
|---|---|
jet\sys\Edb.chk, jet\Ntfrs.jdb and jet\log\*.log |
Working Directory |
Log\*log |
DB Log File Directory |
Exclude Folders from Scan |
In HKLM\Sysem\CurrentControlSet\Services\NtFrs\Parameters\ReplicaSets\GUID |
replica_root |
Replica Set Root |
staging_directory |
Replica Set Stage |
preinstall_directory |
Replica_root\DO_NOT_REMOVE_Ntfrs_Preinstall_Directory |
Preventing Virus Scans from Triggering Excessive FRS Replication
Domain controllers that are running Windows Server 2003 use FRS to replicate system policy and logon scripts that reside in the shared SYSVOL folder. Antivirus software can interfere with the normal functioning of FRS by modifying the security descriptor and time stamp of files in the SYSVOL folder. This modification causes FRS to replicate the changes to other domain controllers, which creates a high volume of file replication traffic.
Some antivirus programs modify files and directories in a way that causes FRS replication. Because such software often scans every file and directory in an FRS replicated tree, this interaction amounts to requesting a full synchronization of all files and folders from every domain controller that is running the software. The following symptoms might indicate this problem in the network:
Files in SYSVOL shares are replicated excessively.
Network traffic between replication partners consumes excessive bandwidth.
The number of files in the staging directory constantly grows and then empties sometime after the antivirus scan completes or after FRS replication.
Note
Staging directory behavior changes for Windows Server 2003 and for Windows 2000 Server SP3 and later. These operating systems contain an updated version of FRS that leaves staging files in place for one week before removing them.
You can maintain high security on domain controllers while preventing antivirus software from causing excessive replication by performing the following tasks:
Configure antivirus software to not scan files in the SYSVOL directory tree.
Require script signing on the domain controller.
For more information about running antivirus software on domain controllers, see article 815263, "Antivirus, Backup, and Disk Optimization Programs That Are Compatible with the File Replication Service," in the Microsoft Knowledge Base at https://go.microsoft.com/fwlink/?LinkId=4441.
Excluding Antivirus Scanning of SYSVOL
Antivirus software can interfere with the normal functioning of FRS by modifying the security descriptor and time stamp of files in the SYSVOL folder. These modifications trigger FRS to replicate the changes in the SYSVOL folder to other domain controllers. This interference results in excessive FRS replication between domain controllers. To run antivirus software on domain controllers, configure the antivirus software to exclude the SYSVOL folder and its subtree from scanning.
Note
The following antivirus applications do not modify SYSVOL files in a way that triggers excessive replication:
eTRUST Antivirus build 96 or later with the NTFS incremental scan feature disabled.
McAfee/NAI NetShield 4.50 with the NetShield Hot Fix Rollup.
Norton Antivirus 7.6 or later.
Requiring Script Signing on Domain Controllers and Administrative Workstations
In contrast to the directory database and log files, excluding the SYSVOL folder from virus scanning does increase the risk of a virus attack on a domain controller. The reason for the risk is that viruses tend to attach to binaries or scripts. Excluding the SYSVOL folder from virus scans increases the risk of virus attacks on logon scripts and startup scripts in the SYSVOL folder on domain controllers. As a countermeasure, implement script signing to protect the integrity of scripts running on domain controllers and administrative workstations.
Note
If you are using one of the antivirus applications listed in the preceding note, you do not need to exclude the SYSVOL folder from being checked by the antivirus application. Therefore, you do not need to implement script signing.
Windows 2000 Server, Windows XP, and Windows Server 2003 support enforcement of script signing to validate the integrity of scripts and binaries before they are executed. Signing a script guarantees who wrote the script and that it has not been tampered with in any way since it was signed. Establish a practice for your organization that requires that all scripts in the SYSVOL folder be signed. Windows Script Host scripts (.vbs, .js, .wsf, and so on) can be signed or verified by using the same tools that are ordinarily used to sign other executables.
Sign scripts by performing the following tasks:
Note
At a minimum, you should enforce script signing on domain controllers and administrative workstations. However, it is a best practice recommendation that script signing be enforced on all computers on the network that are running operating systems that support script signing. Such operating systems include the Windows 2000 family of operating systems, Microsoft® Windows® XP, and the Windows Server 2003 family.
Enroll to acquire a certificate from an internal certification authority (CA).
Choose an internal CA so that confirming the current validity of the certificate does not require an Internet lookup. To ensure that the certificate has not been revoked, the code checks the CA’s certificate revocation list (CRL).
Secure all scripts in the SYSVOL folder by signing.
Note
Batch files cannot be signed; therefore, they are inherently less secure. Convert all batch files to .vbs scripts as soon as possible.
Two alternatives are available for creating signed scripts:
The Windows Product SDK contains a set of tools for signing scripts (signcode.exe and chktrust.exe).
Alternatively, for anyone interested in developing their own tool, Windows Script Host version 5.6 ships with a signer object Scripting.Signer to sign or verify scripts.
For the code that is required to implement one of these signing solutions, see "Securing Scripts with Script Signing" in the Appendix: Procedures section.
Using software restriction policies in Group Policy, you can apply a restriction so that client computers cannot run scripts at all. However, because the goal is that clients be able to run signed scripts, you can further create a certificate rule that allows clients to run scripts if they can verify the signature by using the public key in the certificate.
This step can be performed only if the client computers are running Windows XP or Windows Server 2003. To require that only signed scripts be run on computers that are running Windows 2000 Server or Windows 2000 Professional, add the following registry entry in HKEY_LOCAL_MACHINE\Software\Microsoft\Windows Script Host\Settings on every computer that is running Windows 2000 Server or Windows 2000 Professional:
Entry name: Trust Policy
Data type: REG_WORD
Value: 2
Warning
Incorrectly editing the registry can have serious, unexpected consequences that might require you to restore the registry or to reinstall Windows. Before you edit the registry, create an emergency startup disk and back up any critical data. For more information, see the Registry Reference for Microsoft Windows Server 2003 at https://go.microsoft.com/fwlink/?LinkId=4543.
For more information about implementing script signing, see:
"Providing a Secure Experience" in the Scripting Clinic on the Microsoft MSDN Web site at https://go.microsoft.com/fwlink/?LinkId=20258.
"Digital Code Signing Step-by-Step Guide" on the Microsoft MSDN Web site at https://go.microsoft.com/fwlink/?LinkId=18548.
"Windows Script Host: New Code-Signing Features Protect Against Malicious Scripts" on the Microsoft MSDN Web site at https://go.microsoft.com/fwlink/?LinkId=18550.