Directory services: where identities actually live

Where every protocol ends up

When you sign in to a company application in the morning, a lot happens that you never see. A SAML assertion might travel to the app saying who you are. An OAuth token might let a mobile app read your calendar. Overnight, SCIM might have created your account in a new tool, because yesterday HR recorded that you joined a project. Different protocols, different jobs, and all of them, sooner or later, read from or write to the same place: a directory.

This article opens the access management domain and its first module, on standards, protocols, and directory services. The bet behind the module is simple. Before you can reason about authentication, federation, or governance, you need to speak the common language of IAM, and that language is a stack of protocols resting on one thing they all talk to. The directory answers the most basic question in IAM: who is this, and what do they belong to? Get it wrong, and every protocol on top inherits the mistake. So the module starts at the bottom of the stack.

A useful way to hold the whole module in your head: the directory is the noun of IAM, the store of who exists, and the protocols, SAML, OAuth, OIDC, SCIM, are the verbs, how identity information moves between systems. This article is about the noun.

What a directory service is

A directory service is a database, but not a general-purpose one. It’s built for a particular workload: reading identity data, over and over, from a hierarchy. Applications ask it the same 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 imbalance shapes how directories are built. They favor fast reads and replication over the strict transactional guarantees a relational database cares about.

The old analogy is a phone book. It’s organized by region and then by name, it’s built for looking things up rather than editing them, and copies are everywhere. A directory 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, all queryable over a standard protocol.

Three things set a directory apart from an ordinary database. It’s hierarchical, a tree rather than flat tables, which mirrors how organizations think about themselves: company, department, person. It’s reached through a standard protocol, LDAP in the classic world and HTTP APIs in the cloud, so any application can read it the same way. And it’s replicated, with copies kept in sync across servers, so lookups are fast and local and one failed server doesn’t take identity down with it.

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 organizing its data. It’s lightweight compared with the X.500 standards it came from, and it has been the common language of on-premises directories since the late 1990s.

The tree: DIT, entries, and distinguished names

LDAP arranges data in a Directory Information Tree (DIT). Each node of the tree is an entry, and each entry has a distinguished name (DN): its full, unique 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 López and cn=Daniel Ortiz. Under ou=Groups is a group entry, cn=Engineering. An entry's distinguished name 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 López"]
  P --> D["cn=Daniel Ortiz"]
  G --> E["cn=Engineering"]

The root is the organization, written as domain components (dc=example,dc=com). Below it sit organizational units (ou=People, ou=Groups) that group related entries. The leaves are the actual objects: Sara López’s entry has the DN cn=Sara López,ou=People,dc=example,dc=com. Each comma-separated piece is a relative distinguished name naming one level, and the DN strings them all together, much as a file path identifies one file on a disk.

Attributes, objectClasses, and schema

Each entry holds attributes, name and value pairs such as mail: sara@example.com, telephoneNumber: 4521, or memberOf: cn=Engineering,.... Which attributes an entry may and must have is set by its objectClasses, and the complete set of allowed objectClasses and attributes is the directory’s schema, standardized in RFC 4519 and extended by each deployment.

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

What you can do with LDAP

The protocol is a small set of operations, and knowing them takes a lot of the mystery out of IAM. Bind authenticates to the directory. Search, the workhorse, finds entries matching a filter, such as everyone under ou=People whose department is Finance. Add, modify, and delete are the writes, used by provisioning. Compare checks a single attribute’s value, and unbind closes the session.

Bind deserves a closer look, because it’s an authentication mechanism in its own right. When a legacy application says it “authenticates against LDAP,” it’s literally trying to bind to the directory with the username and password the user typed. If the bind succeeds, the password was right. That was the original foundation for single sign-on inside companies, 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 most of the corporate world has spoken it through for two decades. Microsoft introduced it in 2000, and it’s far more than an LDAP directory. It’s an identity and management platform built around one, and it remains the backbone of on-premises enterprise IT.

Domains, trees, and forests

AD organizes the world in its own hierarchy. A domain is the basic administrative boundary: users, computers, and groups under common policy, served by domain controllers that hold the directory and handle sign-ins. A tree is a set of domains sharing a continuous 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 index of the whole forest for fast searches across domains.

The forest is the line that matters most for security, because it’s the real trust boundary. Everything inside a forest trusts everything else, which is why “compromising one domain can mean compromising the forest” is a sentence that keeps AD administrators awake.

More than LDAP

AD bundles several protocols and services that turn it from a lookup store into a management platform. Kerberos handles authentication, the ticket-based protocol that lets a domain-joined machine prove who its user is without sending the password again; it comes back in the tokens article. Group Policy pushes configuration and security settings to thousands of machines from one place. DNS integration lets clients find domain controllers. And LDAP is still there for directory reads and writes.

That bundle is exactly why AD became so dominant and so hard to leave. It didn’t just store identities; it managed the fleet. Most enterprises don’t replace AD so much as extend it into the cloud.

Where the directory sits in the IAM cycle

It’s worth being precise about the directory’s place in the operational cycle. It usually isn’t the original authoritative source for identity. That’s normally the HR system, which knows who was hired. The directory is the runtime source of truth: the place applications actually query when someone signs in.

The flow goes like this. HR records that a person exists. Joiner-mover-leaver provisioning creates and maintains their entry in the directory. Applications read the directory at every sign-in to authenticate the person and resolve their group memberships. The directory is what turns “HR says this person is a finance analyst” into “this sign-in succeeds and this person can open the finance app.”

In practice, group membership in the directory is how most access is granted and removed: you’re in cn=Finance-App-Users or you aren’t. That makes groups powerful and very prone to sprawl, and it’s where privilege creep lives in concrete form. A directory with ten thousand groups nobody can explain is the most common sign that an IAM program has lost control of its own foundation.

The move to cloud directories

The on-premises world of LDAP and Kerberos assumed users sat at domain-joined machines on the corporate network, reaching internal servers. That assumption broke. People now work from anywhere, on any device, using SaaS applications that run on someone else’s infrastructure. Those applications don’t speak LDAP or Kerberos; they speak web protocols. So a new generation of directories appeared.

Cloud directories, Microsoft Entra ID (formerly Azure AD), Okta Universal Directory, Google’s directory, store identities much as their predecessors did but expose them over protocols built for the internet: SAML, OAuth, OIDC, and SCIM, the rest of this module. Entra ID is not “Active Directory in the cloud,” whatever the old name suggested. The differences are architectural. It isn’t hierarchical: there’s no DIT, no organizational units, no DNs, just a flat tenant organized by groups and administrative units. It’s API-first rather than LDAP-based: you don’t bind and search, you call a REST API, Microsoft Graph, over HTTPS. And it has no domains, trees, forests, or Group Policy, because it isn’t managing domain-joined Windows fleets. Its job is handing identity to cloud and SaaS applications across the open web.

Other directories worth knowing

AD and Entra ID dominate, but they’re not the only options, and knowing the others is part of speaking the language fluently.

The pattern is that the open-source options keep the classic LDAP and Kerberos model alive in Unix-heavy environments, while the cloud platforms serve organizations that never built an on-premises directory and want identity as a service. There’s no single right directory, only the one that fits your mix of platforms, your size, and whether you think of it mainly as a source or as a broker, a distinction the next sections sharpen.

Hybrid identity: living in both worlds

Almost no large enterprise is purely on-premises or purely cloud. They run hybrid identity: Active Directory on premises for domain-joined machines and older applications, synchronized with a cloud directory for SaaS. A sync engine copies identities and attributes from AD to Entra ID, so each person has one identity that works in both. Microsoft has shipped this under names worth recognizing: Azure AD Connect, the original heavier sync server, now old branding; Entra Connect Sync, the current name for that full-featured server; and Entra Cloud Sync, a lighter, cloud-managed agent for simpler setups and increasingly the default for new deployments.

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

You’ll meet this hybrid shape in the field far more often than a clean, cloud-only directory. It also explains why the rest of the module matters: the cloud directory’s whole job is to speak the protocols that let identities from your directory sign in to applications you don’t control.

Authoritative source or identity broker

A directory can play two quite different roles, and mixing them up causes real design mistakes. It can be an authoritative source, the system that owns identities, where they’re created and mastered. Or it can be an identity broker, a system that sits between many applications and one or more upstream sources and handles authentication for them, without necessarily owning the identities.

Classic Active Directory is overwhelmingly a source: identities are born there and live there. A modern cloud identity provider like Okta or Entra ID often plays both roles. It masters some identities directly and brokers others. As a broker it federates downstream applications to a single sign-in, and federates upstream to other sources: your on-premises AD, a partner’s identity provider, or consumer social logins. The user signs in once at the broker, and the broker vouches for them to every connected application.

When you join a new environment, a good first question is which system is the authoritative source for each population of identities, and which is only the broker in front of the sign-in. An identity has exactly one authoritative source but can pass through several brokers. Treating a broker as if it owned identities it only federates is how teams end up unable to say where a user actually comes from, which is the authoritative source problem in a new costume.

The crown jewels

No system in an enterprise is a more valuable target than the directory. It knows every identity and grants every group membership. Compromise it and you haven’t breached one account; you can impersonate all of them.

In Active Directory, the domain controllers are the keys to the kingdom, and an attacker who controls one has a set of techniques with infamous names. DCSync impersonates a domain controller to request every user’s password hash. Kerberoasting pulls service account credentials out of Kerberos tickets to crack offline. A Golden Ticket is a forged Kerberos ticket that grants any access the attacker likes, made possible by stealing the domain’s master key. All of them are catalogued in MITRE ATT&CK, and all share a theme: once the directory falls, normal authentication becomes theater, because the attacker can mint valid credentials at will. Domain administrator effectively means owner of everything.

Protecting the foundation

Because the stakes are total, directory security is some of the most valuable work in IAM, and practitioners have converged on a handful of practices.

The first is tiered administration. Microsoft’s privileged access model separates control of domain controllers (tier 0) from servers (tier 1) and workstations (tier 2), so a compromised laptop can’t be used to reach a domain controller. It’s least privilege applied to the directory itself.

The second is keeping privileged accounts few and watched: a small number of domain administrators, no standing membership where it can be avoided, and alerts on changes to sensitive groups. It’s the just-in-time idea applied to the most dangerous group in the company.

The third is protecting credentials where they’re stored. Tools like LAPS, which randomizes local administrator passwords, and the Protected Users group shrink what any single stolen credential can do.

And the fourth is treating the directory as monitored infrastructure. The attacks above leave traces, but only if someone is looking, so directory and domain controller logs belong in a security monitoring system.

How the directory anchors the rest of the module

Everything that follows in this module is, in one way or another, about getting identity out of the directory and into the systems that need it, safely.

SAML federates a directory identity into a web application: the directory is the source, and SAML is the assertion that carries “this is Sara, and she’s in Engineering” to the app. OAuth delegates authorization, letting an application act on a user’s behalf, with the directory standing behind who that user is. OIDC adds a standard identity layer on top of OAuth, so applications can sign users in against the directory over the open web. And SCIM writes back into directories and applications, the provisioning verb that keeps the directory and downstream accounts in step and powers joiner-mover-leaver automation.

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

Recap

The directory is the foundation under the whole 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 its data model and language: a tree of entries, each with a distinguished name, attributes governed by objectClasses and schema, and a small set of operations such as bind, search, and modify.
3. Active Directory is the dominant on-premises platform, built on LDAP plus Kerberos and Group Policy and organized in domains and forests.
4. Cloud directories such as Entra ID and Okta store identity for the SaaS era and expose it over SAML, OAuth, OIDC, and SCIM, usually synchronized with on-premises AD in a hybrid setup.
5. A directory can be an authoritative source, a broker, or both, and it pays to know which for every population.
6. The directory is the crown jewels: it knows everyone and grants every group, so compromising it is total, and protecting it is some of the most valuable work in IAM.

Hands-on exercises

These are meant to be done, not just read.

1. Query a real directory. Point ldapsearch, or a graphical client such as Apache Directory Studio, at a public test server like ldap.forumsys.com, bind, and search a subtree. Note three entries’ distinguished names, their objectClasses, and the attributes each carries.
2. Trace your own access. In a directory you can see, such as a free Entra ID or Google Workspace developer tenant, or your own account where allowed, find your user object and list every group you belong to. Then match two of those groups to the application access they grant.
3. Design a DIT. Sketch the directory tree for a 200-person company with three departments and some contractors: choose the organizational units, decide where groups live, and write the full DN of one example user.
4. Plan a hybrid setup. A company runs on-premises 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 applications authenticate against which directory.
5. Tier the crown jewels. Given a domain controller, a file server, and a finance analyst’s laptop, assign each to a Microsoft administration tier (0, 1, or 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 actually happens at the protocol level, which LDAP operation is involved, and why this counts as 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 picture, and how would you describe the real relationship between AD and Entra ID?
3. Why can compromising a single domain controller mean compromising the whole forest, and what two specific controls would limit the damage?