Condividi tramite

AAD Connect Network and Name Resolution Test

  • Articolo

Update: I've added several additional parts to this tool since it was originally released, including some debug logging, an Azure credential check to ensure that your identity is part of Global Admins, additional cloud endpoint checks, and a more thorough system inventory.

While assisting some of my customers last year on an multi-forest AAD Connect setup configuration, we ran into communications problems with many of the remote sites.  We had a very aggressive deployment schedule, so couldn't afford to spend a lot of time troubleshooting connectivity issues when we got to the sites.  As a result, we needed a way to test basic name resolution and connectivity settings before we began setup.

And thus, this tool was born.

I've updated it to make it a little more broad and include some more tests, so hopefully some deployment folks will find use in it.  I've got some ideas for additional tests that I'll be adding over the coming weeks, but I wanted to get the first edition out there and start eliciting feedback on it.

The tool has several checks:

AzureCredentialCheck

Configuring Azure AD Connect requires the account used to install be a member of Global Admins.  During AAD Connect setup, a new cloud synchronization account is created, and AAD Connect will be configured to use that.

Dns

In order to configure the Active Directory connector, you must have both name resolution for the domain you're attempting to connect to as well as a network communications path.  For the name resolution part, you need to be able to resolve both domain controller names as well as the SRV record for _ldap._tcp.<domain>.

Network

For the local networking tests, AAD Connect must be able to communicate with the named domain controllers on ports 53 (DNS), 135 (RPC Port Mapper), 389 (LDAP), 445 (SMB), and 3268 (Global Catalog).  Most organizations run DNS on their DCs, which is why this test is currently integrated.  I have plans to skip the port 53 check you've specified another DNS server.

OnlineEndpoints

For the online endpoints test, the AAD Connect server must be able to connect to a number of endpoints and retrieve or post data.  AAD Connect requires port 80 connectivity to retrieve the Certificate Revocation List, as well as port 443 connectivity to talk to the provisioning service and Azure AD.

The online endpoints tested are listed on https://aka.ms/o365endpoints for AAD Connect and AAD Connect Health Service, as well as on the Azure AD troubleshooting documentation page.  You can also use the optional parameter OnlineEndpointTarget to select the list of endpoints to use (Worldwide/Commerical/GCC, U.S. Department of Defense, GCC High).

Certificate Revocation Lists

The test queries attempts to connect to the following Certificate Revocation List sites on port 80:

Required Resources

The OnlineEndPoints test also attempts to communicate with the following required resources on port 443:

Before each URL is tested for TCP connectivity, the test performs a DNS lookup so that a TCP connection test can be instantiated for each of the returned IP addresses.

Required Resources Endpoints

In addition to just testing communication on port 443, the script will also attempt to connect to the generic Windows Communication Foundation (WCF) services configuration page located at:

The script will try to download the main content from these login pages, checking for a 200-response:

I also test getting content from this URL, to ensure that AAD Connect can communicate for purposes of multi-factor authentication.

Optional Resources

The Azure AD Connect Health service isn't required, but is definitely recommended.  The OnlineEndPoints test also attempts to communicate with it via a TCP 443 using the same name resolution and iterative IP connection testing performed for required resources.

  • management.azure.com
  • policykeyservice.dc.ad.msft.net
  • watchdog.servicebus.windows.net (port 5671)

Optional Resources Endpoints

Finally, the OnlineEndPoints test attempts to connect to the WCF service default page for the optional endpoints:

SystemConfiguration

The SystemConfiguration check attempts to discover several things about your server's configuration:

  • If the server GUI components are installed (AAD Connect installation is not supported on Server Core)
  • If the server has been configured to use TLS 1.2
  • .NET Framework component installation
  • .NET machine proxy configuration
  • Netsh / WinHTTP proxy configuration

Running the tests

If the server you want to test is domain-joined, you can simply just run .\AADConnect-CommunicationsTest.ps1 and it will perform all of the checks that it can.  You'll be prompted for an Azure AD credential (or you can specify it via the normal -Credential (Get-Credential) parameter).  If you want to test suitability for a server that isn't joined to the domain you're going to install for (such as a multi-forest setup), you can specify remote domain controllers (-DCs parameter) and the forest's FQDN (-ForestFQDN).  You can also specify individual tests.

You can download the tool on the TechNet Gallery at https://gallery.technet.microsoft.com/Azure-AD-Connect-Network-150c20a3.

Comments

  • Anonymous
    February 10, 2018
    great stuffthanks
  • Anonymous
    February 11, 2018
    https://technet.microsoft.com/en-us/library/cc959340.aspx
  • Anonymous
    February 18, 2018
    very useful, thanks!
    • Anonymous
      February 22, 2018
      Thank you! I’ve got some more ideas cooking for my next round of updates, so stay tuned!
  • Anonymous
    May 30, 2018
    Great tool. Thanks!
    • Anonymous
      May 31, 2018
      Thanks!