---
{
  "title": "LDAP and directory services",
  "summary": "Understand directory access, protected queries, narrowly scoped service accounts, and how membership changes can affect authorization across applications.",
  "topic": "networking",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "units": [
    2
  ],
  "aliases": [],
  "sources": [
    {
      "title": "NIST: Zero Trust Architecture",
      "url": "https://csrc.nist.gov/pubs/sp/800/207/final"
    },
    {
      "title": "IETF: LDAP — The Protocol",
      "url": "https://www.rfc-editor.org/rfc/rfc4511.html"
    }
  ],
  "published": "2026-10-02",
  "editorialVersion": 2
}
---
## The idea

LDAP is a protocol for accessing directory information. Directories can contain identities, group memberships, and other organizational attributes used in access decisions. Protect communication and authentication according to the deployed service, and restrict unnecessary queries or writes. Directory administration is sensitive because changes can affect many applications. The protocol’s existence does not define the application’s authentication or authorization design by itself.

## In practice

An application reads a user’s group membership through a protected directory connection, then evaluates its own permission policy for a resource.

## A common misunderstanding

Directory data is not automatically public, and a group name does not guarantee appropriate authorization.

## Check your understanding

Why govern directory changes carefully?

**Think it through:** Membership or policy changes can grant access across many connected systems.

## A directory supplies structured information

Imagine a fictional academy application queries a directory for staff identities and group membership. LDAP provides a protocol for interacting with that directory information. The application still needs a defined way to authenticate its connection and a policy for interpreting the returned attributes.

Directory membership is important evidence for access decisions, but the application should know which attributes and sources it trusts. A friendly group name does not by itself describe every resource permission it might influence.

## Read access and write access differ

Suppose the application only needs to read selected staff attributes. Granting it broad directory-write authority creates unnecessary risk. Changes to groups or identity records can affect many connected services, making directory administration especially sensitive.

Scope the service identity, search base, accessible attributes, and operations to the actual requirement. Protect directory traffic and credentials according to the deployed service and platform guidance rather than assuming an internal network is enough.

## Query construction is an application boundary

Untrusted search input must not become directory query syntax unintentionally. [[ldap-injection]] explains that separate application risk. A securely transported connection does not correct unsafe query construction or an overprivileged bind identity.

The academy should also understand caching and update delays. A staff role change may take time to reach an application's cached membership decision, so immediate revocation requirements need an explicit design.

For a safe exercise, define an application that reads one approved group and an administrator who changes membership. List the minimum operations each requires and the records needed to explain a permission change. Then add a user-supplied search field and describe how input remains data. The result separates directory transport, service permissions, query handling, and application authorization instead of treating a directory connection as a complete identity solution.

## Keep exploring

- [[identity-and-access-management]]
- [[rbac-and-abac]]
- [[privileged-access]]