Name Suffix Routing

Hello, David Everett here. I recently encountered an issue where authentication was failing across numerous forests after a second kerberos trust was made with a forest. Unlike most implementations of Active Directory which have a forest root and child domains that share a common DNS Namespace hierarchy, this customer had several forests sharing the same DNS Namespace, with CONTOSO.COM being the root of the DNS tree.

The customer presented a very complex Visio diagram of their forests complete with all the trust relationships. While authentication issues were occurring in many of the forests I’m only citing those forests and domains that are of interest in an effort to simplify things.

Existing Forests and Trust Relationships:

The following trusts were already in place for about a year with no issues prior to the addition of a new forest trust:

A new two-way forest trust between CONTOSO.COM and TOWN.COUNTY.CONTOSO.COM was added and authentication in several forests began to fail.

Some of the errors encountered:

After the second forest trust was added an Administrator of SUBDIVISION.TOWN.COUNTY.CONTOSO.COM logged onto a DC in SUBDIVISION and tried to connect to REALM.COUNTY.CONTOSO.COM in Active Directory Users and Computers only to get this error:

Active Directory

Windows cannot connect to the new domain because:
The system detected a possible attempt to compromise security. Please ensure that you can contact the server that authenticated you.

When the SUBDIVISION administrator failed to connect the following event was logged in the System event log of the SUBDIVISION DC:

Event Type: Warning
Event Source: LSASRV
Event Category: SPNEGO (Negotiator)
Event ID: 40960
Date: 3/13/2009
Time: 12:13:31 PM
User: N/A
Computer: SUBDC01
Description:
The Security System detected an authentication error for the server ldap/RELDC1.realm.county.contoso.com. The failure code from authentication protocol Kerberos was "The name or SID of the domain specified is inconsistent with the trust information for that domain.
(0xc000019b)".

Here are some other events and errors you might see referencing domains in other forests that have trusts with the DC logging the event:

Event Type: Error
Event Source: KDC
Event Category: None
Event ID: 12
Date: 3/9/2009
Time: 10:10:45 AM
User: N/A
Computer: SUBDC01
Description:
A request failed from client realm OTHER.NESTED.CONTOSO.COM for a ticket in realm TOWN.COUNTY.CONTOSO.COM. This failed because a trust link between the realms is non transitive.

And

Active Directory

Windows cannot connect to the new domain because:
Logon Failure: The machine you are logging onto is protected by an authentication firewall. The specified account is not allowed to authenticate to the machine.

Understanding the Problem:

When a Forest Trust is created a Name Suffix Route is dynamically added to both sides of the Forest Trust Properties. The Name Suffix Route is comprised of the DNS name suffix of the trusted forest root and a wildcard (*) precedes the DNS name suffix to allow for child domains to be trusted implicitly. The name suffix looks like this: *.CONTOSO.COM.

Name Suffixes Routing controls routing of authentication traffic. When an account attempts to authenticate and that account does not exist in the local domain, the Name Suffix Route is used to direct authentication requests to the trusted forest root domain.

Prior to the addition of the new forest trust a Name Suffix Route of *.CONTOSO.COM existed on the REALM.COUNTY.CONTOSO.COM side of the two-way forest trust between the REALM.COUNTY.CONTOSO.COM and CONTOSO.COM.

Problems only developed after the new two-way forest trust show below was added between CONTOSO.COM and TOWN.COUNTY.CONTOSO.COM. Authentication traffic from TOWN intended for REALM was being sent to CONTOSO. Likewise, authentication traffic from REALM intended for the TOWN forest was being sent to CONTOSO. This occurred because of a dynamically created Name Suffix Route of *.contoso.com that was added to the TOWN.COUNTY.CONTOSO.COM side of the trust.

In most environments the dynamically created Name Suffix Route of *.<forestroot>.<tld> would not cause issues. However, in this customer’s environment a Name Suffix Route of *.<forestroot>.<tld> caused all authentication requests to be sent to the wrong forest. Since the Forest is the security boundary authentication requests stopped at the CONTOSO.COM forest and did not implicitly follow the DNS Hierarchy.

Correcting the problem:

When more than two Forest reside in the same DNS namespace, and the root of that DNS tree is also an Active Directory forest, logic must be added to the Name Suffix Route to ensure authentication traffic is routed to the correct forest root. This can be accomplished by adding Exclusions to the Name Suffix Routes.

1. Exclusions were added to the existing forest trust between REALM and CONTOSO. On the REALM side of the trust properties the following Exclusion had to be added to the *.CONTOSO.COM Name Suffix Route:

TOWN.COUNTY.CONTOSO.COM

NOTE: The * is automatically added in front of the suffix

2. After the new two-way forest trust was created between TOWN and CONTOSO we added the following Exclusion to the *.CONTOSO.COM Name Suffix Route on the TOWN side of the trust:

REALM.COUNTY.CONTOSO.COM

NOTE: The * was automatically added in front of the suffix

More reading:

Routing name suffixes across forests

https://technet.microsoft.com/en-us/library/cc784334.aspx

Exclude name suffixes from routing to a local forest

https://technet.microsoft.com/en-us/library/cc758388.aspx

I hope you find this useful.

UPDATE: Made changes to the diagrams to fix an error and makes things a bit more readable. Nice catch, Randy!

- David ‘Monochrome’ Everett