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.

Specified domain does not exist

Authenticating to the forest with either the NetBIOS name format, KLOUDLESS\jason or the user principal name (UPN) format, jason@kloudless.net 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.

Jason

Category:
Azure Infrastructure, Office 365, Security
Tags:
, , , ,

Join the conversation! 3 Comments

  1. Just stumbled across this article. I had the same problem in my lab and at a customer site – both of which did not have the problem previously with AAD Sync. Odd.

    Reply
  2. Thank you very much.
    That works well 🙂

    Reply
  3. Thanks much.. I had tried all the possible actions but could not fix it. But your blog for really very helpful 🙂

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: