5 Steps to a Secured Active Directory

Active Directory (AD) holds the proverbial keys to the kingdom for many organizations—and not properly securing AD can leave that kingdom vulnerable. Admittedly, AD isn't easy to secure, but there are some basic steps you can take to ensure your AD infrastructure is reasonably secure. Note that I said basic steps. Security is a trade-off. There are always measures you can take to increase security, but they come at a price, either in terms of actual dollars or the loss of flexibility or functionality. Let me show you five steps that don't cost much to implement but can significantly help secure your overall AD infrastructure.

Step 1. Follow the Administrator Best Practices
You can always improve AD security by automating manual processes, such as building domain controllers (DCs), but there hasn't been a programming language developed yet that will automate human behavior. That's why you need to set guidelines on how your administrators should manage AD. You need to make sure that your administrators adhere to the following best practices:

Use separate administrative accounts. Using separate administrative accounts has become standard practice for many organizations, but it's still worth mentioning. If an administrator's machine accidentally becomes infected with a virus, the potential risk is much greater because, with administrative rights, the virus can run programs or scripts. Thus, administrators should use a nonprivileged account (e.g., a user account) for day-to-day use and a separate administrative account to perform privileged AD tasks. You can use tools such as the Runas command to open programs as an administrative user while logged on with a nonadministrative account. For information about how to use the Runas command, see the Windows online Help file.

Use secured administrator workstations. Although there are advantages to requiring your administrators to log on with nonadministrative accounts and use tools such as Runas to open AD administration programs, you're still at risk if the underlying system on which the tools are running isn't secure. If an attacker has taken over an administrator's computer without the administrator knowing it, using alternative credentials buys little security—the attacker can take advantage of those alternative credentials. If you can't ensure the security of your administrators' computers, you need to create a separate secured administrator workstation and have the administrators use terminal services to access that workstation. To secure this workstation, you can put it in a specific organizational unit (OU) and apply restrictive Group Policy settings. Be cognizant of physical security as well. If an administrator's computer is stolen, you should consider everything on that computer comprised.

Check administrative group memberships periodically. One way attackers can obtain elevated privileges is to add their account to an AD administrative group, such as Domain Admins, Administrators, or Enterprise Admins. For this reason, you should pay close attention to the members of AD administrative groups. Unfortunately, AD doesn't have any built-in mechanisms to send notifications when the membership of certain groups change, but it's fairly easy to write a script that enumerates groups' membership and run that script at least once a day. Enabling auditing on those groups is also a good idea because you'll then have a record of any changes in the event logs.

Restrict who has access to the Administrator account password. If an attacker gains access to the Administrator account password, he or she would have significant privileges in the forest and his or her actions would be hard to track. Thus, you typically shouldn't use the Administrator account to perform administrative AD tasks. Instead, you should create alternative administrative accounts, add them to the Domain Admins or Enterprise Admins groups, then use those accounts to perform just about every administrative function. The Administrator account should be used only as a last resort. Because its use should be greatly limited, the number of people who need to know the password should also be limited. And because any administrator can change the Administrator account password, you might even want to monitor all logon attempts for this account.

Have a process for quickly changing the Administrator account password. Even when you limit access to the Administrator account to only a few people, you need a process for quickly changing that account's password. It's a good idea to change the password every month, but if an administrator who knew the password (or had rights to change it) leaves your organization, you need to change the password immediately. This guideline also applies to the Directory Services Restore Mode (DSRM) password that you set when you initially promote a DC and any service accounts that have administrative authority. The DSRM password is the password for the administrative account you use to log on after booting into Restore Mode. Windows Server 2003's Ntdsutil is a simple command-line tool that you can use to change this password.

When changing a password, you should consider using extremely long (more than 20 characters) random passwords. Such passwords are difficult for administrators to memorize for later use. After you set the password, you might want to give it to a manager and have him or her control who uses it.

Have a process for quickly disabling administrative accounts. For most AD organizations, the biggest security risk comes from administrators, especially rogue former administrators who have a gripe with their former employers. Even if you're good friends with an administrator who voluntarily or involuntarily leaves your company, you should immediately remove all administrative access for that person.

Step 2. Follow the DC Best Practices
After making sure that you're following the administrator best practices, you'll want to turn your attention to your DCs because they're the easiest targets in many AD implementations. If an attacker can successfully break in or disrupt a DC, your entire forest might be at risk. Thus, you should follow these best practices:

Ensure the DCs' physical security. The physical security of your DCs is one of the most important issues you need to consider with any AD deployment. If an attacker can gain physical access to a DC, he or she can subvert virtually all other security measures. Physical security generally isn't a problem when you house DCs in data centers; it's more likely to be a problem in branch-office deployments. In branch offices, DCs are often stored in locked rooms that non-IT personnel have access to. In some situations, this setup can't be avoided. But no matter what the situation, you should have a high level of trust in anyone who can physically access the DCs.

Automate the build process. In general, automating a task is much more secure than manually performing that task. This is especially true for building and promoting DCs. The more you can automate the OS build and configuration process, the less variability you'll have in your DCs. When people manually build servers, they tend to do things slightly different from server to server. Even if you have the process thoroughly documented, there still will be slight differences in how the servers are configured. By automating the build and configuration process, you can be reasonably sure that all your DCs are configured and secured similarly. For DCs that are already built, you can use tools such as Group Policy to ensure they're configured the same.

Install important updates quickly. Back in the days of Windows NT, most administrators wouldn't install hotfixes or security updates unless absolutely needed. Frequently, updates would be buggy and cause further problems. Now, we don't have that luxury. Fortunately, the quality of updates from Microsoft is much better. Because DCs are highly visible targets, you have to pay close attention to any security updates that come out. You can sign up to receive email notifications about new security updates at http://www.microsoft.com/security/bulletins/alerts.mspx. You can install security updates immediately with Automatic Updates or test and install them selectively with Microsoft Software Update Services (SUS).

Create a reserve file. In OSs earlier than Windows 2003, if users have the rights to create objects in a container, there's no way to limit the number of objects they can create. The lack of a limit can lead to a situation in which an attacker continuously creates objects and fills up a DC's hard disk. You can mitigate this risk to a certain degree by creating a 10MB to 20MB reserve file on each DC. If you run out of space on a DC, you can delete the reserve file and give yourself a little breathing room until you figure out how to resolve the situation. There's nothing hard about creating a reserve file. It can simply be a Microsoft Word document or text file that contains random text.

Run virus-scanning software. Running virus-scanning software on your DCs is more crucial than running this software on most servers because DCs replicate not only directory information but also file content through the File Replication Service (FRS). Unfortunately, FRS provides a simple way for viruses to be distributed among a large number of servers. And because FRS typically replicates logon scripts, the potential risk permeates all the way to the clients. Running virus-scanning software can drastically reduce the risk of viruses being replicated to servers and clients.

Step 3. Follow the Delegation Best Practices
Misconfiguring the ACLs that protect AD's content can leave AD vulnerable to attack. In addition, the more complicated you make delegation, the more difficult it is to maintain AD as well as troubleshoot problems. Thus, I like to apply the Keep It Simple, Stupid (KISS) philosophy. The simpler you can make delegation, the better off you'll be, especially when it comes to security. In fact, this philosophy applies to designing AD in general, as the sidebar "Design Dictates Security" explains. To help keep delegation simple, I highly recommend that you read the Microsoft article "Best Practices for Delegating Active Directory Administration" (http://tinyurl.com/vzlg).

In addition to keeping delegation simple, you should follow these other best practices:

Don't assign permissions to user accounts. One of my cardinal rules for delegation is to always assign permissions to groups, not users, unless you have a very good reason. What happens when a person to whom you assigned permissions leaves the company or changes job functions and no longer should have that access? It's much more work to track down each permission an account has been granted, revoke those permissions, and grant the permissions to another user than it is to simply remove the old account from a group and add the new account. Even if you think that the rights you're granting to a specific person will never be needed by anyone else, create a group, put that user in it, then assign the permissions to the group.

Don't assign permissions to individual objects. When you assign permissions directly to individual objects (such as a user or group object), things start to get complicated. Such permissions require more maintenance, and they're easy to overlook later. To avoid problems, you should grant rights to OUs or containers as much as possible.

Document the model. One of the most important tasks when you're delegating rights is to document your model. Have you created a role-based model? What are the procedures for requesting access? Have you made exceptions to your general model? All these items are important to document not only to make maintenance easier but also to ensure that everyone knows how rights should be delegated and can identify when permissions aren't structured that way (which can make AD vulnerable to abuse). The form this documentation takes isn't important. This document just needs to be readily available to those administrators who need it.

Become familiar with Dsrevoke. The Delegation of Control wizard that you can run from within tools such as the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in is great for initially delegating access. However, using this wizard or other graphical tools to perform undelegation tasks (e.g., removing all occurrences of a certain account from ACLs) is tedious to say the least. Fortunately, Microsoft released the Dsrevoke tool, which lets you enumerate through all the ACLs in a domain and remove access for the accounts you specify. Become familiar with this tool because it's a delegation lifesaver. You can download this free tool at http://www.microsoft.com/downloads/details.aspx?familyid=77744807-c403-4bda-b0e4-c2093b8d6383&displaylang=en.

Step 4. Monitor and Audit Your AD Organization
Because AD has so many components, it can be difficult to ascertain when someone is trying to subvert your security measures. You can follow the best practices I've outlined so far, but how do you know if someone is trying to slip through? The answer is monitoring and auditing.

At the very least, you should monitor the basic availability of your DCs. Monitoring the availability of a host is something you probably already do to ensure the overall availability of your AD infrastructure. But from a security standpoint, it's important to know when a DC goes down unexpectedly so that you can investigate the cause as soon as possible. Perhaps a DC in a remote site was stolen or an attacker obtained physical access and shut down the machine to install a Trojan horse program.

Besides monitoring the basic availability of DCs, you can use Performance Monitor to monitor many AD measures, ranging from the number of Lightweight Directory Access Protocol (LDAP) queries per second to the amount of data being replicated. You can establish a baseline for each of the counters in which you're interested, then monitor them. If you then notice, for example, the number of LDAP queries or authentication requests per second spike significantly over a period of time, it might be an indication of some sort of attack. For more extensive monitoring (and even alerting), you can use a tool such as Microsoft Operations Manager (MOM).

The auditing facilities provided by Windows OSs and AD let you log certain events to the Security event log. You can log everything from various OS configuration changes to modifications within AD. However, you should enable auditing with caution. If you audit too much, you'll quickly overwhelm your security logs and not be able to pick out the important events. For guidance on what you should audit, see the Microsoft article "Best Practice Guide for Securing Active Directory Installations" (http://tinyurl.com/3c928).

Step 5. Prepare for the Worst
Perhaps the most important aspect of security planning is developing a process for handling successful attacks. Implementing the best practices I've described here doesn't ensure security; it raises the bar for potential attackers. You can have the most locked-down AD infrastructure around, but if an attacker creates a zero-day (i.e., previously unknown) AD attack, there's likely nothing you can do to prevent the attack because you don't know about it yet. That's why preparing for the worst is important—you'll know what to do if you find yourself in that situation. If you find that your forest was fully compromised and needs a bare metal restore, you'll save precious time by having at least thought about the process previously.

You should periodically perform forest recoveries in a lab environment to ensure you can restore a forest from a backup. You should also document the recovery process. Microsoft has a good article, "Best Practices: Active Directory Forest Recovery" (http://tinyurl.com/3rk7b), that can guide through the process.

Take the First Few Steps
In this article, I've covered some of the basic steps you can take to improve your AD security with little cost. I've really only scratched the surface, but if you follow these steps, your AD organization will be much more secure than many others.