Directory Services: Active Directory vs. Entra ID vs. LDAP

What Is a Directory Service and Why Does It Matter?

A directory service is a central database that stores and manages information about users, computers, groups, and other objects in a network. It answers the fundamental question of any IT infrastructure: who are you, and what are you allowed to do?

Without a directory service, every system would need to maintain its own user management. Every server, every application, and every service would have its own database of usernames and passwords. The result would be chaos: inconsistent accounts, orphaned credentials, and uncontrollable permissions.

The directory service centralizes this task. A user is created once, assigned to one or more groups, and all connected systems use this central dataset for authentication and authorization. When the user leaves the organization, their account is deactivated in one place, and access to all connected systems is revoked.

For your ISMS, the directory service is a critical system. It controls who has access to which resources and is thus the technical foundation for your authorization concept, your access policy, and your user lifecycle management. ISO 27001 does not address directory services directly, but the requirements from Annex A.5.15 (Access Control), A.5.16 (Identity Management), A.5.17 (Authentication Information), and A.5.18 (Access Rights) are virtually impossible to implement without a functioning directory service.

Active Directory: The On-Premise Standard

Active Directory (AD) was introduced in 1999 with Windows 2000 Server and has since been the de facto standard for identity management in Windows-based enterprise networks. After over 25 years, more than 90 percent of Fortune 1000 companies use Active Directory worldwide, and it is by far the most widely used solution among mid-market companies as well.

Architecture and Core Concepts

Active Directory is based on a hierarchical structure of Forests, Domains, and Organizational Units (OUs). A Forest is the top-level security boundary and encompasses one or more Domains. A Domain is an administrative area with its own users, computers, and policies. OUs are containers within a Domain used for organizational structuring.

Each Domain is served by at least one Domain Controller (DC), a server that stores the AD database and processes authentication requests. Replication between multiple Domain Controllers ensures fault tolerance and load balancing. If one DC fails, the other DCs take over its function.

Authentication: Kerberos and NTLM

AD primarily uses the Kerberos protocol for authentication. Kerberos is based on a ticket system: the user authenticates once with the Key Distribution Center (KDC) on the Domain Controller and receives a Ticket-Granting Ticket (TGT). With this TGT, they can request Service Tickets to access other resources without entering their password again. This is single sign-on at the network level.

NTLM is the older authentication protocol, still supported for compatibility reasons. NTLM is significantly less secure than Kerberos and is vulnerable to relay attacks and pass-the-hash attacks. In a hardened AD environment, NTLM should be disabled as much as possible.

Group Policies

Group Policies are one of the most powerful features of Active Directory. They enable centralized configuration of security settings, software deployment, and user environments for thousands of computers and users simultaneously.

Through Group Policies, you can enforce the password policy (minimum length, complexity, expiration), configure the local firewall, control software installation, lock USB ports, enforce BitLocker encryption, set Windows Update settings, and restrict access to certain system settings, among other things.

Group Policies are linked to Domains, Sites, or OUs and inherit hierarchically. A Group Policy Object (GPO) linked to the Domain applies to all computers and users in the Domain. A GPO linked to an OU applies only to the objects in that OU and its sub-OUs.

Strengths and Weaknesses of AD

The strengths of Active Directory lie in its deep integration with the Windows ecosystem, its powerful Group Policy system, proven Kerberos authentication, and the extensive expertise available on the market.

The weaknesses emerge with modern requirements. AD requires on-premise servers that must be maintained, patched, and secured. Connecting SaaS applications requires additional infrastructure (ADFS or Entra Connect). Administration is complex and requires specialized expertise. And security depends heavily on hardening: a poorly configured AD is an easy target for attackers.

Entra ID: The Cloud-Native Alternative

Microsoft Entra ID (known as Azure Active Directory until 2023) is Microsoft's cloud-based identity service. It is important to understand that Entra ID is not "AD in the cloud." It is a standalone service with its own architecture, its own protocols, and its own feature set.

Architecture and Core Concepts

Entra ID organizes identities in Tenants. Each Tenant is a dedicated instance of the Entra ID service owned by an organization. Within a Tenant, there are users, groups, applications, and roles — but no Forests, Domains, or OUs in the AD sense.

The structure is flatter than in AD. Instead of a hierarchical OU structure, Entra ID uses Administrative Units, which are less flexible. Permission management is primarily through Roles (RBAC) and Conditional Access Policies, not through Group Policies.

Authentication: OIDC and SAML

Entra ID uses modern authentication protocols: OpenID Connect (OIDC) for authentication and OAuth 2.0 for authorization. SAML 2.0 is supported for integration with enterprise applications. Kerberos and NTLM are not natively supported but can be provided via Entra Connect for hybrid scenarios.

Support for modern protocols makes Entra ID the natural choice for cloud applications. Integration with Microsoft 365, Azure services, and thousands of SaaS applications is done through standardized protocols and is set up in most cases with just a few clicks.

Conditional Access

Conditional Access is the cloud-world equivalent of Group Policies, but with a different approach. Instead of pushing rigid configurations to devices, Conditional Access makes access decisions in real time based on context: who is accessing? From which device? From which location? How high is the risk?

Typical Conditional Access Policies can specify: MFA required when accessing from outside the corporate network. Access only from managed devices for confidential applications. Blocking access from countries where the organization has no locations. Forced password change upon detection of a compromised account (Identity Protection).

Strengths and Weaknesses of Entra ID

The strengths of Entra ID are seamless cloud integration, Conditional Access, native support for modern protocols (OIDC, SAML, FIDO2), low operational overhead (no dedicated server), and continuous development by Microsoft.

The weaknesses primarily concern on-premise scenarios. Entra ID cannot directly interact with local Windows servers, file shares, or printers. This still requires a local Active Directory or Entra Domain Services (a managed AD service in Azure). Dependency on cloud availability is a risk, even though SLAs are high. And licensing can become complex and expensive, especially when advanced features like Conditional Access, PIM, or Identity Protection are needed.

LDAP: The Open Protocol

LDAP (Lightweight Directory Access Protocol) is not a directory service in the strict sense but a protocol for accessing directory services. Active Directory implements LDAP as one of its access protocols. But LDAP also exists as a standalone solution, particularly in Linux and Unix environments.

LDAP Implementations

OpenLDAP is the most widely used open-source LDAP implementation. It runs on Linux and provides a powerful, scalable directory service at no licensing cost. Configuration is done through text files and LDIF files (LDAP Data Interchange Format), which means a steep learning curve but also maximum flexibility.

389 Directory Server (formerly Red Hat Directory Server) is another open-source solution, particularly common in Red Hat environments. It offers a graphical management interface and is somewhat easier to administer than OpenLDAP.

FreeIPA is an integrated identity management solution for Linux that uses 389 Directory Server as a backend but additionally provides Kerberos authentication, DNS management, and a web interface. FreeIPA is the Linux equivalent of Active Directory and is suitable for organizations with a predominantly Linux-based infrastructure.

When Is LDAP the Right Choice?

LDAP as a standalone directory service makes sense in purely or predominantly Linux environments, when Microsoft product licensing costs should be avoided, when applications explicitly require LDAP authentication, and when maximum control over the directory service is desired.

For organizations with a mixed Windows/Linux infrastructure, LDAP alone is often insufficient because integration with Windows features like Group Policies, Kerberos for Windows services, and seamless desktop integration is lacking. In these cases, Active Directory (which supports LDAP as a protocol) or a hybrid solution with AD and FreeIPA is the better choice.

Hybrid Identity Architecture: Connecting AD and Entra ID

The reality for most organizations is neither purely on-premise nor purely cloud, but hybrid. Servers run in your own data center, applications run in the cloud, and employees work both in the office and remotely. This hybrid reality requires a hybrid identity architecture.

Entra Connect: The Bridge

Microsoft Entra Connect (formerly Azure AD Connect) is the tool that connects local Active Directory and Entra ID. It synchronizes users, groups, and attributes from the local AD to Entra ID, so employees can access both local resources and cloud services with the same credentials.

Entra Connect offers three synchronization modes. Password Hash Synchronization (PHS) synchronizes a hash of the password hash to Entra ID. Authentication against cloud services occurs directly in Entra ID without needing to contact the local DC. This is the simplest and recommended mode. Pass-Through Authentication (PTA) forwards authentication to the local DC. The password hash is not transmitted to the cloud, which may be relevant for organizations with strict compliance requirements. Federation with ADFS forwards authentication to a local ADFS infrastructure, which then issues SAML tokens. This mode is the most complex and is recommended only for special scenarios.

Challenges of Hybrid Architecture

Hybrid identity architecture brings specific challenges. The synchronization direction is unidirectional by default: from local AD to Entra ID. If you change a user in Entra ID, the change is not automatically written back to the local AD. Entra Connect Cloud Sync now offers bidirectional scenarios, but configuration is more complex.

Conflicts can occur when the same attribute is changed in both places. Entra Connect resolves conflicts according to defined rules, but the result is not always intuitive. A clear responsibility assignment (which attributes are maintained where?) is essential.

Dependency on Entra Connect as the synchronization component is another risk. If Entra Connect fails, changes in local AD are no longer synchronized to the cloud, and new employees do not receive access to cloud services. Monitoring and alerting for Entra Connect are therefore mandatory.

Entra Domain Services

For scenarios where classic AD features (Kerberos, LDAP, Group Policies) are needed in the cloud, Microsoft offers Entra Domain Services (formerly Azure AD Domain Services). This managed service provides an AD-compatible domain in Azure without requiring you to operate Domain Controllers yourself.

Entra Domain Services is useful for lift-and-shift of on-premise applications to Azure that require AD authentication, for connecting legacy applications to Entra ID via LDAP or Kerberos, and for scenarios where the on-premise AD infrastructure should be retired but not all applications can be migrated to modern protocols.

Migration and Transformation Paths

Many organizations face the question of whether and how to modernize their directory service architecture. The answer depends on the starting situation and the objectives.

From AD to Entra ID (Cloud-Only)

The complete transition from on-premise AD to Entra ID (cloud-only) is the long-term goal for many organizations. This transition means shutting down Domain Controllers and managing all identities exclusively in Entra ID. Endpoints are Entra ID-joined instead of domain-joined, and applications authenticate via OIDC/SAML instead of Kerberos/LDAP. Single Sign-On becomes the central access path for all services.

The prerequisites are demanding: all applications must support modern authentication. File shares must be migrated to SharePoint Online or Azure Files. Printers must be managed via Universal Print. Group Policies must be replaced by Intune configuration profiles.

For most mid-market companies, this transition is a multi-year process. The pragmatic path goes through the hybrid phase, where both systems run in parallel, and individual workloads are gradually migrated to the cloud.

From LDAP to AD or Entra ID

Organizations with a pure LDAP environment that want to adopt Microsoft services face the decision of whether to build AD on-premise or go directly to Entra ID. If there are no on-premise Windows servers to manage and endpoints can be managed with Intune, the direct path to Entra ID is more efficient. If on-premise Windows servers continue to operate, building a local AD with Entra Connect synchronization is the more robust approach.

Security Aspects of Directory Services

The directory service is one of the most critical systems in your infrastructure. A compromised directory service means the attacker controls the identities of all users and has access to all connected systems.

For Active Directory, the hardening measures described in the article on AD security apply: Tiered Administration, LAPS, Kerberoasting protection, NTLM restriction, and regular review of privileged groups.

For Entra ID, Conditional Access Policies, PIM, Identity Protection, and regular review of app registrations and Service Principals are the most important security measures. Special attention should be given to admin roles: Global Administrator should be reserved for no more than two to three people, and all other administrative tasks should be delegated through specialized roles (User Administrator, Exchange Administrator, Security Administrator). A well-designed Privileged Access Management approach is essential here.

For LDAP environments, TLS encryption of all connections (LDAPS), strong bind credentials, ACLs on the directory, and regular backups are the fundamental security measures.

Decision Matrix

The choice of directory service is a long-term architectural decision. Here is a summary of the decision criteria.

If your organization is primarily Windows-based, operates on-premise servers, and needs Group Policies for device management, Active Directory with Entra Connect synchronization is the right choice.

If your organization is primarily cloud-based, uses Microsoft 365, and manages endpoints through Intune, Entra ID as the primary directory service makes sense, supplemented by Entra Domain Services for legacy applications.

If your organization is primarily Linux-based and does not use Microsoft products, FreeIPA or OpenLDAP are the most cost-effective solutions.

If your organization works hybrid, with on-premise servers and cloud services, the combination of AD and Entra ID via Entra Connect is the standard approach.

Regardless of the choice: document your directory service architecture in your ISMS — in ISMS Lite, the entire identity architecture with access policies and recertification cycles can be centrally mapped. Define clear responsibilities for administration, implement monitoring for the directory service, and plan regular permission recertifications. The directory service is the foundation of your entire access control, and this foundation must be solid.

Further Reading

• Securing Active Directory: Hardening, Tiering, and Monitoring
• Creating an Authorization Concept: From Role Models to Recertification
• Single Sign-On (SSO) Implementation: SAML, OIDC, and Practical Deployment
• User Lifecycle Management: Onboarding, Role Changes, Offboarding
• Managing Service Accounts: The Forgotten Security Risk