Trust in Windows Server 2003

Trusts have changed significantly on Windows Server 2003, including the concept of forest trusts. Here's a primer.

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.

Trust Relationships
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.

Selective Authentication
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.

Allowed to Authenticate
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.

Featured

Most   Popular