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.
Register
