Executive Summary

Full report

On this page

Migrating on-prem AD DS to Azure AD (Entra ID) and Azure AD Domain Services (AAD DS) requires a hybrid identity and network design. We recommend deploying Azure AD Connect to synchronize identities (using Password Hash Sync) into a new Azure AD tenant, and enabling Azure AD Domain Services for legacy NTLM/Kerberos/LDAP needs. Network connectivity (Site-to-Site VPN or ExpressRoute) must be established between on-premises and Azure. Group Policy Objects (GPOs) are not natively supported by Azure AD, but AAD DS does provide GPO support within the managed domain. Legacy applications can authenticate against Azure AD DS (Kerberos/NTLM/LDAP) or be migrated to modern auth (OAuth/SAML via App Proxy). Azure AD Premium (P1 or P2) licenses enable Conditional Access, MFA and Privileged Identity Management. Critical data (AD DS state) should be backed up before decommissioning on-prem DCs; Azure AD DS Premium offers daily backups. Monitoring should use Azure AD logs and AAD DS diagnostics to Azure Monitor. We estimate key costs (for 500 users): ~\$3000/mo for Azure AD P1, \$110/mo for AAD DS, plus connectivity (VPN ~\$150/mo vs ExpressRoute ~\$2500–\$3000/mo) and any Windows Server CALs (≈\$40/CAL if on-prem remains).

This plan covers identity synchronization architectures, network options (VPN vs. ExpressRoute), AAD DS deployment and limits, GPO migration strategies, legacy app auth options (NTLM/Kerberos/LDAP), service-account handling, DNS design, security features (CA, MFA, PIM), backup/DR, monitoring, cost/licensing, detailed migration steps, testing/cutover checklist, and risk mitigation. All claims are backed by Microsoft documentation and recent authoritative sources.

Current State and Objectives

• On-premises: Windows Server 2016 Active Directory (AD DS) with multiple domain controllers, ~500 users and 200 devices.
• Goal: Migrate to Azure cloud. Implement Azure AD for cloud identity (Entra ID) and Azure AD Domain Services for legacy domain features, while preserving authentication, GPOs (as applicable), and app compatibility. Decommission on-prem AD when safe.

Key prerequisites include provisioning an Azure subscription and new Azure AD tenant, network connectivity between on-prem and Azure, and appropriate Azure AD licenses (minimum Entra ID Premium P1 for Conditional Access; P2 for PIM). Users and groups will be synchronized via Azure AD Connect. Legacy on-prem identities can continue signing in via Azure AD DS once synced (Kerberos/NTLM support).

Hybrid Network Connectivity (VPN vs ExpressRoute)

A reliable hybrid connection is essential. Below is a comparison:

ExpressRoute provides a more predictable and private link (data does not traverse the public Internet) and cheaper per-GB egress cost than VPN Internet egress. If large data flows or strict performance/SLA is required, ExpressRoute is preferred; otherwise a VPN gateway (Basic or VpnGw1/VpnGw2) is more cost-effective.

graph LR
  subgraph On-Premises
    ONPREMDC((On-Prem AD\ Domain Controllers))
    ONPREMApps((On-Prem\ Legacy Apps))
  end
  subgraph Azure
    AAD[Azure AD\ (Entra ID)]
    AADConnect((Azure AD\ Connect Server))
    AADDS((Azure AD DS\ Managed Domain))
    AzureApps((Azure Domain-joined\ Apps))
    VPNGW([VPN Gateway])
    EXR([ExpressRoute Circuit])
  end
  ONPREMDC -->|Sync & Auth| AADConnect
  AADConnect -->|Sync| AAD
  AAD -->|Provision| AADDS
  ONPREMDC -->|Kerberos/NTLM| ONPREMApps
  AADDS -->|Kerberos/LDAP| AzureApps
  ONPREMApps -- VPN/ER --> AzureApps
  ONPREMDC -.->|Site-to-Site VPN/ExpressRoute| AADDS

Figure: Hybrid topology. On-prem AD Connect syncs identities to Azure AD, which in turn provisions Azure AD DS. On-prem and Azure networks connect via VPN or ExpressRoute.

Azure AD Connect and Identity Sync Architecture

We will deploy Azure AD Connect (currently “Microsoft Entra Connect”) to synchronize on-prem AD accounts into Azure AD. The recommended topology is a single-forest, single-tenant installation (our scenario: one AD forest, one Azure AD). If there were multiple forests, a single Connect server could still sync them (with proper trusts). We will enable Password Hash Synchronization (PHS) since it is simplest to implement, requires minimal on-prem infrastructure, and is required for Azure AD DS provisioning. (Note: Pass-Through Authentication or AD FS federation could be used for pure on-prem auth scenarios, but neither works with AAD DS’s need for password hashes.)

Below is a high-level comparison of sign-in methods:

Sources: Microsoft docs outline that Azure AD Domain Services requires password hash sync. In general, PHS is simplest and allows sign-in even if on-prem is down; PTA/ADFS preserve on-prem policies immediately.

Azure AD Domain Services (Managed Domain)

Azure AD Domain Services (AAD DS) provides a managed AD-compatible domain in Azure. It supports legacy features: domain join, LDAP bind, Kerberos/NTLM authentication, and Group Policy within the managed domain. This lets you “lift-and-shift” on-premises AD-dependent applications to Azure. Key points about AAD DS:

• Automatic Setup: You enable AAD DS in the Azure portal, which deploys two managed domain controllers (HA across zones) within a subnet. These are not accessible via RDP.
• Sync from Azure AD: AAD DS syncs users/groups from Azure AD. Because it needs AD password hashes, we must use PHS (or PDH) on Azure AD Connect.
• Group Policy: AAD DS provides GPO support inside the managed domain. You can create and edit GPOs for the built-in “AADDC Computers/Users” OUs. However, on-prem GPOs are not automatically imported. In hybrid setups, you must manually recreate or import policies into AAD DS. (Alternatively, consider using Microsoft Intune for device policies.)
• Schema and OUs: The schema of AAD DS is fixed and cannot be extended. Synchronized users/groups cannot be modified (they inherit from Azure AD). You get a built-in AADDC Users and AADDC Computers OU. Custom OUs can be created for things like service accounts.
• Trusted Forests: AAD DS (Enterprise/Premium tiers) supports one-way trusts to other forests (not needed in our single-forest case).
• Limitations: No Domain Admin privileges (you use the AAD DC Administrators group for management). You cannot join on-prem machines to AAD DS (only VMs in Azure). AAD DS cannot be directly extended to on-prem.

Use AAD DS for workloads that cannot use cloud-only authentication (e.g. legacy line-of-business apps requiring LDAP/Kerberos/NTLM or computer/domain group policies). All changes in Azure AD (user create/modify) will synchronize to AAD DS (though there is ~30 min sync interval by default).

Group Policy Migration Strategy

Because Azure AD itself has no GPO mechanism, existing on-prem GPOs must be re-addressed. Options include:

• Recreate GPOs in AAD DS: Use the Group Policy Management tools on a VM joined to the AAD DS domain. There are two built-in GPOs (“AADDC Computers” and “AADDC Users”) which you can edit or add new GPOs. On-prem GPOs aren’t synced, so migration may involve backing up GPOs from on-prem and manually importing them into AAD DS (or re-creating equivalent policies).
• Intune/MDM: Many on-prem policies can be replaced with Intune Configuration Profiles for domain-joined or Azure AD–joined devices. This is a modernization opportunity.
• Hybrid Join & Co-management: If devices are hybrid-joined and using Config Manager, you can gradually shift management policies to cloud-based tools.

In summary, plan a GPO audit: drop any on-prem-only policies, migrate essential ones to AAD DS or Intune, and verify on test machines.

Legacy Application Authentication Options

For applications depending on Kerberos, NTLM or LDAP (especially older apps that cannot use modern OAuth):

• Azure AD DS (Managed Domain): As noted, AAD DS provides support for LDAP binds, Kerberos and NTLM in Azure. You can migrate such apps to Azure VMs joined to the AAD DS domain. For example, an on-prem IIS app pool running under a service account can continue to use that account in Azure AD DS.
• Azure AD Kerberos (Hybrid Kerberos): A new option is Azure AD Kerberos, enabling cloud Kerberos for Windows Hello Hybrid-Joined devices. This requires hybrid join of endpoints. It’s typically used for Azure-based services needing Kerberos without full AD DS.
• Azure AD Application Proxy / Modern Auth: If feasible, modernize the app to use SAML/OIDC via Azure AD (with Application Proxy for on-prem deployment). This is the “preferred” future direction.
• Windows 365 / Cloud PC: As a last resort for legacy on-prem apps, provide access via Azure Virtual Desktop or Cloud PC while backend remains unchanged.

The AAD DS approach is often simplest for “lift-and-shift” of AD-integrated apps. Ensure the app servers in Azure use domain accounts from AAD DS. If the on-prem app uses local service accounts, recreate analogous accounts in AAD DS (in a custom OU).

Service and Managed Accounts Handling

On-prem service accounts (standalone AD accounts or gMSAs) can be migrated to Azure AD DS. In fact, Azure AD DS supports gMSA-style managed accounts. You have two choices: sync the existing on-prem service accounts into Azure AD (they’ll appear in AAD DS), or create new service accounts within AAD DS (in a custom OU, since built-in OUs are locked down). The apps will authenticate as before to database or other tiers. Note that the Kerberos key distribution center (KDC) in AAD DS will service these accounts. For cloud workloads (e.g. Azure VMs), consider using Azure Managed Identities or service principals instead of legacy passwords.

DNS and Name Resolution

A robust hybrid DNS design is critical so Azure resources can resolve on-prem names and vice versa. Consider:

• On-premises DNS: Keep at least one on-prem DNS server active. Configure it with a conditional forwarder for the AAD DS managed domain (e.g. yourdomain.onmicrosoft.com) pointing to the Azure DNS IPs provided by AAD DS. This lets on-prem resolve Azure-joined machine names.
• Azure DNS (Virtual Network): Configure your Azure VNet’s DNS servers to include the on-prem DNS IPs (via VPN/ER) so Azure VMs and AAD DS controllers can resolve on-prem AD names. Azure AD DS provides an IP-based DNS service; ensure your VNet’s DNS settings include the AAD DS DNS IP (shown in the AAD DS overview).
• Azure Private DNS / Resolver: For a fully integrated solution, use Azure DNS Private Resolver or Azure Firewall DNS Proxy to route DNS queries between networks (as shown in Microsoft’s hybrid DNS architecture).

Without proper DNS, domain join and authentication will fail. Test name resolution in both directions early.

Security, Conditional Access and MFA

After migration, use Azure AD Premium features to enhance security:

• Conditional Access (CA): Implement CA policies (e.g. block legacy auth, require MFA) to protect cloud apps. CA requires Azure AD P1 or P2 licensing.
• Multi-Factor Authentication: Enable MFA for administrators and optionally all users. Use security defaults or custom CA policies.
• Privileged Identity Management (PIM): In Azure AD P2, use PIM to limit standing privileges (just-in-time elevation) for Azure roles, replacing permanent Domain Admin creds.
• Password Protection: Deploy Azure AD Password Protection on any remaining on-prem DCs to block weak passwords.
• Audit Logging: Ensure Sign-in and Audit logs in Azure AD are retained (P1/P2) and forwarded to a SIEM. Enable AAD DS security and DNS audit logs to an Azure Log Analytics workspace. You can then detect suspicious Kerberos/LDAPS failures.

Backup and Disaster Recovery

• On-Prem AD: Before decommissioning, ensure you have system-state backups of on-prem DCs and ADDS. For quick rollback, maintain at least one DC in site (or in Azure VM) until cutover is stable.
• Azure AD: The Azure AD service itself is multi-region and Microsoft-managed (99.9% SLA). You cannot “backup” Azure AD, but you can export user lists or enable Azure AD Connect staging mode as a standby.
• Azure AD DS: AAD DS Premium includes automated backups (daily, 7-day retention). For critical servers joined to AAD DS, use regular VM backups.
• Recovery Plan: Document the steps to restore either environment (e.g. if AAD DS misconfigures, you could disable AAD DS and revert apps to use on-prem domain join). Keep the on-prem AD alive until after a stable cutover.

Monitoring and Logging

• Azure AD Connect Health: If using Pass-Through or Federation, install Connect Health agents to monitor sync and sign-in errors. For pure PHS, use Azure AD sign-in logs.
• Azure AD (Entra ID) Logs: Enable and review Sign-in and Audit logs in Azure AD (requires P1/P2). Use Azure Monitor or Log Analytics to retain logs longer.
• Azure AD DS Diagnostics: Enable Diagnostic Settings on the AAD DS resource to stream Security and DNS events to a Log Analytics workspace. This includes account lockouts, LDAP failures, etc. Azure Workbooks can visualize these logs.
• Network Monitoring: Monitor VPN/ExpressRoute gateway health and bandwidth. Use Azure Network Watcher to track connectivity (if needed).

Licensing and Cost Estimates

Assumptions: All 500 users require Azure AD identities (cloud-only) after migration. CAL cost is one-time if needed. Intune or Endpoint Manager licenses (≈\$8–\$10/user) may be required if replacing GPOs. On-prem DCs would require existing Windows Server licensing and CALs (unless decommissioned). Traffic volumes and circuit speeds can significantly affect ExpressRoute costs.

Migration Steps (Proposed Plan)

1. Discovery & Planning: Inventory on-prem AD: OUs, user/group counts, GPOs, service accounts, applications (SSO, LDAP/Kerberos/NTLM, etc.), and network layout. Define Azure AD naming, domains, and required licenses. Decide on VPN vs ExpressRoute. Document current authentication flows (password vs AD FS).
2. Azure Setup: Create Azure subscription and new Azure AD tenant (with *.onmicrosoft.com domain). Verify any custom domain in Azure AD if needed. Assign Global Admins.
3. Establish Network: Configure Azure Virtual Network and Site-to-Site VPN (or order ExpressRoute). Ensure routing between on-prem AD subnet and Azure VNet. Test connectivity (ping DCs, DNS).
4. Deploy Azure AD Connect: Install on-prem AD Connect server (dedicated VM). Choose custom install to enable PHS (and optionally Seamless SSO). Sync a small OU for pilot users first. Verify users appear in Azure AD.
5. Configure Azure AD Services:

• If using ADFS/Federation, prepare AD FS farm. (If not, skip.)
• Setup Conditional Access policies and MFA for admins.
• Enable Azure AD Connect Health (optional).

1. Deploy Azure AD Domain Services: In Azure, enable AAD DS for the chosen domain (e.g. contoso.com). Select VNet and subnet. After deployment, note the managed domain DNS name and IPs.
2. Join VM for Management: Spin up a Windows Server VM in the AAD DS-connected VNet; domain-join it to AAD DS. Install RSAT (ADUC, GPMC) for management.
3. Sync Accounts to AAD DS: Ensure Azure AD Connect is syncing password hashes (on next full sync). Azure AD DS will now have synced users/computers.
4. Group Policy Migration: Back up critical on-prem GPOs. In the AAD DS management VM, use GPMC to create new GPOs or import backed-up GPOs into the managed domain. Test application of policies on a domain-joined test VM.
5. Legacy App Cutover (Pilot): For one or two legacy apps, migrate them to Azure VMs joined to AAD DS. Reconfigure app authentication (use AAD DS domain accounts for NTLM/Kerberos). Test functionality.
6. User Pilot: Pick a small user group to test sign-on to Azure AD (cloud apps) and login to any new Windows VMs joined to AAD DS. Confirm password sync and login work.
7. Monitor & Harden: Verify logs (sign-in, audit, AAD DS) are flowing to Log Analytics. Tweak policies. Ensure Conditional Access works.
8. Full Sync & Deployment: Once pilots succeed, enable sync for all users. Domain-join production servers in Azure, migrate remaining apps. Gradually disable on-prem features (e.g. move DNS management to Azure DNS if planned).
9. Cutover: Update user computers to be joined to Azure AD DS (if desired) or hybrid-join. Redirect authentication to Azure AD for cloud apps. Officially switch production workloads to use Azure identities.
10. Decommission On-Prem: After validation, demote on-prem DCs and retire them (once no dependency remains).

At each stage, have a rollback plan: e.g., if sync causes issues, disable Azure AD Connect; if an app fails on Azure AD DS, re-point to on-prem AD; keep old AD operational until final cutover.

Cutover Checklist (Key Tests)

• [ ] User Sign-on: Users can log into Azure AD (portal, Office 365) with current passwords.
• [ ] Password Changes: New password changes on one side (cloud or on-prem) sync correctly.
• [ ] Synchronized Users: All AD user accounts/groups appear in Azure AD DS (check using RSAT).
• [ ] Service Accounts: Any on-prem service accounts are present in Azure AD DS and work in app pools.
• [ ] GPO Effect: Policies applied in AAD DS are enforced on Azure-joined VMs.
• [ ] Legacy Apps: Each legacy application has tested authentication (Kerberos/NTLM/LDAP) against Azure AD DS.
• [ ] Network & DNS: Azure VMs can resolve on-prem hostnames, and on-prem servers resolve Azure hostnames.
• [ ] Security: Conditional Access policies and MFA prompts are working as intended.
• [ ] Monitoring: Logs are being collected (Azure AD sign-in, AAD DS audit).
• [ ] Backup: On-prem AD backups are completed; AAD DS backup retention verified.

Risk Register and Mitigations

Each risk should have a clear rollback. For example, if AAD DS fails, you can drop that service and point apps back to on-prem AD. Keep one on-prem DC as a fallback credential store.

Timeline Estimate

For a 500-user organization, a 6–12 week phased project is typical (depending on complexity). A sample timeline:

• Weeks 1–2: Assessment & design (inventory, network prep, license procurement).
• Weeks 3–4: Setup Azure infrastructure (VPN/ER, Azure AD tenant, AD Connect pilot, AAD DS deployment).
• Weeks 5–7: Pilot migrations (sync a subset of users, deploy AAD DS GPO, test a few apps/users).
• Weeks 8–10: Full roll-out (sync remaining users, join servers, migrate all apps, enable security policies).
• Weeks 11–12: Final cutover (switch remaining workloads, decommission on-prem DCs, freeze legacy AD).

Actual duration will vary. Allocate time for user training and helpdesk support during change.

Recommended Azure Services & Configurations

• Azure AD (Entra ID) – Baseline identity as a cloud service. Use Premium P1/P2 licenses for advanced security.
• Azure AD Connect – For identity sync. Deploy with Staging Mode backup for redundancy.
• Azure AD Domain Services – The managed domain in Azure. Choose the SKU (Standard vs Premium) based on user/app volume (500 users fits Standard).
• Virtual Network & VPN Gateway (or ExpressRoute) – For hybrid connectivity. Place AAD DS subnet in dedicated vNet, and peer with application VNet if separate.
• Azure DNS / DNS Private Resolver – Configure DNS resolution as above.
• Azure Virtual Machines – For management VM (with RSAT) and any lifted applications. Join these VMs to AAD DS.
• Azure Backup – (Optional) Use Azure Backup for any critical VMs or file shares.
• Azure Monitor & Log Analytics – Collect logs (Azure AD sign-ins, Azure AD DS logs via diagnostic settings) and set alerts.
• Azure Security Center / Defender for Cloud – Optional layer to monitor for threats in Azure.

Each service should be configured with least privilege: e.g., only designated admins in the AAD DC Administrators group for AAD DS. Apply Azure RBAC roles (Global Admin, Security Admin, etc.) following the principle of least privilege and use PIM.

Conclusion and Next Steps

Migrating AD to Azure AD + AD DS is a hybrid solution: Azure AD handles cloud identity and modern auth, while Azure AD DS provides on-prem AD compatibility for legacy workloads. Successful migration demands careful planning of synchronization, network, and security. Follow best practices (pilot first, ensure backups, communicate with users) and use Microsoft’s own guides as cited. After migration, continuously monitor with Azure logs and refine Conditional Access.

Sources: Authoritative Microsoft documentation and expert articles were used throughout. (Additional references and diagrams are provided inline.)