Zero Trust in Hybrid Active Directory Environments: Tiering, Legacy Protocols and Entra Integration

In a hybrid estate, a zero trust policy in Microsoft Entra ID is only as strong as the on-premises Active Directory that feeds it, because whoever controls a domain controller, the Entra Connect server or a federation signing key can usually reach the cloud as well. Most zero trust programmes start in the cloud with Conditional Access and device compliance, and leave the forest running on assumptions from 2005: flat administration, NTLM fallback, RC4 tickets and a sync server managed like any other application server. This guide applies zero trust to that hybrid core: tiering the forest into control, management and workload planes, retiring NTLM and Kerberos RC4 as trust you can no longer verify, and treating the Entra Connect trust as control plane infrastructure. It is for identity architects, AD engineers and security teams running Active Directory alongside Entra ID.

This is an independent guide from NHI Mgmt Group, based on Microsoft's public documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.

Key takeaways

• Hierarchy is the core rule. Microsoft's enterprise access model requires that a lower plane can never control a higher one, so any path from a workstation or server admin to a domain controller or sync server is a zero trust defect.
• Hybrid identity infrastructure is control plane. Domain controllers, Entra Connect servers, federation servers and certificate authorities share one tier, one admin population and one set of hardened workstations.
• Cloud admins stay cloud-only. No synchronised on-premises account should hold a privileged Entra or Microsoft 365 role, which breaks the most common on-premises-to-cloud escalation path.
• Legacy protocols are implicit trust. NTLM and RC4 Kerberos cannot give you the explicit verification zero trust needs; removing them is identity work, not just a cryptography upgrade.
• Measure paths, not policies. The useful metrics are attack paths into Tier 0, privileged synced accounts, NTLM and RC4 volumes, and sync server admins, tracked to zero.

Where hybrid trust breaks zero trust assumptions

Zero trust assumes each access request is evaluated on its own merits. Hybrid identity creates standing trust relationships that bypass that evaluation: if an attacker controls the source of truth on-premises, the cloud accepts what it is told. Microsoft's guidance on protecting Microsoft 365 from on-premises attacks is built on this point and recommends treating hybrid identity infrastructure as tier 0, archiving and monitoring its operating system logs.

The federation path is the fastest: an attacker with administrative rights on-premises who obtains a SAML token-signing certificate can sign tokens for any federated user without a password or MFA prompt. See the Golden SAML and Federation Trust Abuse Defence Guide.

Tiering the hybrid forest under zero trust

The classic AD tier model (Tier 0 domain control, Tier 1 servers, Tier 2 workstations) is still the practical way to build a forest, but Microsoft now frames it inside the enterprise access model. That model builds on the AD tier model: Tier 0 expands to become the control plane, Tier 1 splits into a management plane and a data or workload plane, and Tier 2 splits into user access and application access. Its rules are zero trust on all access, pervasive enforcement across users, admins, APIs and service accounts, and hierarchy enforcement to prevent control of higher planes from lower planes.

• Logon restrictions: Tier 0 accounts must never log on to lower-tier hosts, because their credentials are left behind for theft. Enforce with user rights assignment (deny log on locally, through Remote Desktop Services, as a batch job and as a service) in tier-specific GPOs, and add Tier 0 humans to the Protected Users group so NTLM, DES and RC4 are not used for them. See the Privileged Access Workstations Guide.
• Control of control: anything that can change a Tier 0 asset is Tier 0. That includes GPOs linked to the Domain Controllers OU, the OU and ACL owners of Tier 0 objects, the management agent on the sync server, and the backup console that can restore a DC. See the Active Directory ACL and Delegation Hygiene Guide.
• Service accounts: place each service account in the tier of the most sensitive host it logs on to, prefer gMSAs, and remove domain admin rights from any service account. See the How to find service accounts with Domain Admin rights guide.
• Local admin: unique local administrator passwords per machine with Windows LAPS, so one compromised workstation does not give lateral movement through a shared password (ATT&CK T1550.002 Pass the Hash). See the Local Administrator Password Solution (LAPS) Guide.

Breaking the on-premises to cloud privilege path

Microsoft's four principles for protecting Microsoft 365 from on-premises attacks map directly to zero trust: fully isolate Microsoft 365 administrator accounts, manage devices from the cloud, ensure no on-premises account has elevated privileges to Microsoft 365, and use Entra cloud authentication to remove dependence on on-premises credentials.

• Cloud-only privileged roles: use cloud-only accounts for Entra and Microsoft 365 privileged roles, with just-in-time activation through Privileged Identity Management and phishing-resistant authentication to activate. Do not place on-premises accounts or service accounts in privileged cloud roles or groups. See the Entra ID Privileged Roles Guide.
• Emergency access: keep cloud emergency access accounts rather than storing cloud admin credentials in an on-premises vault, and alert on every sign-in and credential change for them.
• Cloud authentication: phishing-resistant passwordless methods such as Windows Hello for Business, passkeys (FIDO2) or certificate-based authentication, so a password changed on-premises is not enough to sign in.
• Retire federation where you can: Microsoft recommends deprecating on-premises federation and web access management infrastructure. See the AD FS to Entra ID Migration guide.
• Cloud-sourced provisioning: provision from cloud HR systems to Entra ID, and use Entra cloud provisioning for disconnected forests instead of creating cross-forest trusts.
• Block legacy authentication: a Conditional Access policy that blocks legacy authentication protocols wherever possible.

Hardening the Entra Connect trust

Microsoft's prerequisites for Entra Connect recommend hardening the server as a Control Plane (formerly Tier 0) asset. The settings below come from that page and the accounts and permissions reference; for the full product baseline see the Microsoft Entra Connect and Cloud Sync Hardening Guide.

Treat the Connect sync account as a high-value non-human identity: review its permissions, alert on interactive use and know who can read its credentials. See How to audit the Entra Connect sync account. Adversaries target this layer directly; MITRE ATT&CK tracks it as T1556.007 Hybrid Identity, and changes to domain or tenant federation trust as T1484.002 Trust Modification.

Retiring legacy protocols as zero trust work

NTLM and RC4 Kerberos give the network implicit trust in a password-equivalent hash. Microsoft lists all versions of NTLM, including LANMAN, NTLMv1 and NTLMv2, as deprecated, and its November 2024 update records NTLMv1 as removed starting in Windows 11 version 24H2 and Windows Server 2025. Microsoft's roadmap for disabling NTLM by default, reported in February 2026, runs in three phases: enhanced auditing now, migration features such as IAKerb and a local KDC expected in the second half of 2026, then network NTLM disabled by default in the next Windows Server and client release. For RC4, Microsoft changed the Kerberos default to AES-SHA1 for accounts without an explicit encryption type in November 2022, planned to disable RC4 as the default assumed type on domain controllers by the end of Q2 2026 under KB5073381, and documents that Windows Server 2025 domain controllers do not issue RC4 ticket-granting tickets. Recheck these pages before relying on a date, because Microsoft has revised them during 2026.

Order matters. Protect Tier 0 first: deny NTLM to domain controllers' privileged sessions and to the Entra Connect server, put Tier 0 humans in Protected Users, and make all Tier 0 service accounts AES-only. Then extend to Tier 1 servers and finally to workstations, where most remaining NTLM comes from printers, NAS devices and legacy applications.

Implementation phases

1. Discover (weeks 1 to 6): inventory Tier 0 assets and every account, group, GPO and ACL that can control them; list synchronised accounts in privileged cloud roles; turn on NTLM auditing and collect 4768 and 4769 events with their encryption type fields.
2. Separate cloud administration (weeks 4 to 10): create cloud-only admin accounts with PIM and phishing-resistant activation, then remove privileged roles from synchronised accounts. Rollback: keep the old assignments documented and the emergency access accounts tested.
3. Build the control plane (months 2 to 6): issue PAWs to Tier 0 admins, create Tier 0 admin accounts, apply logon restriction GPOs in a pilot OU first, move the Entra Connect and AD FS servers into the Tier 0 management boundary and apply the Microsoft hardening list.
4. Close escalation paths (months 3 to 9): remove Tier 0 control from lower-tier groups and ACLs, deploy Windows LAPS, convert service accounts to gMSAs, disable soft matching and hard match takeover, and start the 30-day Seamless SSO key rollover.
5. Retire legacy protocols (months 4 to 18): AES-only Tier 0 service accounts first, then RC4 clean-up across the domain; NTLM audit to exceptions to block, Tier 0 first. Each restriction runs in audit mode, then for a pilot group, with the previous GPO setting kept for immediate rollback.
6. Reduce on-premises dependency (ongoing): cloud authentication, retirement of federation, cloud provisioning and cloud device management, so the forest becomes a workload rather than the root of trust.

Decision guidance

• Full tiering or control plane first: large organisations with many admin teams benefit from a full three-tier build. Smaller organisations get most of the value by defining Tier 0 only: a handful of named admins, PAWs, logon restrictions for those accounts and cloud-only cloud admins.
• Federation or cloud authentication: zero trust favours cloud authentication (password hash sync with phishing-resistant MFA, or passwordless) because it removes an on-premises signing key from the sign-in path. Keep federation only where a documented requirement cannot be met otherwise, and then manage the federation server as Tier 0.
• Blocking NTLM now or later: block early for Tier 0 and internet-facing systems, where the risk is highest and the dependency list is short. For the wider estate, follow the audit, exceptions and block sequence and track exceptions with owners and expiry dates.
• Separate admin forest or in-forest tiering: a separate administrative forest adds its own servers, trusts and staff to protect. For most organisations in-forest tiering with PAWs, plus cloud-only accounts for cloud administration, delivers the hierarchy rule with less to run. See the Active Directory and Entra ID Hardening Guide for the broader hardening baseline.

Detection and measurement

• Tier violations: successful logons (event 4624) by Tier 0 accounts on non-Tier 0 hosts.
• NTLM use: 4624 events with authentication package NTLM and 4776 credential validation on domain controllers, plus the enhanced NTLM audit events on supported versions.
• RC4 use: 4768 and 4769 events where ticket or session encryption type is 0x17 (RC4-HMAC).
• Replication rights: directory replication requests from anything other than domain controllers and the Connect server (ATT&CK T1003.006 DCSync).
• Sync and federation changes: changes to Entra Connect configuration, new federation trusts or domains, and role assignments made outside PIM.

See the Active Directory Security Monitoring and Event IDs Guide for collection and detection detail.

Framework mapping

In ISO/IEC 27001:2022 terms the work sits mainly in Annex A 8.2 Privileged access rights and 8.5 Secure authentication; in CIS Controls v8.1 it sits in Control 5 Account Management and Control 6 Access Control Management. See the Zero Trust Identity Guide for the identity pillar as a whole.

Common failure patterns

• Cloud zero trust on a flat forest: Conditional Access and PIM deployed while Domain Admins still log on to servers and workstations, so a single credential theft on-premises reaches the sync server and from there the cloud.
• Sync server run as an application server: Entra Connect patched and administered by the general server team, backed up by a lower-tier system, and reachable with NTLM.
• Synchronised Global Administrators: on-premises accounts kept in cloud admin roles for convenience, which makes a password reset on-premises a cloud takeover.
• RC4 left on service accounts: domain defaults changed but old service accounts keep RC4 because their passwords predate AES keys or their attribute explicitly allows RC4, leaving them open to Kerberoasting. See the Kerberoasting and AS-REP Roasting Defence Guide.
• NTLM blocked without an exception process: a domain-wide block breaks a line-of-business application, the block is reverted and the project stalls. Audit, record owners, then restrict.
• Forgotten federation keys: AD FS left running after migration, still trusted by the tenant, with a token-signing certificate on a server nobody monitors.

Practitioner checklist

• Define the Tier 0 asset list, including Entra Connect, AD FS, AD CS, PTA agent hosts and DC backup systems.
• Remove privileged Entra and Microsoft 365 roles from every synchronised account; use cloud-only admins with PIM.
• Issue PAWs to Tier 0 admins and enforce logon restrictions so Tier 0 credentials never touch lower tiers.
• Apply Microsoft's Connect server hardening: restricted admins, NTLM denied, LAPS, soft match and hard match takeover disabled.
• Roll the Seamless SSO key at least every 30 days, or retire Seamless SSO where devices are Entra joined.
• Make all Tier 0 and privileged service accounts AES-only and remove RC4 from domain defaults.
• Run NTLM auditing, map every source, and block NTLM for Tier 0 first.
• Enforce SMB signing and LDAP signing with channel binding on domain controllers.
• Alert on Tier 0 logons on lower-tier hosts, non-DC replication requests and federation trust changes.
• Plan retirement of on-premises federation and move provisioning and device management to the cloud.

Standards and references

• Microsoft Learn: Enterprise access model
• Microsoft Learn: Protecting Microsoft 365 from on-premises attacks
• Microsoft Learn: Microsoft Entra Connect prerequisites and server hardening
• Microsoft Learn: Microsoft Entra Connect accounts and permissions
• Microsoft Learn: Detect and remediate RC4 usage in Kerberos
• Microsoft Learn: Deprecated features for Windows client (NTLM)
• Microsoft Learn: Seamless single sign-on FAQ
• MITRE ATT&CK: Modify Authentication Process: Hybrid Identity

Related NHI Mgmt Group resources: Zero Trust Identity Guide · Microsoft Entra Connect and Cloud Sync Hardening Guide · NTLM Deprecation and Elimination Guide · Privileged Access Workstations Guide · Zero Trust for OT and ICS Guide