Professor Windows - March 2003

  • Article

Windows Server 2003 Trust Enhancements

By Yossi Saharon

Reviewed By:

Tal Sarid, Solutions Security Architect, Microsoft Israel

JK Jaganathan, Program Manager, Windows Security, Microsoft Corporation

Introduction

When I think back on my Windows NT 3.x/4.0 days, there is one feature I especially recall not enjoying configuring and maintaining in Windows NT's security management: Trust relationships. And I think I was not alone - this was probably one of the earliest features in Windows NT that system administrators really didn't like much, especially in terms of maintenance. When Windows 2000 came out and introduced transitive trusts based on the Kerberos authentication protocol, things looked very different and trust relationships management in the Windows platform were greatly improved.

Windows Server 2003 includes many enhancements in the fields on information security, with new ways to securely manage your organization's infrastructure. Managing trust relationships in Windows Server 2003 includes both improved and new features that you'll really love.

This column assumes that you have knowledge of Active Directory terminology and architecture. To read more on Active Directory technologies, see the following link: https://www.microsoft.com/windows2000/technologies/directory/default.asp

Same-Same but Different: Introducing Forest Trusts (AKA: Federated Forests)

Coming from Windows 2000's Active Directory MMC experience, a first look in Windows Server 2003 trusts management will not be obviously indicative of that much of a change. Taking a closer look, however, reveals a very different approach in this same-same feeling: The Windows Server 2003 family supports domain trusts and forest trusts. We know what domain trusts are: they allow a user to authenticate to resources in another domain. Like always, all domain trust relationships have only two domains in the relationship: the trusting domain and the trusted domain. There are one-way trusts (unidirectional) and two-way trusts (bi-directional) and a Windows Server 2003 domain can establish a trust among other Windows 2000/2003 domains in the same or different forest, Windows NT 4.0 domains and Kerberos V5 realms. In Windows 2000, if users in one forest needed access to resources in a second forest, an administrator could create an external trust relationship between the two domains, which is one-way and non-transitive. This meant that in order to extend your trust to other domains in the forests you had to explicitly configure each and every one of them.

Windows Server 2003 offers a forest trust: two-way Kerberos-based transitive trust between Windows Server 2003 forests, enabling a transitive trust between all the domains in the two forests. Forest trusts are established between the root domain of both forests and can be either one way or two way. A Few things to remember are to make sure all domain controllers in both forests are running Windows Server 2003, with a correctly configured DNS infrastructure and forest functionality level set to Windows Server 2003 mode in both forests.

Let's look at a quick example: In an enterprise scenario, corporations might have different forests for different business requirements. So, in this example, we have one forest for our external customers, one for our business partners that might be updating some type of line of business application database, and our internal corporate forest (see Figure 1).

There are two distinct aspects of the cross forest transitivity that need to be noted, the first being that all domains are transitive between two forests, as I mentioned before.Again, this can be either full transitive trust if needed, or various degrees of granular trust.

The second point to note is that the transitivity does not flow between forests, meaning that if there is a trust relationship between the customer forest and our corporate forest, this does not flow through on to our partner forest, and therefore trust will not be transitive between the customer forest and our partner forest.

If your browser does not support inline frames, click here to view on a separate page.

Figure 1   Transitive Trusts between all domains in two forests

Psst.. Here's a hint: Try Routing

A forest trust between two Windows Server 2003 forests brings to life a new mechanism to help simplify access to resources between the forests and eliminate the need in shortcut trusts. Let's say there's a workstation in one forest that attempts to access data on a computer in the other forest: Kerberos contacts the domain controller for a service ticket to the SPN of the destination computer, the domain controller queries the global catalog, sees that the SPN is not in the same forest as the domain controller, and sends a referral for its parent domain back to the workstation. Now here's where we throw the "hint" at that workstation: "workstation, pssst.. Go query the parent domain for the service ticket and follow the referral chain until you get to the domain where the resource is located. This is called 'Routing Hints' and is visualized in Figure 2:

If your browser does not support inline frames, click here to view on a separate page.

Figure 2   Routing Hints process step-by-Step

At the end of this process, the initiating workstation holds a Service Ticket to the destination computer.

Preventing Elevation of Privilege Attacks

Today, there's a possibility you will be sent illegitimate SIDs by the other side of the trust, as long as the credentials are validated. However, in Windows Server 2003 we always filter the SIDs to make sure they are relative to one of the domains in the trusted forest. This check helps to prevent elevation of privilege attacks. This also ensures that the other forest issues authorization information only for authorized domains, and is not passing in any unauthorized SIDs.

SID filtering is enabled automatically across a Forest Trust.

The Selective Authentication Option

We all know how a network firewall basically works, allowing through only certain network access requests. That's exactly what the new Selective Authentication option does in Windows Server 2003 trusts: it allows only specific authentication requests.

Let's say that a user authenticates from a trusted forest to ours: it is given the 'Authenticated Users' SID in his token, and can now try and access any resource in our forest. So what can we do? Well, we let the domain controller decide if that user is allowed to authenticate to a specific resource before allowing the user access. Once you enable the Selective Authentication Option, you need to configure which users from the other side of the trust can authenticate to which resources in your domain. The implementation is performed by a new control access right called "Allowed to authenticate" on an object, which becomes available when you switch to Windows Server 2003 forest mode. This helps you get much granular control on who can access what across a forest trust.

If your browser does not support inline frames, click here to view on a separate page.

Figure 3   Configuring "Allowed To Authenticate" right on an AD object

And Then Some!

There are other trust enhancements that, although they are relatively small changes compared to the new forest trust and its great mechanisms, can still really make a difference for some of us. These changes include:

  • Windows Management Instrumentation (WMI) classes to monitor whether Domain Controllers are successfully replicating Active Directory information among themselves. Because Active Directory replication, like many other components, relies on inter-domain trust, this feature also provides a method to monitor that trusts are functioning in a healthy manner.
  • A new Trust Wizard that creates both sides of trust link in one operation, assuming proper credentials are supplied for both sides. This applies to Windows 2000 and Windows Server 2003.
  • A new group named "Incoming Forest Trust Builders" so domain users who are members of this group can create inbound Forest trusts. That way we support delegation to deploy Resource Forests. By default, there are no members in this group.
  • We can now setup trust over firewalls by opening only specific ports. There is a white paper currently being written on "Federated Forests" that will include more information on this option, as well as the list of ports.
  • Another nice enhancement with cross forest trusts is the ability to add users by their UPN (Universal Principal Name. e.g. user@domain.com) from another forest, directly from the access control list UI...very cool!

There are other areas that come into play with multiple forests, such as Synchronizing data between your various forests.

You can synchronize global address lists (GALs) and objects across forests using technologies such as Microsoft Metadirectory Services (MMS) which are part of Windows Server 2003 Enterprise edition.

Common data types that need synchronization across forests include:

  • GALs (Exchange)
  • Public folders
  • Directory objects
  • PKI Certificates and CRLs

Synchronizing this data across forests will help end users view address lists and other data the same way as they do when viewing this information within their own forest.

For more information about MMS, take a look at

https://www.microsoft.com/windows2000/technologies/directory/mms/default.asp.

As you can clearly tell by now, Windows trusts have really come a long way since the Windows NT days. Windows Server 2003 cross-forest trusts is a powerful new feature that will give administrators more control and security, within and between their business environments.

I trust you'll enjoy exploring those new trust mechanisms, trust me. And may the source be with you...always!

Related Links

Technical Overview of Windows Server 2003 Security Services

Forest trusts

Checklist: Creating a forest trust

For any feedback regarding the content of this column, please write to Microsoft TechNet. Please be aware that a response is not guaranteed.