On-premises Microsoft Active Directory, Uplevel Active Directory compatible Directory Services, and cloud-based Azure Active Directory, all provide a central identity that can be used to manage user access to applications, services, or devices. They allow system administrators and Managed Service Providers the ability to centrally control large collections of user devices.
This choice in identity solutions offers the flexibility to use the most appropriate directory service for your organization’s needs. For example, if you mostly manage cloud-only users that run tablets or other mobile devices, Azure Active Directory (AAD) might be sufficient. However, if your user population requires workstations or laptops with centrally administered policies, audited access to resources, and high security levels, on-premises Active Directory (AD) will most likely be required. This document describes the use cases for each of these solutions.
High-Level Capabilities
Active Directory-based identity management from Microsoft and Uplevel share some common technologies; however, the various solutions serve different purposes and therefore offer different capabilities.
Traditional Microsoft Active Directory Compatible Domain Services (AD) is built around an on-premises enterprise-class LDAP server. LDAP provides key features such as identity verification (with authentication via Kerberos), computer object management, group policy administration (via GPOs and sysvol), and trust maintenance. AD is widely used in a huge range of organizations to provide core user authentication and computer management, as well as to provide audited and controlled access to critical resources such as company data storage and applications.
Azure Active Directory (AAD) is not merely a cloud-based implementation of AD. It is primarily aimed at user account and authentication services for mobile devices, and for mediating access to resources such as Office 365 and other SaaS applications. AAD can be synchronized with an on-premises AD environment to provide a single identity to users that works for both cloud and on-premises situations. Microsoft provides a software add-on called Azure AD Connect to help perform this integration.
A third alternative exists: Azure Active Directory Domain Services (AADDS). This mixes the functions of an on-premises AD service with a cloud-based AAD service. It provides a subset of traditional AD features such as domain join, group policy, and Kerberos authentication, while still residing in the cloud. It can integrate and synchronize with AAD (which itself can replicate passwords with on-premises AD!). However, configuring and managing such a complex environment is technically challenging. Also note that AADDS, once set up, is a continuously billable service (i.e., it cannot be turned off without destroying the setup).
Uplevel Active Directory compatible Domain Services behaves very similarly to traditional Microsoft on-premises Active Directory (AD). It uses Kerberos as its authentication protocol, LDAP for directory services, and supports the traditional GPOs and sysvol for policy management. It gives small and midsize organizations most of the key capabilities of Microsoft Active Directory: the ability to gain control over their on-premises devices and applications by authentication, company-wide policy management, and mediating access to company resources. At the same time, it avoids the need to install and maintain a heavyweight enterprise-class server, and greatly simplifies management.
Differences Between Azure AD and Traditional AD
Unlike traditional AD, AAD uses an entirely different software stack and an entirely different set of protocols. Rather than Kerberos/NTLM and LDAP, AAD uses OAuth2 over HTTPS to support web-based APIs and cloud applications. OAuth2 can be used to perform authentication and authorization in most application types, but is mainly used by web apps and modern REST API equipped applications. Traditional applications do not use OAuth2 flows or HTTPS transports.
However, unlike Uplevel Active Directory, AAD is not Active Directory as we traditionally know it. For example:
- AAD does not have the user and computer management functions expected from traditional AD.
- AAD cannot enforce group policies (beyond basic user authentication policies): for instance, it cannot push GPOs to computers joining a domain.
- AAD is not intended to control and audit access to on-premises storage, or control access to resources such as printers.
- AAD does not support replication, and cannot set up as a trusted domain to other domains; further, it has no Domain/Enterprise admin privilege, and does not support managed service accounts.
While AAD is great for virtual machines hosted in Azure – it is simple to set up and works well with your Azure domain – it does not replace a proper domain controller. AAD is mainly intended to support a cloud-only strategy where Single Sign On (SSO) is the key focus.
Recent Comments