Active Directory and Entra ID Hardening Guide

Active Directory (AD) and Microsoft Entra ID sit at the centre of most enterprise identity estates, and they remain the most common path to full compromise. Ransomware operators and state actors aim for Domain Admin or Global Administrator because from there they control everything that trusts the directory. Much of the risk comes from years of accumulated configuration. This guide sets out a prioritised hardening approach for AD, Entra ID and the connection between them, including the service accounts, app registrations and AI agent identities that live in both. It is written for identity, infrastructure and security operations teams.

Key takeaways

Tier zero comes first. Domain controllers, Entra ID privileged roles, identity sync and federation servers, certificate services and PAM are one control plane: protect them with separate accounts, devices and monitoring.
Shrink standing privilege. Microsoft recommends fewer than five Global Administrators and fewer than ten privileged role assignments, with just-in-time activation through Privileged Identity Management for the rest.
Close the known attack paths. Kerberoastable service accounts, DCSync rights, unconstrained delegation, vulnerable certificate templates, legacy authentication and stale objects account for a large share of directory compromises.
Cut the bridge from on-premises to cloud. Cloud administrators should be cloud-only accounts, synchronised objects should hold no cloud privilege, and sync and federation servers belong in tier zero.
Govern the non-human identities. Service accounts, app registrations, service principals and agent identities are frequent targets in both directories; give each an owner, the least privilege it needs and a credential that is not a static password where possible.

Understand tier zero

Microsoft's enterprise access model describes three planes: a control plane built on central identity systems, a management plane for the infrastructure and a data and workload plane where business value sits. It builds on the older AD tier model and expands tier 0 into the control plane, covering "all aspects of access control". The rule that follows is to enforce hierarchy, so that a lower plane can never control a higher one. In practice, tier zero is anything that can control identities across the environment.

Tier zero asset	Why it is tier zero	Typical control
Domain controllers and the AD database	Hold every password hash and the KRBTGT key that signs Kerberos tickets	Dedicated admin accounts, secure administrative hosts, application allowlisting, change monitoring
AD administrative groups and the Group Policy that applies to them	Membership or policy change equals domain control	Minimal membership, no standing members where possible, alerts on change
Entra ID privileged roles (Global Administrator, Privileged Role Administrator and similar)	Tenant-wide control of identities, policies and applications	Cloud-only accounts, phishing-resistant MFA, PIM, access reviews
Entra Connect sync servers, pass-through authentication agents and federation servers	Can change cloud passwords, intercept authentication or mint tokens	Treat as domain controllers; restrict logon; monitor configuration
Active Directory Certificate Services and other CAs trusted for authentication	A CA key or a vulnerable template lets an attacker authenticate as anyone	Template audit, restricted enrolment, CA servers administered from tier zero only
PAM, backup, endpoint management and hypervisor platforms with rights over the above	Indirect control of tier zero systems	Same protections as the assets they manage

Administer tier zero only from dedicated privileged access workstations, with dedicated admin accounts that are never used for email or browsing. Microsoft's AD guidance puts it plainly: never administer a trusted system from a less trusted host. See the Tiered Administration Guide. To find the hidden routes into tier zero, see the Identity Attack Paths Guide.

Active Directory hardening priorities

Joint guidance published in September 2024 by the Australian Signals Directorate with partners including New Zealand's NCSC describes 17 common techniques used against AD. NCSC New Zealand's summary says AD is vulnerable because of its permissive default settings, complex relationships and permissions, legacy protocol support and limited tools for diagnosing security issues. The priorities below address each of those weaknesses.

Privileged groups

Reduce membership of Domain Admins, Enterprise Admins, Schema Admins, Administrators and built-in operator groups to the minimum. Microsoft names Enterprise Admins, Domain Admins and Administrators as the three most privileged built-in groups.
Eliminate permanent membership of highly privileged groups and grant temporary membership when needed, two measures in Microsoft's AD security summary.
Add privileged users to the Protected Users group after testing. Members can only use AES for Kerberos, cannot authenticate with NTLM, cannot be delegated and receive ticket-granting tickets limited to four hours. Microsoft warns against adding highly privileged accounts until you are sure the restrictions will not cause problems.
Monitor all changes to privileged groups and to AdminSDHolder.

Credentials and authentication

Deploy Windows LAPS. Microsoft notes that local administrator accounts often share one password across many devices, which attackers use to move laterally; LAPS rotates and backs up each device's password and protects against pass-the-hash.
Move service accounts to group managed service accounts (gMSAs), where Windows handles password management across multiple servers. Where that is not possible, MITRE recommends AES rather than RC4 and passwords of ideally 25 or more characters to resist Kerberoasting. See the gMSA and dMSA Guide and the Service Account Security Guide.
Audit and reduce NTLM, starting with NTLMv1. Microsoft describes Kerberos as the preferred authentication method for AD, though some applications still use NTLM.
Require LDAP signing. Microsoft explains that unsigned traffic is open to replay and man-in-the-middle attacks.
Reset the KRBTGT password after suspected compromise. Microsoft's forest recovery procedure resets it twice, waiting at least the maximum ticket lifetime (10 hours by default) between resets, because the account keeps a password history of two. See the Kerberos Security Guide.

Delegation and ACLs

Remove unconstrained delegation; use constrained or resource-based constrained delegation where needed. See the Kerberos Delegation Security Guide.
Review dangerous ACLs, such as rights to reset passwords or change group membership on privileged objects. MITRE's DCSync entry recommends managing the access control list for "Replicating Directory Changes" and other replication permissions, since anyone holding them can pull password hashes from a domain controller.

Certificate services

Audit certificate templates. SpecterOps' "Certified Pre-Owned" research catalogued eight escalation paths (ESC1 to ESC8) and reported that "nearly every environment with AD CS that we've examined for domain escalation misconfigurations has been vulnerable". ESC1, for example, needs a template with an authentication EKU, enrolment open to low-privileged users, no manager approval and a requester-supplied subject alternative name.
Restrict enrolment rights, require manager approval on sensitive templates and treat CA servers and keys as tier zero. MITRE notes that an attacker holding a CA private key can forge "golden" certificates. See the Active Directory Certificate Services (AD CS) Security Guide.

Hygiene

Disable and remove stale user, computer and service accounts; assign an owner to the rest.
Isolate, then decommission, legacy operating systems, applications and trusts that are no longer needed.

Attack technique	MITRE ATT&CK	Hardening that blocks it
Kerberoasting service accounts	T1558.003	gMSAs, AES-only encryption, long random passwords, no SPNs on privileged accounts
Golden and silver tickets	T1558.001, T1558.002	Protect domain controllers and service account keys; reset KRBTGT twice after compromise
DCSync	T1003.006	Restrict replication rights to domain controllers; alert on replication from other hosts
Certificate template abuse and forged certificates	T1649	Template audit, enrolment restrictions, manager approval, CA as tier zero
Hybrid identity backdoors (PTA agent or AD FS tampering)	T1556.007	Cloud authentication, review of PTA agents, signed binaries on AD FS hosts
Domain or federation trust modification	T1484.002	Few Global Administrators, alerts on new domains and federation settings

Entra ID hardening priorities

Privileged roles

Keep Global Administrators to fewer than five, as Microsoft recommends, and privileged role assignments to fewer than ten. Microsoft shows warnings in the admin centre when you exceed either number.
Grant the narrowest built-in or custom role, scoped with administrative units where possible, and use Privileged Identity Management for just-in-time activation with approval. See the Privileged Identity Management (PIM) Guide and the JIT Access Guide.
Run recurring access reviews of role assignments and of role-assignable groups, whose owners indirectly decide who holds the role.
Keep two cloud-only emergency access accounts permanently assigned Global Administrator, excluded carefully from policies and monitored. See the Break-Glass Account Guide.

Authentication and Conditional Access

Require MFA for all users and phishing-resistant MFA for administrators. Microsoft's Conditional Access template lists at least 14 roles that should require the phishing-resistant authentication strength, including Global, Privileged Role, Security, Conditional Access, Application and Helpdesk Administrator. See the Phishing-Resistant MFA Guide.
Block legacy authentication. According to Microsoft's analysis, more than 97 per cent of credential stuffing attacks and more than 99 per cent of password spray attacks use legacy authentication protocols.
Require compliant or managed devices for privileged access and sensitive applications, and use sign-in and user risk policies where licensed. See the Conditional Access Guide.

Applications and service principals

Restrict user consent to low-risk permissions and review admin-consented apps. See the Entra ID Applications and Consent Guide.
Find service principals with high-privilege application permissions, such as broad Microsoft Graph or Exchange write rights, and reduce them.
Prefer managed identities, which Microsoft says remove the need for developers to manage credentials at all, and certificate or federated credentials over client secrets. Alert on new credentials added to existing apps.
Assign an owner to every app registration, and remove test and legacy registrations that still hold production permissions.

AI agents and agent identities

AI agents now authenticate to Entra ID and Microsoft Graph like any other workload. Microsoft Entra Agent ID provides agent identities and "agent identity blueprints" that act as templates for creating many agents with consistent policy, and extends Conditional Access, Identity Protection, governance and sign-in logging to them. Whatever platform you use, give each agent its own identity with an owner, never let an agent reuse an administrator's or a service account's credentials, and scope its Graph permissions to the task. See the AI Agent Authorisation Guide.

Tenant settings

Restrict who can register applications, create tenants and invite guests.
Review cross-tenant access and external collaboration settings.

Hybrid identity

Microsoft identifies two primary threat vectors from on-premises into Microsoft 365: federation trust relationships and account synchronisation. A stolen SAML token-signing certificate "allows anyone who has that certificate to impersonate any user in your cloud", and synchronisation can be used to change privileged users or groups. Its guidance is to isolate cloud administrators fully: cloud-native accounts, phishing-resistant credentials, Conditional Access and cloud-managed privileged access workstations, with no on-premises account holding administrative privilege in Microsoft 365.

Treat sync and federation servers as tier zero: Entra Connect servers, pass-through authentication (PTA) agents and AD FS servers can change cloud credentials, see passwords or issue tokens. MITRE T1556.007 describes attackers injecting a malicious DLL into a PTA agent so it accepts every authentication, and APT29 editing AD FS configuration to load a malicious DLL.
Keep sync accounts least privileged: since build 1.4.###.# of Entra Connect, an Enterprise Admin or Domain Admin can no longer be used as the AD DS Connector account. Check older installations and any custom connector permissions.
Do not synchronise privileged accounts: Microsoft advises using cloud-native accounts for Entra roles, because a compromised on-premises account can otherwise compromise Entra resources.
Move to cloud authentication: Microsoft recommends deprecating on-premises federation and web access management infrastructure, which removes a tier zero system and the token-signing key that goes with it.
Watch for configuration change: review PTA agents for unapproved ones, as MITRE suggests, and alert on new federated domains, changed federation settings and sync configuration changes. See the Federation and Trust Guide.

Monitoring

Collect domain controller security logs and Entra ID sign-in and audit logs centrally. Many attacks start on one side and finish on the other, so correlate them. Signals worth an alert:

Signal	Source	What it may indicate
Kerberos service ticket requests with RC4 (event 4769, etype 0x17) or unusual volume from one account	Domain controller security log	Kerberoasting (MITRE detection guidance)
Directory replication requests from hosts that are not domain controllers	Domain controller logs, identity threat detection tools	DCSync
Changes to privileged groups, AdminSDHolder, delegation settings or certificate templates	AD audit logs	Privilege escalation or persistence
Privileged role assigned outside PIM, or a PIM activation at an unusual time	Entra audit logs, PIM alerts	Standing privilege creep or misuse
Any emergency access account sign-in or change	Entra sign-in and audit logs	Misuse or a genuine emergency; both need a response
New custom domain, federation setting, identity provider or Conditional Access change	Entra audit logs	Tenant-level backdoor or weakened policy
Credentials added to service principals; new app consent	Entra audit logs	NHI persistence or illicit consent
New or unexpected PTA agent; unsigned binaries on AD FS hosts	Entra admin centre, endpoint telemetry	Hybrid identity backdoor (T1556.007)

Microsoft also recommends monitoring Entra ID risk detections and behavioural analytics, and alerting on every use of emergency access accounts. Run attack path analysis regularly, because every change can open a new route to tier zero. See the ITDR Guide.

Real-world lessons

Legacy test accounts and apps: the Microsoft Midnight Blizzard Breach 2024 began with a password spray against a legacy, non-production test tenant account without MFA. The actor then compromised a legacy test OAuth application with elevated access to the corporate environment and created malicious OAuth apps of its own.
Hybrid sync as a bridge: in the Storm-0501 Hybrid Cloud Attacks 2024, Microsoft reported that the group extracted plain text credentials of Entra Connect Sync accounts, used a Domain Admin whose matching Entra ID account was a Global Administrator without MFA, and added a federated domain as a backdoor.
Stolen hashes stay dangerous: in the Cisco Active Directory Credentials Leak 2025, the Kraken group published AD usernames and NTLM hashes, reportedly including the krbtgt account; Cisco said the data came from its May 2022 incident. Once directory hashes are taken, every account in them, including service accounts and KRBTGT, needs rotation.
Platform-level identity flaws: the Entra ID Actor Token Flaw 2025 (CVE-2025-55241) let undocumented service-to-service tokens impersonate any user across tenants. Microsoft fixed it within days and saw no evidence of abuse; tenant-wide changes still need monitoring.

Common failure patterns

Tier zero defined too narrowly: domain controllers are protected, but sync, CA, backup and endpoint management servers are administered from ordinary workstations.
Synchronised administrators: on-premises accounts hold Entra roles, so a domain compromise becomes a tenant compromise, as in Storm-0501.
Service accounts in Domain Admins: old service accounts with SPNs, weak passwords and RC4 support sit in privileged groups, making Kerberoasting a direct route to domain control.
Certificate templates never audited: AD CS was installed for one project years ago and nobody owns the templates, leaving ESC-style escalation open.
Forgotten test tenants and apps: non-production accounts and app registrations with production permissions and no owner, the pattern behind Midnight Blizzard.
Incomplete credential reset after compromise: user passwords are reset but KRBTGT, service accounts, gMSA keys and app credentials are not, so attackers return with old material.

Framework mapping

This is an indicative NHI Mgmt Group alignment, not an official crosswalk. Control IDs were checked against NIST CSF 2.0, the NIST SP 800-53 Rev. 5 catalogue, the CIS Controls v8.1 control list and a published ISO/IEC 27001:2022 Annex A index; CIS is mapped at control level.

Control area	NIST CSF 2.0	NIST SP 800-53 Rev. 5	ISO/IEC 27001:2022 Annex A	CIS Controls v8.1	OWASP NHI Top 10
Tier zero and privileged account restriction	PR.AA-05	AC-6(5), AC-2(7), AC-6(2)	8.2 Privileged access rights	5, 6	NHI5
Phishing-resistant MFA for administrators	PR.AA-03	IA-2(1), IA-2(8)	8.5 Secure authentication	6	n/a
Service account and app credentials	PR.AA-01	IA-5, IA-5(1), AC-2	5.17 Authentication information	5	NHI4, NHI7
Secure configuration (legacy protocols, delegation, templates)	PR.PS-01	CM-6, CM-7	8.9 Configuration management	4	n/a
Hybrid identity and federation trust	PR.AA-04	SC-12, CM-3	8.24 Use of cryptography, 8.32 Change management	4	n/a
Access reviews and stale account removal	PR.AA-05	AC-2(3), AC-6(7)	5.18 Access rights	5	NHI1
Directory and tenant monitoring	DE.CM-03, DE.CM-09	AU-6, AU-12, SI-4, AC-6(9)	8.15 Logging, 8.16 Monitoring activities	8	n/a
Response and credential reset after compromise	RS.MI-02, RC.RP-02	IR-4	5.26 Response to information security incidents	17	n/a

Metrics that show progress

Metric	What it shows	Target direction
Permanent members of Domain Admins, Enterprise Admins and Schema Admins	Standing AD privilege	Down, towards zero outside break-glass
Global Administrator and privileged role assignments in Entra ID	Standing cloud privilege	Under five and under ten respectively
Privileged Entra roles held by synchronised accounts	On-premises to cloud bridge	Zero
Service accounts with SPNs that support RC4 or have passwords older than policy	Kerberoasting exposure	Down
Certificate templates with ESC-style misconfigurations	AD CS escalation exposure	Zero
Sign-ins using legacy authentication	MFA bypass routes	Zero
App registrations and service principals without an owner	NHI governance	Zero
Attack paths to tier zero found by the latest analysis	Residual exposure	Down with each run

Implementation roadmap

Phase	Focus	Actions
First 30 days	See and stop the worst	Inventory tier zero assets and privileged accounts in both directories; block legacy authentication; require phishing-resistant MFA for admin roles; confirm two working emergency access accounts; remove service accounts from Domain Admins
Days 31 to 90	Reduce privilege and attack paths	Move Entra roles to cloud-only accounts with PIM; deploy Windows LAPS; convert service accounts to gMSAs or long AES-only passwords; remove unconstrained delegation; audit AD CS templates and DCSync rights
Days 91 to 180	Isolate and monitor	Deploy privileged access workstations for tier zero; harden and monitor sync, PTA and federation servers; plan migration from AD FS to cloud authentication; alert on the signals in the monitoring table; review app registrations and consent
Ongoing	Sustain	Quarterly access reviews of privileged roles and groups; regular attack path analysis; test the KRBTGT reset and forest recovery procedure; govern new agent identities as they appear

Recovery planning belongs alongside hardening: see the Active Directory and Entra ID Recovery Guide and the Top 10 Active Directory Security Risks and How to Fix Them.

Practitioner checklist

Define tier zero, including sync, federation, CA, PAM and management platforms, and administer it from dedicated accounts and workstations.
Keep Global Administrators under five and privileged role assignments under ten; use PIM for just-in-time elevation.
Use cloud-only accounts for every Entra privileged role; synchronise no privileged accounts.
Require phishing-resistant MFA for administrators and block legacy authentication.
Deploy Windows LAPS; move service accounts to gMSAs; enforce AES and long passwords where gMSAs are not possible.
Remove unconstrained delegation, restrict replication rights and fix vulnerable certificate templates.
Reduce service principal permissions, restrict user consent and assign an owner to every app and agent identity.
Protect Entra Connect, PTA agents and AD FS as tier zero, and plan the move to cloud authentication.
Alert on directory attacks, tenant-wide changes and new app credentials; run attack path analysis regularly.
Rehearse KRBTGT reset and credential rotation for service accounts and apps after compromise.