DCSync rights
privilege level the Azure AD Connect sync account typically holds on-premises, making the Connect server a tier-0 target during hybrid migration
Password hash sync
recommended synchronization method for Entra ID migration; enables cloud authentication resilience and leaked-credential detection via Identity Protection
2+ accounts
minimum number of cloud-only break-glass accounts to create before migrating any users; store hardware MFA tokens for these offline
Conditional Access
primary policy enforcement layer in Entra ID that replaces network-perimeter trust; must be configured with MFA and device compliance before go-live

SponsoredRetool

Retool's new app builder is where AI-generated code ships safely

Building apps with AI is easy. Getting them to production safely is another story.

Start building for free today

The Active Directory to Entra ID migration is one of the most security-significant infrastructure changes an organization undertakes. On-premises Active Directory's threat model assumes that attackers must first gain network access to reach your domain controllers. Entra ID's threat model assumes that attackers will attempt to authenticate against your tenant from anywhere in the world, at any time, using credential lists from prior breaches, phishing attacks, and OAuth token theft.

This change in threat model requires deliberate security preparation, not just a technical migration. Organizations that migrate accounts to Entra ID without implementing Conditional Access, disabling legacy authentication, and enabling Identity Protection frequently discover the impact within weeks — through password spray attacks against internet-accessible authentication endpoints that would have been blocked at the network perimeter before migration.

Pre-migration security baseline: what must be done before migrating any accounts

Security configuration in Entra ID must be fully deployed before the first user account is migrated, not retrofitted afterward. The two most critical pre-migration actions are disabling legacy authentication protocols and hardening the Azure AD Connect synchronization server. Legacy authentication protocols such as Basic Auth, IMAP, POP3, and SMTP AUTH cannot perform MFA, which means any account protected by Conditional Access MFA policies remains fully accessible to an attacker who knows the password and targets a legacy protocol endpoint. The Azure AD Connect server bridges on-premises AD and Entra ID during the hybrid period and typically holds DCSync-equivalent rights on both sides, making it the highest-value target in the environment for the duration of migration.

Disable legacy authentication before or during migration

Legacy authentication (Basic Auth, IMAP, POP3, SMTP AUTH, older Office clients) cannot perform MFA. An account protected by MFA is still accessible via legacy authentication protocol — attackers target legacy auth endpoints specifically because they bypass MFA. Disable it in Entra ID: in Conditional Access, create a policy that targets all users, all apps, targets the 'Other clients' client app condition (which matches legacy auth clients), and blocks access. Test in report-only mode first using the Conditional Access What If tool and sign-in log analysis to identify any legitimate legacy auth usage. Common legitimate legacy auth users: shared mailboxes accessed via IMAP, service accounts sending email via SMTP. Replace these with modern authentication or app-specific passwords before enabling the block.

Harden the Azure AD Connect server as a tier-0 asset

The Azure AD Connect synchronization server is one of the highest-privilege systems in a hybrid environment during migration. Its sync account typically has DCSync rights on-premises and write access to Entra ID. Hardening: install AD Connect on a dedicated server that does not run any other services, restrict RDP access to privileged access workstations only, apply EDR software and monitor for DCSync activity from the service account outside of the normal sync window, ensure the server is fully patched before migration begins (unpatched AD Connect servers are a known target for ransomware operators), and configure Entra ID audit logging to alert on any modification to the sync service account permissions.

Post-migration security controls: replacing on-premises equivalents

After accounts are migrated, every on-premises security control that depended on network perimeter trust or domain membership needs a cloud-native replacement. Group Policy Objects do not follow users into Entra ID, so device security settings previously enforced through GPO — password policy, screen lock, BitLocker, Windows Firewall, and antivirus configuration — must be re-implemented using Intune device configuration profiles and Endpoint Security policies. Simultaneously, your SIEM detection rules built around Windows Security event log data need Entra ID sign-in log equivalents, because cloud identity attacks generate different telemetry than on-premises AD attacks. Both replacements must be operational before users who depended on them are migrated.

Replace GPO security policies with Intune configuration profiles

Export your existing GPO settings using the Group Policy Management Console and map each security-relevant setting to its Intune equivalent. Critical settings to map: password complexity and length (Intune device compliance policy), screen lock timeout (Intune device configuration - device restrictions), BitLocker encryption enforcement (Intune endpoint security - disk encryption), Windows Firewall configuration (Intune endpoint security - firewall), and Windows Defender settings (Intune endpoint security - antivirus). Devices that leave the on-premises domain before Intune enrollment is complete will have no security policy applied — coordinate the Intune enrollment timeline with AD unjoin to avoid a policy gap period.

Establish Entra ID detection and response capability

Configure sign-in log forwarding to your SIEM from day one of migration. In the Azure portal: Diagnostic Settings on your Entra ID tenant > send to Log Analytics Workspace or storage account. Configure detection rules for: new Global Administrator assignment (immediate alert, verify out-of-band), OAuth application granted admin consent (review all new app grants), user account added to privileged roles via PIM outside approved maintenance windows, and sign-in risk level 'high' events not blocked by Conditional Access (indicates a gap in your risk-based policy). Test detection by simulating a sign-in from a VPN (should trigger location-based risk) and verify the alert fires before migrating production users.

Free daily briefing

Briefings like this, every morning before 9am.

Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.

The bottom line

Active Directory to Entra ID migration security planning must happen before the first account is moved, not after. The sequence: disable legacy authentication, deploy baseline Conditional Access policies, harden the AD Connect server as a tier-0 asset, create break-glass accounts, enable Identity Protection, and configure SIEM forwarding for Entra ID logs. Only then begin migrating user accounts. During the hybrid period, treat the AD Connect server with the same security rigor as a domain controller — because an attacker who compromises it gets both. After migration, the on-premises network perimeter is replaced by Conditional Access policies, device compliance, and Identity Protection risk-based policies — which together provide stronger access control than network perimeter assumptions, but only if they are configured before migration rather than planned as a future hardening project.

Frequently asked questions

What are the biggest security risks during the hybrid Active Directory and Entra ID transition period?

The hybrid period — when both on-premises AD and Entra ID are authoritative — creates unique security risks. The Azure AD Connect sync account typically requires DCSync rights on the domain controller, making it one of the most privileged accounts in your environment. If an attacker compromises the Azure AD Connect service account or server, they can extract all credential hashes from on-premises AD and may be able to manipulate Entra ID objects. The sync relationship also creates a lateral movement path: compromise on-premises, escalate to the sync account, manipulate Entra ID. Mitigations: harden the Azure AD Connect server as a tier-0 asset (no internet access, EDR agent, privileged access workstation for administration), minimize the sync account's permissions to the minimum required, and monitor sync account activity as a high-priority detection rule.

Should we use password hash sync, pass-through authentication, or federation for Entra ID authentication?

Password hash sync is the recommended method for most organizations. It stores a hash of the on-premises password hash in Entra ID, enabling authentication without calling back to on-premises systems. Resilience advantage: if on-premises AD or the sync server is unavailable (ransomware attack, hardware failure), users can still authenticate to cloud services. Security advantage: password hash sync enables Entra ID Identity Protection's leaked credential detection, which checks synced hashes against Microsoft's database of credentials found in dark web breach data. Pass-through authentication authenticates against on-premises AD in real time, maintaining a dependency on on-premises infrastructure and limiting cloud resilience. Federation (ADFS) is the most complex and failure-prone option and is recommended for migration away from, not toward.

What Entra ID security settings should be configured before any users are migrated?

Before migrating any users: (1) Enable Entra ID Identity Protection and configure risk-based Conditional Access policies (require MFA for medium-risk sign-ins, block high-risk sign-ins). (2) Configure Conditional Access baseline policies: require MFA for all administrators (no exceptions), require MFA for all users accessing sensitive applications, require compliant device for corporate resource access. (3) Disable legacy authentication protocols (Basic Auth, IMAP, POP3, SMTP AUTH) — these bypass MFA and are the source of most Entra ID compromises. (4) Create at least two break-glass accounts (cloud-only, excluded from all Conditional Access, hardware MFA tokens stored securely offline). (5) Enable Entra ID audit logs forwarding to your SIEM before any users authenticate — you want logging active from the first authentication.

What attacks become possible against Entra ID that were not possible against on-premises AD?

Entra ID's authentication endpoints are globally internet-accessible, which expands the threat surface significantly: Password spray attacks against your tenant's authentication endpoint (login.microsoftonline.com) can be launched from anywhere in the world without network access to your environment — on-premises AD required network access to attack. OAuth and OAuth PKCE flow abuse allows attackers to request tokens for Microsoft applications through phishing flows without ever knowing the victim's password. Device code authentication flow phishing (the 'device code phishing' attack) uses the legitimate device code authentication flow to trick victims into authenticating to an attacker's session. Token theft enables persistent access without credentials by stealing OAuth tokens from devices — token lifetime and refresh policies become a critical security control.

How do Conditional Access policies replace on-premises network-perimeter access control?

On-premises AD relies on the network perimeter — only devices physically connected to the corporate network or VPN can authenticate to domain controllers. Entra ID has no network perimeter. Conditional Access replaces this with policy-based access control evaluated at authentication time. Essential Conditional Access policies for migration: (1) Require MFA for all users — replaces network perimeter trust. (2) Require compliant device (Intune enrollment, EDR present, disk encryption) for access to sensitive applications — replaces domain-joined device trust. (3) Block authentication from countries you do not operate in. (4) Require MFA and compliant device for all administrator roles. (5) Block legacy authentication protocols. Implement Conditional Access in report-only mode first, review the impact report, then enable enforcement — this prevents locking out users with valid use cases.

How do we detect and respond to Entra ID-specific attacks after migration?

Entra ID attack detection requires SIEM integration and specific detection rules. Forward Entra ID sign-in logs and audit logs to your SIEM (Microsoft Sentinel, Splunk, or equivalent). Key detection rules: (1) Impossible travel: sign-ins from two countries within a timeframe that makes physical travel impossible. (2) Sign-ins from Tor or anonymous proxy IPs. (3) New admin role assignment: any Entra ID admin role added to any user. (4) New application consent grant: any OAuth application granted access to your tenant. (5) Bulk download by a user who has never downloaded at volume before. (6) Sign-in from a device that is not Entra ID registered or Intune enrolled. Enable Entra ID Identity Protection which auto-generates risk scores for these signals and feeds them into Conditional Access risk-based policies.

What happens to on-premises group policies and security controls after migrating to Entra ID?

Group Policy Objects (GPOs) applied by on-premises Active Directory do not carry over to Entra ID — Entra ID uses Intune configuration profiles and compliance policies to replace GPO-based device management. Plan the replacement mapping before migration: GPO security settings (password policy, screen lock, BitLocker enforcement) map to Intune device configuration profiles and Endpoint Security policies. GPO software deployment maps to Intune application deployment. GPO-based authentication (Kerberos constrained delegation) may need to be replaced with Entra ID application proxy or modern authentication protocols for on-premises applications. Applications that authenticate using Kerberos or NTLM against on-premises AD will not automatically work with Entra ID — catalog all applications and their authentication methods before migration to identify those requiring remediation.

Sources & references

  1. Microsoft Entra ID Migration Guide
  2. Microsoft Security Best Practices: Identity
  3. CISA Guidance on Microsoft 365 Security
  4. Entra ID Identity Protection Documentation

Free resources

25
Free download

Critical CVE Reference Card 2025–2026

25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.

No spam. Unsubscribe anytime.

Free download

Ransomware Incident Response Playbook

Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.

No spam. Unsubscribe anytime.

Free newsletter

Get threat intel before your inbox does.

50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.

Unsubscribe anytime. We never sell your data.

Eric Bang
Author

Founder & Cybersecurity Evangelist, Decryption Digest

Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.

Black Hat Giveaway

Win a $2,495 Black Hat pass.

Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.

Joins Decryption Digest daily briefing. Unsubscribe anytime.

Giveaway: Black Hat USA 2026 Full-Access Pass ($2,495 value)

Details →
Daily Briefing

Subscribe to enter the giveaway

Every subscriber is automatically entered. You also get daily threat intel every morning: zero-days, ransomware, and nation-state campaigns. Free. No spam.

Already subscribed? You're already entered.

Giveaway

Win a $2,495 Black Hat USA 2026 pass.