Azure AD Connectivity Checks Test

Organizations typically use Azure AD Connect to automatically synchronize identity data between their on-premises Active Directory environment and Azure AD.

For this synchronization to work seamlessly, the Azure AD Connect service should be able to connect to the following:

  • The local / on-premises Domain Controller that manages the data to be synchronized with Azure AD

  • The DNS server

  • The endpoint on Azure AD, where the resources to be synchronized reside

If any of these connections fail, then Azure AD Connect may not be able to synchronize identity data. As a result, authentication failures may occur, which in turn can deny Azure users access to critical resources. This can damage the overall SSO (Single SIgn-on) experience of users. To provide users with a superlative login experience, administrators should periodically run connectivity checks to each of the entities above, promptly detect connection errors/failures (if any), and accurately isolate where the bottleneck is. This is where the Azure AD Connectivity Checks test helps!

At configured intervals, this test verifies connectivity to a configured local / on-premises domain controller, the DNS server, and a specified Azure endpoint. Alerts are sent out if any of the above connectivity checks fail or report errors. This way, administrators will be able to accurately tell where the connection errors/failures occurred - when connecting to the domain controller? when connecting to DNS? or when accessing the Azure endpoint. Detailed diagnostics of the test reveals the connection errors, so you can troubleshoot them, rapidly restore the broken connections, thus ensuring an above-par Azure experience for users.

Target of the Test: Microsoft Azure AD Connect

Agent deploying the test: An internal agent

Output of the test: One set of results for every type of connection check that is performed - DNS, Endpoint, and Network

Configurable parameters for the test
Parameters Description

Test Period

How often should the test be executed.


The host for which the test is to be configured.

Domain Controller

This test checks the connection to a local / on-premises domain controller, and alerts if the connection is down / erroneous. To enable the test to perform this check, you should specify the IP/host name of the local / on-premises domain controller here.

Forest FQDN

Specify the fully-qualified domain name of the Active Directory forest to which the Domain Controller specified above belongs.

Online Endpoint

This test checks whether/not the Azure endpoint you configure is accessible. Endpoints are dedicated cloud solutions, which enable government contractors and federal agencies keep their valuable assets in a more secure space, By default, this test checks the connectivity of the Commercial endpoint. Accordingly, this parameter is set to Commercial by default. Commercial is the standard Azure cloud. It is where Enterprise, Business Essentials, Academic and even home Azure tenants reside. It has the most features and tools, nearly global availability, and the lowest prices. Everyone qualifies and no validations are needed. In many cases, security and compliance needs can be met in Commercial through varied tools. Compliance frameworks that can reside in commercial include HIPAA/HITech, NIST 800-53, PCI-CSS, GDPR, CCPA, etc. It is not meant for government or defense compliance and should not be used for such as it shares a global infrastructure and workforce.

The other endpoint options are as follows:

  • GCC: GCC, Government Community Cloud, can essentially be thought of as a government focused copy of the commercial environment. It has many of the same features, but features data centers ONLY in the continental United States (CONUS), as mandated by FedRAMP Moderate.

  • DoD:The DoD cloud was purpose built for the Department of Defense only. No contractors, no outside personnel, no exceptions. One thing to mention is that the DoD enclave is the ONLY of the four clouds to meet DoD SRG Levels 5 and 6.

  • GCC High: GCC High was created to meet the needs of DoD and Federal contractors that needed to meet the stringent cybersecurity and compliance requirements of NIST 800-171, FedRAMP High, and ITAR, or who need to manage CUI/CDI. GCC High is technically a copy of the DoD cloud but exists in its own sovereign environment.

Show Success DD

By default, this parameter is set to No. This means that the test will not report detailed diagnostics for the Success measure by default.

In a typical Azure cloud setup. most connection checks will report positive results - i.e., most connection attempts will be successful. If the details of all these successful checks are stored in a say, poorly sized / tuned eG database, then over time, the database may choke under the load. This parameter's default setting prevents such an unpleasant outcome.

You can turn this flag on if the eG database in your environment has adequate space to store the detailed metrics of the Success measure.

Detailed Diagnosis

To make diagnosis more efficient and accurate, the eG Enterprise embeds an optional detailed diagnostic capability. With this capability, the eG agents can be configured to run detailed, more elaborate tests as and when specific problems are detected. To enable the detailed diagnosis capability of this test for a particular server, choose the On option. To disable the capability, click on the Off option.

The option to selectively enable/disable the detailed diagnosis capability will be available only if the following conditions are fulfilled:

  • The eG manager license should allow the detailed diagnosis capability
  • Both the normal and abnormal frequencies configured for the detailed diagnosis measures should not be 0.
Measures made by the test:
Measurement Description Measurement Unit Interpretation


Indicates the number of connection attempts to this entity that was successful.


Use the detailed diagnosis of this measure to view the details of the successful connections.


Indicates the number of connection attempts to this entity that failed / threw errors.


Ideally, the value of this measure should be 0. A non-zero value is indicative of a connection failure / error. In this case, use the detailed diagnosis of this measure to review the error messages, troubleshoot the failure, and restore the connection.

Use the detailed diagnosis of the Errors measure to review the error messages, troubleshoot the failure, and restore the connection.

Figure 1 : The detailed diagnosis of the Errors measure