Exploiting Weaknesses in Entra ID Account Synchronization to Compromise the On-Prem Environment  

Active Directory (AD) is a Microsoft product designed to assist network administrators in managing user permissions within an organization. It is installed on a Windows Server, turning it into a Domain Controller responsible for managing enterprise environments and performing actions such as storing all user accounts, their passwords and permissions, and managing user authentication. 

Over time, the world is increasingly moving towards cloud adoption, and Microsoft has also been pushing organizations to shift towards cloud-based environments for more streamlined and modern identity management. Microsoft’s solution for cloud-based domain environment is Entra ID. It extends the capabilities of on-premises AD to the cloud, providing a robust solution for managing identities and access for cloud-based applications. To enable a seamless integration with supporting legacy systems, Microsoft introduced Entra ID Connect. This tool allows organizations to link their on-premises Active Directory (AD) environment with Entra ID, creating a “hybrid joined environment”. 

Through Entra ID Connect, organizations can synchronize users and directory data from their on-premises AD to the cloud. This enables users to access cloud services while using the same credentials as for their on-premises systems. One interesting feature Entra ID Connect supports is password writeback, where password changes made in the cloud are synced back to the on-premises AD, ensuring consistent identity management across both environments. This hybrid model ensures that organizations can maintain a unified identity system while operating across both cloud and on-premises infrastructures. 

The differences in permission management between legacy Active Directory and Entra ID can lead to security gaps in the synchronization process between the two products. 

Deep Dive into Permission Management 

Permission management in Active Directory operates in such a way that in each environment, there are several default privileged security groups with elevated permissions to make changes. When we want to grant a specific user these permissions, we simply add them to the group. For example, the “Domain Admin” group grants privileges to all users within a Domain Admin privilegeit. Another method for defining permissions for users or groups is through the ACL (Access Control List). This list exists for each object in AD and specifies the permissions for each entity. This mechanism allows for the assignment of permissions to a regular user to make modifications, even to objects belonging to users with high-level privileges, such as Domain Admins. 

However, in Entra ID (formerly Azure AD), there are no security groups by default. Instead, it uses an RBAC (Role-Based Access Control) mechanism. This means there are many types of roles, each defining different user permissions. You can also assign a role to a group, and all members of that group will inherit the same permissions. But this option does not include groups defined by default, like Active Directory. 

So, what’s the difference between the two mechanisms? In Entra, a modification protection is provided when a user receives privileged permissions by role or group assignment. In legacy AD, we discovered that not all sensitive groups are protected from modifications. In fact, certain sensitive groups are treated as weak when it comes to Entra ID Connect synchronization. 

In Entra, whenever a user receives a privileged role, they are automatically granted modification protection. Only a user with higher-level privileges or equivalent role level can perform changes, preventing any other user with lower role level from doing so. This means the user doesn’t have to be a member of a security group to be protected—simply assigning them a privileged role is enough to provide them with some level of protection, unlike in AD. 

For example, in the hierarchy of administrator roles within Entra ID, the Password Administrator role grants users the ability to reset passwords. However, despite being categorized as an administrator, this role is considered one of the lowest in the admin hierarchy. As a result, Password Administrators can only reset passwords for regular users or users holding the same admin role. They do not have the authority to reset passwords for users in higher-level administrator roles, such as Global Administrators or other privileged accounts, maintaining a clear security boundary between different admin roles. This hierarchical structure ensures that more sensitive roles are protected from unauthorized password changes. 

Password administrator role

How Does Synchronization Happen? 

The synchronization process between on-premises AD and Entra ID can be divided into two main parts: 

  1. Syncing Identities from On-Premises to Entra ID 
  1. Password Writeback from Entra ID to On-Premises 

Part 1: Syncing from On-Premises to Entra ID 

Entra ID Connect creates a service account user called MSOL following the first 8 bytes of the installation identifier. This user has powerful capabilities which may be equivalent to a Domain Controller. The “Replicating Directory Changes All” permission allows the user to perform DC sync and extract all the object’s attributes including the client’s credentials––in other words, its NT Hash. Due to the extensive permissions granted to this user across the directory, it can access and read information about users in protected groups. This is because the permissions provided enable the user to operate with Domain Controller-like privileges. Consequently, even if the user is not explicitly listed in a group’s ACL, it still retains the ability to retrieve the NT Hash of the group members. This permission allows the on-premises side of the synchronization process and is managed using Directory Replication Service Remote Protocol, which operates over RPC transport. The same protocol is used to perform the DCSync attack. The on-premises sync agent sends all user information and attributes to Entra ID over port 443. Once Entra receives this data, it processes and populates the necessary details within its environment, completing the initial synchronization process. 

Part 2: Password Writeback from Entra ID to On-Premises 

The second part of the synchronization process takes place when Password Writeback is enabled in Entra AD Connect. This feature allows password synchronization from the cloud to the on-premises environment, so when a user changes their password in the cloud, the change is also reflected on-premises. This ensures accurate synchronization between the two environments, which is one of the main reasons for connecting them: to allow users to log in with the same password across all applications and environments in the organization. 

When a password reset action is initiated for a user in Entra ID, the system first searches for the username to verify that it exists in Entra ID. If the user is discovered, a permissions check is performed to see if the person attempting the password reset has a role that allows them to perform this action. If the user has the necessary permissions, Entra ID sends the username and the new password to the Entra Service Bus. 

The sync agent running on-premises retrieves this information. Since the MSOL user created by Entra Connect has DS Sync permissions but only for reading, it does not use the RPC protocol to reset the password. Instead, it performs an LDAP request to locate the corresponding user in Active Directory and attempts to update the password with the request using the “IADsUser.ChangePassword” operation. 

At this stage, a crucial security check is performed: when the LDAP request is received by the domain controller (DC), the Active Directory permissions system checks whether the user attempting the password change has the necessary permissions to reset the password for the target user. This is done by examining the target user’s ACL. If the MSOL user does not have the “Reset Password” permission over the entity, an error is sent back to Entra ID, indicating that the password update failed due to insufficient permissions. If the “Reset Password” permission is present, the password change is successfully completed.  

The security gap 

During the synchronization process, I noticed there is no full coverage of which users belong to privileged groups or have higher permissions. Consequently, in the Entra environment, these users do not automatically receive the same privileged status as they do on-premises. By default, hybrid users do not receive the same protection as privileged roles in Entra during initial synchronization, unless the network administrator manually assigns these privileges and protections within Entra ID. 

Understanding the synchronization capabilities between the two environments and the ability to synchronize credentials back from Entra to on-premises, the question arises: what are the potential risks involved? 

The main risk is gaining elevated permissions in on-premises AD through a weak admin role in Entra. While in AD, a user can receive privileged permissions but not necessarily belong to a protected group, which leaves them exposed to attacks. The same risk exists in this attack flow here: 

Once an attacker gains control over an Entra ID user with the Password Administrator role assigned, they can leverage its password reset permission to elevate their permissions, even though the user may not have an on-premises user.  By resetting the password of a user with elevated AD permissions, like a user from the DNS Admins group, they could gain control over the account and potentially escalate privileges within the on-premises domain. 

Reset user passwords

All the attacker needs to do is log in with the right user account, which has at least the Password Administrator role to Entra ID. It doesn’t matter if they use the interface at https://entra.microsoft.com or https://portal.azure.com. Once logged in, they select the target on-premises user and simply reset their password. This allows the attacker to log in to the on-premises environment with the account whose password they changed.  

It is important to note that if the targeted user is part of a protected group in the on-premises environment, the attack will fail.

Failed to reset password of user in protected group

This is because the permission management for protected users on-premises blocks changes from being made by an Entra ID Connect account to users in those protected groups. In an on-premises environment, protected groups can be identified by examining the adminCount attribute of the group. If the adminCount attribute is set to “1”, it indicates that the group is considered protected. These protected groups follow a fixed permissions template that is periodically enforced. Every hour, a protection mechanism in Active Directory runs a process that checks if the group’s permissions in the ACL match the permissions defined in the template. If there is a discrepancy, the process resets the permissions to align with the template.

Protected group adminCount attribute 

This process is managed by a mechanism called SDProp (Security Descriptor Propagator), and the permissions template is known as AdminSDHolder

Attack Scenarios That Exploit This Weakness  

Shadow Admins 

Shadow Admins are users that can reset password to an admin but do not belong to any admin group. Since both on-premises Active Directory and Entra ID treat these Shadow Admins as regular users (without special protection by privileged user groups), an attacker can exploit their ability to reset the password of a privileged user in Entra. This means the attacker can also reset that user’s password in the on-premises environment. 

This scenario provides attackers with a clear pathway to escalate privileges and expand their control across the network, taking advantage of the compromised user’s elevated permissions. 

DNS Admin Group 

Another example is the DNS Admin group. DNS Admins manage critical network infrastructure components, specifically DNS servers. Since the DNS Admin group is set up as a privileged group without additional protection on-premises, an attacker could easily reset the password of a DNS Admin group member via Entra. This would give them full control over that account in the on-premises environment. 

With control of a DNS Admin account, the attacker could significantly disrupt network operations. They might modify DNS records to redirect internal network traffic, perform Man-in-the-Middle (MITM) attacks by rerouting traffic through servers they control, or alter DNS settings to send users to malicious websites.  

MSOL user had a reset password on the DnsAdmins group. 

Group Policy Creator Owners 

Group Policy Creator Owners is another example of a group that could be a privileged group without additional protection. Members of this group can modify Group Policy Objects (GPOs) that they have created. If an attacker gains access to an account in this group, they can exploit their permissions to modify existing enforced GPOs that may include harmful scripts or settings, such as scripts that could steal credentials or install malware. 

Cert Publishers Group 

Cert Publishers group is another example of a privileged group that may not always receive the necessary attention regarding security. Members of this group are granted the ability to publish certificates to Active Directory, which plays a key role in the organization’s Public Key Infrastructure (PKI). If an attacker gains access to an account that is part of the Cert Publishers group, they can issue or manipulate certificates, leading to serious security risks. 

For example, the attacker could publish a malicious or rogue certificate to impersonate trusted users or services, enabling them to carry out MITM attacks, decrypt secure communications, or bypass authentication controls. The attacker could also escalate privileges by issuing certificates for highly privilege accounts like domain administrators, leading to full domain compromise.  

Attack Mitigation 

1. When using a hybrid joined identity setup, always compare the permissions between your on-premises environment and Entra. Additionally, make sure privileged users who exist only in Entra and do not have corresponding accounts in on-premises do not receive password reset permissions. This helps prevent unauthorized external access and control over your environment. 

2. When setting up synchronization between on-premises Active Directory (AD) and Entra ID, it’s essential to always verify the permissions assigned to privileged groups in your on-premises environment. Specifically, you should ensure that these groups do not have unnecessary password change permissions. 

If you notice that members of privileged groups can change passwords, you have two options to address this: 

  1. Manually remove the permissions: You can manually adjust the permissions for each privileged group to remove the ability to change passwords. 
  1. Leverage the AdminSDHolder template: Alternatively, you can modify the adminCount attribute of the privileged groups to be equal to “1”, thus protecting them. 

The AdminSDHolder is a security template in Active Directory that defines and enforces security permissions for members of protected groups. By adding the privileged groups to this template, you can automatically remove their password change permissions. 

Stop Identity Threats Now