Directory Services and Cloud Directory Buyer's Guide

The directory is the system of record that every login, group lookup, Kerberos ticket and service account depends on, and buying the wrong one locks in protocol gaps and attack paths for a decade. The market now spans self-managed Active Directory and LDAP servers, Linux identity management suites, managed Active Directory offered by cloud providers, and cloud directories delivered as a service that combine LDAP, RADIUS, device management and SSO. This vendor-neutral buyer's guide helps identity architects and infrastructure teams define requirements, compare deployment models, test protocol security and plan a proof of concept. It focuses on the directory layer itself: choosing the workforce identity provider for SSO and MFA is covered in the IAM and IdP Buyer's Guide.

Key takeaways

Start from protocols, not features. List every consumer that needs LDAP, Kerberos, NTLM, RADIUS, Group Policy or SCIM before you shortlist anything: protocol gaps are what break migrations.
Insist on secure defaults for LDAP. Signed or TLS-protected binds only, no clear-text simple binds, and unauthenticated binds refused, as RFC 4513 recommends.
Treat the directory as tier 0. Its administrators, sync accounts and replication rights are as valuable as domain admin, so evaluate admin isolation and logging as hard requirements.
Count the non-human identities. Service accounts, LDAP bind accounts, computer objects and sync connectors usually outnumber people, and each needs an owner, a credential policy and an inventory.
Prove recovery and exit before you sign. Test backup, restore, export of objects and attributes, and coexistence with your current directory during the proof of concept.

Define requirements

Write the requirements as an inventory of consumers and data, then derive the capabilities. The questions below drive most of the decision.

Consumers: Which systems authenticate or look up identities against the directory today: Windows domain-joined machines, Linux and Unix hosts, network devices using RADIUS or TACACS+, VPNs, Wi-Fi (802.1X), printers and scanners using LDAP address books, legacy applications using LDAP bind, and SaaS applications fed by SCIM?
Protocols: LDAP v3 (RFC 4511) with StartTLS or LDAPS on 636, Kerberos (88), Global Catalog (3268/3269), Group Policy, NTLM where it cannot yet be removed, RADIUS (1812/1813), and SCIM 2.0 (RFC 7643 and RFC 7644) for provisioning.
Population and scale: Number of users, groups, devices and service accounts; number of sites and their latency to the directory; peak authentication rates such as start of shift.
Source of truth: Is HR the authority for people, and which system is authoritative for groups, devices and service accounts? See the Joiner-Mover-Leaver Guide.
Schema: Custom attributes and object classes your applications depend on, and whether the candidate allows schema extensions.
Hybrid and trust: Forests, domains and trusts that must remain, synchronisation to a cloud identity provider, and partner directories.
Regulatory and residency: Where directory data and password hashes may be stored, retention of audit logs, and any sector rule on authentication strength.
Operations: Who patches, backs up and monitors the directory, and what recovery time you need after ransomware hits the domain.

Deployment models compared

Most organisations end up with more than one model. Decide which model owns which population and protocol rather than looking for a single product that does everything.

Model	Typical fit	Strengths	Trade-offs to test
Self-managed Active Directory Domain Services	Windows-heavy estates, Group Policy, Kerberos applications	Full protocol coverage, schema control, mature tooling	You own patching, tiering, AD CS and forest recovery; large attack surface. See the Active Directory and Entra ID Hardening Guide.
Self-managed LDAP server (for example OpenLDAP or 389 Directory Server)	Linux fleets, network devices, application directories	Standards-based, flexible schema, low licence cost	Needs in-house skill for replication, ACLs and TLS. See the OpenLDAP Security guide.
Linux identity management suite (FreeIPA or Red Hat IdM style)	Linux and Unix estates needing Kerberos, sudo rules, host-based access control and an internal CA	Integrated LDAP, Kerberos, DNS and certificate services; trusts to Active Directory	Operational complexity; check upgrade and replica topology. See the FreeIPA and Red Hat Identity Management Guide.
Managed Active Directory from a cloud provider	Lift-and-shift of legacy Windows workloads into a cloud	Provider runs and patches domain controllers	Restricted administrative rights, limited schema and write scope; for example Microsoft Entra Domain Services is a standalone managed domain fed by one-way sync from Entra ID, and LDAP writes apply only to objects created in the managed domain. See the Microsoft Entra Domain Services Security guide.
Cloud directory as a service	Cloud-first and mixed Mac, Windows and Linux organisations without on-premises domains	Hosted LDAP and RADIUS, device policy, SSO and MFA in one service	Protocol depth (Kerberos, Group Policy), vendor concentration risk, and the impact of a compromise of the provider itself

The vendor's own security is part of the evaluation for any hosted model. The JumpCloud breach showed that an attacker inside a cloud directory provider can reach that provider's customers, so ask how customer tenants are isolated and how fast you would be told.

Capability areas

Area	What to look for
Protocol support	LDAP v3 with StartTLS and LDAPS, SASL (GSSAPI, EXTERNAL with client certificates), Kerberos, RADIUS, SCIM 2.0, and documented limits for each
LDAP security controls	Ability to require signing or TLS for every bind, refuse unauthenticated binds, enforce channel binding on Windows, and restrict anonymous reads. On Active Directory the relevant settings are "Domain controller: LDAP server signing requirements" and "Network security: LDAP client signing requirements"
Kerberos hygiene	AES-only encryption types, RC4 retirement path, constrained or resource-based delegation, and reporting on accounts with service principal names. See the Kerberos RC4 Deprecation guide.
Administrative model	Granular delegated roles, tiered administration, just-in-time elevation, phishing-resistant MFA for admins, and separate admin accounts
Service and machine accounts	Managed service accounts or equivalent automatic password rotation, owner attributes, last-logon data, and bind-account scoping
Linux and Mac integration	Client support through SSSD or native agents, offline credential caching, sudo and host access rules, SSH public key or certificate distribution
Synchronisation	Connectors to cloud identity providers and HR systems, attribute mapping, password hash or pass-through options, and how the sync service account is protected
Availability and replication	Multi-site replicas, read-only replicas for branch sites, replication conflict handling, published service levels
Logging and detection	Bind and authentication logs with client IP and identity, admin change logs, replication-right changes, export to SIEM without extra licences
Backup, recovery and exit	Object-level restore, authoritative restore, isolated recovery, and full export of objects, attributes and group memberships in a documented format

Evaluation criteria

Weight the criteria to your estate. The weights below are an NHI Mgmt Group starting point for a mixed Windows and Linux organisation moving workloads to the cloud, not a sourced benchmark.

Criterion	Suggested weight	Evidence to request
Protocol coverage for your consumer inventory	20%	Tested list of your top 20 consumers working in the pilot
Secure-by-default authentication (signed or TLS binds, AES Kerberos, admin MFA)	20%	Default configuration export and the steps to enforce each control
Administrative isolation and auditability	15%	Role model, sample admin change log, SIEM integration demo
Non-human identity handling	15%	How service accounts are created, owned, rotated and reported
Resilience and recovery	15%	Recovery runbook, timed restore in the pilot, backup isolation
Vendor security and transparency (hosted models)	10%	Independent assurance reports, incident disclosure history, support access controls
Exit and portability	5%	Full export of a test tenant and re-import into another directory

Where identity fits

A directory is where most non-human identities in a traditional estate live: Windows service accounts, LDAP bind accounts used by applications and appliances, computer accounts, and the synchronisation account that connects on-premises and cloud identity. Attackers target these because they rarely have MFA and often have broad rights. Common techniques include enumerating domain accounts (ATT&CK T1087.002), abusing valid domain accounts (T1078.002) and requesting replication with DCSync (T1003.006). The Storm-0501 attacks used stolen sync credentials to move from on-premises into the cloud. Require the candidate to report every account with replication rights, every bind account and its owner, and every account whose password does not rotate. See the service account inventory guide and How to audit the Entra Connect sync account.

Questions to ask vendors

Show us refusing a clear-text simple bind and an unauthenticated bind on a fresh tenant. Are these refused by default, or only after configuration?
How do we find clients still using unsigned or clear-text LDAP before we enforce? On Active Directory, can you collect Directory Service events 2887 and 2889 and report the offending client addresses?
Which Kerberos encryption types are enabled by default, and how do we remove RC4?
Which administrative roles exist, can they be scoped to organisational units or groups, and can admin rights be granted just in time with approval?
How are service accounts and bind accounts rotated, and can an account be restricted to specific hosts or source addresses?
What is logged for each bind and authentication, how long is it retained, and what does export to our SIEM cost?
For hosted models: how is our data isolated from other customers, how is your support staff access to our tenant approved and logged, and what is your incident notification commitment?
Can we extend the schema, and what happens to custom attributes during your upgrades?
Walk us through recovering from a malicious mass deletion or a compromised administrator, with timings.
How do we export every object, attribute and membership if we leave?

Red flags

Clear-text LDAP on port 389 accepted by default with no plan to require signing or TLS.
A single all-powerful administrator role with no scoping, no just-in-time option and no separate admin accounts.
Service or bind accounts with static passwords and no rotation feature, or a recommendation to use a domain admin as the LDAP bind account.
Authentication logs that omit client IP or bind type, or that cost extra to export.
No tested answer to "how do we recover the directory after ransomware", or recovery that depends on the same credentials the attacker would hold. See the Active Directory Recovery buyer's guide.
Vague answers on the provider's own breach history, support access or tenant isolation.

Proof of concept

Baseline: export your current directory's bind and authentication logs for two weeks and list every consumer, protocol and bind type in use.
Build the pilot tenant with production-like settings: signed or TLS binds required, unauthenticated binds refused, AES-only Kerberos, admin MFA, separate admin accounts.
Connect representative consumers: one Windows and one Linux host, a VPN or Wi-Fi RADIUS client, a legacy LDAP application, a printer or appliance, and one SaaS application through SCIM.
Test failure paths: a client that tries a clear-text bind must fail and be logged; a disabled user must lose access on every consumer within your target time.
Test administration: delegate a scoped role, elevate just in time, and confirm every change reaches your SIEM with actor, target and time.
Test service accounts: create, rotate and retire a bind account and confirm the consuming application keeps working through rotation.
Test recovery: delete an organisational unit and restore it, then time a full restore from backup into an isolated environment.
Test exit: export the pilot tenant and import it into a second directory to prove portability.
Plan coexistence and rollback: run old and new directories side by side through synchronisation or trusts, move consumers in rings, and keep the old directory authoritative until each ring passes.

Measuring success after go-live

Percentage of binds that are signed or TLS protected (target 100% before enforcement).
Number of service and bind accounts without an owner, and number with passwords older than your policy.
Number of accounts holding replication or tier 0 rights, reviewed monthly.
Time from HR leaver event to account disable across all consumers.
Restore time measured in the last recovery test.

Framework mapping

Framework	Reference	How the directory supports it
NIST CSF 2.0	PR.AA-01, PR.AA-03	Managing identities and credentials for users, services and hardware; authenticating them
NIST SP 800-53 Rev. 5	AC-2, IA-2, IA-3, IA-5, AU-2	Account management, user and device authentication, authenticator management, event logging
CIS Controls v8.1	Control 5 (Account Management), Control 6 (Access Control Management)	Inventory of accounts including service accounts, centralised account and access management
MITRE ATT&CK	T1087.002, T1078.002, T1003.006	Techniques the logging and admin controls must detect or prevent

Standards and references

How NHI Mgmt Group can help

We provide independent requirements, RFP and evaluation support for directory, IAM and non-human identity programmes, including service account inventory and migration planning. Browse vendors in our NHI and AI products directory or contact us.

Directory Services and Cloud Directory Buyer’s Guide: evaluation criteria, questions and proof of concept tests