Portions of this article draw on the Uplevel AD vs. Azure AD blog post.
Introduction
Three directory products commonly come up in MSP conversations:
- On-premises Microsoft Active Directory.
- Uplevel Active Directory-compatible Directory Services.
- Cloud-based Azure Active Directory, recently rebranded as Microsoft Entra ID.
All three provide a central identity used to manage access to applications, services, and devices — but they aren’t interchangeable. Choosing well depends on whether the user population is mostly mobile/cloud-only, mostly on-prem workstations, or somewhere in between.
Capability summary
The directory products share some technology but solve different problems.
Microsoft on-premises Active Directory (AD)
Traditional AD is built around an on-premises enterprise-class LDAP server. It provides identity verification (via Kerberos), computer-object management, group policy administration (via GPOs and SYSVOL), and cross-domain trust. It’s widely used to provide core user authentication, computer management, and audited access to shared storage and applications.
Azure AD / Microsoft Entra ID
Entra ID is not a cloud version of AD. It’s an identity and authentication service aimed at mobile devices and SaaS (Office 365 and similar). It can synchronize with an on-premises AD via Azure AD Connect to give users a single identity that spans cloud and on-prem.
Core Entra ID capabilities:
- Cloud-first management with single sign-on for cloud applications.
- Conditional access policies and multi-factor authentication.
- Unified identity across many SaaS platforms.
Azure AD Domain Services (AADDS)
A third option mixes the two: Azure AD Domain Services runs an AD-like service in the cloud, offering a subset of traditional AD features (domain join, Group Policy, Kerberos) while remaining cloud-hosted. It can synchronize with Entra ID, which itself can replicate passwords with on-prem AD — three layers of synchronization end to end.
AADDS becomes a continuously billable service once set up. It can’t be paused without destroying the configuration.
Setting up and managing AADDS is technically complex; for most SMBs it’s overkill.
Uplevel AD-compatible Directory Services
Uplevel’s directory service behaves very similarly to traditional on-premises Microsoft AD. It uses Kerberos for authentication, LDAP for directory services, and supports traditional GPOs and SYSVOL for policy management.
It gives SMBs the practical core of AD — central authentication, organization-wide policy, audited access to on-prem resources — without the burden of installing and running a heavyweight Windows Server domain controller.
Where Entra ID differs from traditional AD
Under the hood, Entra ID uses an entirely different software stack and protocol set. Instead of Kerberos / NTLM and LDAP, it uses OAuth 2.0 over HTTPS to support web APIs and SaaS apps. OAuth 2.0 is fine for web and REST applications; traditional Windows applications don’t use it.
Entra ID is not Active Directory as traditionally understood. Specifically, Entra ID:
- Doesn’t have the user- and computer-management functions that traditional AD provides.
- Can’t enforce group policy — it can’t push GPOs to computers joining a domain.
- Doesn’t support OUs, so granular delegated administration isn’t possible.
- Isn’t designed to control or audit access to on-premises storage or shared printers.
- Doesn’t support replication and can’t be set up as a trusted domain.
- Has no Domain/Enterprise Admin role and no managed service accounts.
For VMs hosted in Azure, Entra ID is great — straightforward to set up, plays well with the Azure ecosystem. It is not a replacement for an actual domain controller when on-prem workstations are in scope. Entra ID’s design centre is cloud-only SSO.
Compliance — HIPAA
For HIPAA, the key gap is that Entra ID can’t control which devices (workstations, servers) are permitted to join the network. Controlling device admission is essential for HIPAA compliance, which makes Entra ID alone insufficient.
For a Uplevel-hosted small office, the Uplevel directory service covers this control, alongside the audit logging requirements described in HIPAA Compliance.
Microsoft’s own comparison of identity options is worth reading for context: https://docs.microsoft.com/en-us/azure/active-directory-domain-services/compare-identity-solutions