Directory Service vs Identity Provider: Which Controls Live Where and Why

A directory service stores accounts and their attributes, while an identity provider authenticates someone and issues a signed token that other systems trust, and most identity incidents happen where teams confuse the two. The directory (Active Directory Domain Services, an LDAP server, a cloud directory) is the store of record: who exists, which groups they belong to, which credentials they hold. The identity provider (IdP) is the token issuer: it checks a credential once and hands relying parties a SAML assertion or an OpenID Connect ID Token. This guide explains the split at architecture level, which security controls belong on which side, how each side is attacked, where service accounts and other non-human identities should live, and how to decide between cloud-only and hybrid designs. It is written for identity architects, security engineers and auditors who need to place controls correctly rather than buy a product. For product selection, see the Directory Services and Cloud Directory Buyer's Guide and the IAM and IdP Buyer's Guide.

Key takeaways

• Two jobs, two trust anchors. The directory's crown jewels are its password hashes and replication rights; the IdP's crown jewels are its token-signing keys and federation trusts. Protect both as tier 0.
• LDAP is not an identity provider. An LDAP bind proves a password to one server for one session; it issues no portable, signed assertion. An IdP can use a directory as its account store, but the reverse is not true.
• Each side has its own signature attack. DCSync (T1003.006) steals credentials from the directory; forged SAML tokens (T1606.002) skip authentication at the IdP entirely. Detection and recovery differ for each.
• Hybrid adds a third tier 0 system. The synchronisation server and its connector accounts hold directory replication rights and write access to the cloud IdP, so they are as sensitive as a domain controller.
• Place non-human identities deliberately. Kerberos service accounts belong in the directory with managed passwords; workloads calling cloud APIs belong with the IdP or a workload identity issuer using federation, not shared directory passwords.

The short answer: store of record vs token issuer

A directory service answers "who is this account and what are its attributes?" It holds objects (users, groups, computers, service accounts), their attributes and, usually, their credentials or password hashes. Clients query it with LDAP (RFC 4511) and, in Active Directory, authenticate with Kerberos, which issues tickets valid only inside that realm. An identity provider answers "has this person or workload just proved who they are, and what should I tell the application?" NIST SP 800-63C-4 defines the IdP as the party that authenticates the subscriber and issues assertions to relying parties (RPs), which consume them. In OpenID Connect the OpenID Provider issues an ID Token, a signed JSON Web Token carrying claims such as iss, sub, aud and exp.

So the practical answers to the common questions are:

• Is LDAP an identity provider? No. LDAP is a directory access protocol. A successful Bind authenticates the client to that LDAP server for that connection, but nothing portable is produced that another application can verify independently.
• Do I still need a directory if I have an IdP? Every IdP has an account store. In a cloud IdP the directory is built in (Google Cloud Identity, Microsoft Entra ID and Okta Universal Directory each include one, listed alphabetically). You need a separate traditional directory only if you have consumers that speak LDAP, Kerberos, NTLM or Group Policy.
• What is the difference between a directory and an SSO provider? SSO is a property of the token model: the user authenticates once to the IdP and many applications accept its assertions. A directory alone gives you a shared password, not single sign-on.

Side-by-side comparison

How the two fit together architecturally

Most estates run one of three shapes. Knowing which you have tells you where each control has to live.

Directory-centric (traditional on-premises)

Active Directory is both store and authenticator. Windows logon, file shares and line-of-business applications use Kerberos; network devices and older applications use LDAP binds. If an IdP exists it is AD FS or a similar federation server sitting on the directory, translating a Kerberos or password check into SAML for a handful of web applications. The directory is the single trust anchor, so compromising it compromises everything downstream.

Hybrid (directory feeds a cloud IdP)

The on-premises directory stays authoritative for people and groups and a sync engine pushes objects to a cloud IdP. Microsoft documents three ways to authenticate in this shape: password hash sync (hashes of on-premises passwords are synced and the cloud validates sign-ins), pass-through authentication (on-premises agents validate passwords against AD) and federation (the cloud hands sign-in to AD FS on-premises). The choice decides whether an on-premises outage stops cloud sign-in and whether the cloud can see leaked credentials. Microsoft states that leaked credential detection requires password hash sync and recommends enabling it even when pass-through or federation is the primary method, so it can serve as a fallback. Deeper coverage of this choice is in Identity Federation vs Identity Synchronisation.

Cloud-native (IdP with built-in directory)

The IdP's own directory is the store of record, often fed from HR and pushed to applications with SCIM (RFC 7644, which defines create, read, replace, modify and delete operations over HTTP on /Users and /Groups). Legacy protocol needs are met by a managed domain or a hosted LDAP service. Microsoft Entra Domain Services, for example, is a managed domain synchronised one way from Entra ID; objects synchronised from Entra ID are read-only there, and Microsoft positions it as a bridge for legacy workloads rather than a replacement for on-premises AD.

Which controls live where

The most useful single artefact for an architecture review is a control placement map. Put each control on the side that can actually enforce it; a control placed on the wrong side is either impossible or trivially bypassed.

Threat model: the directory side

An attacker who controls the directory controls the identities. The main paths are well documented:

• Credential extraction by replication: DCSync (T1003.006) mimics a domain controller and asks for password data over MS-DRSR. MITRE notes it is available to Administrators, Domain Admins, Enterprise Admins and DC computer accounts, and recommends managing the access control list for "Replicating Directory Changes". The retrieved KRBTGT hash then enables a Golden Ticket (T1558.001). See the Golden Ticket, Silver Ticket and DCSync Guide.
• Weak binds: RFC 4513 says servers should by default fail unauthenticated binds (a name with an empty password) and should not offer clear-text password mechanisms unless TLS or another confidentiality layer protects the session. Directories that still accept simple binds on port 389 expose service account passwords on the wire. See the LDAP Security Deep Dive Guide.
• Reconnaissance: any authenticated account can usually enumerate users, groups and service principal names (T1087.002), which feeds Kerberoasting and privilege mapping. See LDAP Reconnaissance Detection.
• ACL and delegation abuse: write rights on group objects, GPOs or service accounts let an attacker add themselves to privileged groups without touching a password.

Failure mode: directory compromise is usually silent and broad. Recovery means a forest recovery plan, two KRBTGT resets and rebuilding trust in every account; see the Active Directory and Entra ID Recovery Guide.

Threat model: the identity provider side

An attacker who controls the IdP does not need passwords at all: they need the ability to issue a token that relying parties accept.

• Signing key theft and token forgery: with a SAML token-signing certificate an attacker can forge tokens for any user with arbitrary claims (T1606.002). MITRE lists detection signals such as validly signed assertions with no matching authentication event (Kerberos 4769, AD FS 1200 and 1202) and the same assertion ID used from different places, and recommends rotating the token-signing certificate twice in quick succession after a compromise. The SolarWinds SUNBURST and Golden SAML incident showed forged tokens passing password and MFA checks because the services trusted the signature. The Storm-0558 key breach showed the same lesson at cloud scale: a stolen signing key let tokens be forged that Exchange Online accepted. See the Golden SAML and Federation Trust Abuse Defence Guide.
• Trust modification: adding a new federated domain or identity provider trust (T1484.002) gives an attacker a second, legitimate-looking token issuer.
• Application credential abuse: adding secrets or certificates to existing service principals (T1098.001) and stealing application access tokens (T1528) give persistence without any user sign-in.
• Relying party validation gaps: OpenID Connect Core requires the RP to check that iss matches, that aud contains its client_id, that the signature verifies with the issuer's keys and that the token has not expired. Applications that skip these checks accept tokens issued for someone else. See Identity Federation Failure Modes.

Failure mode: IdP compromise is fast and invisible at the application. Recovery means rolling signing keys, revoking sessions and refresh tokens, and reviewing every trust and application credential.

Hybrid synchronisation: the third tier 0 system

In hybrid estates the sync server bridges the two trust anchors. Microsoft documents that for password hash sync the AD DS Connector account needs Replicate Directory Changes and Replicate Directory Changes All, the same rights DCSync abuses. The Entra Connector account holds the Directory Synchronization Accounts role and writes into the tenant, and the ADSync service account stores the other accounts' passwords encrypted in its database. MITRE tracks tampering with hybrid authentication components as T1556.007 (Hybrid Identity).

Hardening detail for the Microsoft stack is in the Microsoft Entra Connect and Cloud Sync Hardening Guide.

Where service accounts and other NHIs belong

Non-human identities usually outnumber people in both systems, and putting them in the wrong place is a common root cause of incidents.

• Kerberos and Windows services: keep these in the directory as group managed service accounts so the password is managed automatically. Microsoft's AD FS guidance itself recommends a gMSA for the AD FS service account. See the Windows Services and Service Account Security Guide.
• LDAP bind accounts: unavoidable for many appliances and legacy applications. Give each consumer its own read-only bind account, require LDAPS or StartTLS, and restrict where it can bind from.
• Cloud APIs and SaaS integrations: register them with the IdP as service principals or OAuth clients, prefer certificate or federated credentials over client secrets, and give each an owner. See OAuth Apps vs Integration Service Accounts.
• CI/CD and cross-cloud workloads: neither a directory password nor a long-lived IdP secret; use workload identity federation where the workload presents a short-lived token from its own platform. See Workload Identity Federation vs Static Cloud Keys.

Decision criteria: cloud-only, hybrid or directory-centric

Worked scenario: a mid-sized manufacturer

A 3,000-person manufacturer runs a single AD forest, AD FS for 40 SaaS applications, and 600 service accounts, many with passwords that never change. Plant systems use LDAP binds from appliances on port 389. The security team wants to "move to the cloud IdP" and is asked whether AD can be retired.

1. Classify consumers: the inventory shows 40 SaaS apps (token consumers), 120 Windows servers with Kerberos services, 30 appliances using LDAP binds and 15 pipelines using a directory service account to reach a cloud provider. The directory cannot be retired yet; the IdP role can move.
2. Move the IdP role: SaaS applications move from AD FS to the cloud IdP one by one. Password hash sync is enabled first so leaked credential detection works and there is a fallback. AD FS is decommissioned and its federation trust removed, which removes one token-signing key to defend.
3. Harden the directory for what remains: appliances move to LDAPS with per-device bind accounts; Kerberos services move to gMSAs; replication rights are reviewed so only domain controllers and the sync connector hold them.
4. Move NHIs to the right side: the 15 pipelines switch to workload identity federation and their directory accounts are disabled after a 30-day watch period.

Implementation approach

1. Map consumers by protocol: list every system that binds over LDAP, uses Kerberos or NTLM, or consumes SAML or OIDC. This tells you which side each control must live on.
2. Declare the store of record per population: people, groups, devices and each NHI class. Write it down; ambiguity here causes most lifecycle gaps.
3. Classify tier 0: domain controllers, sync servers and their connector accounts, IdP admin roles, signing keys and federation servers. Restrict administration to privileged access workstations.
4. Place controls: use the placement table above; close the gaps where MFA exists at the IdP but legacy protocols bypass it.
5. Pilot changes in audit mode: for LDAP signing or NTLM reduction, log first, fix the consumers that fail, then enforce. For IdP policy changes, use report-only conditional access where available.
6. Plan rollback: keep password hash sync available as a fallback before changing the authentication method, and document how to revert a sync rule.
7. Rehearse key compromise: run a tabletop for KRBTGT reset and for signing-key rollover so both are practised before they are needed.

Detection and measurement

• Directory: replication requests (event 4662 on directory objects with replication rights) from anything other than a domain controller or the sync connector; simple binds over unencrypted LDAP; new members of privileged groups.
• IdP: federation trust or domain changes, new credentials on service principals, sign-ins with assertions that have no matching authentication event, token lifetimes outside baseline.
• Sync layer: sign-ins by connector accounts from unexpected hosts, sync rule changes, new pass-through agents.

Metrics that show the split is working:

• Percentage of accounts with a single declared store of record (target 100%).
• Number of accounts outside domain controllers and sync connectors holding replication rights (target zero).
• Percentage of LDAP binds over LDAPS or StartTLS.
• Median time from directory disable to cloud session revocation for leavers.
• Percentage of application credentials in the IdP that are certificates or federated rather than secrets.
• Days since last tested signing-key rollover and KRBTGT reset.

Common failure patterns

• MFA at the IdP, passwords everywhere else: LDAP and NTLM paths into the same accounts make the IdP's MFA optional for an attacker.
• Signing keys treated as configuration: token-signing certificates exported, backed up to file shares or never rolled. Microsoft's AD FS guidance warns against storing certificates on network shares.
• Sync connector with standing replication rights left unmonitored: it holds the same rights DCSync uses, yet is often missing from the privileged account inventory.
• Disable equals revoke assumption: leavers disabled in the directory keep working cloud tokens because sessions were not revoked.

Framework mapping

Practitioner checklist

• Write down the store of record for people, groups, devices and each NHI class.
• List every consumer by protocol and mark which side each control must live on.
• Add domain controllers, sync servers, connector accounts, IdP admin roles and signing keys to the tier 0 asset list.
• Remove replication rights from every account that is not a domain controller or a documented sync connector.
• Require LDAPS or StartTLS for binds and refuse unauthenticated binds.
• Protect IdP signing keys in an HSM or provider-managed store and rehearse a double rollover.
• Enable password hash sync as a fallback where your hybrid design allows it, and document manual failover.
• Revoke cloud sessions as part of every leaver process, not just directory disable.
• Move workloads calling cloud APIs from directory passwords to workload identity federation.

Standards and references

• IETF: RFC 4511 Lightweight Directory Access Protocol (LDAP): The Protocol
• IETF: RFC 4513 LDAP Authentication Methods and Security Mechanisms
• OpenID Foundation: OpenID Connect Core 1.0
• NIST: SP 800-63C-4 Federation and Assertions
• MITRE ATT&CK: T1003.006 OS Credential Dumping: DCSync
• MITRE ATT&CK: T1606.002 Forge Web Credentials: SAML Tokens
• Microsoft Learn: Choose the right authentication method for your Microsoft Entra hybrid identity solution
• Microsoft Learn: Microsoft Entra Connect accounts and permissions

Related NHI Mgmt Group resources: Active Directory and Entra ID Hardening Guide · SAML vs OIDC Guide · Zero Trust in Hybrid Active Directory Environments · IAM and IdP Buyer's Guide