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
Journey with me down a dark alley where safety is an anachronism; where
you can only depend on yourself; where shadows, soft footsteps and strange
noises convince you that somebody or something is going to get you long
before you reach the other end.
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?
Security Best Practices
Be aware that the domain security boundary can be breached
- Those with überadmin privileges like the Enterprise
- Rogue admins who have abused your trust.
- Coerced admins who may do something because they
are forced by someone through blackmail, at gunpoint,
by the FBI and so on.
- Attackers who don’t have administrative privileges
but manage to gain them.
You must deal with this issue by first determining
which trust model is right for you. If you require autonomy
(independent management of some or all of the services
and data within your domain), you may elect to use the
multiple domain forest model. Autonomy assumes other
administrators may have equal or higher privileges within
their domain. If you require isolation (prevention of
other administrators management of any service or data
within another domain), you’ll opt for a multiple-forests
design. A specific flow chart in the Microsoft white
paper referenced earlier in this article may help you
to decide. The white paper, “Design Considerations for
Delegation of Administration in AD” at www.microsoft.com/windows2000/techinfo/planning/
activedirectory/addeladmin.asp, provides additional
steps toward minimizing the risk of these types of privilege
escalation attacks. These steps follow well-known security
best practices, which I’ve reproduced with commentary
- Have as few administrators as possible. Evaluate
all administrative groups, including Enterprise, Schema
and Domain Admins and Account, Server and Backup Operator
- Constantly review group membership. Consider use
of Restricted Groups to ensure it’s maintained.
- Evaluate administrators on an annual basis.
- Develop a pre-employment process for administrators,
including background checks, bonding and other screening
- Create an atmosphere in which employees feel valued
and supported. Malicious attacks are often performed
by disgruntled employees.
- Require administrators to take their vacation days.
An evaluation of previous fraud and abuse cases has
found that, often, those involved rarely left their
post. Thus, they were able to hide their activities
- Cross-train and rotate administrative employees.
Keeping one administrator from having permanent control
in an area often prevents abuse of privilege.
- Ensure that membership in administrative groups
can’t be manipulated by any user who isn’t a member
of these groups.
- Don’t place external trusted domains into internal
- Audit administrative group membership.
- Require administrators to use non-administrative
logons for ordinary daily tasks such as reading e-mail.
- Don’t allow non-administrators to control an administrator’s
workstation. Never delegate control to a non-administrator
for an OU that includes an administrator’s machine
- Physically secure domain controllers. All Win2K
domain controllers contain a writable copy of AD and
could become victims of an attack that cripples the
entire forest. Pay special attention to branch offices,
where lack of server rooms or adequate lockdown capability
may not be present.
- Prevent non-administrators from having console
access and/or logon privileges to the domain controllers.
Non-administrators shouldn’t be able to physically
access the machine.
- Control and secure backup tapes or other backup
media. Again, non-administrators shouldn’t be able
to access these tapes.
- Reduce the number of services and programs run
on domain controllers. Each service or program may
have unknown vulnerabilities.
- Establish, train, test and maintain business continuity
- Create security standards and best practices for
all systems. Train administrators in their use and
impress upon them the need to follow these standards.
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
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.)
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.