Microsoft Defender for Identity Recommended Actions: Remove non-admin accounts with DCSync permissions

Identity leverages Secure Score with twenty-seven recommended actions. In a series of blog posts, I will go through all twenty-seven recommended actions and what they mean, a plan of approach, their impact, and my security recommendations, hopefully helping others. The twenty-second  one in the series is the “Remove non-admin accounts with DCSync permissions” recommended action.

Introduction

You have twenty-seven recommendations if you filter the Secure Score recommended actions for Microsoft Defender for Identity.

• Resolve unsecure domain configurations
• Resolve unsecure account attributes
• Remove dormant accounts from sensitive groups
• Protect and manage local admin passwords with Microsoft LAPS
• Configure VPN integration
• Reduce lateral movement path risk to sensitive entities
• Stop clear text credentials exposure
• Disable Print spooler service on domain controllers
• Stop weak cipher usage
• Remove unsecure SID history attributes from entities
• Modify unsecure Kerberos delegations to prevent impersonation
• Install Defender for Identity Sensor on all Domain Controllers
• Set a honeytoken account
• Start your Defender for Identity deployment, installing Sensors on DC’s and other eligible servers
• Accounts with non-default Primary Group ID
• Change Domain Controller computer account old password
• Reversible passwords found in GPOs
• Unsafe permissions on the DnsAdmins group
• GPO assigns unprivileged identities to local groups with elevated privileges
• Remove access rights on suspicious accounts with the Admin SDHolder permission
• Remove local admins on identity assets
• Remove non-admin accounts with DCSync permissions
• GPO can be modified by unprivileged accounts
• Built-in Active Directory Guest account is enabled
• Change password for krbtgt account
• Change password of built-in domain Administrator account
• Ensure that all privileged accounts have the configuration flag

Some recommended actions are easy to configure, but others require time, proper planning, auditing, and expertise. This blog post will review the recommended action of “Remove non-admin accounts with DCSync permissions.”

Update: Microsoft keeps updating the recommended actions list. I will do my best to keep the list up-to-date.

DCSync

DCSync is a technique that leverages specific Active Directory permissions to replicate data from a domain controller. Normally, only domain controllers use replication protocols to synchronize identity information, but with the right permissions, any account can request this replication, effectively acting like a domain controller. This means that an attacker, or even a misconfigured account, with DCSync permissions can extract sensitive information directly from AD, including password hashes, and sensitive information for privileged accounts, such as the krbtgt account.

If an attacker obtains the krbtgt account’s keys or hash, they can forge valid Kerberos Ticket Granting Tickets (TGT) and impersonate any user, including Domain Admins, across the domain. Because TGTs are cryptographically signed with the krbtgt key, forged tickets appear authentic to domain controllers and let attackers access resources stealthily and persistently, surviving password changes.

Remediation requires carefully rotating the krbtgt key, the recommended double reset, and thorough detection and containment, because until those keys are replaced, the attacker effectively holds the root of trust for Kerberos in your environment, owning the entire domain.

Replicating Directory Changes

Only a very small set of identities should ever hold Replicating Directory Changes rights. Domain Controller computer accounts need them by design so DCs can replicate AD between each other, and the Azure AD Connect sync account, whether a dedicated user account or a managed service account, needs them so it can read directory data to sync to Azure AD.

In rare, short-lived scenarios, you might also grant the same rights to a vetted third-party directory migration or sync tool, but those permissions should be removed immediately after the project ends. No human user, application service account, or generic admin account requires replication rights for normal operations, giving those accounts replication privileges is over-permissioning and a major security risk.

Detection

While understanding the risk of DCSync is important, detection is just as crucial. This is where Microsoft Defender for Identity becomes valuable. Microsoft Defender for Identity continuously monitors your domain for accounts that hold replication permissions, highlighting those that are not domain controllers or the Azure AD Connect sync account. If such an account is discovered, it will be surfaced in the security assessment section, allowing you to quickly identify and respond to potential misuse.

Microsoft Defender for Identity does more than simply point out the problem. By tracking these findings against your Secure Score also helps you measure progress as you remove excessive permissions and harden your environment. Administrators can use this visibility to distinguish between accounts that legitimately require replication rights and those that were mistakenly over-privileged. Once identified, unnecessary rights should be revoked, and the assessment will reflect the reduced exposure.

This detection capability is crucial because DCSync attacks do not resemble normal logons. They appear as replication traffic, which often goes unnoticed in traditional monitoring. Without a tool like Microsoft Defender for Identity, dangerous accounts could quietly retain the ability to replicate sensitive secrets for years.

Conclusion

Securing replication rights in Active Directory is not just about preventing configuration mistakes, it is about closing off one of the most powerful attack techniques available to adversaries. DCSync turns an over-privileged account into a domain controller in disguise, capable of extracting the secrets that underpin your entire identity infrastructure. By keeping replication permissions limited to domain controllers and the Azure AD Connect sync account, and by using Microsoft Defender for Identity to continuously monitor for deviations, you reduce the chance of an attacker quietly gaining the keys to the kingdom. Identity is the new security boundary, and visibility into these permissions is an essential step in protecting it.