Back in the old days when someone referred to Active Directory, IT administrators knew they were talking about classic on-premise Active Directory, Microsoft’s LDAP directory implementation, first released with Windows Server 2000.
As the name implies, Active Directory is a directory - a data store of objects including users and computers associated with a specific organization. Properties about each are stored in the form of attributes. For a user object, obvious ones are first name, last name, company, department, email, mobile phone, etc.
With the emergence of Cloud computing, Microsoft implemented Azure Active Directory. While it shares the name Active Directory with its on-prem cousin, it should be viewed as a discrete and separate implementation of a directory. It is by no means an extension of the classic on-prem AD.
To better understand the different types of Active Directory, we need to look into each one in more detail.
First, let's look at each variation of the Active Directory family:
Active Directory Domain Services (AD DS)
This is the classic on-prem Active Directory. This is the directory service we're familiar with, and includes all the traditional objects - users, computers, groups, printers, group policies (GPO), organizational units (OU), etc. It can operate independently or in conjunction with the other types of Active Directory.
Azure Active Directory (AAD)
This is a SaaS solution designed to support cloud-based applications. It includes objects such as users, groups and devices. It's a stripped down directory that comes with Microsoft Online Services, such as Office 365. It's easy to manage, and does not have the rich feature set as compared to AD DS. It can operate independently or in conjunction with the other types of Active Directory.
Azure Active Directory Domain Services (AADDS)
This is a PaaS solution designed to eliminate the requirement to maintain domain controllers. In situations where the presence of domain services is still required (e.g. Server Infrastructure, Windows Virtual Desktop), AADDS offers a subset of the functionality of the full blown on-prem AD, but has many more features compared to AAD. It's a middle ground between AAD and AD DS. Azure Active Directory Domain Services has a dependency on Azure Active Directory - there is a one-way sync of user and group data from AAD to AADDS. Azure AD users and groups can be used to access resources created in AADDS.
Second, let's look at the permutation of Active Directory Hybrids:
Active Directory & Azure Active Directory (AD DS – AAD)
A combination of on-prem AD and Azure AD. There is limited bi-directional sync of data between the systems via Azure AD Connect. The “on-prem” domain controllers can reside in Azure making this hybrid configuration the IaaS solution.
Active Directory (in Azure) & Azure Active Directory (AD DS in Azure – AAD)
This is basically the same implementation as the one above. The only difference is that your AD DS Domain Controllers (DCs) resides in Azure. That makes this the IaaS solution since you’re not maintaining any on-prem hardware. However, you will still be patching DCs in the Cloud.
Active Directory, Azure Active Directory & Azure Active Directory Domain Services (AD DS – AAD – AADDS)
A combination of on-prem AD, Azure AD, and Azure AD Domain Services. While this implementation is technically possible, keep in mind that there is only a one-way sync between AAD to AADDS. The AADDS domain also runs on DCs that don’t communicate with the on-prem AD DS DCs. This means the AADDS domain is a separate domain from the on-prem AD DS implementation.
Azure AD Domain Services in this case is redundant due to the presence of the existing on-prem Domain Services infrastructure. There may be a limited use case for this configuration.
So essentially, there are three variations of Active Directory plus three hybrid permutations. Each of these implementations can make sense depending on an organization’s needs.
While there can be some integration between the various types of Active Directory, they should be viewed as discrete and independent from one another. The integration is limited to unidirectional and bi-directional data synchronization of subsets of object properties. In these various implementations, we do not extend our traditional AD into the Cloud. We link separate systems together.
By the way, if you haven’t started stuttering while you read this article, you’re doing better than us! If you’re still confused which permutation makes sense for your business, talk to us!