Edit

Hybrid identity with Active Directory and Microsoft Entra ID in Azure landing zones

  • Article

This article provides guidance on how to design and implement Microsoft Entra ID and hybrid identity for Azure landing zones.

Organizations that operate in the cloud require a directory service to manage user identities and access to resources. Microsoft Entra ID is a cloud-based identity and access management service that provides robust capabilities to manage users and groups. You can use it as a standalone identity solution, or integrate it with a Microsoft Entra Domain Services infrastructure or an on-premises Active Directory Domain Services (AD DS) infrastructure.

Microsoft Entra ID provides modern, secure identity and access management that's suitable for many organizations and workloads, and is at the core of Azure and Microsoft 365 services. If your organization has an on-premises AD DS infrastructure, your cloud-based workloads might require directory synchronization with Microsoft Entra ID for a consistent set of identities, groups, and roles between your on-premises and cloud environments. Or if you have applications that depend on legacy authentication mechanisms, you might have to deploy managed Domain Services in the cloud.

Cloud-based identity management is an iterative process. You could start with a cloud-native solution with a small set of users and corresponding roles for an initial deployment, and as your migration matures, you might need to integrate your identity solution by using directory synchronization or add cloud-hosted domain services as part of your cloud deployments.

Over time, revisit your identity solution depending on your workload authentication requirements and other needs, such as changes to your organizational identity strategy and security requirements, or integration with other directory services. When you evaluate Active Directory solutions, understand the differences between Microsoft Entra ID, Domain Services, and AD DS on Windows Server.

For help with your identity strategy, see Identity decision guide.

Identity and access management services in Azure landing zones

The platform team is responsible for the administration of identity and access management. Identity and access management services are fundamental to organizational security. Organizations can use Microsoft Entra ID to protect platform resources by controlling administrative access. This approach prevents users outside the platform team from making changes to the configuration or to the security principals contained within Microsoft Entra ID.

Organizations that use AD DS or Domain Services must also protect the domain controllers from unauthorized access. Domain controllers are particularly attractive targets for attackers and should have strict security controls and segregation from application workloads.

Domain controllers and associated components, such as Microsoft Entra ID Connect servers, are deployed in the Identity subscription, which is in the platform management group. Domain controllers aren't delegated to application teams. By providing this isolation, application owners can consume the identity services without having to manage them, and the risk of identity and access management services being compromised is reduced. The resources in the Identity platform subscription are a critical point of security for your cloud and on-premises environments.

Landing zones should be provisioned so application owners can use either Microsoft Entra ID or AD DS and Domain Services, as required by their workloads. Depending on which identity solution you use, you might need to configure other services as necessary. For example, you might need to enable and secure network connectivity to the Identity virtual network. If you use a subscription-vending process, include this configuration information in your subscription request.

Azure and on-premises domains (hybrid identity)

User objects that are created entirely in Microsoft Entra ID are known as cloud-only accounts. They support modern authentication and access to Azure and Microsoft 365 resources, and access for local devices that use Windows 10 or Windows 11.

However, many organizations already have longstanding AD DS directories that might be integrated with other systems, such as line-of-business or enterprise resource planning (ERP) via Lightweight Directory Access Protocol (LDAP). These domains might have many domain-joined computers and applications that use Kerberos or older NTLMv2 protocols for authentication. In these environments, you can synchronize user objects to Microsoft Entra ID so that users can sign in to both on-premises systems and cloud resources with a single identity. Uniting on-premises and cloud directory services is known as hybrid identity. You can extend on-premises domains into Azure landing zones:

  • To maintain a single user object in both cloud and on-premises environments, you can sync AD DS domain users with Microsoft Entra ID via Microsoft Entra Connect or Microsoft Entra Connect Sync. To determine the recommended configuration for your environment, see Topologies for Microsoft Entra Connect.

  • To domain join Windows VMs and other services, you can deploy AD DS domain controllers or Domain Services in Azure. With this approach, AD DS users can sign in to Windows servers, Azure Files shares, and other resources that use Active Directory as an authentication source. You can also use other Active Directory technologies, such as group policy. For more information, see Common deployment scenarios for Microsoft Entra Domain Services.

Hybrid identity recommendations

Important

We highly recommend migrating to Microsoft Entra ID unless there's a specific requirement for using AD FS. For more information, see Resources for decommissioning AD FS and Migrating from AD FS to Microsoft Entra ID.

Microsoft Entra ID, Domain Services, and AD DS

Administrators should familiarize themselves with the options for implementing Microsoft directory services:

  • You can deploy AD DS domain controllers into Azure as Windows virtual machines (VMs) that platform or identity administrators have full control of. This approach is an infrastructure as a service (IaaS) solution. You can join the domain controllers to an existing Active Directory domain, or you can host a new domain that has an optional trust relationship with existing on-premises domains. For more information, see Azure Virtual Machines baseline architecture in an Azure landing zone.

  • Domain Services is an Azure-managed service that you can use to create a new managed Active Directory domain that's hosted in Azure. The domain can have a trust relationship with existing domains and can synchronize identities from Microsoft Entra ID. Administrators don't have direct access to the domain controllers and aren't responsible for patching and other maintenance operations.

  • When you deploy Domain Services or integrate on-premises environments into Azure, use locations with availability zones for increased availability.

After AD DS or Domain Services is configured, you can domain join Azure VMs and file shares by using the same method as on-premises computers. For more information, see Compare Microsoft directory-based services.

Microsoft Entra ID and AD DS recommendations

  • To access applications that use on-premises authentication remotely via Microsoft Entra ID, use Microsoft Entra application proxy. This feature provides secure remote access to on-premises web applications. It doesn't require a VPN or any changes to the network infrastructure. However, it's deployed as a single instance into Microsoft Entra ID, so application owners and the platform or identity teams must collaborate to ensure that the application is configured correctly.

  • Evaluate the compatibility of workloads for AD DS on Windows Server and Domain Services. For more information, see Common use cases and scenarios.

  • Deploy domain controller VMs or Domain Services replica sets into the Identity platform subscription within the platform management group.

  • Secure the virtual network that contains the domain controllers. Prevent direct internet connectivity to and from those systems by placing the AD DS servers in an isolated subnet with a network security group (NSG), providing firewall functionality. Resources that use domain controllers for authentication must have a network route to the domain controller subnet. Only enable a network route for applications that require access to services in the Identity subscription. For more information, see Deploy AD DS in an Azure virtual network.

  • In a multiregional organization, deploy Domain Services into the region that hosts the core platform components. You can only deploy Domain Services into a single subscription. You can expand Domain Services to further regions by adding up to four more replica sets in separate virtual networks that are peered to the primary virtual network. To minimize latency, keep your core applications close to, or in the same region as, the virtual network for your replica sets.

  • When you deploy AD DS domain controllers in Azure, deploy them across availability zones for increased resiliency. For more information, see Create VMs in availability zones and Migrate VMs to availability zones.

  • Authentication can occur in the cloud and on-premises, or on-premises only. As part of your identity planning, explore the authentication methods for Microsoft Entra ID.

  • If a Windows user requires Kerberos for Azure Files file shares, consider using Kerberos authentication for Microsoft Entra ID rather than deploying domain controllers in the cloud.

Next steps

Landing zone identity and access management