Active Directory Scenarios with Azure

This is a short post to help you decide what kind of Active Directory structure you need in your Azure or on-premises/Azure environment. "What choice should I make?" and "What are the trade-offs?" are questions I frequently hear, so hopefully this will organize it for you.

There are basically six scenarios for using Active Directory. They all have pros and cons, mostly with effort vs flexibility. Of course what you should pick depends on what you need.

On-Premises AD

This is the traditional on-premises network that existed before Azure. It is not part of Azure, but it is here to make sure that all the AD scenarios are covered.

A traditional AD structure consists of one or more forests, each with one or more domains. Trust relationships can be established across the domains in a forest, or between domains across forests, allowing for resource sharing (printers, disk, etc.).

In the pie above, there is a network of computers to represent an on-premises operation. It could be spread out geographically, but that is not important right now.

Azure AD

Each Azure tenant is based around an Azure AD (AAD) instance. There can can be only one. That is the black dot in the cloud in the pie above. AAD is different from on-premises AD. It is focused on identity: there are users and groups but no organizational units and no group policies. Identity is not served through LDAP, but through HTTP and HTTPS using SAML, WS-Federation, OpenID Connect, and OAuth. Obviously HTTPS is required when Azure AD is exposed publicly.

If everything is in the cloud, AAD is the simplest, easiest way to approach identity. A plus that AAD has is dynamic groups, where group membership is determined by rules instead of direct assignment. Microsoft is quiet about the infrastructure behind AAD, but from technical documents we can deduce that it is replicated across regions and in some cases geographies and should be completely resilient.

The major drawback is AAD is focused on identity, cannot provide group policy to the virtual machines hosted in Azure.

Azure is Multi-Tenant (Multiple tenants, each with a separate Azure AD)

Azure supports multiple tenants under one subscription (a billing entity, one or more exist under each account). At first glance you may ask why. Consider though a company providing a web-based application that has both employees and customers. The employees need an infrastructure to do customer relationship management, use internal databases, work on documents, read email, etc. The customers need a separate infrastructure that supports the web-applications and web-services they use, and need identity (authentication and authorization) to determine what they can do. So, for better security and tracking of cost, two separate tenants!

On-Premises / Azure AD Hybrid

This is referred to by multiple names throughout Microsoft, but the official name is Azure AD Hybrid. An on-premises AD is connected to AAD using Azure AD Connect. Azure AD Connect synchronizes the users and groups in one on-premises domain controller to one AAD.

Multiple forests and domains can be synchronized, but the users and groups end up in the flat space of AAD all together (don't have conflicting names!). The full details on synchronization can be found here. User and group synchronization is one-way. If password write-back is configured (see the instructions here) then password changes in AAD will be synchronized back to the on-premises server (the server initiates the connection).

Besides the obvious drawbacks, if the on-premises server fails a new one will need to be manually configured with Azure AD Connect to update AAD.

AD in Azure Virtual Machines Pure or Hybrid

Using Azure it is possible (and really the whole point) to build one ore more networks of disk resources and virtual machines to host services. It is just as easy to build active directory servers as part of this environment as it is on-premises. Since you have full control of the servers, you can either have a pure Azure environment, or you can link it to your on-premises forest using a virtual private network (VPN).

The advantages are that you have a full-blown AD environment, you can cross from on-premises to Azure, you can geographically separate the resources and provide redundancy.

The disadvantage is that you have to perform all of the configuration and maintenance of the AD servers.

Azure AD Domain Services

There are some limitations, but if you want to unburden yourself from your own AD servers then Azure AD Domain Services (AD DS) is almost a full-blown AD configured and maintained by Microsoft. This is often referred to as a managed domain because Microsoft manages the service. In the pie above, AD DS is the grey circle because Microsoft manages it.

All you have to do is provide the configuration and data. There is an automatic one-way connection established from the AAD (that has to exist in the tenant) to the AD DS instance, so any users and groups created there flow to AD DS. That also gives you the benefit of dynamic groups from AAD. .

Also on the plus side, it supports organizational units and group policies, so the computers in your domain show up and get group policies applied to them.

And, while you create AD DS in a resource group, Microsoft does backups, and has redundant copies so that the domain will be available even if a data center or network fails. Like AAD, Microsoft is silent on where the data is actually stored and the service is provided from. But, we can deduce for performance reasons that the primary service is in the same region as the our resource group.

On the minus side AD DS will not sync backwards to AAD. There really is no point, passwords, etc. cannot be changed by applications. The organizational units and group policies you create do not map back to AAD.

But, the minus side has three other big issues and any one of them could be a deal-breaker. Check the Azure AD DS FAQ for current information.

First, schema changes are not supported. So if there is an application that requires schema changes it cannot run using AD DS. You are locked into the schema that Microsoft provides.

Second, LDAP writes are not supported and not all data is writable. Data synchronized from AAD cannot be updated, only objects in organizational units you create. And while you can write data using the manual tools and PowerShell, applications cannot write into AD using LDAP. So again if there is an application that stores its data in AD, it is not going to work with AD DS.

Third, there are no forests and multiple domains. There is just the one domain.

Azure AD DS Hybrid

AD DS thinks it is the only domain (no forest, no other domains) and does not have any means to let you add additional AD servers, on-premises or in the cloud. On the surface why would you want to, Microsoft is managing this for you so you do not need redundancy.

But what happens when you need on-premises AD for services on that side? Well we can make it work, and we can push in multiple forests and domains, but it is a bit of a hack. If you think about it you already know it: you can use Azure AD Connect to synchronize AAD from your on-premises AD, and then the AAD will synchronize with your AD DS.

If you want more details, all of the information about all of this synchronization can be found here.