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, 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
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.
Thank you very much.
That works well 🙂
Thanks much.. I had tried all the possible actions but could not fix it. But your blog for really very helpful 🙂
If you are still experiencing access issues and the aforementioned by Jason would not help just add AAD Connect server (as computer object) to your AD’s (domainname.com) security group beside the MSOLxyz user.
which security group exactly? I am running into this problem with a customer at the moment. and its the DC as well…
AD Connectors require SRV lookups, so you can also try configuring a conditional forwarding zone for the target forest in your AAD connect environment, and then making sure that your network connectivity is in place:
DNS Resolution
Configure the domain controller that AAD Connect uses as its primary DNS server with a conditional forwarder zone.
1. Log into the domain controller.
2. Launch an elevated PowerShell prompt.
3. Run the following command in the elevated prompt:
$RemoteDnsServers = @(‘10.2.1.1′,’10.2.1.2′,’10.2.1.3’)
Add-DnsServerConditionalForwarderZone -MasterServers $RemoteDnsServers -Name targetdomain.com
Verification
1. From the AAD Connect server, open a command prompt.
2. Run the following commands in the prompt:
PS C:\> nslookup -q=srv _ldap._tcp.targetdomain.com
The expected result is similar to the following:
Server: dc.localdomain.com
Address: 10.1.1.1
_ldap._tcp.forestc.com SRV service location:
priority = 0
weight = 100
port = 389
svr hostname = dc1.targetdomain.com
dc1.targetdomain.com internet address = 10.2.1.1