Transition to the cloud
After you align your organization toward halting growth of the Active Directory footprint, you can focus on moving the existing on-premises workloads to Microsoft Entra ID. This article describes the various migration workstreams. You can execute the workstreams in this article based on your priorities and resources.
A typical migration workstream has the following stages:
Discover: Find out what you currently have in your environment.
Pilot: Deploy new cloud capabilities to a small subset of users, applications, or devices, depending on the workstream.
Scale out: Expand the pilot to complete the transition of a capability to the cloud.
Cut over (when applicable): Stop using the old on-premises workload.
Users and groups
Enable password self-service
We recommend a passwordless environment. Until then, you can migrate password self-service workflows from on-premises systems to Microsoft Entra ID to simplify your environment. Microsoft Entra ID self-service password reset (SSPR) gives users the ability to change or reset their password, with no administrator or help desk involvement.
To enable self-service capabilities, choose the appropriate authentication methods for your organization. After the authentication methods are updated, you can enable user self-service password capability for your Microsoft Entra authentication environment. For deployment guidance, see Deployment considerations for Microsoft Entra self-service password reset.
Additional considerations include:
- Deploy Microsoft Entra Password Protection in a subset of domain controllers with Audit mode to gather information about the impact of modern policies.
- Gradually enable combined registration for SSPR and Microsoft Entra multifactor authentication. For example, roll out by region, subsidiary, or department for all users.
- Go through a cycle of password change for all users to flush out weak passwords. After the cycle is complete, implement the policy expiration time.
- Switch the Password Protection configuration in the domain controllers that have the mode set to Enforced. For more information, see Enable on-premises Microsoft Entra Password Protection.
Note
- We recommend user communications and evangelizing for a smooth deployment. See Sample SSPR rollout materials.
- If you use Microsoft Entra ID Protection, enable password reset as a control in Conditional Access policies for users marked as risky.
Move management of groups
To transform groups and distribution lists:
For security groups, use your existing business logic that assigns users to security groups. Migrate the logic and capability to Microsoft Entra ID and dynamic membership groups.
For self-managed group capabilities provided by Microsoft Identity Manager, replace the capability with self-service group management.
You can convert distribution lists to Microsoft 365 groups in Outlook. This approach is a great way to give your organization's distribution lists all the features and functionality of Microsoft 365 groups.
Upgrade your distribution lists to Microsoft 365 groups in Outlook and decommission your on-premises Exchange server.
Move provisioning of users and groups to applications
You can simplify your environment by removing application provisioning flows from on-premises identity management (IDM) systems such as Microsoft Identity Manager. Based on your application discovery, categorize your application based on the following characteristics:
Applications in your environment that have a provisioning integration with the Microsoft Entra application gallery.
Applications that aren't in the gallery but support the SCIM 2.0 protocol. These applications are natively compatible with the Microsoft Entra cloud provisioning service.
On-premises applications that have an ECMA connector available. These applications can be integrated with Microsoft Entra on-premises application provisioning.
For more information, check Plan an automatic user-provisioning deployment for Microsoft Entra ID.
Move to cloud HR provisioning
You can reduce your on-premises footprint by moving the HR provisioning workflows from on-premises IDM systems, such as Microsoft Identity Manager, to Microsoft Entra ID. Two account types are available for Microsoft Entra cloud HR provisioning:
For new employees who are exclusively using applications that use Microsoft Entra ID, you can choose to provision cloud-only accounts. This provisioning helps you contain the footprint of Active Directory.
For new employees who need access to applications that have dependency on Active Directory, you can provision hybrid accounts.
Microsoft Entra cloud HR provisioning can also manage Active Directory accounts for existing employees. For more information, see Plan cloud HR application to Microsoft Entra user provisioning and Plan the deployment project.
Move lifecycle workflows
Evaluate your existing joiner/mover/leaver workflows and processes for applicability and relevance to your Microsoft Entra cloud environment. You can then simplify these workflows and create new ones using lifecycle workflows.
Move external identity management
If your organization provisions accounts in Active Directory or other on-premises directories for external identities such as vendors, contractors, or consultants, you can simplify your environment by managing those third-party user objects natively in the cloud. Here are some possibilities:
For new external users, use Microsoft Entra External ID, which stops the Active Directory footprint of users.
For existing Active Directory accounts that you provision for external identities, you can remove the overhead of managing local credentials (for example, passwords) by configuring them for business-to-business (B2B) collaboration. Follow the steps in Invite internal users to B2B collaboration.
Use Microsoft Entra entitlement management to grant access to applications and resources. Most companies have dedicated systems and workflows for this purpose that you can now move out of on-premises tools.
Use access reviews to remove access rights and/or external identities that are no longer needed.
Devices
Move non-Windows workstations
You can integrate non-Windows workstations with Microsoft Entra ID to enhance the user experience and to benefit from cloud-based security features such as Conditional Access.
For macOS:
Register macOS to Microsoft Entra ID and enroll/manage them by using a mobile device management solution.
Deploy the Microsoft Enterprise SSO (single sign-on) plug-in for Apple devices.
Plan to deploy Platform SSO for macOS 13.
For Linux, you can sign in to a Linux virtual machine (VM) by using Microsoft Entra credentials.
Replace other Windows versions for workstations
If you have the following operating systems on workstations, consider upgrading to the latest versions to benefit from cloud-native management (Microsoft Entra join and unified endpoint management):
Windows 7 or 8.x
Windows Server
VDI solution
This project has two primary initiatives:
New deployments: Deploy a cloud-managed virtual desktop infrastructure (VDI) solution, such as Windows 365 or Azure Virtual Desktop, that doesn't require on-premises Active Directory.
Existing deployments: If your existing VDI deployment is dependent on Active Directory, use business objectives and goals to determine whether you maintain the solution or migrate it to Microsoft Entra ID.
For more information, see:
Applications
To help maintain a secure environment, Microsoft Entra ID supports modern authentication protocols. To transition application authentication from Active Directory to Microsoft Entra ID, you must:
Determine which applications can migrate to Microsoft Entra ID with no modification.
Determine which applications have an upgrade path that enables you to migrate with an upgrade.
Determine which applications require replacement or significant code changes to migrate.
The outcome of your application discovery initiative is to create a prioritized list for migrating your application portfolio. The list contains applications that:
Require an upgrade or update to the software, and an upgrade path is available.
Require an upgrade or update to the software, but an upgrade path isn't available.
By using the list, you can further evaluate the applications that don't have an existing upgrade path. Determine whether business value warrants updating the software or if it should be retired. If the software should be retired, decide whether you need a replacement.
Based on the results, you might redesign aspects of your transformation from Active Directory to Microsoft Entra ID. There are approaches that you can use to extend on-premises Active Directory to Azure infrastructure as a service (IaaS) (lift and shift) for applications with unsupported authentication protocols. We recommend that you set a policy that requires an exception to use this approach.
Application discovery
After you've segmented your app portfolio, you can prioritize migration based on business value and business priority. You can use tools to create or refresh your app inventory.
There are three main ways to categorize your apps:
Modern authentication apps: These applications use modern authentication protocols (such as OIDC, OAuth2, SAML, or WS-Federation) or that use a federation service such as Active Directory Federation Services (AD FS).
Web access management (WAM) tools: These applications use headers, cookies, and similar techniques for SSO. These apps typically require a WAM identity provider, such as Symantec SiteMinder.
Legacy apps: These applications use legacy protocols such as Kerberos, LDAP, Radius, Remote Desktop, and NTLM (not recommended).
Microsoft Entra ID can be used with each type of application to provide levels of functionality that results in different migration strategies, complexity, and trade-offs. Some organizations have an application inventory that can be used as a discovery baseline. (It's common that this inventory isn't complete or updated.)
To discover modern authentication apps:
If you're using AD FS, use the AD FS application activity report.
If you're using a different identity provider, use the logs and configuration.
The following tools can help you discover applications that use LDAP:
Event1644Reader: Sample tool for collecting data on LDAP queries made to domain controllers by using field engineering logs.
Microsoft 365 Defender for Identity: Security solution that uses a sign-in operations monitoring capability. (Note that it captures binds by using LDAP, not Secure LDAP.)
PSLDAPQueryLogging: GitHub tool for reporting on LDAP queries.
Migrate AD FS or other federation services
When you plan your migration to Microsoft Entra ID, consider migrating the apps that use modern authentication protocols (such as SAML and OpenID Connect) first. You can reconfigure these apps to authenticate with Microsoft Entra ID either via a built-in connector from the Azure App Gallery or via registration in Microsoft Entra ID.
After you move SaaS applications that were federated to Microsoft Entra ID, there are a few steps to decommission the on-premises federation system:
Move remote access to internal applications, if you're using Microsoft Entra application proxy
Important
If you're using other features, verify that those services are relocated before you decommission Active Directory Federation Services.
Move WAM authentication apps
This project focuses on migrating SSO capability from WAM systems to Microsoft Entra ID. To learn more, see Migrate applications from Symantec SiteMinder to Microsoft Entra ID.
Define an application server management strategy
In terms of infrastructure management, on-premises environments often use a combination of Group Policy objects (GPOs) and Microsoft Configuration Manager features to segment management duties. For example, duties can be segmented into security policy management, update management, configuration management, and monitoring.
Active Directory is for on-premises IT environments, and Microsoft Entra ID is for cloud-based IT environments. One-to-one parity of features isn't present here, so you can manage application servers in several ways.
For example, Azure Arc helps bring many of the features that exist in Active Directory together into a single view when you use Microsoft Entra ID for identity and access management (IAM). You can also use Microsoft Entra Domain Services to domain-join servers in Microsoft Entra ID, especially when you want those servers to use GPOs for specific business or technical reasons.
Use the following table to determine what Azure-based tools you can use to replace the on-premises environment:
| Management area | On-premises (Active Directory) feature | Equivalent Microsoft Entra feature |
|---|---|---|
| Security policy management | GPO, Microsoft Configuration Manager | Microsoft 365 Defender for Cloud |
| Update management | Microsoft Configuration Manager, Windows Server Update Services | Azure Automation Update Management |
| Configuration management | GPO, Microsoft Configuration Manager | Azure Automation State Configuration |
| Monitoring | System Center Operations Manager | Azure Monitor Log Analytics |
Here's more information that you can use for application server management:
Azure Arc enables Azure features for non-Azure VMs. For example, you can use it to get Azure features for Windows Server when it's used on-premises or on Amazon Web Services, or authenticate to Linux machines with SSH.
If you must wait to migrate or perform a partial migration, you can use GPOs with Microsoft Entra Domain Services.
If you require management of application servers with Microsoft Configuration Manager, you can't achieve this requirement by using Microsoft Entra Domain Services. Microsoft Configuration Manager isn't supported to run in a Microsoft Entra Domain Services environment. Instead, you need to extend your on-premises Active Directory instance to a domain controller running on an Azure VM. Or, you need to deploy a new Active Directory instance to an Azure IaaS virtual network.
Define the migration strategy for legacy applications
Legacy applications have dependencies like these to Active Directory:
User authentication and authorization: Kerberos, NTLM, LDAP bind, ACLs.
Access to directory data: LDAP queries, schema extensions, read/write of directory objects.
Server management: As determined by the server management strategy.
To reduce or eliminate those dependencies, you have three main approaches.
Approach 1
In the most preferred approach, you undertake projects to migrate from legacy applications to SaaS alternatives that use modern authentication. Have the SaaS alternatives authenticate to Microsoft Entra ID directly:
Deploy Microsoft Entra Domain Services into an Azure virtual network and extend the schema to incorporate additional attributes needed by the applications.
Lift and shift legacy apps to VMs on the Azure virtual network that are domain-joined to Microsoft Entra Domain Services.
Publish legacy apps to the cloud by using Microsoft Entra application proxy or a secure hybrid access partner.
As legacy apps retire through attrition, eventually decommission Microsoft Entra Domain Services running in the Azure virtual network.
Note
- Use Microsoft Entra Domain Services if the dependencies are aligned with common deployment scenarios for Microsoft Entra Domain Services.
- To validate if Microsoft Entra Domain Services is a good fit, you might use tools like Service Map in Azure Marketplace and automatic dependency mapping with Service Map and Live Maps.
- Validate that your SQL Server instantiations can be migrated to a different domain. If your SQL service is running in virtual machines, use this guidance.
Approach 2
If the first approach isn't possible and an application has a strong dependency on Active Directory, you can extend on-premises Active Directory to Azure IaaS.
You can replatform to support modern serverless hosting--for example, use platform as a service (PaaS). Or, you can update the code to support modern authentication. You can also enable the app to integrate with Microsoft Entra ID directly. Learn about Microsoft Authentication Library in the Microsoft identity platform.
Connect an Azure virtual network to the on-premises network via virtual private network (VPN) or Azure ExpressRoute.
Deploy new domain controllers for the on-premises Active Directory instance as virtual machines into the Azure virtual network.
Lift and shift legacy apps to VMs on the Azure virtual network that are domain joined.
Publish legacy apps to the cloud by using Microsoft Entra application proxy or a secure hybrid access partner.
Eventually, decommission the on-premises Active Directory infrastructure and run Active Directory in the Azure virtual network entirely.
As legacy apps retire through attrition, eventually decommission the Active Directory instance running in the Azure virtual network.
Approach 3
If the first migration isn't possible and an application has a strong dependency on Active Directory, you can deploy a new Active Directory instance to Azure IaaS. Leave the applications as legacy applications for the foreseeable future, or sunset them when the opportunity arises.
This approach enables you to decouple the app from the existing Active Directory instance to reduce surface area. We recommend that you consider it only as a last resort.
Deploy a new Active Directory instance as virtual machines in an Azure virtual network.
Lift and shift legacy apps to VMs on the Azure virtual network that are domain-joined to the new Active Directory instance.
Publish legacy apps to the cloud by using Microsoft Entra application proxy or a secure hybrid access partner.
As legacy apps retire through attrition, eventually decommission the Active Directory instance running in the Azure virtual network.
Comparison of strategies
| Strategy | Microsoft Entra Domain Services | Extend Active Directory to IaaS | Independent Active Directory instance in IaaS |
|---|---|---|---|
| Decoupling from on-premises Active Directory | Yes | No | Yes |
| Allowing schema extensions | No | Yes | Yes |
| Full administrative control | No | Yes | Yes |
| Potential reconfiguration of apps required (for example, ACLs or authorization) | Yes | No | Yes |
Move VPN authentication
This project focuses on moving your VPN authentication to Microsoft Entra ID. It's important to know that different configurations are available for VPN gateway connections. You need to determine which configuration best fits your needs. For more information on designing a solution, see VPN gateway design.
Here are key points about usage of Microsoft Entra ID for VPN authentication:
Check if your VPN providers support modern authentication. For example:
For Windows 10 devices, consider integrating Microsoft Entra support into the built-in VPN client.
After you evaluate this scenario, you can implement a solution to remove your dependency with on-premises to authenticate to VPN.
Move remote access to internal applications
To simplify your environment, you can use Microsoft Entra application proxy or secure hybrid access partners to provide remote access. This allows you to remove the dependency on on-premises reverse proxy solutions.
It's important to mention that enabling remote access to an application by using the preceding technologies is an interim step. You need to do more work to completely decouple the application from Active Directory.
Microsoft Entra Domain Services allows you to migrate application servers to the cloud IaaS and decouple from Active Directory, while using Microsoft Entra application proxy to enable remote access. To learn more about this scenario, check Deploy Microsoft Entra application proxy for Microsoft Entra Domain Services.