Microsoft synchronization capabilities for managing identities in hybrid environments are not without their risks. In this blog, Tenable Research explores how potential weaknesses in these synchronization options can be exploited.
Synchronizing identity accounts between Microsoft Active Directory (AD) and Entra ID is important for user experience, as it seamlessly synchronizes user identities, credentials and groups between on-premises and cloud-based systems. At the same time, Tenable Research shows the following synchronization options can introduce cybersecurity risk that extend beyond hybrid tenants:
- the already known Directory Synchronization Accounts Entra role
- the new On Premises Directory Sync Account Entra role
- the new Microsoft Entra AD Synchronization Service application
In 2024, Microsoft introduced two new security hardening measures for hybrid Entra ID synchronization. However, despite these improvements, both the Directory Synchronization Accounts and the new On Premises Directory Sync Account roles retain access to critical synchronization APIs. Moreover, the new ‘Microsoft Entra AD Synchronization Service’ application exposes the privileged ADSynchronization.ReadWrite.All permission, introducing another potential attack path that security teams must watch closely.
In this technical blog, we break down the changes Microsoft made to each of its synchronization options, explore where new risks were introduced and provide guidance on how Tenable Identity Exposure can help you monitor and secure your hybrid synchronization environment.
Directory Synchronization Accounts role: Where it all begins
In hybrid environments, Entra ID — the Identity Provider in Microsoft’s suite of Entra products — and Active Directory (AD) are synchronized through a specific service account in Entra ID (called “SYNC_… for Entra Connect and “ADToAADSyncServiceAccount” for Entra Cloud Sync). This service account is assigned the Entra role called Directory Synchronization Accounts and it is hidden in Azure Portal / Entra Admin Center.
In August 2024, as part of its security hardening effort, Microsoft announced it had removed unused permissions from the privileged Directory Synchronization Accounts role.
At Tenable Research we wondered: how can Entra ID <-> AD synchronization continue working following this reduction of privileges?
Answer: our tests showed that the Directory Synchronization Accounts role is still privileged because it can continue calling the synchronization API.
In December 2024, Microsoft announced a second security hardening with the introduction of a new app called Microsoft Entra AD Synchronization Service.
At Tenable Research, we were naturally curious about this new app. What does it look like? What are its characteristics? Does it have an API? Does it have, or expose, interesting permissions?
Answer: this application exposes the ADSynchronization.ReadWrite.All API permission, which is privileged since it allows calling the private synchronization API.
Directory Synchronization Accounts Entra role remains privileged
In June 2024, I explored the “Directory Synchronization Accounts” role in the article Stealthy Persistence with “Directory Synchronization Accounts” Role in Entra ID. I explained two ways role was privileged:
- it had privileged Entra permissions; and
- it had implicit permissions in the private undocumented “Azure AD Synchronization” API (the one at
https://adminwebservice.microsoftonline.com/provisioningservice.svc).
The latter is also called “Sync provisioning service” by Dr. Nestori Syynimaa who implemented it in AADInternals.
The August security hardening update introduced a number of changes to the Directory Synchronization Accounts role, but did these changes successfully eliminate the role’s privileges?
Reduced permissions in the Directory Synchronization Accounts role
The Directory Synchronization Accounts role used to have 48 Entra role permissions. It underwent a drastic reduction as a result of the security hardening, with Microsoft removing all of them and replacing them with only one: microsoft.directory/onPremisesSynchronization/standard/read. Now that the role only has this read permission, it isn’t privileged anymore, which might lead you to assume it is not dangerous.
Previously, the role included microsoft.directory/applications/credentials/update and microsoft.directory/servicePrincipals/credentials/update, which could allow attackers to add credentials to privileged applications/service principals so they could authenticate as these service principals and benefit from their privileges. These made the role privileged.
Fabian Bader popularized in 2023 a similar technique of abusing this role by taking over privileged applications, via the microsoft.directory/applications/owners/update and microsoft.directory/servicePrincipals/owners/update permissions. He has since updated his article From on-prem to Global Admin without password reset after Microsoft eliminated these permissions.
But permissions for the Synchronization API were implicit in the Directory Synchronization Accounts role, i.e. not listed as Entra role permissions in the role itself. So what about them?
Implicit synchronization API permissions are still present
Since they are implicit, the only way I knew to test their privileges was to simply try it out and see what happened.
I created a user, assigned it only the Directory Synchronization Accounts role and used the corresponding commands of the AADInternals toolkit, like Set-AADIntAzureADObject and Set-AADIntUserPassword. These continued working as they had before Microsoft’s security hardening. Here’s a proof with a password reset:
PS C:\> Import-Module -Name AADInternals
[...]
PS C:\> $at = Get-AADIntAccessTokenForAADGraph
Logging in to Microsoft Services
Enter email, phone, or Skype: @.onmicrosoft.com
Password:
PS C:\> $userid = (Read-AADIntAccesstoken $at).oid
PS C:\> Connect-AzureAD -AadAccessToken $at -TenantId -AccountId $userid
[...]
PS C:\> Get-AzureADUserMembership -ObjectId $userid | Where-Object { $_.ObjectType -eq "Role" }
ObjectId DisplayName Description
-------- ----------- -----------
Directory Synchronization Accounts Only used by Azure AD Connect service.
PS C:\> Set-AADIntUserPassword -AccessToken $at -SourceAnchor -Password
CloudAnchor Result SourceAnchor
----------- ------ ------------
CloudAnchor 0 The Result is 0 means that the password reset worked.
I conclude then that these implicit permissions remain present in the Directory Synchronization Accounts role and thus the role is still privileged. It can be used to create and edit users, reset their password and manage synchronized groups. This isn’t that surprising; I had assumed it would be so, for how else could the AD <-> Entra ID synchronization process continue working after the massive permissions reduction?
I wondered a while ago if this wasn’t perhaps made possible via the microsoft.directory/passwordHashSync/allProperties/allTasks Entra permission in the role, but as we can see, it continues working without it so this hypothesis is rejected. It’s indeed an implicit and hidden permission.
Of course there are some limitations when abusing the private undocumented Azure AD Synchronization API. For example, this API is meant for managing hybrid users only. In Entra ID you can have cloud-only users as well and hybrid users. Previously, this API was allowed to touch both kinds of users. This wasn’t necessary and could create a larger-than-necessary blast radius if it was abused. Microsoft addressed this by restricting the power of this API to only hybrid users.
Which is, by the way, one of the reasons why we have an Indicator of Exposure in Tenable Identity Exposure in order to verify that privileged accounts in Entra ID are cloud-only. But even with these limitations, we can agree that the Directory Synchronization Accounts role is risky enough to cause concern.
What about the new On Premises Directory Sync Account Entra role?
Microsoft announced the permissions reduction as part of its initial security hardening in August 2024. I had noticed things moving one month earlier, when I detected a new, interesting role called On Premises Directory Sync Account. This new role is very similar to the Directory Synchronization Accounts role that I know very well. Both are hidden in Azure Portal / Entra Admin Center. The On Premises Directory Sync Account role is even undocumented. This is likely because they aren’t meant to be used by customers. Even so they both remain present and available for misuse by attackers.
It’s unclear to me what Microsoft’s reasons were for creating the new On Premises Directory Sync Account role. Perhaps it’s meant to be used with Entra Cloud Sync, and the old one for Entra Connect, as Nathan McNulty thought too. The descriptions for Entra Connect and Entra Cloud Sync don’t make this clear, and both synchronization software still use the old Directory Synchronization Accounts role. If anyone has a clue, please let me know!
Here are the details of both roles coming from the Microsoft Graph API:
| Old role | New role | |
| Display name | Directory Synchronization Accounts | On Premises Directory Sync Account |
| ID | d29b2b05-8046-44ba-8758-1e26182fcf32 | a92aed5d-d78a-4d16-b381-09adb37eb3b0 |
| Description | Only used by Microsoft Entra Connect service. | Only used by Microsoft Entra Connect Sync Account. |
| Rich description | This role is automatically assigned to the Microsoft Entra Connect service, and is not intended or supported for any other use. | This role is automatically assigned to the Microsoft Entra Connect Sync Account, and is not intended or supported for any other use. |
| Permissions | microsoft.directory/onPremisesSynchronization/standard/read |
microsoft.directory/onPremisesSynchronization/standard/read |
| Is privileged | false | false |
Naturally I wondered if there was a difference when calling the Synchronization API, but it turns out both roles allow the same operations. Here’s the same proof as before, this time with a user having the On Premises Directory Sync Account role:
PS C:\> Import-Module -Name AADInternals
[...]
PS C:\> $at = Get-AADIntAccessTokenForAADGraph
Logging in to Microsoft Services
Enter email, phone, or Skype: @.onmicrosoft.com
Password:
PS C:\> $userid = (Read-AADIntAccesstoken $at).oid
PS C:\> Connect-AzureAD -AadAccessToken $at -TenantId -AccountId $userid
[...]
PS C:\> Get-AzureADUserMembership -ObjectId $userid | Where-Object { $_.ObjectType -eq "Role" }
ObjectId DisplayName Description
-------- ----------- -----------
On Premises Directory Sync Account Only used by Microsoft Entra Connect Sync Account.
PS C:\> Set-AADIntUserPassword -AccessToken $at -SourceAnchor -Password
CloudAnchor Result SourceAnchor
----------- ------ ------------
CloudAnchor 0 As we noted with the old Directory Synchronization Accounts role, the new On Premises Directory Sync Account role also can only touch hybrid users and cannot modify Entra applications/service principals since it doesn’t have the necessary permissions either. Moreover, the latest version of Entra Connect (2.4.129.0 at the time this blog was written), continues to create a user called On-Premises Directory Synchronization Service Account with the old Directory Synchronization Accounts role assigned.
Tenable considers both Entra synchronization roles as privileged
According to the new privileged roles and permissions feature of Entra ID, these roles are not considered privileged. The new feature marks some permissions as privileged which then flows down to all roles having at least one privileged permission. Because the Directory Synchronization Accounts role and the On Premises Directory Sync Account role lack privileged permissions they are not marked as privileged.
Tenable respectfully disagrees with this conclusion because of the potential for abuse of these roles.
Now, let’s talk about that new app: Microsoft Entra AD Synchronization Service
No, Entra “AD” is not a typo. And even though the name might lead one to conclude this is a brand new offering, it appears that the name is likely meant to indicate its function as a bridge between Entra [ID] and AD.
Microsoft describes Entra AD Synchronization Service as “a dedicated first-party application to enable the synchronization between Active Directory and Microsoft Entra ID.” It’s described as being for customer tenants using Microsoft Entra Connect Sync or Microsoft Entra Cloud Sync service. While Microsoft communicated about this new app in December and made it available in all tenants, for now it isn’t used. At least not publicly. My goal in discussing it here is to raise awareness of the fact that, while this app is not yet generally used, it is available and already open for potential abuse.
As a first-party application, the application object (aka “app registration”) is hosted in Microsoft’s tenant, while the corresponding Service Principal (SP) object (aka “enterprise application”) is instantiated in the customer’s tenant (see how below). Below are key characteristics of this service principal (retrieved via the Graph API):
| Attribute | Value |
| displayName | Microsoft Entra AD Synchronization Service |
| id | Not relevant as it’s different in each tenant |
| appId | 6bf85cfa-ac8a-4be5-b5de-425a0d0dc016 |
| appOwnerOrganizationId | f8cdef31-a31e-4b4a-93e4-5f571e91255a (well-known “Microsoft Services” tenant where many first-party apps are registered) |
| servicePrincipalNames | [“6bf85cfa-ac8a-4be5-b5de-425a0d0dc016”] |
In my test tenant, this SP doesn’t have any app/delegated permissions granted. But its related app exposes two permissions:
- app permission
(appRoles): ADSynchronization.ReadWrite.Allhaving the IDab43b826-2c7a-4aff-9ecd-d0629d0ca6a9 - delegated permission (publishedPermissionScopes):
ADSynchronization.ReadWrite.Allhaving the ID0b41ed4d-5f52-442b-8952-ea7d90719860
The SP doesn’t have any password/key/federated credentials set. Entra ID blocked my attempts to add some (CannotUpdateLockedServicePrincipalProperty), which I believe is caused by app instance property lock.
So, how to get this SP in your tenant if you don’t have it already? I already had Entra Connect in my test tenant, so I just had to reinstall it, which triggered the creation of the SP. Surprisingly, according to the audit logs, it was created by the classic synchronization service user (“SYNC_… for Entra Connect):
Perhaps you have noticed in the above image the following intriguing Credential property: [{"CredentialType":2,"KeyStoreId":"291154f0-a9f5-45bb-87be-9c8ee5b6d62c","KeyGroupId":"291154f0-a9f5-45bb-87be-9c8ee5b6d62c"}]
I’ve observed the same for other SPs so we can ignore it.
The dangers of ADSynchronization.ReadWrite.All
Now, I know that the “Microsoft Entra AD Synchronization Service” app exposes a single permission: ADSynchronization.ReadWrite.All. This permission is available both as an app permission and a delegated permission. So I tried using it with a client Service Principal.
- Create an app registration
-
In the “API permissions” menu, click “Add a permission” and search for the “Microsoft Entra AD Synchronization Service” API:
-
Select the “application permissions” type. There’s only one, as I already know, so I check it and add:
-
Grant admin consent:
- Assign credentials to the client app to allow authenticating as its SP
Now that I have a new client SP, with this permission granted on the Microsoft Entra AD Synchronization Service API, how to use it?
On the Microsoft Entra AD Synchronization Service SP, I have no clue (e.g. reply URL) where the corresponding API is. But I know that it’s related to synchronization and I assume it’s meant to replace the usual service account. So, I’ll try to access the Synchronization API. This is the API we discussed earlier in this blog — the private undocumented “Azure AD Synchronization” API at https://adminwebservice.microsoftonline.com/provisioningservice.svc, also called “Sync provisioning service” by Dr. Nestori Syynimaa who implemented it in AADInternals.
Here’s the PowerShell script I’m using to obtain a token (using the client credentials grant OAuth 2.0 flow, also refer to this doc on the .default scope), for the Microsoft Entra AD Synchronization Service API (using known ID 6bf85cfa-ac8a-4be5-b5de-425a0d0dc016), with the credentials of my client app. Then it shows the content of the token and tries to use the Synchronization API to reset the password of a hybrid user:
Import-Module AADInternals -Force
$TenantId = '
$ClientId = '' # my "client app for Microsoft Entra AD Synchronization Service"
$ClientSecret=""
$at = $null
$response = $null
$response = Invoke-RestMethod -Method Post -Uri "https://login.microsoftonline.com/$TenantId/oauth2/v2.0/token" -Body @{grant_type = "client_credentials"; client_id = $ClientId; client_secret = $ClientSecret; scope="6bf85cfa-ac8a-4be5-b5de-425a0d0dc016/.default"}
$at = $response.access_token
Read-AADIntAccessToken -AccessToken $at
Set-AADIntUserPassword -AccessToken $at -SourceAnchor -Password Here’s the output I get. First, the obtained access token:
aud : 6bf85cfa-ac8a-4be5-b5de-425a0d0dc016
iss : https://login.microsoftonline.com/<$TenantId>/v2.0
[...]
azp : <$ClientId>
[...]
idtyp : app
oid : Which confirms that I obtained a token as desired: meant for (aud) the Microsoft Entra AD Synchronization Service API, with the ADSynchronization.ReadWrite.All permission. Then, I have the confirmation that it works when I use it (since the Result is 0):
CloudAnchor : CloudAnchor
Result : 0
SourceAnchor : Actually it doesn’t work immediately, because normally the token to call the Synchronization API has to be for the Azure AD Graph API (graph.windows.net), which is, by the way, currently being deprecated. And the code of AADInternals doesn’t expect anything else, so to make it work, I had to add -Force:$True to the following line of code in Set-UserPassword, like so:
$AccessToken = Get-AccessTokenFromCache -AccessToken $AccessToken -ClientID "1b730954-1685-4b74-9bfd-dac224a7b894" -Resource "https://graph.windows.net" -Force:$TrueTo conclude, any service principal granted the ADSynchronization.ReadWrite.All permission on the “Microsoft Entra AD Synchronization Service” app can do everything that the Synchronization API allows (such as resetting hybrid users’ passwords). Therefore, these potential service principals must be considered as malicious until the app is officially put in use. Then, when Microsoft releases it, there will be legitimate cases to exclude, of course.
Tenable Identity Exposure considers “ADSynchronization.ReadWrite.All” to be dangerous
Tenable Identity Exposure has two Indicators of Exposure related to the topic of dangerous API permissions:
They were focused on dangerous permissions on the Azure AD Graph and MS Graph APIs, but following this research, we’ve expanded them to include the ADSynchronization.ReadWrite.All permission on the Microsoft Entra AD Synchronization Service API (see screenshot below).
I want to highlight here that most online resources and tools are focused on checking permissions granted for the two most well-known APIs — Azure AD Graph and MS Graph API permissions, e.g. RoleManagement.ReadWrite.Directory. By only focusing on these two APIs, organizations risk overlooking the dangerous permission on the Microsoft Entra AD Synchronization Service API. You can use Tenable Identity Exposure to address these permissions, or you can check your scripts/tools to better secure your hybrid identity environment
Conclusion
Even after Microsoft’s 2024 hardening efforts, hybrid Entra ID synchronization remains a critical exposure point. The ‘Directory Synchronization Accounts’ and ‘On Premises Directory Sync Account’ roles still retain implicit access to sensitive synchronization APIs, and the new ‘Microsoft Entra AD Synchronization Service’ app introduces the powerful ADSynchronization.ReadWrite.All permission — creating additional risk if misused.
Security teams should proactively monitor for these roles and permissions in their environments, treat them as privileged and ensure they are continuously assessed for exposure risks. Tenable Identity Exposure accounts for these evolving exposures to help defenders stay ahead.
Tenable Research will continue to monitor this evolution to provide the most accurate indicators to our customers — ensuring you have the visibility needed to protect your hybrid identity environments.