Microsoft Entra Connect Sync (aka Azure AD Connect) allows establishing hybrid identity scenarios by interconnecting on-premises Active Directory and Entra ID (aka Azure AD) and leveraging synchronisation features in both directions. As you might already know, this brings potential for abuse of the assigned permissions to the involved service accounts and permissions of this service.
On the internet are already some posts with subset of this information but I wanted to provide an actionable post with individual measures to implement. Of course should we do MFA for all admins and AD tiering but some of those steps involve more complex measures to implement and I will try to provide some individual building blocks you can use to harden the configuration of your Entra Connect service accounts.
Understanding the scope
To understand the scope of hardening we need to have an overview of the inner workings of that service. Entra Connect uses three different kind of service accounts for the different systems:
- Entra: For the connected Entra tenant, per each Entra Connect installation a cloud only account is created by the wizard: Sync_EIDC02_bba3d8efb72a@nicoladev.onmicrosoft.com
- Active Directory: The active directory account is used to connect a forest and allows both reading and depending on the leveraged synchronisation options also modifying the objects for password reset or group write-back scenarios
- Synchronisation Service: Under this principal, the actual Entra Connect service is running on the server
Each kind of service account has various interesting privileges that can be abused by attackers. While the security of the server running Entra connect is also an important aspect I want to focus more on the leveraged user accounts as they are subject to multiple well-known attack scenarios.
Hardening measures for the Entra account
The following measures are scoped to Entra ID features and capabilities.
Conditional Access Policy
Although we need to exclude the Entra Connect cloud account from conditional access policies requiring MFA or a specific device state, we can still leverage Conditional Access to only allow sign-ins from defined locations. With that in mind, we can restrict the sign-in only from our local server breakout IP defined as a trusted or named location.
Tracking AuditLogs
The AuditLogs table of Entra ID contain all the activities that involve modifications of directory objects. This means we can both audit, track and potentially alert on changes targeting the Entra Connect cloud accounts:
Additionally we can also retrieve events that originated from the Entra cloud accounts:
Hardening measures for the AD account
For the on-premises account used to connect to the AD forest, we can apply the following hardening measures.
Permission Scope
When you connect an AD forest and let the synchronisation wizard create the account, the permissions are scoped by default to the forest level, including all child domains. This is usually way too permissive as only a subset of AD accounts needs to (or should) be synchronised.
Especially from privileged accounts, we definitely want to remove the permissions of the Entra connect AD account to replicate changes or perform password resets.
We can check and remove the assigned permissions on the domain level:
With the PowerShell module that ships with each Entra connect installation, we can re-add the proper permissions based on an organisational unit level, e.g. if you have a parent OU that contains all the standard user accounts:
Protected Users
The AD built-in “Protected Users” group includes a couple of nice features that help us to secure the Entra ID Connect AD account, as the following features will be unavailable:
- Authenticate with NTLM authentication.
- Use DES or RC4 encryption types in Kerberos pre-authentication.
- Be delegated with unconstrained or constrained delegation.
- Renew the Kerberos TGTs beyond the initial four-hour lifetime.
As this account is only used to authenticate against AD and does not run an actual service or has delegations it can be added to the protected users group without breaking anything:
If your account was created prior Windows Server 2012 times it might be a good idea to recreate the account (with granular permissions) or at least reset the password to ensure it has an AES key available.
Microsoft Defender for Identity
Microsoft Defender for Identity can help to detect abnormal activity in your Active Directory. Especially the detections for DCSync attacks can help if someone would attempt to impersonate the account from another system.
Hardening measures for the Synchronisation Service
Service Account
When using the express settings, by default a virtual service account is created, with the password never expires flag. A group managed service account introduces additional security as AD rotates the password. Dirteam provides an excellent article for that: Using Azure AD Connect with a gMSA — The things that are better left unspoken (dirteam.com).
Hard- and Soft-Matching features in Entra
Identities in Entra ID can be matched by Entra Connect to match existing accounts in the following ways:
- Hard Matching matches objects on the source anchor attribute of the object in AD to the ImmutableID attribute of the object in Azure AD
- Soft Matching matches objects, based on the userPrincipalName attribute and the primary email address (denoted with SMTP: in the proxyAddresses attribute).
While these features might come in handy for migrations they impose a serious attack surface for account takeover scenarios and should be disabled during regular Entra Connect operations.
To retrieve the state for both hard and soft matching, you can run the following Microsoft Graph commands:
To disable both Hard- and Soft-Matching you can run the following Microsoft Graph PowerShell command:
Conclusion
Microsoft Entra Connect sync is a lucrative target for attackers to perform identity takeover in on-premises AD on Entra ID. I hope this article showed you some steps to plan and implement hardening if not already done.
By limiting the default permissions and matching features you can reduce the attack surface a lot with minimal effort and side-effects and can combine these measures with other aspects described.
References
- Protected Users Security Group | Microsoft Learn
- Securing Microsoft Azure AD Connect (trimarcsecurity.com)
- Secure user-based service accounts in Active Directory — Microsoft Entra | Microsoft Learn
- Obtaining Domain Admin from Azure AD by abusing Cloud Kerberos Trust — dirkjanm.io
- Targeting MSOL Accounts to Compromise Internal Networks Tevora
- TODO: Disable Soft Matching in Azure AD Connect — The things that are better left unspoken (dirteam.com)
- Azure AD built-in roles — Microsoft Entra | Microsoft Learn
