Directory services: where identities actually live

Why the protocols module starts here

Welcome to Access Management, and to its foundational module: standards, protocols, and directory services. The pedagogical bet of this module is simple — before you can reason about authentication, federation, or governance, you have to speak the common language of IAM. That language is a stack of protocols, and underneath all of them sits one thing every protocol ultimately talks to: the directory.

A directory is where identities actually live. When SAML asserts who you are, when OAuth issues a token, when SCIM provisions an account, when the JML lifecycle creates a joiner — all of it reads from or writes to a directory. The directory answers the most basic question in all of IAM: who is this, and what do they belong to? Get the directory wrong and every protocol on top of it inherits the mistake. So we start at the bottom of the stack and build up.

What a directory service actually is

A directory service is a specialized database, but it’s not a general-purpose one. It’s optimized for a very particular workload: read-heavy, hierarchical lookups of identity data. Applications ask it the same kinds of questions thousands of times a second — “does this user exist?”, “what’s their email?”, “which groups are they in?” — and rarely write to it. That asymmetry shapes everything about how directories are built: they favor fast reads and replication over the transactional write guarantees a relational database obsesses over.

The classic analogy is a phone book. A phone book is organized hierarchically (by region, then name), optimized for lookup rather than editing, and replicated widely so everyone has a copy. A directory service is the same idea for digital identities: a tree of entries, each describing one thing — a person, a group, a printer, a service account — with a set of attributes, queryable over a standard protocol.

Three properties distinguish a directory from an ordinary database:

• Hierarchical structure: entries live in a tree, not flat tables, mirroring how organizations think (company → department → person).
• Standard access protocol: clients talk to it over LDAP (or, in the cloud era, HTTP APIs), so any application can read it the same way.
• Replication and distribution: copies are kept in sync across servers so a lookup is always fast and locally available, and the failure of one server doesn’t take identity down.

LDAP: the data model and the language

LDAP — the Lightweight Directory Access Protocol — is both a protocol for talking to a directory and a model for structuring its data. It’s “lightweight” relative to the heavier X.500 directory standards it descended from, and it has been the lingua franca of on-premises directories since the late 1990s.

The tree: DIT, entries, and distinguished names

LDAP organizes data as a Directory Information Tree (DIT). Every node in the tree is an entry, and every entry has a distinguished name (DN) — its unique, full path read from the entry up to the root.

flowchart TD
  accTitle: An LDAP Directory Information Tree
  accDescr: The tree is rooted at the domain components dc=example,dc=com. Below the root are two organizational units, ou=People and ou=Groups. Under ou=People are two person entries, cn=Sara Lopez and cn=Daniel Ortiz. Under ou=Groups is a group entry, cn=Engineering. The distinguished name of an entry is the path from that entry up to the root.
  ROOT["dc=example,dc=com"] --> P["ou=People"]
  ROOT --> G["ou=Groups"]
  P --> S["cn=Sara Lopez"]
  P --> D["cn=Daniel Ortiz"]
  G --> E["cn=Engineering"]

Reading the tree: the root is the organization, expressed as domain components (dc=example,dc=com). Below it are organizational units (ou=People, ou=Groups) that group related entries. The leaves are the actual objects — a person named Sara Lopez has the DN cn=Sara Lopez,ou=People,dc=example,dc=com. Each comma-separated piece is a relative distinguished name (RDN) naming one level; the DN is the concatenation of all of them, exactly like a filesystem path uniquely identifies a file.

Attributes, objectClasses, and schema

Each entry holds attributes — name/value pairs like mail: sara@example.com, telephoneNumber: 4521, memberOf: cn=Engineering,.... What attributes an entry may and must have is governed by its objectClasses, and the full set of allowed objectClasses and attributes is the directory’s schema (standardized in RFC 4519 and extended per deployment).

For example, an entry with objectClass inetOrgPerson must have a surname (sn) and common name (cn), and may have mail, mobile, title, and dozens more. The schema is the contract: it’s why any LDAP client can read any LDAP directory and know that mail means an email address. Extending the schema (adding custom attributes) is powerful but permanent and disruptive, which is why mature teams treat schema changes with the same care as database migrations.

LDAP operations

The protocol itself is a small set of operations, and knowing them demystifies a lot of IAM:

• Bind: authenticate to the directory (this is how LDAP does authentication — an app “binds” as a user with their password to verify it).
• Search: the workhorse — query for entries matching a filter, e.g. “all entries under ou=People where department=Finance.”
• Add / Modify / Delete: write operations, used by provisioning.
• Compare and Unbind: check an attribute value, and close the session.

The bind operation is worth dwelling on, because it’s a foundational authentication mechanism: when a legacy app “authenticates against LDAP,” it’s literally attempting to bind to the directory using the credentials the user typed. If the bind succeeds, the password was correct. This is the original single sign-on substrate, and it still runs underneath a surprising amount of enterprise software.

Active Directory: the directory that runs the enterprise

If LDAP is the language, Active Directory (AD) is the system that, for two decades, most of the corporate world has spoken it through. Introduced by Microsoft in 2000, AD is far more than an LDAP directory — it’s an identity and management platform built around it, and it remains the backbone of on-premises enterprise IT.

Domains, trees, and forests

AD organizes the world into a hierarchy of its own:

• A domain is the core administrative boundary — a collection of users, computers, and groups under common policy, served by domain controllers (DCs) that hold the directory and authenticate logins.
• A tree is a set of domains sharing a contiguous namespace.
• A forest is the top-level security boundary — one or more trees that trust each other and share a schema and a global catalog (a partial, forest-wide index for fast cross-domain search).

The forest is the line that matters most for security: it is the trust boundary. Everything inside a forest implicitly trusts everything else, which is why “compromise of one domain can mean compromise of the forest” is a sentence that keeps AD administrators up at night.

More than LDAP

AD bundles several protocols and services that together make it a management platform, not just a lookup store:

• Kerberos for authentication — the ticket-based protocol that lets a domain-joined machine prove who its user is without resending the password (we’ll meet it again in the tokens article).
• Group Policy (GPO) for pushing configuration and security settings to thousands of machines centrally.
• DNS integration, because clients locate domain controllers via DNS.
• LDAP, still, for directory reads and writes.

This bundling is exactly why AD became so dominant and so sticky: it didn’t just store identities, it managed the fleet. It’s also why migrating away from it is so hard, and why most enterprises don’t replace AD so much as extend it into the cloud.

The directory’s place in the IAM cycle

It’s worth being precise about where the directory sits relative to the operational cycle. The directory is not usually the original authoritative source of identity — that’s typically the HR system, which knows who was hired. Instead, the directory is the runtime source of truth: the place applications actually query at access time.

The flow is: HR declares a person exists → JML provisioning creates and maintains their entry in the directory → applications read the directory on every login to authenticate them and resolve their group memberships. The directory is the operational heart that turns “HR says this person is a Finance analyst” into “this login succeeds and this person can open the Finance app.” Group membership in the directory is, in practice, how most access is actually granted and revoked.

The shift to cloud directories

The on-premises, LDAP-and-Kerberos world assumed your users sat at domain-joined machines on the corporate network reaching internal servers. That assumption broke. Users now work from anywhere, on any device, reaching SaaS applications that live on someone else’s infrastructure. SaaS apps don’t speak LDAP or Kerberos — they speak HTTP-based protocols. So a new generation of directories emerged.

Cloud directories — Microsoft Entra ID (formerly Azure AD), Okta Universal Directory, Google’s directory — store identities much like their predecessors but expose them over modern, internet-friendly protocols: SAML, OAuth, OIDC, and SCIM (the rest of this module). Critically, Entra ID is not “Active Directory in the cloud,” despite the old name. The differences are architectural, not cosmetic:

• It isn’t hierarchical. There’s no DIT, no organizational units, no DN. Identities live in a flat tenant, organized by groups and administrative units rather than a tree.
• It’s API-first, not LDAP. You don’t bind and search over LDAP; you call a REST API — Microsoft Graph — over HTTPS. The query model is web-native, not directory-native.
• It has no domains, trees, forests, or Group Policy. The whole AD management apparatus is absent, because Entra ID isn’t managing domain-joined Windows fleets — it’s brokering identity to cloud and SaaS apps over the open web.

Alternatives and when to use them

AD and Entra ID dominate, but they’re far from the only directories, and knowing the alternatives is part of speaking the common language fluently:

The pattern to notice: the open-source options (OpenLDAP, FreeIPA) keep the classic LDAP/Kerberos model alive for Unix-centric environments, while the cloud platforms (JumpCloud, Okta) target organizations that never built an on-prem directory and want identity delivered as a service. There’s no single “right” directory — there’s the one that fits your platform mix, your scale, and whether you’re broker-first or source-first (a distinction we sharpen below).

Hybrid identity: living in both worlds

Almost no large enterprise is purely on-prem or purely cloud. They run hybrid identity: Active Directory on-premises for domain-joined machines and legacy apps, synchronized to a cloud directory for SaaS. A sync engine copies identities and attributes from AD up to Entra ID, so a user has one identity that works in both worlds. Microsoft has shipped this under several names worth recognizing:

• Azure AD Connect — the original, heavier sync server (now legacy branding).
• Entra Connect Sync — the current name for that full-featured sync server.
• Entra Cloud Sync — a lighter-weight, cloud-managed agent for simpler topologies, increasingly the default for new deployments.

flowchart LR
  accTitle: Hybrid identity synchronization flow
  accDescr: The HR system feeds the on-premises Active Directory, which authenticates domain-joined machines and legacy apps via LDAP and Kerberos. A synchronization engine, Entra Connect, projects identities and attributes from on-prem AD into the cloud directory, Entra ID. The cloud directory then brokers access to SaaS applications using the SAML, OIDC, and SCIM protocols.
  HR[HR system] --> AD[(On-prem<br/>Active Directory)]
  AD -->|LDAP / Kerberos| LEGACY[Domain-joined machines<br/>& legacy apps]
  AD -->|sync: Entra Connect| CLOUD[(Cloud directory<br/>Entra ID)]
  CLOUD -->|SAML / OIDC| SAAS[SaaS apps]
  CLOUD -->|SCIM| SAAS

This hybrid shape is the reality you’ll encounter in the field far more often than a clean greenfield cloud directory. It also explains why the rest of this module matters: the cloud directory’s whole job is to speak the protocols that let identities from your directory log into applications you don’t control. The directory is the noun; SAML, OIDC, and SCIM are how that noun travels to the cloud.

Authoritative source vs. identity broker

A directory can play two very different roles, and conflating them causes real design mistakes. It can be an authoritative source — the system that owns identities, the place they’re created and mastered. Or it can be an identity broker — a system that mediates authentication between many applications and one or more upstream identity sources, without necessarily owning the identities itself.

Classic Active Directory is overwhelmingly an authoritative source: identities are born and live there. A modern cloud IdP like Okta or Entra ID often plays both roles at once — it masters some identities directly while brokering others. As a broker it federates downstream apps to a single login, and federates upstream to other sources: your on-prem AD, a partner’s IdP, or social/consumer logins. The user signs in once at the broker, and the broker vouches for them to every connected app.

The directory is the crown jewels

No system in an enterprise is a higher-value target than the directory, and understanding why is essential to understanding IAM security. The directory knows every identity and grants every group membership. Compromise it and you don’t breach one account — you can impersonate all of them.

In Active Directory specifically, the domain controllers are the keys to the kingdom. An attacker who gains control of a DC can perform attacks with names that have become infamous in security:

• DCSync — impersonating a domain controller to ask for every user’s password hash.
• Kerberoasting — extracting service-account credentials from Kerberos tickets to crack offline.
• Golden Ticket — forging Kerberos tickets that grant arbitrary access, having stolen the domain’s master key.

These (catalogued in detail in the MITRE ATT&CK framework) all share a theme: once the directory falls, normal authentication becomes theater, because the attacker can mint valid credentials at will. “Domain admin” is effectively “owns everything.”

Protecting the substrate

Because the stakes are total, directory security is among the highest-leverage work in IAM. The practices practitioners converge on:

• Tiered administration: Microsoft’s tier model separates control of domain controllers (tier 0) from servers (tier 1) and workstations (tier 2), so a compromised laptop can’t pivot to a DC. This is least privilege applied to the directory itself.
• Minimize and monitor privileged accounts: few domain admins, no standing membership where avoidable, and alerting on sensitive group changes — the JIT principle applied to the most dangerous group in the company.
• Protect credentials at rest: tools like LAPS (randomized local admin passwords) and Protected Users groups shrink the blast radius of any single stolen credential.
• Treat the directory as monitored infrastructure: feed directory and DC logs to a SIEM, because the attacks above leave detectable traces — if you’re watching.

How directories underpin the rest of the module

Everything that follows in this module is, in a sense, about getting identity out of the directory and into the systems that need it, safely. A quick map of where we’re headed:

• SAML federates a directory identity into a web app: the directory is the source, SAML is the assertion that carries “this is Sara, and she’s in Engineering” to the app.
• OAuth delegates authorization — letting an app act on a user’s behalf — with the directory backing who that user is.
• OIDC adds a standard identity layer on OAuth, so apps can log users in against the directory over the open web.
• SCIM writes back to directories and apps — the provisioning verb that keeps the directory and downstream accounts in sync, the protocol behind JML automation.

In every case the directory is the anchor. The protocols are sophisticated, but they exist to serve a simple purpose: take the authoritative “who” that lives in the directory and make it usable, securely, everywhere else.

Recap

The directory is the substrate beneath the entire IAM protocol stack:

1. A directory service is a read-optimized, hierarchical, replicated store of identities and their attributes, queried over a standard protocol.
2. LDAP is the data model and language — the DIT of entries, each with a distinguished name, attributes governed by objectClasses and schema, accessed through a small set of operations (bind, search, modify).
3. Active Directory is the dominant on-prem platform built on LDAP plus Kerberos and Group Policy, organized into domains and forests.
4. Cloud directories (Entra ID, Okta) store identity for the SaaS era and expose it over SAML, OAuth, OIDC, and SCIM — usually synchronized with on-prem AD in a hybrid setup.
5. The directory is the crown jewels: it knows everyone and grants every group, so its compromise is total, and its protection is among the highest-value work in IAM.

Hands-on exercises

These are practical — do them, don’t just read them:

1. Query a real directory. Point ldapsearch (or a GUI like Apache Directory Studio) at a public test server such as ldap.forumsys.com, bind, and search a subtree. Identify three entries’ distinguished names, their objectClasses, and the attributes each carries.
2. Trace your own access. In a directory you can see — a free Entra ID or Google Workspace developer tenant, or your own account if permitted — find your user object and list every group you belong to. Then map two of those groups to the actual app access they grant.
3. Design a DIT (use case). Sketch the Directory Information Tree for a 200-person company with three departments plus contractors: choose the OU structure, decide where groups live, and write the full DN of one example user.
4. Plan a hybrid topology (use case). A company runs on-prem AD and is adopting SaaS. Decide what should sync to Entra ID, whether you’d use Entra Connect Sync or Cloud Sync and why, and which apps authenticate against which directory.
5. Tier the crown jewels (use case). Given a domain controller, a file server, and a finance analyst’s laptop, assign each to a Microsoft admin tier (0/1/2) and name one control that stops a compromised laptop from reaching the domain controller.

Three questions to test yourself

1. An application “authenticates users against LDAP.” Explain what’s actually happening at the protocol level, which LDAP operation is involved, and why this is a form of single sign-on.
2. A colleague says “we’re moving to the cloud, so we’ll just lift-and-shift Active Directory into Entra ID.” What’s wrong with that mental model, and how would you describe the real relationship between AD and Entra ID?
3. Why does compromising a single domain controller potentially mean compromising the entire forest, and name two specific controls that would limit the blast radius?