This article will probe some of these issues and upcoming articles will look into Active Directory security even further.
An article on Microsoft's Web site, called 10 Immutable Laws of Security, lists 10 ways that a "bad guy" can compromise your network resources. Three of these laws apply to our discussion here:
- If a bad guy has unrestricted physical access to your computer, it's not your computer anymore.
- If a bad guy can persuade you to run his program on your computer, it's not your computer anymore. (Of course if the bad guy runs the program himself, then it's not your computer anymore either).
- A machine is only as secure as the administrator is trustworthy.
It is important to remember that the domain controller is a gateway to domain resources. Once a DC is compromised, the entire Active Directory is compromised. There are several ways for an intruder to accomplish this -- and remember, the intruder can be internal as well as external. One way is to be physically in the room and touch a DC even without any rights granted to a person is a danger. Thus, if a person has physical access, he or she owns your computer, since physical access grants them control.
Take a good look at your server's physical security
Do you really know every person who has physical access to your domain controllers or other servers? Even if you have them in a locked, secured area, it might surprise you to know who has access.
In one particular story that makes the rounds among IT staffers, a server was rebooting every night at about 11 p.m., and no one could figure out why. Analyzing logs, gathering data and interviewing administrators all proved to be fruitless. Finally, an administrator decided to stay in the office and physically monitor things until after 11 p.m. to try and find out what was happening. He immediately found the problem. Shortly after 11 p.m. the custodian came in to clean the computer room and needed a power outlet to plug in the vacuum cleaner. The only outlet accessible had two cords plugged in (one of them was the server). She pulled the plug to the server, plugged in and used the vacuum cleaner, then plugged the server cord back in.
But what if the custodian was a malicious intruder who could remove a disk drive, crack the administrator password, etc.? How hard would it be to get a job as a custodian to get access to the computer room? Obtaining physical access gives an intruder a huge step forward in his or her attack. Of course, the point here is not to shake down the custodian tonight, but to take a realistic look at physical security.
Be aware of who has administrative rights
Consider a domain administrator in a multiple domain environment who needed to perform an authoritative restore. What if he restored the configuration container as well as his domain, which would inject demoted DCs back into the forest in several domains and break replication severely?
How is this possible? The answer is quite simple. Authoritative restore is performed in Directory Service Repair Mode (DSRM) while the Active Directory is offline. Users log on to the DC with the DSRM Administrator (essentially a local administrator) account and password. That custodian we talked about earlier? If she knew that password, she could boot into DSRM and with the AD offline, restore whatever she wanted to restore. Since there is no Active Directory loaded, there is no security, so delegation of authority is irrelevant. You can't shield a domain admin because he or she can change the DSRM password in the NTDSUtil program.
So how do you avoid this? Again, the answer is to not give domain admin privileges to someone who isn't skilled enough to handle the job or to someone you're not sure you can trust.
Next, anyone with the ability to install/modify system files, including services/drivers (such as server operators, backup operators or print operators) owns your computer. There are many ways for this to happen. Naturally, a secure account could be compromised, giving the intruder the rights to do this, but a valid holder of these rights could cause harm unintentionally by installing an application without testing it first.
I once heard about a situation where a server was being backed up, but 15 minutes into the backup, the backup program hung and never completed. Again, analyzing logs and data didn't find the answer. Finally, the operator on the shift at the time of the backup failure was interviewed. Apparently, doing backups late at night was boring so he installed the game Doom on the server and shared it with his friends so they could all play. The performance hit by the game caused the backup program to fail. The operator didn't look to see if it was successful, he just filed the tape. Just think how frightening it is to have a Doom-playing employee with backup operator rights! Technology can't solve everything.
This example points out how important it is to make sure the people who have access to privileged accounts are trustworthy -- and skilled. Don't provide privileges to someone who isn't skilled enough to perform the operations properly. Of course, the most dangerous account is the domain administrator. I will discuss more issues in future articles regarding the domain admin account, but suffice it to say your infrastructure could very well depend on who controls this account.
Microsoft's best practice in limiting disastrous errors caused by domain admins doing something wrong is to be careful who you give the rights to. Keep in mind that if an intruder gets control of any single DC, this means that he or she also owns every DC in the forest as well as any machine that is a member of the domain. In addition, any resources in trusted domains could be at risk if the compromised account has delegated rights in those domains. Again, in future articles I will go into more detail on this.
Take extra care in securing domain controllers. They hold the infrastructure together and are often overlooked. Also, be sure to remember that physical access is just as important in your security plan as determining delegation of rights.
Gary Olsen is a systems software engineer for Hewlett-Packard in Global Solutions Engineering. He authored Windows 2000: Active Directory Design and Deployment and co-authored Windows Server 2003 on HP ProLiant Servers.
This was first published in December 2006