Active Directory (AD) is well understood. It’s been around for decades and Microsoft shops know what it does and how to work with it. A Windows admin who’s not familiar with cloud directory functions will naturally be hesitant to change. This “translation” guide is a resource for comparing familiar AD terminology with the cloud equivalents.
It’s not always a direct comparison. Cloud architecture, device, and resource management also solve modern problems. A Microsoft shop may feel as if the cloud is Venus and AD is Mars, but that’s because the terminology is different and a few of the concepts might be less familiar.
This guide is a Rosetta stone to help you understand the concepts and terms that are specific to AD and the cloud. The platforms aren’t as different as they might seem, and they’re interoperable. They fall under the umbrella of identity and access management (IAM), for both users and devices, which provides access control and management for your resources using trusted industry standards.
A cloud directory is based on LDAP, but also utilizes web protocols including OIDC, SAML, and modern authentication for secure single sign-on (SSO) across domains. A cloud directory also centrally manages IAM by extending to your complete infrastructure. This section illustrates the fundamental concepts for authentication and how cloud directories strengthen it.
Kerberos (ports 88, 464) is the primary authentication protocol for hosts to prove their identities in AD. Add-on components are necessary for web SSO. It’s vulnerable to several known methods of attack, including Kerberoasting, Golden Tickets, Pass the Ticket, et al.
Cloud directories frequently utilize HTTPS/TLS (port 443), OpenID Connect (OIDC), and Security Assertion Markup Language (SAML). These provide SSO for web apps and more. Vendors may support networking protocols including LDAP, RADIUS, and SSH.
Windows New Technology LAN Manager (NTLM) protocols remain in use to provide authentication, integrity, and confidentiality to Windows users. Microsoft recommends using Kerberos but it still supports NTLM.
NTLM authentication is possible through managed local users via a cloud directory. A cloud directory layers additional security onto authentications through managed devices and multi-factor authentication (MFA).
AD utilizes a proprietary implementation of LDAP (ports 389, 636) to store data about devices, users, and other objects for AD. LDAP can authenticate and authorize user access to IT resources.
LDAP is an important component of a cloud directory, and it’s read-only for added security. A cloud directory may more closely mirror RFC specifications for LDAP using the currently supported OpenLDAP schema (version 3.0). LDAP bind DN may be used to authenticate users to applications/devices when LDAP is enabled for a group of users. The key difference to AD is that MFA may also be configured for LDAP authentications as a conditional access policy for a single app or as a global policy for all LDAP apps.
Active Directory Certificate Services (AD CS) is a Windows Server role that must be set up and supported in order to issue and manage public key infrastructure (PKI) certificates (ports 2560, 9389).
A cloud directory may include its own certificate authority, available without the requirement to manage additional infrastructure. This enables certificate-based authentication for RADIUS. Device trust certificates are used with conditional access.
SAML is not supported natively. AD FS or integration with web services are required.
The SAML protocol authenticates users to web-based applications and is typically a standard capability in a cloud directory.
OIDC is not supported natively. AD FS or integration with web services are required.
OIDC extends the OAuth protocol so that client services (your applications) verify user identities and exchange profile information through OpenID providers via RESTful APIs that dispatch JSON Web Tokens (JWTs) to share information during the authentication process. Not all cloud directories support OIDC for SSO.
AD can store public keys, but it’s necessary to create a Certificate Snap-in in Microsoft Management Console (MMC), port 9389.
SSH key management is cloud native.
There is no native equivalent for WebAuthn. Add-on services and software components are required. Supply chain assurance is an important factor to consider when third-party software is installed on domain controllers.
WebAuthn is a core component of the FIDO2 Project, which enables hardware security keys. It’s supported by some, but not all, cloud directories.
There is no native equivalent for device biometrics. Add-on services and software components are required. Supply chain assurance is an important factor to consider when third-party software is installed on domain controllers.
Out-of-the-box support for device biometrics can secure logins into sensitive resources.
There is no native equivalent for phishing-resistant and passwordless authentication flows. Add-on services and software components are required. Supply chain assurance is an important factor to consider when third-party software is installed on domain controllers.
Cloud directories may incorporate phishing-resistant modern authentication and more passwordless workflows.
There is no native equivalent to conditional access. Add-on services and software components are required. Supply chain assurance is an important factor to consider when third-party software is installed on domain controllers. This impedes Zero Trust security strategies.
Conditional access uses signals and telemetry to restrict access control to users that are located in a specific place, are within a defined IP range, and that devices are within a trusted state to access sources. They can also be used to create global MFA policies.
A cloud directory doesn’t require VPN infrastructure to support remote workers; all web traffic occurs over port 443 across network boundaries.
An organization with expert-level knowledge can leverage AD for strong access control. That can be important for scenarios where regulations require that authentication occurs on-premises.
However, cloud directories can feature more modern and mature approaches to entitlement management that reduce the likelihood of human error leading to account compromise.
An access control list (ACL) contains entries that define who has access to objects and the level of access that they should have. This process can involve using and understanding the PS Get-ObjectAcl cmdlet.
Advanced lifecycle management provides more mature privilege management by leveraging attribute-based access control (ABAC). Users are not only assigned rights; automated lifecycle management can make a designated action when changes happen to attributes or within human resources systems.
Role-based access controls (RBAC) may also provide fine-grained access to resources and determine what can be done with them. SCIM integrations will provision and sync users, attributes, and groups, which automates the setting and management of privileges in SaaS applications.
Security Groups assign users and resources permissions to access shared IT assets. User assignments are manual without add-ons or extensive customizations.
Cloud directories also use groups to assign user permissions and access to shared IT resources. They just work a little bit differently and can provide more automation.
Nested groups make one AD security group a member of another, which may be useful for user provisioning for specific roles/functions. It’s convenient, but best practices for groups should be followed to avoid security breaches or overprovisioning.
Cloud directories can utilize dynamic groups to make assignments. However, some directories such as Entra ID limit these capabilities, depending upon licensing tiers.
Automatic user provisioning to resources is not natively supported. AD must be extended with either internal solutions that use the LDAP_SERVER_DIRSYNC_OID control or the purchase of a separate Identity Management solution.
Built-in SCIM capabilities automate sending user attributes, roles information, and group membership which are needed for granular authorizations to resources. It also enables automatic deprovisioning. Reports provide an audit of what users have access to and from what group.
Group scopes determine how widely a group is used in a domain or forest. There are three types: universal, global, or domain local. Many organizations have benefited from this hierarchical structure.
Some cloud directories can assign specific roles and users, whether internal or external identities, to organizational units, application registrations, or groups. Likewise, a multi-tenant portal may provide specific permissions and access levels for admin users across domains.
Groups are typically created at an organization level. The scope of the group is determined by the resources to which the group is associated and the roles and policies that may be applied.
Active Directory manages endpoints running Windows, and their access to network resources, through Group Policy Objects (GPOs). MMC snap-ins provide GUIs for admins to manage users and computers. It must be extended by software and services to manage non-Window devices.
A cloud directory may have unified endpoint management (UEM) to manage every operating system, and also integrate with AD in a hybrid configuration. Others utilize point solutions.
Active Directory Users and Computers is a tool for account creation and the management of directory objects such as contacts, computers running Windows, folders, groups, and printers. It’s one of several tools that can be used to manage AD.
Alternatively, directory integration maintains AD’s management of those resources. SSO can also be leveraged to integrate with cloud file and printer management services.
Group Policy Management Console (GPMC) is a snap-in that enables admins to manage Group Policy Objects (GPOs) across all OUs, domains, and sites. It’s also used to enforce policies for Windows endpoints.
This isn’t required in a cloud directory. Devices and policies are managed via UEM blades in the interface.
Group Policy Objects (GPOs) are a virtual collection of settings that define policies for computer and user accounts on Windows endpoints. GPOs have unique identifiers and contain policy settings for AD and applied to the Registry in Windows. The Group Policy Object Editor tool is recommended to define Group Policy.
A cloud directory may have predefined, point-and-click policies or interfaces for advanced registry settings and templates.
GPO Inheritance determines which settings apply where. It’s flexible, but may become complex within more expansive setups.
A cloud directory provides a clear policy to device mapping through the UI, i.e., it’s more searchable, to avoid getting lost in the nested hierarchy.
Policy processing establishes a hierarchy for how the AD system processes GPOs. The order is local, site, domain, and then organizational unit.
A cloud directory provides a clear policy to device mapping through the UI, i.e., it’s more searchable, to avoid getting lost in the nested hierarchy.
Policy templates can be deployed in AD in the form of a Group Policy administrative template (.adm). Per Microsoft, ADM files describe where registry-based policy settings are stored in the registry.
Cloud directories may provide policy templates and/or can import policies from Administrative Template files, depending on the vendor.
The Windows Registry is a central hierarchical database that stores information about applications, hardware, settings, and users.
Cloud directories leverage the Registry to store policies and settings, same as AD.
AD doesn’t use agents on Windows and doesn’t support non-Windows devices such as macOS and Linux.
Agents are used by UEM systems to deploy applications, collect telemetry for reporting, execute commands, and enforce policies on endpoints.
Windows 10/11 supports MDM, but AD doesn’t provide those devices.
MDM, or mobile device management, is a methodology to deploy apps, policies, and control endpoints. Several operating systems, including macOS and Windows, have built-in interfaces for this purpose. MDM provides tamper-proof compliances on devices.
AD doesn’t support managing Android devices.
Enterprise mobility management (EMM) manages and secures data on Android devices. Android Enterprise is a platform that’s open to EMM providers.
AD doesn’t support managing Apple devices.
Automated Device Enrollment (ADE) is a feature of Apple’s Apple Business Manager system for MDM that allows for zero-touch device onboarding. This is particularly useful for when an organization has bulk apps and licensing requirements.
Security groups in AD may be added to a GPO.
Policy Groups are used by cloud directory to add preconfigured policies to devices. These may include patching policies or settings.
AD makes it possible to trigger an event via audit account management when a computer is created. Creating a task or script ensures that the command(s) will run.
Command triggers are used to automate system management actions within cloud directory that have integrated UEM. These require fewer steps than AD, but some of the steps (such as scripting) use existing skills.
Cloud directories and on-premise AD environments leverage LDAP, so they follow the same standard at a high level. However, there are a few key lower-level differences in the platform architectures as well as the presence of uniquely Microsoft components with AD.
Active Directory Domain Services (AD DS) is an AD server role that provides a central database that serves as the foundation for a local Windows network.
This installation isn’t required with a cloud directory. Cloud directories are domainless and users and devices are untrusted by default, which is in alignment with a Zero Trust security strategy.
A domain controller is a server that controls a Windows network and has a single database for user and service authentications.
A cloud directory organizes a single organization into a tenant. There may be more than one authentication database when identity federation or synchronization is enabled.
A domain tree is a collection of one or more domains with a common namespace. For example, a subdomain, or branch of the same company. A collection of trees is called a forest, and can have different name spaces. For instance, a company might have acquired another with an entirely different domain.
Cloud directories are domainless. They can support any number of domains and subdomains. Therefore, there is no equivalent in a cloud directory. However, device groups can be configured to manage users who are working at different locations, and in some cloud directory instances, organizational units or access packages set entitlements for external collaboration. The directory is essentially any overlay where accounts from AD, Google Workspace, and other sources can all be managed.
Functional levels determine which domain (or forest) enterprise features can be used within a domain.
The subscription or tier of service controls the functionality that can be used within the cloud directory.
Organizational units are containers within AD for computers, groups, and users. It’s the most granular unit within the AD architecture.
Some cloud directories feature administrative units or organizational units, but those do not support GPOs. They serve as a container for users and groups that are under the scope of management.
A global catalog is an AD feature that enables a domain controller to pull information about a domain within a forest. The object may fall outside of a given domain. It’s used for authentication. This is common when multiple domains exist.
Cloud directories integrate identities through directory and HR system syncs or federation through web standards. Multiple domains can reside within the same organization. In a domainless cloud directory, objects are not separated based on domains.
All objects within a tenant can be accessed via whatever means the cloud directory provides. A cloud directory provides more choice for which identity provider is selected. Some cloud directories incorporate external domains as managed identities using RBAC or guest users via access packages.
Objects are virtual entities that represent resources such as computers, printers, and users/groups. These can be single assets or a container of objects, such as OUs.
Cloud directories also use objects. Typical objects are users, devices, and specific resources.
A distinguished name (DN) defines identities in an LDAP directory.
Cloud directories also utilize DNs. The formatting may be different, but can be easily mapped.
AD uses userPrincipalName (UPN), a user name formatted with an email domain.
A cloud directory can map user names to UPNs when it’s importing accounts from AD.
An objectSID is an attribute/property that AD DS stores as a unique identifier for local accounts and groups.
An objectGUID, or Globally Unique Identifier, is a system-generated value that serves a similar purpose in cloud directories.
High availability can be established when there are multiple AD domain controllers. Admins must update and maintain servers, backup, and network components.
Cloud directories provide scalability and availability by default without additional infrastructure to configure and support.
Attributes are information about the properties of objects.
Attributes also exist in cloud directory, with the difference being that dynamic groups leverage them to automate lifecycle management. Attributes are usually mapped between directories.
Active Directory Federation Services (AD FS) is required for identity federation.
A cloud directory may have federation to interoperate with other identity providers (IdP) or to provide pass-through authentication for AD to help modernize it for your digital estate.
AD doesn’t sync with cloud directories without agents being installed onto domain controllers (or other servers) to synchronize with web services.
A cloud directory syncs with other directories and identity providers using standard networking and web protocols. No additional infrastructure is required.
Reporting and Auditing
Microsoft shops have turned to various workarounds or add-ons to produce reports. You may have a SQL guru on staff, or a PowerShell pro, or turn to any of the available free and commercial reporting add-ons.
Cloud directories, by contrast, have auditing and reporting interfaces with the capacity to export logs.
AD admins often require third-party tools to query directory objects. AD relies on EventsLog on the server(s) side and on the device side. Reporting from remote laptops to an ELK stack may be less secure due to the lack of physical security and write API key.
Cloud directories provide information on devices, directory events, and more. JumpCloud’s Directory Insights is an event logging and compliance feature that provides an audit trail for critical events.
The PowerShell Get-ADUser cmdlet is often used by admins to search for user objects.
A web GUI and reports contain pertinent information about users. Some cloud directories also include PS modules.
Active Directory Users and Computers can be used to manage and search for AD directory objects by type. Admins sometimes turn to trusted workarounds such as using SQL Server to streamline the process.
Cloud directories include interfaces for devices and users, beyond Windows, and beyond a single identity provider or directory.
AD only supports Windows, but stores information about assets such as files, hardware, and software. A separate security information and event management (SIEM) system may be necessary to track events. Windows Server records events to Directory Services or LDS instance log in Event Viewer.
JumpCloud’s System Insights extends device management by providing telemetry across your fleet of macOS, Windows, and Linux devices. Other cloud directories that integrate device management may capture telemetry.
These reports aren’t available in AD, because it doesn’t support SSO and other modern directory features.
Cloud directories include pre-built reports for compliance and auditing purposes. These may include information about: Devices, Directories, RADIUS Servers, LDAP, User to SSO Applications, OS Patch Management Policy, Browser Patch Management Policy, and Users to User Groups.
Deployment is the clearest distinction between these directory paradigms: a cloud directory can work without setting up, managing, and supporting your own server infrastructure.
A cloud directory provides high availability and scalability by default. There are also differences in how endpoints are managed, because AD only supports Windows, and uses modern device management for Windows (along with the option to select templates or create Registry policies).
A domain controller must be deployed to run the AD DS server role.
A cloud directory doesn’t require a domain controller.
Schema can be used to provide fine-grained customizations for object classes within the LDAP database. For instance, an organization may need custom attributes.
Cloud directory users can be decorated with a series of predefined or custom attributes. Mapping may be required for other directories or to consume attributes from network protocols.
Computers running Windows are joined to AD, either through settings or CLI, which then creates an account for it in the domain. Non-Windows endpoints require integrations with cloud services and/or UEM solutions.
Cross-OS MDM and EMM enrollments are available to join endpoints to the cloud directory. Agents provide another option, and in the case of Windows, may be used in unison with MDM to extend system management via remote assistance, sudo terminal (or PowerShell) commands, reporting, and more.
Active Directory Lightweight Directory Services (AD LDS) is a standalone LDAP server that can provide a dedicated directory for applications and application data. It’s usually installed on a server that’s not a domain controller.
A cloud directory can register LDAP and SSO applications without a dedicated mode. Additional servers are not required.
Read-Only Domain Controller (RODC) is an alternative type of domain controller that has read-only AD DS partitions to enhance security for remote workers or as a control for limited physical security.
It’s commonly used in scenarios where quick logins are needed. RODC may create challenges when there are changes happening in the “remote office” (i.e., a new device joining domain). It has to be repopulated on a writable domain controller.
A SaaS directory does not have a physical infrastructure presence by default, which removes a part of the concern RODC was designed to address. It takes away the physical infrastructure burdens from the users, and offers equal security/manager abilities to the end user directly.
Commercial cloud datacenters have professional security staff and highly credentialed security teams. Aspects of the cloud directory, such as LDAP authentication, is read-only by default.
AD DS uses Domain Name System (DNS) so that clients can locate domain controllers. It also responds to DNS queries from clients. It’s important to harden DNS zones in AD to avoid potential security threats. Mistakes in DNS configurations are one of the most common reasons for non-performance in AD.
DNS is commonly managed by network hardware. An IT team could also keep a domain controller to manage DNS or select a cloud-based DNS provider. Many offer reliable, low-latency services.
Active Directory replication is used to keep data in sync between domain controllers. It uses Remote Procedure Call (RCP) over IP. It’s particularly useful for failover scenarios such as taking a datacenter offline for patching. IT shops are obligated to manage network and server infrastructure, security, and support.
A cloud directory provides automatic high availability, and there’s no need to do this.
Cloud directories provide hosted instances of commonly used network protocols.
The Network Policy Server (NPS) server role must be installed and supported for RADIUS authentications. This may be required for VPNs. There is no MFA out of the box.
A cloud directory may offer Cloud RADIUS and Cloud LDAP without additional setup. MFA is environment-wide. Some identity providers charge extra for these services or require integrations.
AD is very extensible, but its total cost of ownership rises as it becomes more complex and requirements increase.
A cloud directory features capabilities that most small and medium-sized (SMEs) would require to manage their IT infrastructure and integrates with services via APIs and SSO.
Microsoft Management Console (MMC) snap-ins are tools that are hosted in MMC. MMC provides a framework for these add-ons that usually help consolidate management tasks. However, it’s not necessarily a centralized management console: you must know where to look first.
Management capabilities and services such as a certificate authority are included in cloud directories, in one place. APIs may be leveraged for more specific use cases. Management capabilities can be accessed from either the UI or API for cloud directories.
Commercial add-ons make it possible for AD to be used as a source of truth for identities within modern IAM and UEM infrastructures.
SSO and security features such as modern authentication are included by default. JumpCloud integrates UEM into its directory and leverages standard mechanisms such as MDM and EMM for system management. Agents extend security and support via patch management and remote assistance.
Microsoft built out robust management tools for AD over decades where IT requirements changed from single domains to distributed workforces and many apps migrated to the cloud.
A cloud directory had the benefit of being more modern and reimaging management interfaces.
Active Directory Administrative Center (ADAC) is a feature of Windows Server that was created to ease AD’s administrative burden for managing directory objects. It’s a GUI that sits on top of PowerShell.
A cloud directory unifies user and device management into an easy-to-use UX. Commands are also available.
Active Directory Service Interfaces Editor (ADSI Edit) is a snap-in that’s used to edit attributes and objects that may not be exposed through more commonly used tools such as AD Users and Computers or AD Sites and Services. It can work across different network resources.
A cloud directory unifies user and device management into an easy-to-use UX. Commands are also available.
Active Directory Sites and Services is a snap-in that creates and manages sites (i.e., as network topology and subnets) and how directory replication is configured and managed for domain controllers at different sites.
AD Sites and Services is about optimization and reliability when organizations are spread out by linking DCs and replicating data between them.
Cloud directories are domainless. The directory of objects is available from anywhere in the world as long as there is an internet connection. A cloud directory unifies user and device management into an easy-to-use UX. Commands are also available. Cloud directories optimize performance by having servers in key geographical locations to provide shortest path routing. In short, cloud directories handle the performance and reliability for organizations.
Active Directory Web Services (ADWS) provides a web interface for AD DS and AD LS that are running on a local server within your network. This makes it possible for AD to communicate with external web apps over the WS-Fed protocols. These protocols are much less supported by SSO applications than SAML or OIDC. Certificate Services are recommended to secure credentials passing over the communications channel.
SSO protocols are included in cloud directories, over port 443, and admins don’t require any special server to access their organizations. JumpCloud offers the most popular standards: SAML 2.0 and OIDC. It also supports SCIM/JIT provisioning for hundreds of popular SaaS apps.
Remote Desktop Protocol (RDP) provides a way to connect to remote computers and servers over a network. A VPN may be required to access domain resources as well as RDP client/server software and licenses.
Free cross-OS remote assistance is built into the JumpCloud platform for all supported desktop operating systems. It works over port 443 without any VPN being required and in a browser tab. It’s possible for admins to configure advanced features such as unattended sessions.
GPOs may be used to deploy application patches and updates, but more commonly, patching solutions are integrated with AD.
Application catalogs or custom repositories can be used to deploy applications and keep them up to date. Some directories include integrated application lifecycle management.
PowerShell is frequently used to execute commands against AD and joined PCs.
Sudo access to run scripts and commands is featured in some cloud directories, sometimes including a virtual command line.
Many organizations configure and deploy ConfigMgr (better known as SCCM) as part of their AD infrastructure. There are various licensing, site, and site system prerequisites. Systems and apps can be patched this way.
OS and browser patch management is built into JumpCloud to enhance compliance and security down the stack. Browser vulnerabilities are increasingly a cause for security concerns. There’s no need to set up and maintain a patching server infrastructure.
Contact us for a free demo and learn more about how to modernize Active Directory with JumpCloud. To learn more about JumpCloud versus Microsoft’s Entra ID (Azure AD) with Intune, please contact us or join our community for conversations with other IT admins who have similar interests.