Reading Time: 4 minutes

You’ve been assigned a task to design architecture a new cloud service deployment that should be elastic, scalable, resilient with global coverage while keeping the cost in control. Two things that make it even more challenging: first it should be used by applications that do not speak cloud-ready auth protocols and second give user-access to external SaaS public offerings without recreating users to any external directory by leveraging Azure AD features.

Let’s have a closer look.

Business case

We need the following to satisfy the business needs for identity:

  1. It should talk Kerberos, NTLM
  2. Access to external SaaS applications
  3. Be a global and resilient solution
  4. Lower overall maintenance cost

Windows AD DS vs Azure AD

Azure AD is not the traditional Windows AD DS but just on the cloud. They are completely different. They talk different protocols (SAML and OAuth2, vs Kerberos and NTLM, etc.) and they operate significantly differently. Azure AD is a cloud-based identity solution that helps you manage users and applications. Active Directory or Windows Active Directory if you will, manages objects, like devices and users, on your on-premises network.

Azure AD came to bridge the gap between users in any identity provider (IdP) like Active Directory and SaaS applications without the need to replicate the users and maintain different user databases.

Windows AD and Azure AD

So that is a good thing, Azure AD can take the existing user base and make them leverage direct access to 3rd party SaaS offerings. But we are still missing at least one thing: the backward compatible auth protocols.

Where next? Azure AD DS

Azure AD DS is an Azure PaaS offering and the closest thing to Windows Server Active Directory on Azure without you managing the domain controller (DC) infrastructure. In few words, instead of you deploying 2 Azure VMs to hold your DCs and then maintaining (= secure, patch, monitor, backup, and troubleshoot) them, you can deploy one Azure AD DS resource on your Azure tenant that will act almost identical to your “old-school” Windows Server Active Directory.

When you deploy an Azure AD DS instance, Azure in the back scene it deploys to domain controllers to satisfy fault tolerance and high availability. If the Azure region you deploy supports availability zones then the DCs are distributed across zones. If not, then the domain controllers are deployed across availability sets.

On-premises AD could be your AD living inside Azure VMs

Azure AD DS integrates with your existing Azure AD tenant. This integration lets users sign in to service and applications connected to the managed domain using their existing credentials. You can also use existing groups and user accounts to secure access to resources.

Fast facts about Azure AD DS:

  • it can only be one per Azure AD tenant
  • once you deploy it you cannot change its location, virtual network (vnet), or just about anything else related to underlying infrastructure services
  • guest users on your Azure AD tenant cannot be synced
  • you don’t have direct access -desktop- on the domain controllers
  • Domain Administrator and Enterprise Administrator privileges aren’t available for you to use within the domain
  • Distributed File System (DFS) is not supported
  • Once deployed you can stop or otherwise pause the service

Note: To manage an Azure AD DS instance you need to deploy an Azure VM in the same vnet and install the Remote Server Administration Tools of the Windows Server features. Then you can manage the “managed” AD domain by using the tool “Active Directory Administration Center”.

From the comparison table above we see that it all seems to check out fine apart from one: geo-distributed deployment.

OK, we are getting somewhere but we need to tackle the global presence point because if our domain controllers live in West Europe Azure region and we have deployments in other Azure regions i.e. Brazil South, UAE Central, South India, etc. there can be quite a network latency to authenticate and authorize users and applications.

Enters the replica sets concepts of Azure AD DS

In the previous section, we described that the creation of an Azure AD DS managed domain creates in the back 2 domain controllers. This is called a replica set.

There is a concept in Azure AD DS replica sets for expanding a managed domain to have more than one replica set per Azure AD tenant. This is currently in preview but the word is that it will go GA in Q1 of 2021.

You create each replica set in a virtual network located in the region that is closest to your country deployment and then you need to setup vnet peering between any virtual network that hosts the Azure AD DS replica set. This configuration creates a mesh network topology and enables for directory replication. Also, there is the option of deploying different replica sets in the same virtual network but in different subnets.

This diagram shows a managed domain with two replica sets. The first replica set is created with the domain namespace. A second replica set is created after that.

Replica sets ensure availability of authentication services in regions where a replica set is configured.

To support multiple Azure AD Domain Services replica sets, the managed domain service SKU must be either Enterprise or Premium.

While in preview, it is limited to a maximum of four replica sets – the initial replica set for the managed domain, plus three additional replica sets.

In a next blog post, I will walk you through the complete process of creating a managed domain, a management VM and creating multiple replication sets to ensure local resiliency for authentication to your regional solutions.

And with that, we covered all the business case points.

Hope you enjoyed it and feel free to comment below.

Cheers!