If domain controller security could be described in a single sentence, a good one would be "Defending the keys to the kingdom." This statement really captures what domain controller security is all about. Active Directory, which is protected by the domain controller, manages network resources and user accounts and acts as the central authority for network security. If the domain controller gets compromised, the objects in Active Directory can easily be compromised too, and at that point you’re pretty much sunk.
The critical role that the domain controller plays within a network makes it a prime and likely target for attackers. They will try to do nefarious things against the domain controller such as launch password attacks, denial of service (DoS) attacks, and even physical security attacks, so understanding the threats to your organization’s domain controllers as well as countermeasures is critical. The threats discussed in this chapter include:
Password attacks
Elevation of privilege
Denial of service
Physical security threats
If domain controllers are the kingdom, the passwords that protect the user accounts are the main keys to that kingdom. An attacker who is able to gain access to your organization’s domain controllers might be able to conduct an offline password attack if he backs up data from your organization’s domain controller Active Directory and restores it on another computer. Alternatively, that attacker can also conduct online attacks against domain user accounts protected with weak passwords.
To effectively defeat password attacks, first make the password as complex and hard to crack as possible, and then protect the passwords themselves so that attackers cannot easily gain access to them. The following sections explain how to do this.
When user account passwords are stored in the Windows system, they are not stored as clear text; instead, they are stored as hashes in Active Directory. When a password that is fewer than 15 characters is store or changed, two hashes are generated: a LAN Manager hash (LM hash) and a Windows NT hash (NT hash). Of the two, LM hashes are more susceptible to brute force attacks, so your organization might want to disable storing this type of hash. There are several ways to do this, so follow the steps that best match your organization’s requirements as outlined in the article "How to Prevent Windows from Storing a LAN Manager Hash of Your Password in Active Directory and Local SAM Databases," at http://support.microsoft.com/default.aspx?scid=kb;en-us;299656&sd=tech. One way discussed in the article is to disable LAN Manager hashes by using Group Policy:
Under Administrative Tools, open Domain Security Policy.
Expand Local Policies and select Security Options.
Set the Network Security: Do Not Store LAN Manager Hash Value On Next Password Change policy to Enabled, as shown in Figure 26-1.
If your organization has no need to store passwords using reversible encryption, this ability should be disabled. Doing this makes it more difficult for password crackers to retrieve passwords. You can set this policy by following these steps:
Under Administrative Tools, open Domain Security Policy.
Expand Account Policies and select Password Policies.
Set the Store Passwords Using Reversible Encryption policy to Disabled, as shown in Figure 26-2.
This policy is disabled by default on Microsoft Windows Server 2003 and Windows 2000 domain controllers in their Default Domain Group Policy object (GPO).
You can use Group Policy to enforce complexity onto user account passwords. Enabling this Group Policy setting means that passwords must meet the following complexity requirements:
Does not contain the user’s account name or part of it
Must be at least six characters long
Must contain characters from at least three of the following categories:
English uppercase letters (A through Z)
English lowercase letters (a through z)
Base 10 digits (0 through 9)
Nonalphabetic characters (examples include !, @, #, and $)
Unicode characters, such as Phi or Φ
By default, the password complexity policy is enabled on domain controllers. You can enable this policy with the following steps:
Under Administrative Tools, open Domain Security Policy.
Expand Account Policies and select Password Policies.
Set the Password Must Meet Complexity Requirements policy to Enabled, as shown in Figure 26-3.
Once you enable this policy, verify that you cannot create an account with a password that violates this policy. For example, a password such as H!9e1 should not pass the password complexity filter because it violates length requirements.
More Info
If the default password complexity requirements do not meet your organization’s security requirements, you can find information about creating your own filter and installing it at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/security/security/password_filter_programming_considerations.asp.
Users should be educated about what constitutes a strong password. (See Chapter 15.) Don’t rely soley on password filters such as the one just discussed to enforce strong passwords. Users could, for instance, bypass the default password filter with a password such as Hello11, which from a cracking standpoint is fairly easy to crack.
The system key (Syskey) utility provides an extra line of protection against password-cracking attacks. It uses strong encryption techniques to protect password information stored in directory services on your organization’s domain controllers. Protecting passwords in this manner makes cracking attacks more difficult and time-consuming for attackers than if passwords were not encrypted. Syskey offers the levels of protection detailed in Table 26-1.
Table 26-1. Syskey Modes
Syskey mode | Relative security level | Description |
|---|---|---|
Mode 1: System-generated System Key | Secure | The system key is a system-generated random key that is stored locally on the system. In this mode, systems can be restarted without an administrator entering a password or providing a floppy disk containing the system key at system startup (Modes 2 and 3). This mode is enabled by default on all computers running Microsoft Windows 2000, Windows XP, and Windows Server 2003. |
Mode 2: Password Startup | More secure | This mode uses a system key that is derived from an administrator-chosen password. This password is required during system startup. The system key is stored locally on the system in an encrypted format. If this password is forgotten, the system will not be able to start up and will have to be rebuilt. |
Mode 3: System-generated System Key Requiring Floppy Disk | Most secure | The system key is a system-generated random key that is stored on a floppy disk. This floppy must be inserted for the system to start up. If the floppy disk is lost or damaged and no backup exists, the system will not be able to start up and will have to be rebuilt. |
To change your organization’s domain controller’s Syskey mode, follow these steps:
Click Start, then Run, and type syskey.exe as the application to open. Press Enter.
In the Securing The Windows Account Database dialog box, click Update.
Select the appropriate Syskey mode and click OK. In Figure 26-4, the Store Startup Key Locally option is selected, which corresponds to Mode 1 in Table 26-1.
Compromising a domain controller is a highly sought-after prize by attackers in the game of domain controller security. Elevating their privileges on a domain controller can allow them to modify the contents of Active Directory. Common ways that attackers can elevate their privileges on domain controllers include:
Exploiting nonessential services
Exploiting nonessential accounts
Exploiting unpatched domain controllers
Attacking privileged domain accounts and groups
Nonessential services help attackers by extending the attack area. The more services an attacker can try to exploit, the more ways she can compromise your organization’s domain controller and the more likely she will be to succeed. Nonessential services are especially appealing to attackers for the following reasons:
Attacks against nonessential services are often unnoticed. If an attacker crashes a critical service—intentionally or otherwise—while trying to exploit it, users will notice and security teams will be alerted. However, if attackers manage to crash a nonessential service, there is a good chance the crash will go unnoticed because users don’t depend on the service, and operations teams don’t often monitor unused services.
Nonessential services are often not configured properly or secured. Nonessential services are often not configured correctly. For instance, many of these services start up using sample configurations created by vendors. These configurations, in all likelihood, will not meet the requirements of your organization’s security policy, making them a threat.
Nonessential services are often not running in a secure state. In addition to the service not being configured properly, the service can be running in an insecure state. For instance, a Web server could be configured properly if it protects sensitive data with transport security such as SSL and digest authentication; however, it could still be running under a highly privileged security context like SYSTEM or root. Compromises of these services could grant the attacker a highly privileged level of access on your organization’s domain controllers. Unpatched services are also running in an insecure state.
You can easily enumerate the services running on your organization’s domain controller using the Sc.exe command-line tool and the following command:
sc.exe \<dc_name> queryex | findstr "SERVICE_NAME"
Replace <dc_name> with either the host name or the IP address of your organization’s domain controller. The output will be similar to the following:
C:>sc.exe \192.168.1.1 queryex | findstr "SERVICE_NAME" SERVICE_NAME: ALG SERVICE_NAME: Browser ... SERVICE_NAME: winmgmt
You can also determine a service’s starting account name by querying the configuration information about a service using the Sc.exe "qc" option. For instance, if you wanted to determine the startup account of the Windows Messenger service, you would use the following command:
sc.exe \192.168.1.1 qc messenger
As you can see from the following output, the startup account (see the SERVICE_START_NAME field) for the service is LocalSystem.
[SC] GetServiceConfig SUCCESS
SERVICE_NAME: messenger
TYPE : 20 WIN32_SHARE_PROCESS
START_TYPE : 2 AUTO_START
ERROR_CONTROL : 1 NORMAL
BINARY_PATH_NAME : C:WINDOWSSystem32svchost.exe -k netsvcs
LOAD_ORDER_GROUP :
TAG : 0
DISPLAY_NAME : Messenger
DEPENDENCIES : LanmanWorkstation
: NetBIOS
: PlugPlay
: RpcSS
SERVICE_START_NAME : LocalSystemDetermining missing patches on your organization’s domain controllers, which could lead to insecure service states, is discussed later in this chapter.
Disabling nonessential services on the domain controller greatly helps to reduce the surface area with which the attacker can work. The idea is this: if the service is not there, attackers can’t exploit it and they’ll have to find another way into your organization’s domain controllers (or better yet, give up).
Note
Disabling nonessential services also buys you performance gains. The fewer nonessential services you have running on your domain controller, the more resources such as processor and memory can be used for essential services.
According to the Microsoft Windows Server 2003 Security Guide at http://go.microsoft.com/fwlink/?LinkId=14846, the services listed in Table 26-2 must be enabled on Windows Server 2003 domain controllers.
Table 26-2. Windows Server 2003 Domain Controller Services
Service | Service name | Description |
|---|---|---|
Distributed File System | Dfs | Manages logical volumes across local and wide area networks |
Domain Name System (DNS) Server | Dns | Responds to DNS queries and dynamic DNS requests |
File Replication | NtFrs | Allows files to be copied and maintained across multiple servers |
Intersite Messaging | IsmServ | Allows messages to be exchanged between Windows servers |
Kerberos Key Distribution Center | Kdc | Enables users to log onto domains using the Kerberos authentication protocol |
Remote Procedure Call (RPC) Locator | RpcLocator | Enables RPC clients using RpcNs* APIs to locate RPC servers |
All services not listed in Table 26-2 that are found running on your organization’s Windows Server 2003 domain controller should be reviewed for business justification. If no justification is found for a service, the service should be disabled. Figure 26-5 illustrates how you disable a service from being automatically started by the system: you set its startup type to Disabled on the service property page. If the service is already running, you will also have to stop the service by clicking the Stop button.
To verify that the service you disabled is stopped, you can use the Sc.exe tool in the following way:
sc.exe \<dc_name> queryex | findstr /I "<servicename>"
Replace <dc_name> with the host name or the IP address of your organization’s domain controller, and replace <servicename> with the case-sensitive service name of the service that you disabled. For example, if you disabled the Print Spooler service, you would use the following command to test whether the service was running:
Sc.exe \192.168.1.1 queryex | findstr /I "Spooler"
If the service is correctly stopped, this command should produce no output exploitation.
Nonessential exploitation accounts are accounts that serve no business purpose. Nonessential accounts are accounts that have never been used or are no longer needed (because of employee terminations, for example). Much like nonessential services, nonessential accounts are favorites among attackers for the following reasons:
Attacks against nonessential accounts are often unnoticed. During brute force password attacks, accounts might get locked out after too many failed attempts. These types of attacks are very detectable because valid users and services will be unable to use the accounts the next time they log on. If an unused account gets locked out, it’s unlikely anyone will notice and so the attacker will go unnoticed.
Nonessential accounts are not often protected well. Passwords protecting nonessential accounts are usually protected by weak passwords or old passwords. New accounts are often created with weak default passwords, and abandoned accounts are protected with old passwords, making them more susceptible to brute force password attacks.
Attackers target accounts that have never been used or have not been used for a very long time. You can find such accounts in your organization’s domain by using the Windows Net.exe command:
net.exe user <username> /DOMAIN
Replace <username> with the user name of the domain user you want to query. For example, net.exe user TestUser /DOMAIN will return the domain account information about the user TestUser. This command returns useful account information such as when a user’s password was last set, when the user’s current password expires, and when the user last logged on. You and your attackers are interested in this last field, and you can explicitly capture this information by passing the output from Net.exe to Findstr.exe like this:
C:>net.exe user TestUser /DOMAIN | findstr "Last logon" Last logon 1/6/2004 2:05 PM
If the account has never been logged on to, this field will contain the value "Never"; otherwise, the last time the account was logged on to will be displayed.
Here are countermeasures you can use to mitigate the threat of nonessential domain accounts:
Create policy. Policy should be created that states how long accounts are allowed to remain unused before they are disabled or deleted.
Review domain accounts. Once policy is created, review the account information for each user in your organization’s domain. If an account that violates this policy is found, the account should be reviewed and disabled, or it should be deleted if the account is no longer needed exploitation.
Cough-cough-wuaaaaha-uuuhhhhhhh-ugh-gasp! That’s the sound of the heart attack you should be having if your organization deploys its domain controllers in an unpatched state. Seriously though, this threat is probably the worst one of them all. Because of the role domain controllers play and the type of information they manage, domain controllers are considered prime targets for attackers, so they should be kept up-to-date on patches. If they are not, attackers could potentially compromise every single user account and service in your organization’s domain.
The following are ways you can detect missing patches on your domain controllers:
Using automated tools. Automated tools such as Microsoft Baseline Security Analyzer (MBSA) can be used to determine the patches missing as well as some common misconfigurations on your organization’s domain controller. A copy of MBSA can be downloaded from http://www.microsoft.com/technet/security/tools/mbsahome.mspx. The Windows Update website at http://windowsupdate.microsoft.com could also be used to detect missing patches.
Using manual methods. You can manually take an inventory of the patches installed on your domain controllers with tools such as Srvinfo.exe, which can be downloaded with the Windows Server 2003 Resource Kit tools at http://www.microsoft.com/downloads/details.aspx?familyid=9d467a69-57ff-4ae7-96ee-b18c4790cffd&displaylang=en. Once you have a list compiled, you can compare it with the results returned by the Microsoft Security Bulletin Search at http://www.microsoft.com/technet/security/current.aspx.
Scan your organization’s domain controllers often and on a regular basis and apply patches as appropriate. Patch verification can be done by following the steps listed under "Verify patch installation" in the "Additional information about this patch" section of each Microsoft TechNet Security Bulletin.
You and your organization should also be concerned about the threat attackers pose to privileged domain accounts and groups. Accounts such as the domain Administrator account and groups such as the Domain Admins group are highly targeted because if attackers can compromise these, they can easily compromise the Active Directory database and essentially take control of the entire domain. Accounts and groups you should be actively protecting include:
Administrator account. Talk about the key to the kingdom! Well, here it is: the Administrator account. This is a built-in account for managing the domain controller and domains and has full privileges across the domain. This account also has, by default, membership in highly privileged domain groups such as Domain Admins, Enterprise Admins, and Schema Admins, and it has full privileges to domain resources.
Domain Admins group. This group has full administrative privileges for the entire domain. So if an attacker is able to gain membership to this group or to any account that is a member of this group, that attacker has essentially compromised the entire domain. By default, only the domain administrator is a member of this group.
Enterprise Admins group. Members of this group are designated administrators of the enterprise. By default, the domain administrator is a member of this group.
Schema Admins. Schema Admins can modify Active Directory schemas. By default, the domain administrator is a member of this group.
Excessive membership into these privileged groups can also create a threat to your organization’s domain. To view membership into highly privileged domain groups, you can manually inspect group memberships using the administrative console. Alternatively, you can use the Windows Net.exe utility. At a command prompt, type the following:
net.exe group <domain_group_name> /DOMAIN
Replace <domain_group_name> with one of the group names listed in Table 26-3.
Table 26-3. Highly Privileged Domain Group Names
Group name | Group description |
|---|---|
"Domain Admins" | Domain administrators’ group name |
"Enterprise Admins" | Enterprise administrators’ group name |
"Schema Admins" | Schema administrators’ group name |
To view membership in the Domain Admins group, for example, you could use this command:
net.exe group "Domain Admins" /DOMAIN
Figure 26-6 illustrates this command and the resulting output.
If your organization has created its own groups, use their appropriate names with the Net.exe command. Protecting domain group membership is important; following are some countermeasures and an example to show you how.
Protecting highly privileged accounts and groups within your domain requires that you keep attackers out and also that you limit membership within these groups. The following can help you accomplish this:
Secure highly privileged accounts. Highly privileged accounts such as the domain administrator’s account should always be protected with strong passwords. See Chapter 15 for information about strong passwords as well as the "Password Attacks" section earlier in this chapter. You should also rename the Administrator account and change its description to something that does not give away its real role in the domain, such as "User."
Limit membership. Membership to highly privileged domain groups should be limited. Current membership into highly privileged groups should be reviewed and excessive rights removed immediately.
Use Restricted Groups policy to limit membership. To control membership to a group, you can use the Restricted Groups policy. When this policy is enforced on a group, only explicitly specified users or other groups are allowed to be members of that group. All others are removed during policy refresh or configuration. Group policy is extremely useful in preventing unauthorized or accidental additions to groups.
All right, time for an example. Say you wanted only the Administrator account to be a member of the Domain Admins group. Let’s see how you can use the Restricted Groups policy to enforce this:
Under Administrative Tools, open Domain Security Policy.
Right-click Restricted Groups and choose Add Group.
Use the Browse button to select the group you want to apply the policy to, and click OK. In our example, we want the Domain Admins group. The Domain Admins Properties dialog box appears (Figure 26-7), allowing you to specify group restrictions.
In the Members Of This Group list, specify only the users or other groups that are allowed to be members of this group. For this example, you want to add the Administrator account. In the This Group Is A Member Of list, specify the other groups that this group is allowed to be a member of.
Click OK.
To verify that this policy is enforced, try adding an account to a restricted group that is not explicitly specified in the Member Of This Group list and verifying that the account is removed on policy refresh or configuration.
Besides trying to elevate their privileges on your organization’s domain controllers and the domains they control, attackers will also try to disrupt communications to and from them through DoS attacks. If domain controllers are unreachable, clients will be unable to authenticate with the domain. Security changes to the Group Policy object might also be prevented from replicating throughout the domain.
The threat of DoS attacks against your organization’s domain controllers can be greatly reduced with the following countermeasures:
Patch domain controllers. Keeping your organization’s domain controllers up-to-date on patches will greatly reduce the threat of attackers exploiting known vulnerabilities that cause DoS attacks.
Deploy multiple domain controllers per domain. Deploying multiple domain controllers per domain in a forest allows domain users to still be able to perform authentication with the domain if one domain controller is attacked or fails because of hardware issues.
Perform regular backups. Perform regular backups of your organization’s domain controllers so that in the event of a serious failure, caused by attackers or other factors, the domain controllers can be easily restored.
Critical infrastructure should always be stored in physically secure locations, especially in the case of your organization’s domain controllers. Attackers who have physically compromised a domain controller can often thwart most software security mechanisms. For example, an attacker could use a boot disk to access data on hard disks that normally would be protected by security mechanisms such as access control lists (ACLs). Or they could do something as simple as restarting the domain controller and cause a DoS attack. Or something even simpler such as access an unattended domain controller whose screen has not been locked. Or they could conduct offline password cracking attacks. Or they could even. . . . Put another way, the sky’s the limit for attackers when they have physical access to a domain controller.
You should at least be asking the following questions when you are assessing the physical security of your organization’s domain controller. Just answering these can help uncover overlooked physical security threats.
How easy is it for external and internal attackers to gain physical access?
What physical security mechanisms would they need to bypass (card keys, video cameras, security guards, man-traps, and so on) to gain physical access, and are these mechanisms sufficient?
How could attackers gain access to domain controllers besides the front door? Could they sneak under raised floors, ceiling spaces, and so on?
What software security mechanisms are in place to help defeat physical security threats?
Is access being logged, and more importantly, reviewed and tracked?
Does building staff have access? How about contractors?
Who else has access? Do they require access to fulfill their job requirements?
This last question is especially important because even when your domain controllers are stored in very secure locations, their physical security can be threatened if excessive access to them is given.
The importance of physically protecting your organization’s domain controllers has, we hope, set in by now. Physical security is often overlooked or more likely is lost in the fuss and bustle of protecting against non-physical threats such as DoS and password attacks. Here are some countermeasures to help raise the physical security level of your organization’s domain controllers:
Store domain controllers in physically secure locations. Your organization’s domain controllers should be stored in physically secure locations that require card access, at a minimum. Also, domain controllers themselves should be stored in locked server racks.
Limit access. Limit the number of people who have physical access to your organization’s domain controllers to only authorized administrators. Also keep the number of people who have access relatively small, say 3 to 5 people, so tracking access is easier and the room for attack is reduced. Unsupervised building staff should be denied access to secure locations. A simple table template such as the one shown in Table 26-4 will be useful when auditing physical access rights. To use this table, simply enumerate all the users who have physical access to domain controllers and enter them into the table.
Table 26-4. Table Template to Assess Physical Access Justification
User name/Position
Physical access level
Business justification for access level
Joe Healy/Domain Administrator
Unsupervised
Requires physical access to make domain-wide configurations on domain controllers
Brenda Diaz/Lab manager
Unsupervised
Requires physical access for domain controller hardware maintenance and other support
Marcus Loh/Building staff
Supervised
Requires physical access for cleaning server rooms
Educate users. Employees who do have authorized physical access to domain controllers need to become part of the solution. Educate them about the threat of physical security and proper practices. Employees who notice tailgaters following them, for example, should require tailgaters to swipe access card readers or inform security teams.
Keep detailed logs. Keep logs of who physically accesses domain controllers, when access was granted, and for what reasons. Maintaining detailed logs such as these will allow you to trace access in the event of a security incident.
Create policy. Create policy that clearly states the allowed physical security practices. Employees at Microsoft, for instance, are required to swipe their access cards with card readers before entering facilities and do not allow tailgating nor allow other employees to tailgate.
Use Syskey protection. The Syskey utility discussed in the "Password Attacks" section of this chapter can be used to help protect against physical security attacks when set to Mode 2 or Mode 3 protection. (See Table 26-1.)
Q. | Is there a guide I can follow on hardening Windows Server 2003 domain controllers? |
A. | Check out the following link to Chapter 4, "Hardening Domain Controllers," in the "Windows Server 2003 Security Guide" at http://www.microsoft.com/technet/security/prodtech/win2003/w2003hg/sgch04.mspx. |
Q. | Are attackers the only source of physical security threats to domain controllers? |
A. | No. Attackers are only half the story when it comes to physical security. You will also have to make provisions for threats such as fires, power failures, and natural disasters. |
Q. | Are there any security templates I can use to quickly secure my organization’s domain controllers? |
A. | Yes. The "Windows Server 2003 Security Guide" at http://www.microsoft.com/technet/security/prodtech/win2003/w2003hg/sgch04.mspx has bundled security templates you can use to help secure your domain controller. |