13.8 Providing Security for Domain Controllers

Since the domain controllers hold the keys to the kingdom, they need to receive special attention. Domain controllers offer two primary types of access: physical access and network access. With physical access, someone can physically access the computer, such as putting a CD in the CD-ROM drive and typing at the keyboard. Physical access could also result in someone stealing the computer. Network access requires a bit more sophistication from the attacker, but there are plenty of avenues into the domain controller. The network access that needs to be considered includes acquiring user account names, share names, data, and communications with the domain controller.

13.8.1 Physical Access

One of the most important security measures you can take for your domain controllers is to secure them physically. The actual box, tower, or blade needs to be secured. This means behind a door with a lock that only administrators have the key to. In addition to placing the domain controller in a locked room, you need to consider providing these additional security measures to lock down your domain controllers:

  • Use physical access controls to secure the lock to the server room as described in Chapter 2.

  • Use smart cards on the servers as described in Chapter 10, so users must use two-factor authentication to access the domain controllers.

  • Do not leave users logged on to the domain controllers. It is a misconception that a user must log on to the domain controller for it to function. The services that run on the domain controller start without any user logging on.

Another important factor for physical access to a domain controller is providing security access control when the domain controller is restarted. The Syskey utility is described in full detail in Chapter 4.

13.8.2 Network Access

Domain controllers also need to be protected from access across the network. Primarily, you need to protect the administrator account that resides on the domain controllers most of all. The administrator account is the golden user account that an attacker seeks to find and log on as. To protect the domain controller from network access:

Allow only administrators the ability to log on locally to the domain controllers

This behavior is controlled by using user rights. For domain controllers, this is the default behavior and should not be changed. Standard users who can log on locally to a domain controller can access all the resources that are stored on the computer, not just those that are available over the network.

Remove the ability for the Administrator account to access the domain controllers from across the network

It should be agreed upon that the Administrator account should not be used for typical administration. This account needs to be protected and not used for routine tasks. This account will be used if there is a problem with a domain controller or recovery needs to be performed on a domain controller. These special uses of this account do not require network access to the domain controllers. Therefore, it is ideal to deny network access to the domain controllers for this account.

Don't use the Administrator account as a service account on the domain controllers

If the Administrator account is used as a service account, it breaks the rule that this account should not be used for routine tasks. Service accounts log on to servers and domain controllers as if they are physical users. If a virus attacks this computer, it can use the context of the service account to attack other computers on the network. With this highest privileged access, there is almost nothing that the virus could not do.

The solution to not using the Administrator account as a service account is to create special accounts to be used for services. After the new user accounts are created, you can narrow the computers that the account can log on to, by using the Logon to Workstations option that was discussed earlier in this chapter.

Don't allow SID/name translation

Many attackers want to know the name of the built-in Administrator account so they can attempt to log on with this account. After you take the precautions to hide this account by renaming it, the only way to identify this account is by its security identifier (SID). This is possible because all Administrator accounts end in 500 on a Windows computer. If the attacker is able to enumerate or translate names and SIDs, the attacker will be able to find the built-in Administrator's new name.

To combat against this, disable the GPO setting labeled Allow Anonymous SID/Name Translation, shown in Figure 13-10.

Figure 13-10. Default Domain Controller Policy showing location to lock down SID/name translation, anonymous access, and enumeration of SAM and shares

Don't allow anonymous share enumeration

An attacker that acquires a list of shares on a target computer in a different network can attack that target computer through many avenues. This list of shares is not easily obtained by browsing for the shares when the target computers are on different networks. However, if an attacker is able to access the target computer with anonymous credentials, the list of shares can be obtained and used as an entry point to the target computer.

To combat against this, enable the GPO setting labeled "Do not allow anonymous enumeration of SAM accounts and shares." There is no GPO setting that directly controls access to shares only, so this GPO setting must be used. We will talk about controlling the SAM next.

Don't allow anonymous SAM enumeration

If an attacker can obtain a list of users from the SAM or Active Directory, she will have many opportunities to try to falsify the user credentials to access the network. This list is well protected by default from an attacker without administrative privileges. However, if an attacker is able to access the target computer with anonymous credentials, the list of user accounts can be obtained and used to try and falsify credentials to get access to other computers on the network.

To combat against this, enable the GPO setting labeled "Do not allow anonymous enumeration of SAM accounts and shares" and "Do not allow anonymous enumeration of SAM accounts." Of course, if you want to target only the SAM accounts and not the shares, you will use the second option. Microsoft has separated these out to give you more control over what you want to restrict.

Don't allow the Everyone group to include anonymous

Anonymous users are allowed to perform certain activities in a Windows computer, such as list the user accounts and shares. This allows system services and functions to access the operating system without special requirements. In Windows Server 2003, the Everyone group by default is not included on the access token for the anonymous logon, so permissions that are applied to the Everyone group will not pertain to the anonymous logon. This will restrict the access that anonymous users have for the computer and should be maintained. This is desired behavior, to not have the anonymous logon access resources that the Everyone group can access.

To ensure this behavior, disable the GPO setting labeled "Let Everyone permissions apply to anonymous users."

The final suggestions listed are completed using the Default Domain Controller Policy. Figure 13-10 illustrates the location and settings within the GPO to control anonymous access to domain controllers.

13.8.3 Domain Controller Communications

Domain controllers communicate constantly to exchange Active Directory and GPO information. This replication that domain controllers rely on can be compromised if the network traffic is captured. There are methods to protect this vulnerability, depending on where the network traffic is being transmitted and how secure the network is. If the network is trusted but contains two different segments that don't trust each other, a firewall can be used to separate the two network segments. If this method is used, the domain controller replication traffic may be filtered out by the firewall. So, the firewall needs to be opened up to allow this domain controller replication traffic.

Another scenario might be that the domain controller replication and communication traffic needs to be protected, over either a trusted or untrusted network. This protection can be handled by opening up firewalls for domain controller replication traffic, which we just saw in the previous example, or by using two different IPSec methods. These three solutions are discussed in the following three subsections. Open firewall ports on trusted network

Your company may have installed and configured firewalls between different networks within your IT infrastructure. This is designed to control the traffic that passes from one network to another, even though all networks are trusted. Although this configuration allows for a secure environment, which is controlled, it does cause grief for domain controllers attempting to communicate across these networks.

If your situation fits into this scenario, you can open the ports on the firewalls that are required for domain controllers to communicate with one another. To do this, you will need to open up a few ports on each firewall to allow domain controller communication. Table 13-4 lists each service and port that you will need to open.

Table 13-4. Services and ports needed for domain controller replication




53/tcp and 53/udp

Global catalog LDAP


Global catalog LDAP over SSL



88/tcp and 88/udp





NetBIOS name service

137/tcp and 137/udp

NetBIOS datagram service


NetBIOS session service


Network time protocol (NTP)


RPC dynamic assignment


RPC endpoint mapper

135/tcp and 135/udp

SMB over IP (Microsoft-DS)

445/tcp and 445/udp

WINS replication (if required)

42/tcp and 42/udp

WINS resolution (if required)

1512/tcp and 1512/udp

This solution does not increase the security of domain controller communication; rather, it allows domain controllers to work in the secure infrastructure that has been created with the firewalls. One variable on the list, RPC dynamic assignment, will require additional attention to configure the communication. This is the value that is used when connecting to an RPC endpoint. This endpoint either can be a random number between 1024 and 65535 or can be statically assigned. Here, you are statically assigning the value, instead of having the firewall open the entire range. The static value that you provide for this port needs to fall between the range of 49152 and 65535. This must be configured in the registry of every domain controller in the domain. To complete the registry update:

  1. Open the registry editing tool by typing regedit at the Start Run prompt.

  2. Expand the HKLM window to the following path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters.

  3. Click on the Edit New DWORD Value menu option.

  4. Type TCP/IP Port into the text field, then press the Enter key.

  5. Double-click on the TPC/IP Port value.

  6. Type a number between 49152 and 65535 into the Value Data text box, then click on the OK button.

  7. Exit the registry editing tool.

  8. Restart the computer.

This will not increase security for the communication between domain controllers. However, it will allow domain controllers to communicate between different networks where there is a firewall restricting ports. IPSec for DC communication and replication

A lot of information is replicated between domain controllers that you don't want an attacker to get hold of. Replication between domain controllers includes user account names, group account names, replication schedules, and more. About the only method that you have to secure this communication is to configure IPSec for communicating between the domain controllers.

IPSec will encrypt the data as it is sent across the network. IPSec is a good solution because it encapsulates RPC traffic, which is normally prone to attacks. Another benefit from IPSec for this communication is that it provides mutual authentication, allowing the domain controllers to identify each other before any vital information is sent across the network.

To configure IPSec for all communication between domain controllers, you will need to configure each domain controller's IPSec settings. The following is a general overview of the steps that need to be performed on each domain controller, with some tips to help you configure each step correctly:

  1. Create an IPSec IP filter list and filter action using the Local Security Policy.

    1. Make these configurations on each domain controller.

    2. Make sure you set the filter list to control only domain controller-to-domain controller communication.

    3. Include all protocols, to secure all communication. (Refer to the earlier section on RPC communication to specify certain communication protocols to be included in the IPSec filter.)

  2. Create an IPSec policy for replication using the Local Security Policy.

    1. Note this is not a tunnel.

    2. This will be for LAN, not RAS access.

    3. You will need to choose authentication methods.

    4. Match up filter list and filter action to this IPSec policy.

  3. Assign the policy!

    You could also use the netsh ipsec command to manage the IPSec policies.

After this is configured, the domain controllers will use IPSec for all communication. They will not use IPSec for communication with other domain members, which is not a horrible decision. You should not attempt to configure IPSec for all computers on the network, due to the complexity of the IPSec policies and lack of support for IPSec with so many client computers that still exist on corporate networks.

If you need to send IPSec traffic across a firewall, you don't need to open up the myriad of ports that we did in the previous section. You need to open up only the ports related to IPSec. These would include those listed in Table 13-5.

Table 13-5. Services and protocol needed for IPSec to pass through a firewall




53/tcp and 53/udp


88/tcp and 88/udp

Internet Key Exchange (IKE)


IPSec encapsulated security payload (ESP)

IP protocol 50

IPSec authenticated header (AH)

IP protocol 51 Domain controller communication across untrusted network with IPSec tunnel

If your domain controllers are crossing an untrusted network with replication and basic communication, you need to look into another solution for securing the network traffic. The ideal solution is to use an IPSec tunnel. (If you are using a remote connection for the communication, you can use L2TP/IPSec for the remote access VPN.)

IPSec tunnels are used to increase the security of the server-to-server communication. The IPSec encapsulated packets will have the same benefits that you read about in Chapter 8 on IP Security. The IPSec tunnel is an advanced IPSec policy setting that will have more configurations than our previous example in which we used IPSec transport mode to secure the network traffic.

A minor difference that you will need to keep in mind when establishing your IPSec tunnel is that you can't mirror the filters for tunneled traffic. You will need to have two rules: one for the outbound traffic and one for the inbound traffic. When you establish the two rules, you will need to configure the tunnel endpoints. For the outbound tunnel endpoint, it will be the IP address for the computer on the other end of the tunnel. For the inbound tunnel endpoint, it will be the IP address configured on the local computer. See Chapter 8 for more information about configuring IPSec policies, filters, and rules.

13.8.4 Locating Domain Controllers in Active Directory

Although this may seem silly, many people want to move the domain controller computer accounts to different OUs. This is a mistake, considering the importance of the Default Domain Controller Policy preconfigured at the Domain Controllers OU. Therefore, additional OUs can be created below the Domain Controllers OU to contain different domain controller accounts, but domain controllers should not be moved outside of the Domain Controllers OU.

13.8.5 Roles and Responsibilities

Domain controllers have a crucial role in housing and protecting the Active Directory. They are also very busy keeping up with changes among other domain controllers and authenticating user logons. With all this activity and security responsibility, domain controllers should be limited to performing the domain controller duties.

Additional duties that domain controllers may properly be responsible for include:

  • Flexible single master operator role

  • Global catalog

Domain controllers should not be running other services that can be handled by member servers, which don't have the responsibility of Active Directory or authenticating user logons. Services that should be handed off to member servers include:

  • Antivirus monitoring

  • Backup

  • Management

  • Monitoring

  • Asset control