Azure Active Directory is not Active Directory!

If you’ve been working with Azure for a while you likely already know this, but this topic is something I see over and over again with people who are getting started with Azure. Azure Active Directory is not a cloud version of Active Directory, and in fact, it bears minimal resemblance to its on-premises namesake at all.

The question I see over and over again with people new to Azure, I even answered this question just this week, is “how do I join my servers to Azure AD?”. People expect (not unexpectedly) to be able to use Azure Active Directory just like they have always used Active Directory. So this article is for you if you’re new to Azure and trying to get your head around what Azure AD is and how it works, and how it compares to Active Directory (or not).

What is Active Directory

If you’re reading this article, more than likely you already know what Active Directory (AD) is. You’ve probably worked with it for years, and now you’re looking to move to the cloud and understand what AAD is. However, to make sure we can compare AD (and particularly the domain services part of AD) to AAD, lets quickly list the essential functions that make up AD:

• Secure Object store, including Users, Computers and Groups
• Object organisation use OU’s, Domains and Forests
• Common Authentication and Authorisation provider
• LDAP, NTLM, Kerberos
• Group Policy
• Customisable Schema

Alongside Domain Services we also have components like Certificate Services, Federation Services and Privileged Access Management.

What is Azure Active Directory

So if we know what Active Directory is, then how does this compare to Azure Active Directory? The answer to this is, not very closely. The decision to name AAD after AD I suspect was more of a marketing decision than a technical one, and it has lead to years of confusion. In many ways, AAD was designed for a world where PaaS and SaaS services where the default choice, not for IaaS in the cloud.

Azure Active Directory is a secure authentication store, which can contain users and groups, but that is about where the similarities end. AAD is a cloud-based identity management store for modern applications. AAD is designed to allow you to create users, groups and applications that work with modern authentication mechanisms like SAML and OAuth.

Applications are an object that exists in Azure AD but not in AD. Applications allow you to create an identity for your applications that you can grant access for users to, and to allow you to grant your users access to applications owned by others.

What AAD does not provide is any AD service beyond user management.

• You can’t join computers to an Azure AD domain in the way you would with AD. This is one of the most commonly asked questions when moving to Azure. There is something called Azure AD Join, but this is a different beast that we will look at later. This means there are no computer objects in your AD to apply things like GPOs to, and no centralised control of user rights on those machines.
• There is no Group Policy. Azure AD has some policy tools like conditional access, but it is more focused on granting or not granting access to applications.
• No support for LDAP, directory queries all use the REST API, Graph or PowerShell/CLI
• There’s no support for NTLM or Kerberos. AAD is modern authentication protocols only
• There’s no schema you have access to or can modify
• Flat structure, no OU’s, Domains or Forests

Hopefully, it is reasonably clear now that Azure AD is a very different thing to AD, and I would encourage you to treat it this way. AAD is for user, group and application management in the cloud. If you’re building all new services using PaaS or SaaS and using modern authentication protocols then you should be all set with AAD, it’s what it was designed for. However, if you’re running IaaS in Azure and want classic AD to domain join machines and create GPO’s, then AAD won’t cut it for you (and that is by design).

AD In the Cloud

Hopefully, now it’s clear what AAD is and isn’t, and if your building modern apps and AAD does what you need, then you can stop reading now. However, if you are going down the IaaS route in Azure and you feel you still need the services of an AD domain, what options are there?

Azure AD Join

We mentioned this briefly earlier; it is possible to join devices directly to Azure AD. AAD Join is limited to Windows 10 machines only and provides limited functionality, certainly nothing like a full AD join. When Azure AD joined, it is then possible to login to machines using Azure AD user accounts. It is also possible to apply conditional access policies that require machines to be AAD joined before accessing resources or applications. If you’re looking for a way to provide common user account management across Windows 10 machines, then this may work for you.

Azure AD Domain Services

If you need more than just user management, then it is possible to extend Azure AD to offer more AD based services using Azure AD Domain Services. AAD DS is an Azure product that you enable on your virtual network which deploys two domain controllers that are managed by Microsoft and synchronised with your Azure AD tenant. This allows you to grant machine access to users in your AAD tenant, but also to implement things like custom OU’s, group policy, LDAP queries, NTLM and Kerberos. This is a domain managed by Microsoft, so you do not have to worry about patching your domain controllers or ensuring they are up. However, it also means you do not have full control of the domain. You do not, for example, have domain admin rights, only enough rights to undertake the tasks Microsoft allows. You can see a full breakdown of AAD DS limitations here.

IaaS Domain Controllers

Nothing is stopping you just deploying some virtual machines in Azure and turning them into domain controllers. This is a support configuration and is in use by many people who need the full suite of services provided by AD inside Azure.

The downside to this approach is that you need to manage this yourself. You need to take care of patching and updating your servers, backing up your domain and any other maintenance you require. You are also in charge of making sure it is highly available and implementing a DR strategy if you require it. If you need all that AD has to offer then, this can be a great option, but if all you want is a common user store for machine login, it might be overkill.

Access your On-Premises Domain

Finally, you can also extend your existing on-premises domain into Azure. Using ExpressRoute or VPN, you can connect your on-premises network to your Azure vNet and allow access to domain controllers. You can even deploy IaaS domain controllers in Azure that are joined to your on-premises domain. This then adds a dependency to your infrastructure of connectivity back to the on-premises network, so this connectivity becomes a key point of failure. You need to ensure that resiliency is built in.

Summary

If you’re new to Azure and especially identity in Azure, I hope the concept of Azure Active Directory is a bit clearer. This is a new, modern authentication provider and is not Active Directory in the cloud. AAD does not behave like the Active Directory you know and love and really shouldn’t be compared to it, it is a different service.

If you need AD in your cloud environment, then there are options to achieve this, but vanilla AAD is not going to give you that. Take a look at the options listed in this article and see what meets your needs.