Directory Services

A directory is a structured, searchable source of identities and resources. Organizations use directories to locate users, groups, computers, services, and policies—and to make authentication and authorization decisions consistently across many systems.

TL;DR

Quick Example

This access mapping is a design example; nesting and token behavior depend on the directory and application.

Core Concepts

Directory, Protocol, and Identity Provider

A directory stores objects and attributes. LDAP is an access protocol. An identity provider issues authentication assertions or tokens for applications. Products can combine these functions, but their protocols and trust models are not interchangeable.

Replication Is Not a Backup

Replication distributes changes, including unintended deletion or malicious changes. Recovery needs protected backups and a tested procedure suited to the directory product.

The Mental Model

Think of a directory as an object database with a schema, identifiers, attributes, and access rules. Active Directory Domain Services (AD DS) adds domains, domain controllers, replication, and Group Policy. DNS helps clients locate controllers, and Kerberos authentication depends on acceptable clock synchronization. These are AD DS properties, not requirements of every directory.

LDAP is a protocol for accessing directory information; it is not synonymous with Active Directory. Microsoft Entra ID is a cloud identity provider with a different architecture from AD DS. Do not assume that a cloud tenant provides LDAP, domain controllers, or Group Policy.

Groups Before Individuals

Assign permissions to resource roles, place job or team groups into those roles, then place people into the job groups. This keeps access intelligible when people move roles.

Avoid direct per-user grants, deeply nested groups no one can explain, and names that hide purpose. Every privileged group needs an owner, documented scope, and regular review.

Operational Guardrails

Monitor replication, controller health, DNS, time synchronization, authentication failures, privileged-group changes, stale objects, and backup age. Delegate narrow administrative tasks instead of broad domain privileges. Protect service identities, rotate credentials, and separate high-privilege administration from ordinary endpoints.

Recovery planning must cover deleted objects, a failed controller, corrupted directory data, lost privileged access, and complete forest or tenant compromise. Keep emergency access and recovery instructions available when normal identity services are unavailable.

Comparison

Best Practices

Model Effective Access

Test permissions through nested groups and application roles. A group inventory alone may miss direct grants, inherited rights, and application-local accounts.

Protect the Recovery Path

Store recovery instructions and approved emergency credentials so they remain usable during an identity outage. Exercise their use and audit every activation.

Common Mistakes

Treating All Directories as AD DS

Bad: Expect LDAP and Group Policy from any cloud identity tenant.

Correct: Match the application's protocol and policy needs to the chosen service.

Restoring Controllers Like Ordinary Files

Bad: Assume an arbitrary VM rollback safely repairs directory corruption.

Correct: Follow the directory vendor's supported restore or forest-recovery procedure and validate replication.

FAQ

Is LDAP the same as Active Directory?

No. LDAP is a protocol; AD DS is a directory service that supports LDAP along with other capabilities.

Does having two controllers eliminate recovery planning?

No. Replicated mistakes, compromise, shared infrastructure failure, and lost credentials can affect both.

Should access be assigned only through groups?

Prefer owned role groups where supported. Document necessary exceptions and verify effective access at the target application.

Related Topics

References