Considerations for Deploying Forest Trust

Applies To: Windows Server 2003 with SP1

This section discusses the various considerations and best practices to keep in mind when you deploy forest trusts.

UPN Considerations

When you deploy forest trusts, you can use explicit UPN suffixes across multiple forests. You could not use explicit UPN suffixes across multiple forests with external trusts. Administrators who want to use explicit UPN suffixes should carefully plan their UPN structure across forests. UPN suffixes across forests should be unique and should not overlap.

You can use overlapping UPN suffixes, such as plant.contoso.com and contoso.com, but you must also use TopLevelName exclusion (TLNEx) records. This is because the TopLevelName record for contoso.com (UPN suffixes and tree names of trusted or trusting forests are stored as TopLevelName records in the local forests) claims all of the namespaces that are under contoso.com, including plant.contoso.com. Because of this, there is a conflict about where to route a request for a name, such as server.plant.contoso.com. To ensure that this request is sent to the correct forest, all of the forests that have a trust to contoso.com should add a TopLevelName exclusion record for plant.contoso.com to that trust. The TopLevelName exclusion records specify that requests for names that are under plant.contoso.com should not be routed to that forest. TopLevelName exclusion records add an additional level of complexity, so it is recommended that administrators choose UPN suffixes that do not overlap.

Shared UPN suffixes, such as two forests that both claim contoso.com, are not permitted when you use forest trusts. Administrators who want to use shared UPN suffixes only for logons in their forest (users can use the UPN suffix only to logon to the same forest that their account is in) have to remove the definition of the suffix across the forest and define only the UPN attribute on the user object. This means that you cannot set the UPN suffix on the User object through the Active Directory Users and Computers MMC Snap-in user interface (UI). Because of this, you have to programmatically write the attribute to the user object. When you remove the definition of the UPN suffix across the forest by using the Active Directory Users and Computers MMC Snap-in, the UPN suffix is not propagated to another forest that shares the suffix and, therefore, does not result in a collision. (Note that a collision is when two forests clam the same TLN.) If a collision does occur, the forest trust is disabled. Note that you cannot set an exclusion record if both forests claim the same namespace (for example, if two forests both claim contoso.com). With this approach, you cannot log on across forests with the shared UPN. Because of this, you should use this approach only when the occurrence of logons to computers that are in another forest (a forest other than the forest in which the user account is located) are minimal. Note that you can seamlessly gain access to resources in another forest after you log onto a computer in the forest to which you are a member by using the shared UPN suffix.

Considerations for Restricting the Scope of a Forest Trust

There are two methods that you can use to restrict which users are permitted to gain access to the forest from the trusted forest:

• You can disable the corresponding DomainInfo record for the domain or the TopLevelName record for the tree in the UI. This method is useful when only a small part of the other forest is not trusted. Note that only authentication requests from users in that domain are disabled when you disable a DomainInfo record. When you disable a DomainInfo record, authentication requests are not disabled if those authentication requests are received from users who are in the local forest if those users want to gain access to resources that are in the disabled domain.

  -or-

• You can use the Selective Authentication option. This option is useful only when you want to allow access to a small number of users. If there is a large number of users who want to gain access to a large set of resources, it can be difficult to manage the requests to grant the Allowed to Authenticate right to users. Note that only users who have Write_DAC permissions to the resource object in Active Directory can set this permission. This permission is restricted to both the Domain Admins and delegated administrators who created the object. Note that when a user joins a computer to the domain by using the Add workstation to domain privilege, the user does not receive the Write_DAC permission and, because of this, the user cannot grant users who are in other forests the Allowed to Authenticate right on the computer that the user joined.

Smart Card Logon Considerations

For smart card logons to work across forests, users must have a public key infrastructure (PKI) trust and a forest trust. This means that the forest to which the user is logging on must trust the Certification Authority (CA) that issued the users smart card certificate for smart card logon. In addition, the computer to which the user is logging on must trust the computer certificate for the domain controller of the users domain for server authentication. You can do this by either making the CA a trusted root CA, or by qualified subordination.

User Experience Changes in Moving to Forest Trusts from External Trusts

There may be certain changes in the user experience after the move to forest trusts. To minimize these changes and ensure that there is a consistent experience, you may want to upgrade to the latest service pack on computers that are running Windows XP, Windows 2000, or Windows NT Server 4.0; you may also want to deploy the appropriate hotfixes. The following list describes the impact of the service packs and hotfixes:

• Windows logons and authentication: When users log on to computers that are joined to a forest other than the forest where their user account is located, they do not see their account domain listed in the logon dialog box. The user has to type their user principal name (UPN) in the dialog box. This could be the implicit UPN suffix (user_ID@DNS_domain_name.com) or a UPN suffix that is explicitly defined by the administrator, such as someone@fabrikam.com. If you want to log on with the Windows NT Server 4.0 style name, you should apply the corresponding hotfix to the computer. Note that domains that are in other forests are not displayed in the logon box; you have to type the name as domain\user in the logon box. If your users are not currently using UPNs to log on, have them use the Windows NT Server 4.0 style so that the user logon experience is consistent.

• Authorization: On computers that are not running either Windows Server 2003 or Windows XP Service Pack 2 (SP2), you cannot browse principals in another forest to add them to DACLs and groups. Instead, you can type the UPN or Windows NT Server 4.0 name for the principal that is in the other forest. On computers that are running either Windows Server 2003 or Windows XP SP2, you can browse and search principals that are in the other forest. You must run either Windows 2000 Service Pack 4 (or the hotfix that is specified below) or Windows XP to resolve principals in the Object Picker tool that are in the other forest by using UPN names or Windows NT Server 4.0 names. On computers that are running Windows NT Server 4.0, you can type the Windows NT Server 4.0 style name for the user who is in the other forest. On computers that are running Windows 95, Windows 98, or Windows Millennium Edition (Me), you can choose the domain from which you want to browse for users, and then you can select the user. Microsoft Exchange Server 5.5 administrators and Microsoft SQL Server 2000 administrators have to explicitly type the Windows NT Server 4.0 style name when they want to select Windows users so that they can add the users, associate the users with a mailbox, and then enable SQL server logon. Note that you cannot browse for the users who are in the other forest.

The following tables describe the general user experience when they move to forest trust from external trust.

Logons and Authentication

Lookup and Authorization