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.

  • Did you set up DNS forwarders from each domain to the other domain? – joeqwerty Sep 28 '15 at 14:57
  • @joeqwerty DNS is correctly set up. I have added some details regarding the DNS setup in the post. – Per von Zweigbergk Sep 28 '15 at 14:58
  • What about adding the DNS domain of the other domain(s) to the DNS suffix search order? So in alpha, add bravo.example.com to the search order. – Greg Askew Sep 28 '15 at 16:11
  • @GregAskew I'm not sure what that would accomplish, considering that the trust works fine as long as the DC's have different names. If anything, that might make the problem worse. – Per von Zweigbergk Sep 28 '15 at 16:51
  • Ah ok. Unfortunately I think you are fully into unorthodox territory. If you find someone that is doing this successfully, let us know. – Greg Askew Sep 28 '15 at 17:15

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.

  • I don't see how this answer is relevant to the question asked. Can you please clarify your answer as to what action should be taken to resolve the issue? The article linked is updated for Windows Server 2003 only and does not address the particular scenario here. Both forests have unique names both in DNS and Netbios. – Per von Zweigbergk Dec 2 '15 at 20:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.