Forum Discussion
AD Connect Start-ConnectivityValidation - GetDomain failing error while running adding directories
LainRobertson Thanks so much for your time on this post and the detailed analysis. I further tested as you suggested and have very strange results. Seems like ICMP is blocked for the very DMZ DC which is supposed to have more connectivity with the ADC forest as compared to the local network of the country forest. We actually have onboarded all countries on ADC successfully except last 3.
Sorry need to hide the IPs as they are of our production environment, is ICMP mandatorily required for ADC?
The below command took well more than 9secs, around 30 actually to fail and give the exact error. However, my observation till now was that the GetForest succeeds and GetDomain fails.
[System.DirectoryServices.ActiveDirectory.Forest]::GetForest([System.DirectoryServices.ActiveDirectory.DirectoryContext]::new([System.DirectoryServices.ActiveDirectory.DirectoryContextType]::Forest, "forestFqdn.somedomain.com"))
Also worth mentioning is that since that local network of countries is not directly pingable from ADC forest and we rely on the DMZ DC for that. We ensure that all the DCs IP are listed in the output for NSLookup and they further resolve to the machine FQDN by setting the Server to the DMZ DC IP.
We also had some countries where there are syncing users in both Parent & Child domains, so we ensure both atleast 1 child & root DCs are included in the DMZ. The local network again will not have direct connectivity.
Last but not the least, all ports mentioned are open except 5986, need to check if WinRM/TLS is required and will get it opened if yes. Here is the exact error for your ready reference:-
PS C:\Program Files\Microsoft Azure Active Directory Connect\Tools> Start-ConnectivityValidation -Forest xxxxx -AutoCreateConnectorAccount:$false -UserName "xxxxx\yyyyyy"
Please provide the credentials of the account you entered on AADConnect Wizard.
DOMAIN\Username: xxxxx\yyyyyy (previously obtained)
Diagnosis is starting...
Attempting to obtain a domainFQDN
Attempting to retrieve DomainFQDN object...
Exception calling "GetDomain" with "1" argument(s): "The specified domain does not exist or cannot be contacted."
There has been a problem while validating connectivity between AADConnect and the Active Directory.
An attempt to diagnose the problem will be performed by running a set of network connectivity tests
Press ENTER to continue:
Starting NetworkConnectivityDiagnosisTools
Verifying that 'xxxxxxx' exists
xxxxxxxxx exists
Verifying if the provided credentials are correct
Attempting to obtain a domainFQDN
Attempting to retrieve DomainFQDN object...
There was an error during the validation of the credentials you have entered. Details: Exception calling "GetDomain" with "1" argument(s): "The specified domain does not exist or cannot be contacted."
Here's another AAD Connect-specific article that outlines in greater detail the port requirements:
It's considerably more useful than the previous troubleshooting article and provides a per component breakdown (including the wizard.)
As I said above, I feel your issue is with domain controller selection but this is still a very useful reference.
Cheers,
Lain
- Ajay_JoshiMar 20, 2023Brass Contributor
There are 4 DCs in the forest and 1 of them is in the DMZ, conditional forwarder in the ADC forward points to it.
Although I'm yet to check the Netlogon logs in the target forest, I noticed something interesting with the network connectivity tests. While the Confirm-TargetsAreReachable & Confirm-DNSConnectivity results are all green & successful, Confirm-NetworkConnectivity provides something to think about.
If I run this and DC1 doesn't have port 53 open, its gives an error and doesn't even check the next DC.
Confirm-NetworkConnectivity -DCs DC1.forest.com,DC2.forest.com,DC3.forest.com
TCP connection to DC1.forest.com on port 53 failed.
But if we mention DC3 first which has the connectivity, then it succeeds for it and then does check the next and then if it fails, stops checking further.
Confirm-NetworkConnectivity -DCs DC3.forest.com,DC2.forest.com,DC1.forest.comTCP connection to DC3.forest.com on port 53 succeeded.
TCP connection to DC3.forest.com on port 88 succeeded.
TCP connection to DC3.forest.com on port 389 succeeded.
TCP connection toDC2.forest.com on port 53 failed.
Could this be the issue? Probably the lookup list has the internal DC as the first entry which doesn't have connectivity. Although an assumption, I'm more suspicious after seeing this result:-PS C:\Program Files\Microsoft Azure Active Directory Connect\Tools> Confirm-FunctionalLevel -Forest forest.com
Verifying that the AD forest functional level is >= Windows2003Forest
Obtaining ForestFQDN
Attempting to retrieve ForestFQDN...
Exception calling "GetForest" with "1" argument(s): "The specified forest does not exist or cannot be contacted."CurrentForestLevel is
The binary operator GreaterThanOrEqual is not defined for the types 'System.DirectoryServices.ActiveDirectory.ForestMode' and
'System.DirectoryServices.ActiveDirectory.ForestMode'.
At C:\Program Files\Microsoft Azure Active Directory Connect\Tools\ADConnectivityTool.psm1:1127 char:8
+ If($CurrentForestLevel -lt $MinAdForestVersion)
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: (:) [], InvalidOperationException
+ FullyQualifiedErrorId : System.InvalidOperationException
The Active Directory forest functional level is correct
TrueIt fails in the beginning probably with the internal DC and then succeeds with the DMZ DC. This output is actually similar to the forest which were successfully onboarded to ADC. Just that the initial error statement is "The user name or password is incorrect." instead of "The specified forest does not exist or cannot be contacted". Rest all output is same including the "The binary operator GreaterThanOrEqual is not defined for the types" error.
- SupernovaMar 20, 2023Copper Contributor
Run Netdom query FSMO and check the PDC on that forest.
If PDC is DC1.Forest.com then need to fix the DNS on that DC first.
Run
Nltest /DsgetDC: Domain Name and check.
If that one shows DC then force it to DC3
nltest /dsgetdc:DCname -force
- LainRobertsonMar 20, 2023Silver Contributor
I just want to re-iterate what I said in my first post:
Controlling where DNS goes (via your conditional forwarder) does not control where subsequent traffic for other protocols - such as LDAP - goes.
TCP/UDP port 53 is DNS and this is not your issue, meaning you can ignore this DNS-specific error.
As you said, you are using a conditional forwarder for the remote forest, and the server entered into the conditional forwarder is only pointing to the IP address of the DMZ host. This means that DNS can only go to that one specific domain controller, making DNS connectivity tests to the other domain controllers irrelevant.
What we are focusing on are the non-DNS conversations between your AAD Connect host and the remote forest, as these are not controlled by the conditional forwarder. These are the conversations that are likely trying to use the internally-located domain controllers, since all five are returned to the AAD Connect host.
As I said earlier, there's a number of different strategies for solving this issue, however, the most future proof is the one I mentioned in my earlier reply about using Active Directory sites and subnets to solve the domain controller selection issue.
Quoting from the following article, this is what I'm talking about:
After the client locates a domain controller, it establishes communication by using LDAP to gain access to Active Directory. As part of that negotiation, the domain controller identifies which site the client is in based on the IP subnet of that client.
If the client is communicating with a domain controller that isn't in the closest (most optimal) site, the domain controller returns the name of the client's site. If the client has already tried to find domain controllers in that site, the client uses the domain controller that isn't optimal. For example, the client sends a DNS Lookup query to DNS to find domain controllers in the client's subnet.
Otherwise, the client does a site-specific DNS lookup again with the new optimal site name. The domain controller uses some of the directory service information for identifying sites and subnets.
While this represents the best solution (in my opinion), there are other DNS-based solutions such as:
- Using DNS policy (if the remote domain controllers are Windows Server 2016 or later);
- Manipulating the DC locator DNS records (you need to know what you're doing with this one or it negatively impacts everyone);
- Using a split-brain DNS approach (more control but at the cost of extra and ongoing manual administration);
- hosts file (I'm really not a fan of this one but it is an option.)
Of these lesser-preferred options, I'd recommend option 1. Here's a link to DNS policies:
The problem you're now trying to solve is not "where is DNS going to?" but "where is everything after DNS going to?"
Here is another article that lists the various DNS queries your AAD Connect host (which in this context is the DNS client) can ask of the remote DMZ domain controller, though don't invest too much time reading this one as it's purely educational (for now):
Your focus for now is getting a random selection from a pool of five domain controllers down to consistently selecting the DMZ domain controller for non-DNS traffic. Using the aforementioned sites and subnets approach, or one of the lesser-preferred DNS-related configurations should be your priority.
Cheers,
Lain
- Ajay_JoshiMar 22, 2023Brass Contributor
LainRobertson Supernova Thanks for providing inputs, I've tested a lot of things.
Firstly, the Netlogon logs have this error:-
03/22 12:14:38 [7968] Forest.com: NO_CLIENT_SITE: ADConnectServerName ADConnectIP
Strangely, MIM server too has the same error entry, but as mentioned earlier, might not matter in its case.
Nltest /DsgetDC:forest.com indeed returned the primary DC to which AD Connect doesn't have connectivity. This is the issue I think.
Since, the primary DC is in Default Site, I changed the SRV records on it to point to the DMZ DC. Need to wait for replication.
Meanwhile also trying to understand the DNS Split brain approach and using DNS policy. I'm unable to find a method that cane be used to force the DMZ DC to return its own name to DNS queries rather than the PDC's.