Security Advisor
Trust in Windows Server 2003
Trusts have changed significantly on Windows Server 2003, including the concept of forest trusts. Here's a primer.
- By Roberta Bragg
- 09/01/2003
The other day I was talking with my personal trainer, Scottie, about personal security. I was getting ready to go on another trip and, as usual, he was full of advice.
“Don’t let someone who calls you by name get within six feet of you if you don’t recognize them,” he commanded. He went on to explain. “They might have gotten your name from the name on that forgotten conference badge, company ID pinned to your purse, the vanity plates on your new SUV or even from the T-shirt you’re wearing. They might be up to no good.”
“But wait,” I responded. “My name and picture appears in a national magazine; what if it’s one of my fans?”
“In your dreams” he muttered, then turned and walked away.
Trust is a complicated issue. It’s hard to know when to trust another
person and it’s hard to know when and how to develop trust between two
Windows domains or forests. Which domains or forests should you trust
and which assets are you going to allow others to touch? Won’t creating
a trust expose resources to unauthorized access? While I can’t help you
make decisions about which people and Windows domains or forests to trust,
I can help you understand the kinds of Windows trust relationships you
can make. Windows Server 2003 provides new opportunities for trust between
other Windows domains. There are new ways to establish trusts, like a
complete forest trust where one trust relationship established between
forest root domains can mean transitive Kerberos trust between all domains
in the forests. There are also new ways to limit trust, such as selective
authentication, which restricts access within a trust relationship. This
means you can establish a trust and limit access to specific groups and
specific servers within a domain or to specific domains within the forest.
Trusts B2003 (Before Windows 2003)
Note: Forget for a minute the ability to abuse
the Everyone group and anonymous logon; we’re talking upfront, honest
administration here. There’s always a way to hack in, if you’ve a mind
and the talent. Protecting systems from abuse is a combination of hardening
them and using them the way they were designed. The first is a subject
for another column; today we’re going to assume locked down systems in
a protected network.
Windows NT 4.0
In the Windows NT 4.0 world, every domain was an island. If you didn’t
have an account in the domain, you couldn’t be granted privileges nor
given access to resources such as files and folders. In organizations
with multiple domains, you created Windows trust relationships between
domains. They were one-way, non-transitive trusts. Non-transitive means
that if domain A trusts domain B, and domain C trusts domain B, there
is no trust relationship between domain A and C. One-way means that one
domain is trusted—it has accounts to which the other domain wants to give
access. If domain A trusts domain C, then domain C is said to be trusted
and domain A to be trusting. Domain A can grant file access to users and
groups in the C domain. Because the trust is one-way, a second trust—domain
C trusting domain A—has to be created so that domain C can give domain
resource access to users and groups from domain A. These features, one-way
and non-transitive, meant, for many organizations, hundreds of trust relationships
had to be created and managed.
Windows 2000
In a Windows 2000 forest, no domain is an island. All domains are universally
connected via Kerberos-style transitive trusts. That means any domain
administrator of any forest domain can grant access to his or her domain’s
resources to any user or any group from any other domain in the forest.
Cool. But what if you need to grant access to your domain resources to
users in an NT domain or those in another forest? Win2K domains can engage
in “external” trusts—trust relationships with a single domain from another
forest, or with an NT domain. These trust relationships are NT-style trusts;
non-transitive, one-way, no Kerberos. If users from multiple domains in
forest A require access to resources in forest B, multiple external trusts
must be made. If multiple trusts are required, we begin to have the same
problem as with NT trusts. Lots of management, lots of pain, diagrams
blackened with arrows which represent the relationships.
There’s another characteristic of Win2K external and NT trusts more unpleasant
and difficult to resolve. We’d like to think that once the trust is made,
administrators in the trusting domain must take action before users in
the trusted domain can touch anything. But that’s not exactly true. Because
we can’t always protect systems from anonymous access (some critical application
may require it), and because the Everyone group has far-reaching access
by default on NT and Win2K systems, just successfully completing a trust
relationship between two domains gives a lot of default access to the
trusting domain. A disgruntled employee could take advantage of this,
and should an account in the trusted domain be compromised, then the entire
trusting domain is also at risk; there’s no way to limit the trust to
specific servers or resources.
A Better Trust Model
Windows 2003 solves both of these problems: The need to create complete,
Kerberos-style, transitive trusts between two forests, and the ability
to limit what trust means, both in the forest trust, and in the external
trust.
The forest trust is, simply, just that. When a forest trust is established between forest A and forest B, every domain in each forest “trusts” every domain in the other forest. If I want to assign resource access in every domain in forest A to any user with an account in any domain in forest B, I can do so. What’s more, trusts are Kerberos trusts, and Kerberos can be used for authentication. Forest trusts can be one- or two-way; it’s simply a choice in the new Trust wizard.
In addition to a trust wizard there is new nomenclature. Trusts are no longer defined in terms of “trusted” and “trusting” domains, but in terms of “outgoing” and “incoming” trusts. In reality it’s still simply a way to describe the direction of the trust. An incoming trust from A to B means that users and groups in B can be assigned access to resources in A. (A and B can represent domains joined in an external trust or forests in a forest trust.) An outgoing trust, one from A to B, means that users and groups in A can be assigned access to resources in B. Figure 1 illustrates an incoming trust from forest B to forest A. Note that users John and Mary, who have accounts in domains in forest B, are given access to folders on servers in two different domains in forest A. In the figure, the arrow between the two root domains of the forests indicates the trust; we don’t need to draw all the arrows between domains.
 |
| Figure 1. An incoming trust into forest A means users
in forest B can be granted access to forest A resources. John and Mary don’t
have blanket access to all resources in forest A, but only specific folders
on specific servers. |
The complete nature of this trust brings problems. While the Everyone
group is more restricted, anonymous access is curtailed and the anonymous
SID is no longer part of Everyone, Windows 2003 still provides, by default,
more access than some would like. Certainly there is exposure. Completing
a forest trust does mean added risk. Fortunately, there is a solution
which can help mitigate that risk.
| Functional
Levels in Windows Server 2003 |
| Functional level is both a statement of
fact about the operating system level of domain controllers,
and a Windows 2003 mode set by an administrator. The functional
level can’t be set unless its requirements are met; once
set, it provides additional features. Also note that while
you can raise the functional level of a domain or forest,
you can’t reduce it. A Windows 2003 domain at the Windows
2003 functional level can’t return to the Win2K functional
level (this means new Win2K domain controllers can’t be
added to the domain).
There are two types of functional levels. A domain
functional level indicates which operating systems DCs
in the domain may have, and a forest functional level
indicates the functional level of all domains in the
forest. Table 1 summarizes these notions. Note that
these requirements are strict, i.e., in order to raise
a functional level you must meet them. However, functional
levels aren’t raised automatically. If your domain entirely
consists of Windows 2003 DCs and you haven’t raised
its functional level, it’ll remain at the default Win2K
functional level. This is an important concept, as many
advantages in Windows 2003 can’t be used until the functional
level is raised to Windows 2003. For example, you can’t
create forest trusts, even if both forests consist of
nothing but Windows 2003 DCs, until both forests are
raised to Windows 2003 functional level.
Table 1.
The highest forest Functional Level attainable
for a forest is dependent on the operating systems
installed on domain controllers.
|
| |
FUNCTIONAL |
LEVEL |
Operating
Systems on
Domain Controllers |
Domain |
Forest |
Windows 2003
|
Windows 2003
|
Windows 2003
|
| Windows 2003
or NT |
Windows 2003
or Interim |
Windows 2003
or Interim |
| Windows 2003 or Win2K |
Win2K Native |
Win2K
|
| Windows 2003
or Win2K or NT |
Win2K Mixed |
Win2K |
|
|
|
|
|
Selective Authentication
Windows 2003 forest and external trusts can be limited by choosing Selective
Authentication. If Selective Authentication is chosen during trust building,
no access can be granted to servers in the trusting domain of an external
trust, or any domain of the incoming forest trust, until the Allowed to
Authenticate permission is granted to groups or users as specified by
the administrators of the domain. Administrators can add trusted user
and group ACLs to resources in the domains, but no actual access by these
external entities will be allowed until they’re also given the Allowed
to Authenticate permission.
This does seem counter-intuitive at first. Why can users be granted access but be prevented from using it? Wouldn’t it be easier to also prevent the administrator from setting up ACLs? Aren’t we going to be spending a lot of time troubleshooting why access isn’t working?
I don’t know why, in designing selective authentication, a decision was
made to make it work this way. However, it would seem to be pretty complicated
to deny access to trusted users and group accounts in the object picker
and yet allow this same access when granting the Allowed to Authenticate
permission. In a perfectly managed Windows 2003 forest, you shouldn’t
run into this problem; if selective authentication is used, ACLs won’t
be set in domains or on servers for which the Allowed to Authenticate
permission hasn’t been granted. In other words, trusts will be set up
and managed correctly, and administrators will both follow instructions
and not exceed their authority. However, in real-world networks, stuff
happens and troubleshooting is required. Frankly, I’d rather have the
ability to perform selective authentication, even if it means I’ll step
on my own toes occasionally.
Choosing Selected Authentication
If a trust will be an external trust and selective authentication is established,
Allowed to Authenticate permission must be granted on each server in the
trusted domain on which you wish to share resource access to external
users. For example, you want to give the PublicRelations group in the
west.new access to files on the fileserver runners.workout.bodyworks.xx
domain. These two domains are part of separate forests (playball.xx and
bodyworks.xx) and the workout. Bodyworks. xx domain has many servers.
You only want the folks in PR to have access to the Runners server. To
provide this access and only this access, from the workout.bodyworks.xx
domain create an Incoming external trust with the west.newyork.baseballisus.playball.xx
domain and require selective authentication. When the trust is complete,
visit the Runners server security property page in Active Directory Users
and Computers and grant the Allowed to Authenticate permission to the
west.newyork.baseballisus. playball.xx\ PublicRelations group. Finally,
visit the file system of the Runners server and grant appropriate access
to files, folders and shares the Public Relations group needs to have.
Figure 2 shows the New Trust wizard. Note that no access to the other
trusting domain servers can be granted to the Public Relations group,
nor can other West domain users or groups be granted access to runners
or any other server in the Workout domain.
 |
| Figure 2. Choosing Selective authentication places
restrictions on access. |
Using selective authentication requires planning and forethought; here are the steps in a nutshell.
1. Selective authentication requires Windows 2003. Creating a forest trust requires the forest to be at Windows 2003 forest functional level. (See “Functional Levels in Windows Server 2003” for an explanation.) Be sure domains and forests are at the proper functional level before creating the trust.
2. Carefully plan which resources to expose. It makes no sense to opt for selective authentication if you want all resources to be available. It also makes no sense to use selective authentication without planning which resources need to be available and to which users. A trust set for selective authentication in which Allowed to Authenticate permission is not granted anywhere is useless.
3. Make selective authentication your choice. It can be made during trust creation or added or removed afterward.
4. Grant privileges and resource access to the resource domains and servers as desired, as shown in Figure 3.
 |
| Figure 3. Don’t forget to assign the Allowed to Authenticate
permission when using selective authentication. |
Trust relationships are complex. To learn more about them in Windows
2003, read the whitepaper “Planning and Implementing Federated Forests
in Windows 2003” at http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtech
nol/windowsserver2003/maintain/ security/fedffin2.asp.
| SID
Filtering |
Windows 2003 provides another feature, which limits trust boundaries between forests. SID-Filtering is automatically enforced between forests in a forest trust. This means that a rogue administrator or attacker using a compromised account in one forest can’t spoof SIDs belonging to another forest and use them to gain elevated privileges across a trust boundary. SID-Filtering acts like ingress filtering on a router. Ingress filtering drops packets arriving on an external interface that have a source address from the internal network (a network connected via the internal interface of the router). SID-Filtering drops SIDs from a user’s authorization data if the user’s account is from an external domain or forest and the SID is from the internal domain or forest. |
|
|
Trust Must be Earned
In the end, what matters most in a trust relationship is the proof that
your trust is warranted. You don’t get that by opening up the doors and
exclaiming, “My house is your house.” You need auditable trust boundaries
that limit outside access to goods and services. Your limits for outsiders
should follow the security principal of least privilege—only give users
just the privileges and permissions they need to do their jobs. Windows
2003 trusts and selected authentication can help you do that.