“Active Directory vs. Azure Active Directory”? Okay, I readily admit that this match-up will never inspire the same passion as “Coke vs. Pepsi,” “Marvel vs. DC” or “Kirk vs. Picard.” Still, these two core Microsoft technologies affect your digital life more than you might realize, so it’s really important to understand them.
To help, this blog posts lays out all the key things you need to know: how they’re similar, how they’re different and — critically — how they can work together.
Active Directory vs. Azure Active Directory: Key similarities
The name “Active Directory” reveals a lot about what Active Directory (AD) and Azure Active Directory (Azure AD) have in common. Let’s start with “directory.” In general, a directory is an organized list of things, like the fat Yellow Pages that used to land on your (or your parents’) doorstep or the Contacts list on your phone. Both AD and Azure AD maintain a database or directory of objects; one of the most important types of object is the user account, which includes details like a person’s username and password, as well as their real name, job title, department and so on.
But unlike the Yellow Pages, the Active Directory and Azure AD directories are active. A printed directory is quite static: It doesn’t do anything; it sits there for you to consult. In contrast, AD and Azure AD do quite a lot. In fact, they perform the same two fundamental services: providing authentication and authorization for users attempting to access the devices, data, applications and other digital resources in your IT ecosystem:
- Authentication is the process of validating that someone or something actually is who they say they are. Traditionally, individuals authenticate by supplying a username and password — ideally, only you know your password, so by entering it, you’re proving that it’s actually you who’s logging on and not someone else. As you undoubtedly know, it’s all too easy for someone else to guess or steal your password these days, so now you often have to provide a second piece of proof that you’re who you say you are, such as a code sent to your mobile device or a fingerprint, in a process that’s called (you guessed it!) multifactor authentication (MFA).
- Authorization is the process of determining of what someone or something is allowed to do once they have been authenticated. For example, a company would probably want to permit CPA Alex to create and edit certain financial documents, but not allow sysadmin Chris to even read them. Similarly, Chris would be allowed to build and run PowerShell scripts and access data forbidden to Alex.
To put it another way, both Active Directory and Azure Active Directory are two things: a directory of critical information about objects in your IT environment, and a set of services that control much of the activity that goes on, with authentication and authorization being two of the most important services.
Active Directory vs. Azure Active Directory: Key differences
The most fundamental difference between the two technologies is that Active Directory originally lived in on-premises datacenters while Azure Active Directory was designed for the Microsoft cloud. Let’s unpack what that means.
Active Directory generally lives on special on-prem computers called domain controllers (DCs). You purchase these machines, you install the Windows Server operating system on each of them, you configure them, and you are responsible for their care and feeding. DCs host the AD directory and run the AD services. Typically, organizations have multiple DCs that work together. In particular, any change made to the directory on one domain controller — such as a user updating their password or a user account being locked out for too many failed login attempts — is replicated to the other domain controllers so they all stay up to date. In recent years, some organizations have moved their Active Directory to the cloud; however, they remain responsible for where the infrastructure is.
Azure AD lives on Microsoft servers in Microsoft datacenters. You don’t have to purchase them, configure them, ensure they have the proper temperature and humidity, or protect them from intruders and natural disasters. If your organization subscribes to any Microsoft Online business service such as Office 365 (now called Microsoft 365), you have Azure AD. (However, only some Azure AD features are included for free; others require an Azure AD Basic, Premium P1 or Premium P2 license.)
But here’s the crucial thing to understand: Azure AD is not the same old Active Directory you know, just running on Microsoft servers instead of your own DCs. Azure AD is a different technology, specifically designed to meet the needs of the cloud environment rather than an on-prem environment. Let’s dive into the most critical of those differences.
Structure
In Active Directory, the primary unit is the domain: a group of related users, computers and other AD objects that are stored in a single database (directory) and can be managed together. A small company might have only one domain, but larger organizations often have multiple domains, such as separate domains for different locations or business units. Multiple domains can be combined into a tree, and multiple trees can be grouped into a forest.
Azure AD does not have any of these things. Instead, the basic building block is the tenant: a dedicated instance of Azure AD for a particular company. You create your tenant when your organization signs up for a Microsoft cloud service like Office 365. Your Azure tenant has a dedicated directory that includes all your users and performs services like authentication and authorization for you.
Authentication
Both Active Directory and Azure Active Directory perform authentication, but they use completely different protocols for getting the job done. (A protocol is basically a set of rules for exchanging data between different machines, including how the information will be structured and how each side will send and receive it.)
Active Directory has been around so long that the authentication protocols have evolved a great deal, from LM to NTLM, and then to the currently supported NTLMv2 and Kerberos. Each advancement made it harder for imposters to fool the system and successfully authenticate using someone else’s credentials.
Azure AD doesn’t support any of these protocols. Instead, it uses modern authentication protocols like OAuth, SAML and OpenID Connect. Moreover, Azure Active Directory authentication is a multifaceted process that includes components like self-service password reset, Azure AD Multifactor Authentication, Conditional Access policies and even passwordless authentication.
Authorization
Active Directory and Azure Active Directory also perform authorization in quite different ways. In both cases, authorization is a complex process that involves a great many components; I’m going to focus on only the most important elements, so don’t mistake this short blog post for a comprehensive discussion.
In Active Directory, there are three primary ways for controlling what users are permitted to do:
- AD security group membership — An AD security group is basically a list of user accounts and a set of permissions that are granted to every user in the group. There are a variety of built-in security groups, such as Domain Admins and Guests, and you can create your own custom ones as well. For example, you might have a security group called “Finance Team” that allows everyone in the group to run certain applications and modify certain files relevant to their collective responsibilities.
- Directly assigned permissions — You can also directly assign permissions to Active Directory objects like user accounts. This enables very fine-grained control over access, but it is generally not a best practice because managing the permissions for each user individually is highly error prone and becomes impossible to effectively manage almost immediately.
- Group Policy — Group Policy is a very powerful feature of Active Directory that affects many processes, one of which is authorization. It enables centralized management of users and computers, so, for example, you can use it to prevent anyone from executing commands from the command prompt on their machine or copying data to a removable device. It can also be used more granularly, for instance, to block unidentified users on remote computers from connecting to a network share.
So, when an authenticated user tries to do something — such as read a piece of data or run an application — Active Directory decides whether to allow the action by (among other things) checking the permissions they’ve been granted directly and via their security group memberships and the rules laid down in Group Policy.
Azure AD handles authorization very differently. Again, it’s a complex process that I’m not detailing completely, but here are the main components:
- Azure AD security groups — Security groups in Azure AD are similar in structure and function to those in on-premises Active Directory: All members of the group are granted all the permissions assigned to the group. However, Active Directory groups are comprised of on-prem user accounts and control access to on-prem applications and resources, while Azure AD security groups are comprised of Azure AD user accounts and are used to grant access to Microsoft 365 resources, such as SharePoint Online.
- Microsoft 365 groups (formerly called Office 365 groups) — A Microsoft 365 group is kind of like an Azure AD security group on steroids. It has a list of members, but it’s also coupled to resources and workloads for the group, such as a SharePoint team site and a shared Exchange mailbox. Microsoft 365 groups can include users from both inside and outside your company, and they can be configured for dynamic membership, which means group members are added or removed automatically based on attributes such as department, location or title.
- Azure AD roles — Azure AD roles grant specific sets of permissions to different types of administrators. For example, the Global Administrator role grants access to all administrative features in Azure AD and to services that use Azure AD identities, such as the Microsoft 365 Security Center, Exchange Online and SharePoint Online. The Exchange Administrator role, as the name implies, grants a user global permissions within Exchange Online. There are dozens of built-in Azure AD roles, and you can also create your own custom roles.
Computer and device management
In Active Directory, one of the most powerful tools for managing computers is Group Policy. For instance, you can use Group Policy to block users from adding new Microsoft accounts on a particular computer, prevent the installation of unauthorized machines, lock a computer after a certain period of inactivity, automatically install software updates on all computers, and prevent the use of removable storage devices.
Azure AD, as we have already seen, does not have Group Policy. Instead, device management is done with Microsoft Intune. You can set up different rules for organization-owned devices and personal (BYOD) devices enrolled in Intune. Options include blocking jailbroken devices, pushing certificates to devices so users can connect to your network via a VPN, and wipe corporate data from a device that is lost or stolen.
Active Directory vs. Azure Active Directory: One or the other — or both!
These significant differences between the two technologies mean that they are appropriate in different scenarios. But it doesn’t have to be “Active Directory vs. Azure Active Directory” — in fact, most of the time, it is actually “Active Directory and Azure Active Directory.” Let’s look at why and how organizations use both of them together in what’s called a hybrid IT environment.
Reasons for keeping on-prem Active Directory
While some organizations are born in the cloud and therefore never had any on-prem IT environment to manage, most organizations are in quite a different situation. They had a well-established, complex IT ecosystem before the cloud came along, and now they want to take advantage of all the Microsoft cloud has to offer.
Reduce your AD attack surface.
Why would they keep their on-prem Active Directory instead of moving entirely to the cloud? There are actually multiple compelling reasons, including the following:
- Older apps — Organizations often have a wide variety of third-party and bespoke applications that are crucial to their operation, but that do not readily port to the cloud. For example, a healthcare organization might have expensive MRI machines that rely on Active Directory for access control, and it’s simply too expensive to replace them. Another organization might have built their own business process automation or customer relationship management software, and modifying it would be both expensive and risky. That being said, many applications can be modernized or replaced with cloud-based alternatives; it just takes time and care.
- Security and compliance — Some data and processes are so critical or sensitive that they should not live in the cloud. For example, industrial control systems and sensitive infrastructure should not be exposed to the internet. Organizations might have developed robust procedures for protecting sensitive and highly regulated data like health records or financial information on premises, and be worried about compliance with HIPAA, SOX, GDPR and other regulations if they were to move it to the cloud.
- Business continuity — Organizations are also concerned about ensuring they can keep running even if they lose internet access or Azure AD goes down. (That’s especially true of organizations that manage critical infrastructure, like water plants.) This concern is quite warranted: An Azure AD authentication outage in March left Microsoft 365 users around the world unable to sign into Teams and other Office 365 apps — and brought back painful memories of a similar Azure AD outage in September of 2020. Keeping an on-premises Active Directory mitigates that risk. In addition, for some organizations, the physical location of data is in itself an operational issue; for example, trading companies need to have their computers located physically close to the stock exchange’s computers, since microseconds can make crucial differences in high-frequency trading.
- Self-sufficiency — More generally, organizations are wary of putting all their eggs in one basket and handing that basket to a third party with its own interests and priorities. If your on-prem Exchange Server goes down, you can decide whether getting it back up is at the top of the list for your IT team, but if your Microsoft 365 email isn’t working right, you’re at the mercy of Microsoft, who might have bigger fish to fry at the moment.
Connecting Active Directory and Azure Active Directory
For those and other reasons, organizations choose to have a hybrid IT environment and sync data from their on-prem Active Directory to Azure Active Directory.
Microsoft offers two tools to help: Azure AD Connect and Azure AD Connect cloud sync. These tools automatically synchronize identity data between an on-premises Active Directory environment and Azure AD, which enables users to use the same credentials to access both on-premises applications and cloud services like Microsoft 365. For the essential details, check out my blog post, “Azure AD Connect: How it works and best practices.”
Final thoughts
I hope I’ve convinced you that “Active Directory vs. Azure Active Directory” is a false dichotomy. The two technologies simply serve different purposes. Organizations born in the cloud will likely never have the need for Active Directory, and a small number of companies might stick with the AD they already have and never adopt Azure AD. But most organizations have valid reasons for using both technologies together — just as their cafeterias might offer both Coke and Pepsi and their employees can legitimately love both Star Trek TOS and TNG.
