There are several ways you can leverage Active Directory in today’s cloud-centric world. This article hopes to demystify your Active Directory options and provide you some guidance around what might best suit your business best.
Azure Active Directory (AAD)
If you are using Office 365 or Azure today, you already have an Azure AD tenant. Azure AD is provided as a service and is fully integrated into the Azure Portal. Microsoft describes it as a cloud-based identity and mobile device management service that provides user account and authentication services for resources such as Microsoft 365, the Azure portal, or SaaS applications. Azure AD supports modern internet friendly authentication protocols such as SAML 2.0, OpenID Connect, OAuth 2.0, and WS-Federation.
Azure AD is native to Azure and does not contain all the features of a traditional Active Directory domain. Its primary job is as an Identity provider, and it is lacking features such as Group Policy. Such features are delivered differently from Azure, in the case of Group Policy, Microsoft Endpoint Manager (Intune) is its new cloud native replacement.
Azure AD is a requirement of Azure and Office 365 and is automatically provisioned by Microsoft. It may be enough for your business if you are not already running a traditional Active Directory domain, and you don’t have any applications or services that leverage it.
Where Azure AD cannot meet your needs on its own, Microsoft has options to support several different Active Directory environments in parallel, and through synchronisation, provide a common set of users, groups, and credentials across them all. You’ll learn more about these options throughout in the article.
Traditional Active Directory Domain Services
Active Directory Domain Services (ADDS) is what I call a traditional Active Directory domain. ADDS is an LDAP server that provides key features such as identity and authentication, computer object management, group policy, and trusts. Originally, such a domain would have been run on-premises, but today there are several options that provide much the same features:
- A self-managed domain running on Windows Server with Active Directory Domain Services (ADDS). You may run the domain on-premises, cloud, or both. You self-manage and administer these resources yourself.
- A managed domain that you create using Azure Active Directory Domain Services (AADDS). Microsoft creates and manages the required resources. AADDS provides managed domain services with a subset of fully compatible traditional ADDS features such as domain join, group policy, LDAP, and Kerberos / NTLM authentication.
In either case, unlike Azure AD, you can support Kerberos and NTLM authentication protocols to support legacy applications and services. You can also continue to leverage Group Policy.
Key feature differences:
| Feature | Azure ADDS | Self-managed ADDS |
| Managed Service | Y | N |
| Domain or Enterprise administrator privileges | N | Y |
| Schema extensions | N | Y |
| AD domain / forest trusts | Y (one-way outbound forest trusts only) | Y |
Learn more about the differences here.
Self-Managed Domain – Windows Server Active Directory Domain Services (ADDS)
This is where you self-manage a Windows Server based Active Directory Domain. Businesses have been running this model for many years, and it will be where most have started. Originally these would have been run on-premises, but today they could be hosted in the cloud too; either way the principle is the same.
If you are not in this deployment scenario already, you would be unlikely to go this route. Reasons you might deploy this model:
- You have on-premises hardware to sweat
- You require legacy authentication protocols (Kerberos / NTLM) to support legacy applications
- You wish to leverage AD Schema extensions
- You have a requirement for AD domain or forest trusts
Still, if you are deploying ADDS greenfield, there are better options.
Managed Domain – Azure Active Directory Domain Services (AADDS)
Like Windows Server Active Directory Domain Services, AADDS provides a subset of fully compatible traditional Active Directory features such as domain join, group policy, LDAP, and Kerberos/NTLM authentication. The difference is that it is delivered and managed by Microsoft in Azure as PaaS:
- Microsoft manages the Domain Controllers
- There is no Enterprise or Domain Admin level access, and management permissions are delegated in Azure
- Domain Controllers are patched automatically
- Secure locked-down domain that is compliant with AD deployment best-practices
- Fault resilience of Azure
- Automatic health detection & remediation
- Automatic backups for disaster recovery
- No need to monitor replication to DC’s
- Highly Available domain
- Azure AD automatically syncs to AADDS and there is no need to run Azure AD Connect
Out of the box, an AADDS managed domain performs an automatic one-way synchronization from Azure AD to provide access to a common set of users, groups, credentials, and attributes. You can create resources directly in the AADDS domain, but they cannot be synchronised back to Azure AD. Applications, services, and VM’s in Azure that connect to the AADDS domain can then use features such as domain join, group policy, LDAP, and Kerberos/NTLM authentication; You get the benefits of cloud with the ability to the run legacy apps and services that are not built for modern alternatives such as Azure AD and Microsoft Endpoint Manager (Intune). You also get Azure-local directory lookups which avoid having to route back to an on-premises ADDS environment. It’s also with noting that an AADDS managed domain is a stand-alone domain and is not an extension of your Azure AD or on-premises domain.
Reasons you might deploy this model:
- You want to transition on-premises services to the cloud but have a need for a traditional domain e.g. applications or services that require legacy authentication protocols (Kerberos / NTLM) or you require Group Policy
- You are running an on-premises domain but have services running in Azure that would benefit from a local domain e.g. local connectivity and resiliency
Azure Active Directory Synchronisation Options
Azure Active Directory Synchronisation gives you a flexible way to leverage Active Directory services depending on where you are on your journey to the cloud. The following options are ways you can synchronise across different Active Directory environments to provide a common set of users, groups, and credentials.
Hybrid
A Hybrid AD environment comprises an on-premises Windows Server Active Directory Domain Services (ADDS) domain which synchronises to Azure Active Directory (AAD) using Azure Active Directory Connect. In this case:
- User identities are sourced from Windows Server AD
- Desktops/Servers are domain joined to Windows Server AD or Azure AD
Cloud-only
A Cloud-only AD environment comprises an Azure Active Directory Domain Services (AADDS) domain which automatically synchronises from Azure Active Directory (AAD). In this case:
- User identities are sourced from Azure AD
- Desktops/Servers are domain joined to Azure ADDS or Azure AD
Combined
You can also combine a Hybrid and Cloud-only environment. In this case Azure AD sits in the middle – the on-premises AD environment synchronises to Azure AD using Azure Active Directory Connect. The Azure ADDS domain synchronises from Azure Active Directory (AAD). In this case:
- User identities are sourced from Windows Server AD
- Desktops/Servers are domain joined to Windows Server ADDS, Azure ADDS or Azure AD
What’s not synchronised?
The following objects or attributes aren’t synchronised from an on-premises ADDS environment to Azure AD or Azure ADDS:
- Excluded attributes: You can choose to exclude certain attributes from synchronising to Azure AD from an on-premises ADDS environment using Azure AD Connect. These excluded attributes aren’t then available in Azure ADDS.
- Group Policies: Group Policies configured in an on-premises ADDS environment aren’t synchronised to Azure ADDS.
- Sysvol folder: The contents of the Sysvol folder in an on-premises ADDS environment aren’t synchronised to Azure ADDS.
- Computer objects: Computer objects for computers joined to an on-premises ADDS environment aren’t synchronised to Azure ADDS.
- SidHistory attributes for users and groups: The primary user and primary group SIDs from an on-premises ADDS environment are synchronised to Azure ADDS. However, existing SidHistory attributes for users and groups aren’t synchronised from the on-premises ADDS environment to Azure ADDS.
- Organization Units (OU) structures: Organizational Units defined in an on-premises ADDS environment don’t synchronise to Azure ADDS.
Domain Join: Azure AD vs Active Directory Domain Services
| Aspect | Azure AD-joined | ADDS-joined |
|---|---|---|
| Device controlled by | Azure AD. | Azure/Windows Active Directory Domain Services (ADDS). |
| Representation in the directory | Device objects in the Azure AD directory. | Computer objects in ADDS. |
| Authentication | OAuth / OpenID Connect based protocols. | Kerberos and NTLM protocols. |
| Management | Mobile Device Management (MDM) software like Microsoft Endpoint Manager (Intune). | Group Policy |
| Networking | Works over the internet. | Must be connected to, or peered with, the virtual network where the domain is deployed. |
| Great for… | End-user mobile or desktop devices. | Legacy applications and services. |
Learn more here.
Conclusion
Hopefully, you now have a better idea of Microsoft Active Directory deployment options and when you might use what. Understanding these options will help you plan your migration towards the cloud.
If you would like to learn more, I found the following video extremely useful:
