Routing name suffixes across forests

  • Articolo

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Routing name suffixes across forests

Name suffix routing is a mechanism used to manage how authentication requests are routed across Windows Server 2003 forests that are joined together by forest trusts. To simplify administration of authentication requests, when a forest trust is initially created, all unique name suffixes are routed by default. A unique name suffix is a name suffix within a forest, such as a user principal name (UPN) suffix, service principal name (SPN) suffix, or DNS forest or domain tree name, that is not subordinate to any other name suffix. For example, the DNS forest name microsoft.com is a unique name suffix within the microsoft.com forest.

Forests can contain multiple unique name suffixes, and all children of unique name suffixes are routed implicitly. In Active Directory Domains and Trusts, name suffixes appear with an asterisk (*) at the beginning because of this. For example, if your forest uses *.microsoft.com as a unique name suffix, then authentication requests for all children of microsoft.com (*.child.microsoft.com) will be routed because the child domains are part of the microsoft.com name suffix.

If a forest trust exists between two forests, then name suffixes that do not exist in one forest can be used to route authentication requests to a second forest. When a new child name suffix (*.child.widgets.com) is added to a unique name suffix (*.widgets.com), the child name suffix will inherit the routing configuration of the unique name suffix to which it belongs. Any new unique name suffixes that are created after a forest trust has been established will be visible in the forest trust Properties dialog box after you verify the trust. However, routing for those new unique name suffixes will be disabled by default. For more information about how to verify a trust, see Verify a trust.

When a duplicate name suffix is detected, the routing for the newest name suffix will be disabled by default. For more information about how to route name suffixes, see Enable or disable an existing name suffix from routing. Administrators can use the forest trust Properties dialog box to manually prevent authentication requests for specific name suffixes from being routed to a forest.

Notes

  • Do not add the @ sign to the UPN suffix or a user name. When authentication requests are routed to a trusted forest, all characters before the first @ symbol are interpreted as the user name and everything after the first @ symbol as the UPN suffix.

  • The Local Security Authority (LSA) will block routing to any UPN suffix that is not a valid DNS name. For example, adding an @ symbol to a UPN suffix will cause it to automatically be disabled.

Collision detection

When two Windows Server 2003 forests are linked by a forest trust, there is a possibility that unique name suffixes existing in one forest might collide with unique name suffixes located in the second forest. Collision detection guarantees that each name suffix will only be routed to a single forest.

Active Directory Domains and Trusts will detect a name suffix conflict when:

  • The same Domain Name System (DNS) name is already in use.

  • The same NetBIOS name is already in use.

  • A domain security ID (SID) conflicts with another name suffix SID.

When a name suffix in a forest conflicts with a new forest trust partner or when a name suffix in an existing forest trust conflicts with a new forest trust partner, the name will be disabled in the new trust. For example, a conflict will occur if one forest is named widgets.com and the second forest is named sales.widgets.com. Despite the name suffix conflict, routing will still work for any other unique name suffixes in the second forest.

For another example, assume that the msn.com forest needs to establish a two-way, forest trust with the widgets.com forest. Both msn.com and widgets.com have identical UPN suffixes of microsoft.com. During the creation of the two-way, forest trust, the New Trust Wizard will detect and display the conflict between the two UPN name suffixes and then create the forest trust.

If Active Directory Domains and Trusts detects a name suffix conflict with a trust partner domain, access to that domain from outside the forest may be denied. However, access to the conflicted domain from within its forest will function normally.

For example, if the domain widgets.com exists in both the msn.com and microsoft.com forests, users within the msn.com forest will be able to access resources in widgets.com domain that resides in the msn.com forest. However, users in the msn.com forest will be denied access to resources in the widgets.com domain located in the microsoft.com forest.

Conflicts will be listed in Active Directory Domains and Trusts, in the forest trust Properties dialog box, on the Name Suffix Routing tab. If a name suffix conflict is detected during the creation of the forest trust, then the New Trust Wizard will prompt you to save a log file of the conflicts. You can also save a log file after a trust has been created. For more information about how to save this log file, see Change the routing status of a name suffix.

If a NetBIOS or domain SID conflict exists, Active Directory Domains and Trusts identifies the name suffixes routing status as enabled or disabled with exceptions, as appropriate. The details about where the conflict exists are listed in the log file.

You can also use the Netdom command-line tool to list all routed names and to enable and disable routing for NetBIOS names and SIDs. For example, a forest named microsoft.com has a forest trust with widgets.com and you also need to add a forest trust to msn.com. Both widgets.com and msn.com have child domains with the NetBIOS name of SALES (and DNS names of USsales.widgets.com and sales.msn.com).

After you create the new trust to msn.com, routing to the SALES domain name in msn.com will be disabled. If you need to use the name SALES to route to the msn.com forest but don't need to use it to the widgets.com forest, you can use Netdom to disable SALES in widgets.com, and then enable it in msn.com.

For information about Netdom, see Active Directory support tools.