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