Security Advisor

Whom Do You Trust?

Active Directory’s trust model makes administration easier than NT, but also introduces the potential to do more damage. Make sure your administrators are trustworthy.

• By Roberta Bragg
• 07/01/2002

You don’t do alleys, you say? Wrong. The alley is your network, the footsteps belong to one of your peers. They think they can hide, and they’re right. They have administrative access to your network/domain/machine and think they have the right to use that power as they please. It may be that they’re mad because they feel they’ve been passed over, insulted. Perhaps they were just fired, but still know too much. Or maybe they got greedy, and someone’s paying them for information or disruptive activity. Maybe, just maybe, they even feel they’re doing the right thing by freely providing confidential information to some authority—or perhaps a court order compels them to do so. Maybe they’re just plain stupid.

As if it’s not enough that you have to consider attacks from the outside and the inside, now you have to suspect those you might ordinarily respect and work with as equals. I’m talking about the damage a fellow administrator can do and why you and your company may want to rethink employment practices, policies and procedures—even your Active Directory design.

I’m going to talk about these issues—both the obvious and less so. I’ll point out an AD alley to avoid or at least to march down arm-in-arm with your crew. However, I want you to consider that the real issue here is one of trust between human beings and how it shouldn’t be given lightly. It’s not just AD that may have hidden issues here, but I digress. My story involves the changes to the NT domain trust model that Windows 2000 makes.

What’s a Security Boundary?
Every NT domain stands alone. By default, the NT domain is a security boundary. Accounts in one domain have no access in another. To provide access, the administrators of both domains must create a trust. Two trusts must be created to make the trust work in each direction. Trusts aren’t transitive; that is, a trust between domain A and domain B and a second trust between domain B and domain C doesn’t imply trust between domains A and C. You can think of domains in NT as hard stops, security boundaries that limit the power of their administrators to a single domain. Even a trust confers no cross-domain administrative privileges or opportunities on the trusted administrator.

Enter Win2K. Trust within a Win2K forest is automatically two-way and transitive. Every domain in the forest automatically trusts every other one. As in NT, ordinary rights and access to resources by users in the “other” (trusted) Win2K domain must be conferred by the trusting Win2K domain. So, can’t we say that a Win2K domain is a security boundary? Well, we can, but we have to be careful to define exactly what that means, something even Microsoft admits it didn’t do a very good job of when Win2K was released. At that time, the Win2K domain was described as the security boundary. Trust relationships, though everywhere, seemed harmless enough. You still had to give access rights. Those rights couldn’t be taken, right? Wrong.

Though security configuration must be made at the domain level, the ability to do so can be procedurally, accidentally and maliciously accomplished by administrators of other domains.

Figure 1 depicts the NT domain vs. the Win2K domain. The NT domain is an allocated island, a castle with a huge moat. The Win2K domain is warring fiefdoms with the drawbridges down, the guards only partially awake at the gate, and lots of secret tunnels ripe for discovery.

Figure 1. NT domains are islands unto themselves, while Windows 2000 domains are far more trusting.

Enter the ÜberAdmins
Anyone who’s read or experienced an AD forest realizes that forest-wide Win2K groups have powers outside their domain. The root domain in the forest contains three groups that extend administrative powers forest-wide: Enterprise Admins, Schema Admins, and Group Policy Creator Owners. The rationale seems simple and innocent enough: Forest-wide control is necessary and useful. Who restores the domain administrator’s account if he manages to lock himself out by adding an empty Administrator’s group to Restricted Groups in a domain-level policy? Simple—an Enterprise Admin. Enterprise Admins are the überadmins of the forest. While domain admins can remove an Enterprise Admin’s permissions from their domain, an Enterprise Admin can gain it back. Schema is a forest-wide issue, so it only seems right to have a special group and give only certain accounts the right to modify it. Surely we don’t want just anyone creating group policies, thus we restrict membership to this group as well.

The problem comes when we begin to think of ways in which these highly trusted individuals with rights that cross the domain boundary could cause problems. They can control all domains in the forest in some way. If I control schema changes, I control the applications you can use in your domain. If I can write group policies, I can write one that prevents or allows your users rights and access. And if I can act with full administrative powers in your domain, I can do what should only be the administrator’s right within that domain.

Perhaps in your organization this is OK, especially if you’re centrally administered. Some authority sets the rules that all may follow. In this scenario, the forest structure makes sense. Power flows from the top. Domain admins and those in OUs with delegated responsibilities have a job to do. Enterprise Admins can take over when necessary. Management Policy controls how all parties operate and, for the most part, it’s followed. A decentralized organization can also function in this model. Typically, an empty root forest is created. But someone has to administer it. Management policy prevents those admins from using the power they have.

Beware of Removing Enterprise Admins
Attempts at removing the Enterprise Admin’s power from child domains can be successful, as the local domain administrator is all-powerful within the domain. To do so, use the steps outlined in the Lucent white paper “Windows 2000 AD Design: Restricting the Enterprise Administrators Group,” at www. lucent.com. Once done, however, it prevents the exercise of activities that only Enterprise Admins have.

• Only Enterprise Admins have complete access to all of AD. This is required to add and delete child domains. When a domain has removed the Enterprise Admin’s privileges, it prevents additions or deletions of domains that are its children or its children’s children, as illustrated by Figure 2. No domains below the west.hcwt.com domain can be added or deleted. Liberty.west.hcwt.com domain, for example, can’t be deleted or birth child domains.
• Only Enterprise Admins can authorize DHCP servers. An unauthorized Win2K DHCP server will shut itself down and not offer addresses when requested. A workaround for this would be to give an Enterprise Admin membership in a child domain’s DHCP users groups.
• However, perhaps there’s some compelling legal, structural, management or historical reason why a single forest design won’t work. Financial institutions, for example, may segregate IT by country to avoid legal issues; they need to be able to prove that no one from one country’s domain can access data from another’s. De-centralized businesses or those with a need to segregate activities with business partners from internal IT may also elect a multiple-forest model.

Figure 2. Be careful when taking an Enterprise Admin out of the picture. In this example, revoking the Enterprise Admin’s privileges at the West.hcwt.com level would prevent any child domain additions or deletions at the lower levels.

Aren’t Site Policies a Good Thing?
Group policies may be implemented at the site level, in addition to domain, OU and local levels. There’s nothing wrong with that, except sites may contain multiple domains, so the administrator who can create a site policy has the power to affect multiple domains. This is another violation of the “domain-as-security-boundary” model. Site policies don’t make much sense in some areas, but I’ve seen successful implementations where, for example, software installation is provided for in a site-level group policy.

All of these things—Enterprise Admins, Schema Admins, Group Policy Creator Owners and Site Level Group Policies—can be used in your organization as desired. Knowing their reach and applying the privileges they entail can be managed. Just as domain admins can manage OUs even when the management of OUs is delegated, it doesn’t mean they will. Your official policies and procedures dictate that. If you don’t want potential management by other organization members, perhaps you’ve already chosen the isolation model of multiple forests.

However, there are two additional issues here. First, how much do you trust those admins who are members of the more privileged groups? Second, are there more insidious ways in which an ordinary domain admin might be able to obtain access and privileges in another domain?

Trust Me, Said the Admin
Sure, OK, yeah. You gotta trust someone. But, really, what do you know about these folks? Do organizations do background checks on admins like they do on financial managers? Do they ask them to be bonded? If they don’t, perhaps they should. Perhaps we should all be thinking about anyone with admin privileges as being the equivalent of someone who handles money for the organization. Quite frequently, the most menial clerk who directly handles cash is subjected to inspection before hiring, and frequently afterward. Why not network, Web and systems administrators? They have plenty of access to things that might tempt them: customer lists; customer credit card numbers; employee information, including the ability to reset passwords and access data; access to sensitive data, perhaps even including encrypted e-mail.

In my days as a systems administrator I wouldn’t have appreciated a background check or more invasive inspection. But do you want to worry that the person you’re depending on might be messing with your accounts? (I hate to plant suspicion in anyone’s mind, but there you are. If you’re going to have a multiple-domain forest, you’re going to need to pay careful attention to who holds these administrative positions of trust.)

Damage Potential
All right. You’ve resolved the issues of the überadmins and got the trust-your-admin program going. What damage can an ordinary admin—no membership in the über groups, no privileges granted by other domain admins, no memberships in another domain’s groups—do outside his or her own domain? Two years ago I would’ve said, “Nothing,” but I was wrong. Misled, but wrong. In an unobtrusive white paper (and apparently some interesting talks at conferences), Microsoft revealed the potential for abuse that’s a result of the tightly coupled AD forest. The paper, “Design Considerations for Delegation of Administration in AD,” at www.microsoft.com/windows2000/techinfo/
planning/activedirectory/addeladmin.asp, is fairly vague but does state that, “Domain owners cannot prevent other malicious domain owners from controlling their services and accessing their data.” Here’s what they can do:

• Modify system software on a domain controller.
• Obstruct operations in other domains in the forest.
• View forest configuration data.
• Configure forest configuration data.
• View any domain’s data.
• Modify any domain’s data.
• View the data from any computers joined in the forest.
• Modify any data on any computer joined in the forest.

It’s not that some hidden GUI interface somewhere allows this. It’s just that domain admins can load malicious system programs (they have to be able to load system programs to add hot fixes and service packs). They can also access and change data in the configuration container for the forest. Then, through replication, the malicious software or configuration change gets transferred to the other domains. Think smart programmers, but also think evil folk who might modify membership in the Exchange Administrators group and thus be able to read anyone’s e-mail or even impersonate them and send e-mail. Once their software or manipulative effort gives them elevated privileges in some other domain, it’s a short step to adding or modifying accounts, changing DACLs on resources, or manipulating group policies for their benefit.

Even if you trust all your administrators today to not abuse these opportunities, can you trust them to guard their domains so that administrative privilege isn’t stolen? Can you trust them forever and a day? (You’ve heard the expression that disgruntled employees are the ones attacking your network? Well, gruntle them already. For some help, see “Administrator Security Best Practices.”) As long as we have people involved in administration, we’re going to have difficulty enforcing uniform security. We’ll always have trouble creating hack-proof domains. If any domain in the forest is breached, the attacker can use it to leverage an attack against any other domain in the forest.