AAD Connect Error: Azure Service Connectivity Failed

5 / 5 ( 1 vote )

This week, while helping a customer onboard to Azure AD Connect, we ran into an interesting error:

Azure Service Connectivity Failed, Unable to proceed
The on-premises synchronization service is not able to connect to Azure Active Directory. Updating the proxy settings for the ADSync service account may resolve this issue.
Extended Message: System.Net.WebException: The underlying connect was closed: Cloud not establish trust relationship for the SSL/TLS secure channel. –> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.

What to do, what to do, what to do?


After receiving this error, my immediate reaction was to respond to the error and suggestion presented: Updating the proxy settings for the ADSync service account may resolve this issue.  Many of my customers use some sort of proxy or security appliance between their server environment and the internet.  We have many suggestions and recommendations, such as “bypass the proxy for Office 365 services” and, if that isn’t possible, set the machine proxy using Netsh.


In this case, I recommended the customer download my troubleshooting/diagnostic tool at http://aka.ms/aadnetwork and send the log over.  Both fortunately (and unfortunately, from the troubleshooting perspective), the report was green checkmarks all the way down (or, in the case of a TXT file, [success] messages).  What next?


At first, my shoot-from-the-hip answer was the server can’t verify the issuer’s certificate revocation list.  As per the x.509 RFC, a CRL is used to verify that a device, service, or application certificate is still valid.  To perform this check, a client queries the a service’s certificate issuer’s revocation list on port 80 and looks for the certificate that was presented to it.  Among other data, the CRL lists the certificate’s common name and it’s validity dates.  If the certificate is no longer valid (say, it was revoked because the key was compromised or the service is no longer in use), the CRL will return a status indicated that the certificate is no longer valid.  If the certificate passes the validity test, the client can proceed with its transaction.

I have several customers that have blocked outbound access on port 80 from server environments, which prevents CRL lookups from performing normally.  In this case, the result from the AAD Network test tool verified that the server could reach the necessary CRLs on port 80.

After reviewing the customer’s AAD Connect installation log, I located the last web service call invoked during the error:

I asked the customer to verify that the certificate issuer for https://adminwebservice.microsoftonline.com (DigiCert) was in the server’s trusted root certification store. The certificate chain is as follows:

The customer reported that it was not.  After the customer installed the certificate, installation was able to complete successfully.

Published by Aaron Guilmette

Helping companies conquer inferior technology since 1997. I spend my time developing and implementing technology solutions so people can spend less time with technology. Specialties: Active Directory and Exchange consulting and deployment, Virtualization, Disaster Recovery, Office 365, datacenter migration/consolidation, cheese. View all posts by Aaron Guilmette

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Exit mobile version