NETID Trust Implications

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

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 NETID 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 authentication (in general, they are also capable of NTLMv1 and LM too, but we don’t allow that). Forest trusts are capable of Kerberos authentication, but can also use NTLMv2 (again, they can use the other methods, but we don’t allow them). Each of those authentication methods comes with a set of security assumptions that you may want to consider.

One way to address the increased number of trusted users is to implement Selective Authentication.

About Selective Authentication

By choosing ‘selective authentication’, users from the trusted domain are not members of the dynamic ‘Authenticated Users’ group. Administrators must explicitly grant the ‘allowed to authenticate’ permission on the AD computer object to the users/groups in the trusted domain for each computer object (in the trusting domain) you want to allow those users to login to. While this can be a great option to limit where UW NetIDs can be used, such as a scenario where a student lab should have UW NetID access (but the rest of the domain shouldn’t), it does comes with the cost of needing to explicitly allow their use on each individual computer. You can, of course, use group policy to assign that user right, and you could grant the user right as broadly as using the ‘Domain Users’ and ‘Domain Computers’ groups in the trusted domain.

Here are some external documents about Selective Authentication:

Forest Trust Issues

If you’ve chosen to use a forest trust to the NETID domain, 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 NETID 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.

Configuration Settings

At this time, you may want to review the group policies of the netid.washington.edu forest to ensure that your local configuration settings are compatible. Pay special attention to the LMCompatibilityLevel (known in group policy as Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\Network Security\Network Security: LAN Manager authentication level). MI policy only allows NTLMv2 or Kerberos authentication. If your computer(s) don’t allow and negotiate these authentication protocols (because they are configured not to, or have support issues that prohibit their use), then you will be unable to successfully authenticate and use the user accounts.

You can read more about this at:

What should my LmCompatibilityLevel settings be?
I can login on some computers but not others. Why is this happening?
I can login with my NETID user account, but I can’t access resources on a server even though I’ve granted that account access. What’s wrong?