This article compares options for integrating your on-premises Active Directory (AD) environment with an Azure network. For each option, a more detailed reference architecture is available.
Many organizations use Active Directory Domain Services (AD DS) to authenticate identities associated with users, computers, applications, or other resources that are included in a security boundary. Directory and identity services are typically hosted on-premises, but if your application is hosted partly on-premises and partly in Azure, there may be latency sending authentication requests from Azure back to on-premises. Implementing directory and identity services in Azure can reduce this latency.
Azure provides two solutions for implementing directory and identity services in Azure:
Use Microsoft Entra ID to create an Active Directory domain in the cloud and connect it to your on-premises Active Directory domain. Microsoft Entra Connect integrates your on-premises directories with Microsoft Entra ID.
Extend your existing on-premises Active Directory infrastructure to Azure, by deploying a VM in Azure that runs AD DS as a Domain Controller. This architecture is more common when the on-premises network and the Azure virtual network (VNet) are connected by a VPN or ExpressRoute connection. Several variations of this architecture are possible:
- Create a domain in Azure and join it to your on-premises AD forest.
- Create a separate forest in Azure that is trusted by domains in your on-premises forest.
- Replicate an Active Directory Federation Services (AD FS) deployment to Azure.
The next sections describe each of these options in more detail.
Integrate your on-premises domains with Microsoft Entra ID
Use Microsoft Entra ID to create a domain in Azure and link it to an on-premises AD domain.
The Microsoft Entra directory is not an extension of an on-premises directory. Rather, it's a copy that contains the same objects and identities. Changes made to these items on-premises are copied to Microsoft Entra ID, but changes made in Microsoft Entra ID are not replicated back to the on-premises domain.
You can also use Microsoft Entra ID without using an on-premises directory. In this case, Microsoft Entra ID acts as the primary source of all identity information, rather than containing data replicated from an on-premises directory.
Benefits
- You don't need to maintain an AD infrastructure in the cloud. Microsoft Entra ID is entirely managed and maintained by Microsoft.
- Microsoft Entra ID provides the same identity information that is available on-premises.
- Authentication can happen in Azure, reducing the need for external applications and users to contact the on-premises domain.
Challenges
- You must configure connectivity with your on-premises domain to keep the Microsoft Entra directory synchronized.
- Applications may need to be rewritten to enable authentication through Microsoft Entra ID.
- If you wish to authenticate service and computer accounts, you will have to also deploy Microsoft Entra Domain Services.
Reference architecture
AD DS in Azure joined to an on-premises forest
Deploy AD Domain Services (AD DS) servers to Azure. Create a domain in Azure and join it to your on-premises AD forest.
Consider this option if you need to use AD DS features that are not currently implemented by Microsoft Entra ID.
Benefits
- Provides access to the same identity information that is available on-premises.
- You can authenticate user, service, and computer accounts on-premises and in Azure.
- You don't need to manage a separate AD forest. The domain in Azure can belong to the on-premises forest.
- You can apply group policy defined by on-premises Group Policy Objects to the domain in Azure.
Challenges
- You must deploy and manage your own AD DS servers and domain in the cloud.
- There may be some synchronization latency between the domain servers in the cloud and the servers running on-premises.
Reference architecture
AD DS in Azure with a separate forest
Deploy AD Domain Services (AD DS) servers to Azure, but create a separate Active Directory forest that is separate from the on-premises forest. This forest is trusted by domains in your on-premises forest.
Typical uses for this architecture include maintaining security separation for objects and identities held in the cloud, and migrating individual domains from on-premises to the cloud.
Benefits
- You can implement on-premises identities and separate Azure-only identities.
- You don't need to replicate from the on-premises AD forest to Azure.
Challenges
- Authentication within Azure for on-premises identities requires extra network hops to the on-premises AD servers.
- You must deploy your own AD DS servers and forest in the cloud, and establish the appropriate trust relationships between forests.
Reference architecture
Extend AD FS to Azure
Replicate an Active Directory Federation Services (AD FS) deployment to Azure, to perform federated authentication and authorization for components running in Azure.
Typical uses for this architecture:
- Authenticate and authorize users from partner organizations.
- Allow users to authenticate from web browsers running outside of the organizational firewall.
- Allow users to connect from authorized external devices such as mobile devices.
Benefits
- You can leverage claims-aware applications.
- Provides the ability to trust external partners for authentication.
- Compatibility with large set of authentication protocols.
Challenges
- You must deploy your own AD DS, AD FS, and AD FS Web Application Proxy servers in Azure.
- This architecture can be complex to configure.
Reference architecture