UW Windows Infrastructure Trust Relationships

Requesting a trust with the UW Windows Infrastructure (UWWI) is the first step in making use of the automatically-provisioned Windows user accounts that correspond to UW NetIDs (hereafter referred to as UW Windows user accounts). After successfully obtaining a trust and configuring your resources with the appropriate access controls, you will be able to tell your clients to login with UW Windows user accounts to obtain access to your Windows domain-based resources.

Before requesting a trust, you'll want to consider the implications of both the trust itself and the type of trust you'll need to request.  There are important differences between a Domain Trust and a Forest Trust.

What are the kinds of trusts and the differences?

There are two kinds of trusts available to you when using the UW Windows Infrastructure:

1. A One-Way Forest Trust
2. A One-Way Domain Trust

Both types of trusts will allow you to utilize UW Windows user accounts. There are some important differences that you will need to be aware of and take in account before making your decision:

Domain Trust		Forest Trust
The single trusting domain	Trust Boundaries	Entire forest
NTLMv2 only (NTLMv1 and LanMan are prohibited)	Authentication Protocols	Kerberos, NTLMv2, and NTLMv1 (LanMan is prohibited)
Windows 2000 Mixed Mode (any mode, really)	Minimum Forest/Domain Functional Level	Entire forest must be at Windows Server 2003 Native
Traditional DOMAIN\username	User Name Conventions	Traditional DOMAIN\username or Kerberos-style user@netid.washington.edu format
Yes	Available to the UW Windows Forest	Not available at this time

In your internal planning, you should take these five differences into account and carefully consider how they affect your environment. No matter which you choose, each will impact your environment differently. Seasoned Windows system administrators are probably more comfortable with the traditional DOMAIN\username-style of expressing a user account in an access control list (ACL) - yet, security professionals would strongly encourage the use of Kerberos as an authentication protocol because of its built-in mechanisms to safeguard against common attacks. If you have a lot of legacy systems (mainframes, Windows NT or 9x systems), you may be locked into using a domain trust because most of these legacy systems don't support Kerberos.

Generally speaking, there are three categories to consider when you add a trust to your domain or forest: security implications, issues tied to forest trusts, and use of groups via a trust.

Security Implications of a Trust

When you create a trust between your domain and an external domain, some of the scope of built-in groups change. This carries with it implications for who can access resources. The implications are primarily for one built-in group: 'Authenticated Users'. 'Authenticated Users' is a dynamic group whose membership represents all users in trusted domains. The use of 'Authenticated Users' in Microsoft default ACLs has waned with each major product release. However, 'Authenticated Users' is included by default as a member of the local 'Users' group, which gives it wide ranging access that can include the ability to logon locally and read quite a bit of data. You may want to remove that group membership if you don't want all UWWI users accounts to have that level of access.

Domain controllers need to support a wider range of users and include more use of 'Authenticated Users' in default ACLs. We don't recommend changing the default ACLs on domain controllers.

Another security implication to the trust is the authentication method used. The authentication method is tied to the type of trust. Domain trusts are capable of NTLMv2 and NTLMv1 authentication (in general, they are also capable of LM too, but UWWI doesn't allow that). Forest trusts are capable of Kerberos authentication, but can also use NTLMv2 and NTLMv1 (again, they can use the other methods, but UWWI doesn't allow them). Each of those authentication methods comes with a set of security assumptions that you may want to consider.

Forest Trust Issues

If you've chosen to use a forest trust to UWWI, then there are some user interface adjustments that you need to understand. Microsoft has a Knowledge Base article (KB816467) that tersely describes these issues. In summary, the issues are:

• The domain drop-down list available at interactive login will not necessarily have the trusted domain listed (it is if your domain is the forest root domain), meaning that in order to authenticate to the trusted domain users will have to fully qualify their username, e.g. "NETID\barkills" or "barkills@netid.washington.edu"
• using the built-in Object Picker to browse and identify users/group may not work as it does for objects in your forest, and within the Object Picker you may need to fully qualify users/groups, e.g."NETID\barkills" or "barkills@netid.washington.edu" 

Use of Groups via a Trust

You may want to add UWWI users or groups to your domain groups. This diagram shows the valid possibilities. Lines in blue indicate group membership possibilities. Lines in red indicate ACL possibilities. Only the Forest A-Domain X (AX) column shows all intra-domain possibilities, the interaction between AX and BY shows cross-domain plus cross-forest possibilities and the interaction between BY and BZ shows cross-domain, intraforest possibilities.

Take care to note that the ONLY group type in your domain/forest can contain groups from another forest is a domain local group.

Next Steps

Once you've decided which type of trust you are looking for, proceed to the request form.  You should expect a Windows challenge/response prompt and you should provide your UW NetID and password to that prompt, using the form NETID\username. You might also want to review the following procedures before your trust request is approved:

• Setting up a Forest Trust to the UW Windows Infrastructure
• Setting up a Domain Trust to the UW Windows Infrastructure