I ran into a little issue while on site with a customer who required AAD Connect to be configured for use in a multi-forest environment with three forests. There was a forest trust between two of the forests, however the third forest did not have any trusts in place. Prior to implementing this solution, we ran up a test environment to do a run through and document the steps required for an implementation plan.
The test environment consisted of three Windows Server 2012 AD forests all at 2012 functional level – kloudy.net, kloudysky.net and kloudless.net and a single Office 365 tenant, MyHappyKloudTenant.onmicrosoft.com.
I installed the AAD Connect application into the kloudy.net forest, and proceeded to run through the wizard. All was well until I came to adding the untrusted forest, kloudless.net to the “configured directory” list. I could add the trusted forest (kloudysky.net) easily enough, however when I attempted to add kloudless.net I received the helpful little error message “The specified domain does not exist or cannot be contacted”.
“That’s interesting” I thought. I know I created the domain, so it exists. And I can ping the domain using the FQDN, so it’s definitely resolvable and contactable.
Authenticating to the forest with either the NetBIOS name format, KLOUDLESS\jason or the user principal name (UPN) format, firstname.lastname@example.org ended up with the same error “The specified domain does not exist or cannot be contacted”. After some poking around (and input from a helpful architect on site) a solution was found.
In the USERNAME field, use the FQDN of the authenticating domain instead of the NetBIOS name, so in my case it was kloudless.net\jason instead of KLOUDLESS\jason
Now, my colleagues have suggested that this issue may be an environmental one relating to name resolution, and I tend to agree.
In my case, each domain had its own integrated DNS with secondary zones for each of the other domain names, so kloudy.net had integrated DNS with secondary zones for kloudless.net and kloudysky.net. And so forth for each of the forests. Name resolution was functional to all domains from all domains.
Either way, in the case of my test environment, using the FQDN of the authenticating forest provides the outcome we were looking for, and I hope that if you happen to come across this issue, I’ve saved you a little bit of time.