Today has been one of those days, where I get to meet a new organization with a new intriguing issue, that no one has a solution for. The brief error description I got handed down read “They can’t get the Active Directory trust to work.”.
An organization that has been a customer of my employer for a longer period of time, recently acquired another company. Both organization rock an Active Directory domain in a single Active Directory Forest, sporting two Domain Controllers each.
This second organization is located in Germany, and outfitted their hardware with German versions of Windows Server. This already added a nice layer of complexity for most people, but luckily I know my German. I’ll refer to them as the German domain and/or forest from here on.
Now, the time had come to build a trust relationship between the two Active Directory environments living in their own Active Directory forests.
No matter how they tried, they couldn’t make it work the way they wanted: They wanted to give access to their resources to the German people. This calls for an outgoing forest trust (one-way).
The error was loud and clear every time they tried to set up a forest trust from their Active Directory forest to the German forest (realm trusts weren’t an issue, but we don’t want one of those):
The trust relationship cannot be created because the following error occurred:
Either the domain does not exist, or network or other problems are preventing connection.
Troubleshooting name resolution
I quickly glanced at the DNS configuration and noticed stub zones were created at both ends to allow for name resolution. While I’d work with Conditional Forwarders so people can rip out and replace DNS servers on each end without stuff breaking, this should be fine.
The domain exists.
Troubleshooting the network
I started with troubleshooting the network connectivity between the two forests, and thus, the two datacenters.
I downloaded PortQry v2 and checked all the ports between each and every Domain Controller. Although UDP responses were generally a bit slower, every kind of necessary traffic flow seemed to be available.
The network is not preventing the trust connection.
Troubleshooting the domains
I took some time to get acquainted with the Active Directory domains. I sought for empty and disconnected root domains (none present), the correct placement and working of the FSMO roles and Global Catalogs (GCs) and, of course, time synchronization. Everything seemed to work well in these areas.
Luckily, this wasn’t something big.
Troubleshooting the Domain Controllers
I walked through the configuration of the Domain Controllers. I noticed a secondary UPN Suffix added to the German domain, that also wasn’t publicly routable (another .local domain). Every user account in the domain was equipped with this alternative UPN Suffix…
Using the Active Directory Best Practices Analyzer on one of the Windows Server 2012-based Domain Controllers, I noticed a lot of errors on the Domain Controller not having registered its DNS SRV records correctly.
As I looked closely at the Advanced TCP/IP Settings (Right-click the network icon in the task tray, choose Open Network and Sharing Settings. In the left pane of the Network Settings, click Change adapter settings. Right-click the network adapter, then choose Properties. Double-click Internet Protocol Version 4 (IPv4) from the list of items. Click on Advanced…. Go to the DNS tab.) I noticed, this tab didn’t show the DNS Suffix for the domain anywhere.
Combing through the Event log
I then decided to comb though the event logs using Event Viewer (eventvwr.exe). Quickly, I noticed server events with Event-ID 5744 and source NETLOGON.
Inspecting the Netlogon.dns file
I opened up an elevated Notepad (notepad.exe) and took a look at C:\windows\system32\config\netlogon.dns.
Sure enough, the records the Domain Controller was registering didn’t include any DNS Suffix.
Yep, name resolution is the problem that is preventing the trust connection.
I checked in the System Properties for one of the Domain Controllers on the German side, and stumbled upon a glaring configuration mistake, behind the More… button:
Just like you would expect on a Domain Controller that is configured for a disjoint namespace, the Domain Controller was configured with a different DNS Suffix than the Active Directory domain. In this case, however, it was configured without a DNS Suffix…
Changing this to the DNS Suffix of the Active Directory domain on all Domain Controllers and then rebooting them solved this case.
As it turned out, every time we wanted to get something authenticated in the German domain, we would try and talk to the Primary Domain Controller using its NetBIOS hostname without DNS Suffix, because the DNS Suffix wasn’t registered… We couldn’t find it by its hostname and we didn’t append a DNS Suffix to it ourselves.
The back story
A few years ago, the German organization tried to use a shortcut to get rid of their former business name and continue with a new business name. With an UPN Suffix they could quickly get people to authenticate with their new userPrincipalName.
Removing the DNS Suffix on the Domain Controllers, apparently, also seemed like a good idea at that time and without trusts or other external interfaces, this didn’t lead to problems.
Years later, though, it led to me visiting the organization that bought them and laughing really load at this silly configuration…
Active Directory and Active Directory Domain Services Port Requirements
Troubleshooting Active Directory Domains and Trusts
Overview of Active Directory Troubleshooting
Event ID 5774