Troubleshooting stories from the field are the best. That’s why I like writing them down. Although, sometimes they might appear as straight cases of schadenfreude, I feel there are lessons to be learned for anyone, if you’re willing to look closely and listen carefully.

Last week I experienced an issue with Azure AD Connect at a customer, that made absolutely no sense at all.

The situation

The customer has an Active Directory Domain Services environment, consisting of one Active Directory domain. The Active Directory domain is synchronized to Azure Active Directory using Azure AD Connect. Users authenticate to Azure AD using Active Directory Federation Services (AD FS).

To facilitate release management, we advised to implement a Staging Mode Azure AD Connect server and the accompanying processes. We asked an admin at the customer to get us an additional domain-joined virtual machine running Windows Server 2019.

We downloaded Azure AD Connect using the same account and ran the installer. We made the following choices:

• On the Welcome to Azure AD Connect screen, we checked the I agree to the license terms and privacy notice. option and clicked the Continue button.
• On the Express Settings screen, we clicked the Customize button.
• On the Install required components screen, we clicked the Install button.
• On the User sign-in screen, we selected Federation with AD FS as the sign on method and clicked the Next button to continue.

• On the Connect to Azure AD screen, we signed in with an account with the Global administrator role in Azure AD and clicked Next. After inserting the credentials, we performed multi-factor authentication.
• On the Connect your directories screen, we clicked the Add Directory button.
• In the AD forest account dialog screen, we kept the default option to Create new AD account and entered the credentials for the customer’s admin account:

The issue

Azure AD Connect validated the credentials, and threw an error:

Cannot establish a connection to the Domain Controller(s) associated to a forest named: 'domain.tld'. Please validate the following:

• The Credentials (Username and Password) you have provided are correct
• UDP and TCP port 389 are open in these DCs (you have to perform this manual check on the “Windows Firewall with Advanced Security” window on every Domain Controller) Learn more

This error is unexpected.

My troubleshooting

I started troubleshooting the issue.

I didn’t have to question whether the server was domain-joined; if it’s not domain-joined you can’t select Active Directory Federation Services (AD FS) as the authentication method to Azure Active Directory…

Am I logged in with a domain account or a local account?

The first question I wanted to solve is whether we were logged onto the Azure AD Connect installation using a domain account or a local account.

I started up a Command Prompt (cmd.exe) and used whoami.exe to view information for the signed-in account. We were signed in using an account that is a member of the Domain Admins group.

Can I resolve the domain in DNS?

I started up a Command Prompt (cmd.exe) and used nslookup.exe appended with the domain name. This returned the Domain Controllers without issues.

Can I communicate to the Domain Controllers?

As Azure AD Connect mentioned network connectivity was probably to blame for the error, I started up a PowerShell window and used Test-NetConnection to probe several of Active Directory’s common ports. This returned success values for all ports I tried on all Domain Controllers I tried. I guess this is not a Firewall issue, either…

What does Azure AD Connect think it actually is?

I decided to take a look at the Azure AD Connect diagnostics data. Azure AD Connect provides detailed output of all its actions in the C:\ProgramData\AADConnect folder.

I opened up the trace file and scrolled down to the bottom:

That’s where I read what was going on. It wasn’t a connectivity problem at al. The admin account simply lacked the Enterprise Admins group membership.

Actually, Azure AD Connect’s AD Forest account dialog screen, clearly states you need to specify an ENTERPRISE ADMIN USERNAME.

However, in an Active Directory environment with a single domain, the privileges for Domain Admins and Enterprise Admins are equal, as the Microsoft Docs on Default groups points out…

The solution

We asked the admin to add his account to the Enterprise Admins group. As this is a single domain, this change is performed without issues.

We signed off and on again after this change. We ran the Azure AD Connect wizard again and decided to remove the membership to the Enterprise Admins group after installing and configuring Azure AD Connect.

Concluding

Enterprise Admins privileges may be needed for Azure AD Connect configuration of the service account to communicate to Active Directory. Whether it makes sense or not…

Further reading

Leveraging Azure AD Connect Staging Mode for Release Management
From the Field: the Case of the Active Directory trust without DNS Suffixes
From the Field: The Case of the Unreanimatable Tombstone Objects
From the field: The Case of the Domain Controller that would not function after an Azure Site Recovery test failover