If you’re here, you have at least some questions around Azure Active Directory—a.k.a. AAD / Azure AD. As the possible winner for the “Worst-Named Microsoft Service” award, there is no shame if you’re not completely clear on what AAD is, how it’s supposed to be used, and what it isn’t. We’re going to take a stab at bringing some very high-level clarity to these questions.
If you’re here, you have at least some questions around Azure Active Directory—a.k.a. AAD / Azure AD. As the possible winner for the “Worst-Named Microsoft Service” award, there is no shame if you’re not completely clear on what AAD is, how it’s supposed to be used, and what it isn’t. We’re going to take a stab at bringing some very high-level clarity to these questions.
There are, of course, innumerable TechNet articles articulating the various wonders of AAD, and in their defense they do an admirable job; however we’ve always found they tend to focus too much on the trees (pun intended) and not enough on the forest.
Active Directory
To the end of describing some of this metaphorical forest, we should actually step back and briefly review what exactly traditional Active Directory is. This may seem basic, but it is important foundation for the conversation to come.
Anybody reading this works in, or has worked in, a traditional Active Directory environment. Active Directory is, and has been for more than 20 years, the backbone of virtually every business on the planet (except perhaps those Novel shops . . . but we do not speak of such things here). But what is Active Directory?
First, it functions as an Authentication Mechanism and Identity Source. It retains user identities (usernames) and hashes of their passwords and provides confirmation to requesting services when these pairings do or do not match.
Second, it’s a hierarchical management and organizational structure. Organizational Units (OUs), containers, nested groups—all components of the x500 directory structure that allow administrators the ability to organize and categorize endpoint and user accounts with immense granularity. This hierarchical structure is critical, as when you start leveraging LDAP queries you can ask complex questions about an object’s location and memberships in order to understand who/what/where it is.
Finally, it bundles in a policy application engine in the form of the Group Policy Processing Engine.
GPO is ubiquitous in organizations as a basic way to customize the user and machine experience and configuration. GPOs are applied at the OU level and even support some basic conditional application mechanisms (e.g., if User is in Group X, then apply Policy Y).
If you’re interested in more of what Active Directory “does,” then check out this Wikipedia article, which, against all expectations, actually lays out Active Directory’s functions and history pretty accurately.
Where Active Directory Falls Short
Active Directory has done all we have asked of it for more than 20 years, but like any legacy technology, it does not support some of the more modern authentication mechanisms. Specifically, it cannot deal in any cloud-based identity protocols such as SAML, OAuth, OAuth2, or OpenID Connect.
This single shortcoming, a lack of support for modern cloud authentication, is where Azure AD comes in.
What Is Azure Active Directory (a.k.a. Azure AD, AAD)?
At its heart, Azure AD is nothing more than a cloud-based identity provider that can talk the more modern, cloud/SaaS-centric, authentication protocols. It is a flat-bottomed bucket of account objects and password hashes. That is it. If you came here in search of the answer to “What is AAD,” you now have it.
In terms of specific features and license levels, Microsoft has provided a very nice matrix breaking down what is included with which license levels, which can be found here: https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-mfa-licensing.
What Azure AD Is Not
As you’ve doubtlessly already gathered, AAD is a tremendously poor name for this product, given that it is in fact not Active Directory in Azure, despite what the name would imply.
Azure AD does not speak Kerberos, NTLM, or LDAP—at all. This means, among other things, that any “non-cloud” or legacy app will likely not be able to authenticate against it, nor query information from it.
Further, Azure AD is completely flat—there is no OU hierarchy like there is in traditional Active Directory. All the accounts sit in one great big bucket. Following on from this, there is also no direct concept of Group Policy in AAD. If you think about it, without OU structures, much of the granularity and organization thereof that is usually relied upon in GPO structures doesn’t exist, so it makes little sense to try to manage those objects in this way.
Do You Need AAD?
For almost every existing organization with on-premises Active Directory, the answer to the above question is going to be a resounding “probably.”
While not technically required for a pure on-prem environment, it is highly likely that even the most cloud-hesitant organizations will have need for some sort of modern authentication in at least one service or app being used.
For example, any organization running any of the Microsoft Online Services (O365, OneDrive, SharePoint Online, Exchange Online, etc.) must have AAD set up (and ideally synchronizing with on-prem Active Directory—more on this later).
From a security perspective, one of the best arguments for Azure AD is its ability to control access to applications and protect a user’s identities. To this end, Azure AD has several key built-in functionalities:
- Conditional Access
- Providing barriers to entry when accessing applications or devices
- Multi-Factor Authentication
- Soft token, SMS, etc.
- Self-Service Password Reset
- Azure AD Password Protection
- Scanning for leaked passwords against the globally known banned password database
- Monitoring of risky user logons and risky user behavior
The Future of Traditional Active Directory
Even with the enormous differences, the question still gets asked: “Is AAD replacing Active Directory?” The short answer is: no. Active Directory as we know it today is not going away.
The longer answer, frankly, starts with “Of course not!”
Azure AD is not “next-gen” Active Directory, nor a successor, add-on, or really in any way related to traditional Active Directory, other than also being a type of identity provider made by the same software vendor. Their feature sets are almost entirely mutually exclusive.
By way of analogy, even though both things move you from one place to another, you could no more replace a boat with a car as a way to travel from New York to London.
Both solutions serve a specific purpose, and though they can be tied together, they are really two completely separate solutions to two different problems. One is not an iteration on the other.
Because they are so different, do not expect every current software vendor to just add “AAD support” to their otherwise non-cloud products. As noted, Active Directory is not going anywhere, and for non-cloud workloads, Active Directory will continue to be the gold standard in all the areas it’s used today.
If Active Directory Isn’t Going Anywhere, Then Why Does AAD Exist?
We mentioned very briefly that Azure AD is a cloud identity provider, and that’s all well and good, but why does it exist? Why not just add SAML or OAuth support to existing Active Directory? Essentially, trying to forklift the required modern authentication functionality into on-prem Active Directory would require such a – from an infrastructure perspective for most businesses, as to make it an effective non-starter.
It made far more sense to build a second, separate authentication platform, based on and supporting all the modern auth concepts, and then offer a way to connect this to legacy Active Directory, rather than shoehorn this functionality into the existing platform.
Better Together—Azure AD Connect
Knowing that Active Directory can’t “talk cloud” and AAD can’t talk LDAP, almost every organization is going to need to eventually run some sort of hybrid Active Directory / AAD environment.
Enter Azure AD Connect, a tool set designed to link an on-premises Active Directory infrastructure to a Microsoft-hosted AAD instance. In essence, all this tool does is copy your on-prem user account names to AAD, along with the hashes of passwords, thus allowing modern auth against AAD to reflect credentials stored in on-prem Active Directory. (If you are familiar with Microsoft Forefront Identity Manager, you are pretty much familiar with Azure AD Connect.) Once the on premises Active Directory has been synchronized with AAD, users can seamlessly sign on to SaaS applications like Microsoft 365.
In this sort of hybrid environment, the on-prem Active Directory will always be the source of truth. This means that Azure Active Directory will never have the password of a user. If a user initiates a password reset from Azure, it is Azure AD Connect that handles that reset request and forwards the request to an on-prem Domain Controller.
What about Azure Active Directory Domain Services?
There is another flavor of Active Directory / AAD mix to cover, and that is Azure Active Directory Domain Servers (AAD-DS). In simple terms, think of AAD-DS as a stripped down “Active Directory as a Service” solution, provided by Microsoft.
It can be used as a standalone Active Directory instance to support untrusted environments that you do not want to authenticate back to your production Active Directory infrastructure.
There are a slew of catches when it comes to AAD-DS as well. To name a few:
- It can’t be the same as your on-prem or legacy directory.
- It’s completely managed by Azure, so administrative access is limited.
- Endpoints joined to AAD-DS must be in Azure.
- There is no two-way trust.
- It can’t be moved to another region in Azure, VNet, or subnet.
- It can’t be synced to more than one Azure region.
In short, AAD-DS is not a way to run “Active Directory in the cloud.” For most traditional organizations looking to build out a cloud-based directory presence, building a hybrid infrastructure consisting of traditional Active Directory controllers running in Azure, with AD Connect synchronizing those to an Azure AD instance, is going to be the recommended solution.
Recommendations
This is a lot of information to digest in the abstract, so let’s break it down a bit from a solution perspective.
Azure AD without Traditional Active Directory
This solution is only going to be viable for pure-cloud organizations, with no legacy or on-prem applications, where AAD will be your identity source of truth. Keep in mind, without traditional Active Directory, there is no LDAP support, nor Kerberos auth, and so you’ll be limited to modern SAML/OAuth SaaS platforms.
Azure AD with Traditional Active Directory (Standard “Hybrid” Model)
This is going to be the best path for the majority of existing organizations that are looking to build out support for modern authentication within their environments.
This solution offers the best of both worlds: maintaining full legacy ldap/kerberos/ntlm support for on-prem and current applications and endpoints while also bridging the gap to modern SaaS applications and platforms that require modern authentication with SAML, OAuth, and the like.
Everything Else
As always, if you have any questions regarding Azure, Azure AD, or even traditional Active Directory, Alchemy Services can help. Please reach out to [info@alchemytechgroup.com], or your Account Manager, to set up a time with one of our Solutions Architects to review your business needs.
