Azure AD is the next evolution. It takes identity to the next level by building upon AD DS and provides an Identity as a Service (IDaaS) to provide this same level of security and access management to the cloud.
Just as with AD DS, Azure AD is a database of users that can be used to grant access to all your systems. It’s important to understand that it is an entirely separate database— one that is stored within Azure—and therefore the underlying hardware and software that powers it is wholly managed by Azure—hence IDaaS.
In a traditional on-premises world, you would be responsible for building directory servers to host and manage AD DS. As an IT administrator or architect, you need to consider how many servers you require and what specifications they need to be to support your user load and resilience, to ensure the system is always available. If your identity system failed due to hardware failure, access to all your systems would be blocked.
Azure AD is a managed service, and Microsoft ensures the integrity, security, and resilience of the platform for you.
Whereas AD DS secures domain-joined devices, Azure AD secures cloud-based systems such as web apps. With Azure Web Apps, for example, they are not domain-joined to an internal network. Users may authenticate over the internet—that is, over public networks, as opposed to internal networks. As such, the protocols used must also be different—NTLM and Kerberos used in AD DS would not be suitable and, instead, traditional web protocols must be used—that is, HyperText Transfer Protocol Secure (HTTPS), as depicted in the following diagram:

Figure 3.4 – Azure AD versus AD DS protocols
Azure AD also integrates with other Microsoft online services such as Office 365. If you sign up for Microsoft Office 365, an Azure AD tenant will be created for you to manage your users. This same “tenant” can also be used to manage your Azure subscriptions and the apps you build within them.
Azure AD is distinctly separate from AD DS—that is, they are entirely different databases. However, you can link or synchronize Azure AD and your on-premises AD DS, effectively extending your internal directory into the cloud. We will cover this in more detail later, but for now, understand that although different, AD DS and cloud-based Azure AD can be connected.
Important note
Azure AD, even with synchronization, does not support domain-joining virtual machines (VMs). For domain-joined VMs in Azure, either allow AD DS traffic back to on-premises, build domain controllers within the Azure network or use Azure AD DS, which is a fully managed AD DS solution.
The following table shows some of the common differences between the two services:

An instance of Azure AD is called an Azure tenant. Think of a tenant as the user database. In the next section, we will look at tenants in more detail.