So, I have two forests, let's call them alpha.example.com and bravo.example.com. The NETBIOS names of the domains are ALPHA and BRAVO, respectively. That would seem to imply that there is no problem with the domain naming, they have two different names, both DNS-wise and NETBIOS-wise.
I have the following servers as domain controllers:
- dc01.alpha.example.com
- dc02.alpha.example.com
- dc01.bravo.example.com
When I try to establish a forest trust between ALPHA and BRAVO like this, I get "No Logon servers available to service the logon request" when it comes to actually verify the trust. I've found some forum threads online as well as heard some anecdotal evidence that there are issues when connecting two domains together where there are the same names for the domain controllers in both domains. This doesn't seem to make sense to me, and it sounds like it's a bug in Microsoft tools.
I didn't think this should be an issue, since dc01.alpha.example.com and dc01.bravo.example.com are obviously two different machines, but Windows doesn't seem to agree with me.
Am I missing some piece of information that would enable me to get this setup to work? Renaming the domain controllers is a bad answer for us unfortunately, because the end game is connecting together a lot of forests that all have domain controllers named the same. That would mean renaming a bunch of DC:s.
For the record, renaming one of the domain controllers does allow me to establish a trust, but I really don't want to have to do that in the real world if I can help it.
All machines in the lab are running Windows Server 2012 R2 up to date on patches, but with no special hotfixes installed.
DNS is setup in the following way: in the ALPHA domain, a stub zone is added for bravo.example.com, pointing at dc01.bravo.example.com's IP address. In turn, dc01.bravo.example.com uses dc01.alpha.example.com and dc01.bravo.example.com as upstream DNS. It's a bit of a hacky setup (because it's a lab…), but the result is correctly workign DNS resolution in both ways. dc01.bravo.example.com can resolve names in bravo.example.com (because it's authoritative) and alpha.exaple.com names are correctly resolved because upstream DNS is authoritative for it. Resolvers in alpha can resolve bravo's names correctly because of the stub zone (which is added to AD so that both DNS servers get it.)
I have additionally tried:
- Changing from a stub zone to a conditional forwarder
- Running a forest trust rather than an external trust
No change in symptoms.
Best Answer
Your issues is due to what's called name suffix routing. The following article describes the issue: https://technet.microsoft.com/en-us/library/cc784334%28v=ws.10%29.aspx It states that netdom can be used to address the problem.
Article states in part
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.