Choose a solution for integrating on-premises Active Directory with Azure

This article compares options for integrating your on-premises Active Directory (AD) environment with an Azure network. We provide a reference architecture and a deployable solution for each option.

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 Azure AD to create an Active Directory domain in the cloud and connect it to your on-premises Active Directory domain. Azure AD Connect integrates your on-premises directories with Azure AD.

  • 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 Azure AD

Use Azure Active Directory (Azure AD) to create a domain in Azure and link it to an on-premises AD domain.

The Azure AD 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 Azure AD, but changes made in Azure AD are not replicated back to the on-premises domain.

You can also use Azure AD without using an on-premises directory. In this case, Azure AD acts as the primary source of all identity information, rather than containing data replicated from an on-premises directory.


  • You don't need to maintain an AD infrastructure in the cloud. Azure AD is entirely managed and maintained by Microsoft.
  • Azure AD 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.


  • Identity services are limited to users and groups. There is no ability to authenticate service and computer accounts.
  • You must configure connectivity with your on-premises domain to keep the Azure AD directory synchronized.
  • Applications may need to be rewritten to enable authentication through Azure AD.


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 Azure AD.


  • 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.


  • 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.


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.


  • 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.


  • 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.


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.


  • You can leverage claims-aware applications.
  • Provides the ability to trust external partners for authentication.
  • Compatibility with large set of authentication protocols.


  • 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.