Directory service (LDAP and Active Directory) rollout playbook: build a tier 0 directory, phase by phase

A directory service ends up holding the keys to every server, workstation and application that trusts it, so the shortcuts taken during rollout, such as a flat admin model, cleartext binds and service accounts with passwords that never change, tend to last for a decade. This playbook covers deploying a new directory, or a new forest or LDAP tree, as a product class: design decisions, standing up the domain controllers or directory servers as tier 0, the admin and delegation model, service accounts and secure binds, onboarding clients and applications in waves, and launching with testing, recovery and rollback. It is vendor-neutral and draws on the joint guidance on detecting and mitigating Active Directory compromises from ASD, CISA, NSA and partner agencies, IETF RFC 4513, NIST SP 800-53 Rev. 5 and MITRE ATT&CK. It is written for identity engineers, infrastructure architects and the security leads who approve the build. Product choice is covered in the Directory Services and Cloud Directory Buyer's Guide; protocol depth is in the LDAP Security Deep Dive Guide.

Key takeaways

• Treat the directory as tier 0 from the first server. The joint agency guidance places domain controllers, certificate authorities, federation and synchronisation servers and their backups at the highest tier; build them that way rather than hardening later.
• Design the admin model before creating accounts. Separate tiers, a small set of dedicated admin accounts and delegated rights for routine tasks prevent the "everyone is a domain admin" pattern.
• Service accounts are the softest target. Kerberoasting and DCSync both start with over-privileged service identities; use managed service accounts or long, rotated passwords and keep them out of privileged groups.
• Refuse cleartext from day one. RFC 4513 says unauthenticated binds should fail by default and name/password binds need confidentiality protection, so require TLS and signing before the first application connects.
• Prove recovery before go-live. An offline, tested restore of the directory is the only rollback that works after a compromise.

Phase 0: scope and design decisions

Agree what the directory will be authoritative for and how it fits the wider identity architecture. A directory stores identities, groups and policy for devices and LDAP-aware applications; an identity provider handles federated sign-in to web and SaaS applications. Most estates need both, with the directory feeding the identity provider. See Directory Service vs Identity Provider.

Also decide the organisational unit (OU) structure. Design OUs around administration and policy, not the org chart: separate OUs for tier 0 assets, admin accounts, service accounts, servers by tier, workstations and users, so that delegation and policy can be scoped cleanly. See the Active Directory Delegation Design Guide.

Phase 1: build the directory servers as tier 0

The joint guidance from ASD, CISA, NSA, the Canadian Centre for Cyber Security, NCSC-NZ and NCSC-UK (September 2024) describes 17 common compromise techniques, from Kerberoasting to Golden Tickets, and its general recommendation is a tiered model in which tier 0 credentials are never exposed to lower-tier systems. Apply that to the build itself.

1. Dedicated hosts: domain controllers and directory servers run nothing else: no web, file, print or management agents beyond those approved for tier 0. The guidance recommends disabling the print spooler on domain controllers.
2. Hardened baseline: apply a recognised hardening benchmark for the server OS and directory role, managed as code with drift detection (NIST SP 800-53 CM-6 and CM-7; CIS Controls v8.1 safeguard 4.1).
3. Virtualisation and storage: if replicas are virtual machines, the hypervisor, its management plane and the storage holding the database are tier 0 too, administered only by tier 0 accounts.
4. Admin access path: tier 0 systems are administered only from privileged access workstations with phishing-resistant MFA, as the guidance recommends. See the Privileged Access Workstations Guide.
5. Logging before data: forward directory server, certificate authority and PowerShell logs to the SIEM and confirm they arrive before the first user is created. The guidance lists event 1102 (security log cleared) among the signals to watch.
6. Secure defaults at creation: set the machine account quota to 0 so ordinary users cannot join computers, require Kerberos pre-authentication on every account, and disable NTLMv1. All three come directly from the agency mitigations for MachineAccountQuota abuse, AS-REP roasting and DCSync.

Phase 2: admin model and delegation

The agencies recommend minimising membership of the most privileged groups and protecting tier 0 with phishing-resistant MFA, privileged access workstations and zero trust controls. Turn that into a concrete model before the first admin account is created.

• Separate accounts: every administrator has a daily account and one admin account per tier they manage (NIST SP 800-53 AC-6; CIS Controls v8.1 safeguard 5.4).
• Protect privileged users: the guidance recommends marking privileged accounts as sensitive so they cannot be delegated and placing them in the protected users group, which removes weaker authentication options for them.
• Logon restrictions: enforce the tier rules with policy (deny logon rights for higher-tier accounts on lower-tier hosts), not just a written standard.
• Break-glass: one or two emergency tier 0 accounts with long random passwords held offline, alerted on use and tested quarterly. See the Break-Glass Account Guide.
• ACL hygiene from the start: keep a record of every non-default permission on the domain root, AdminSDHolder-protected objects and OUs. See the Active Directory ACL Hygiene Guide.

Phase 3: service accounts and secure binds

Applications and appliances connect to a directory with service identities, and these are where most directory compromises begin. The agency guidance ties Kerberoasting (T1558.003) to service accounts with a service principal name (SPN) and DCSync (T1003.006) to accounts that hold replication rights.

• Managed first: use the directory's managed service account feature (group managed service accounts in Active Directory), which rotates long passwords automatically. See the Group Managed Service Accounts (gMSA) Guide. Where that is not possible, the guidance calls for long, unique, managed passwords of at least 30 characters.
• Few SPNs, no privilege: minimise accounts with SPNs and keep them out of privileged groups.
• Replication rights: only directory servers should hold them. The guidance recommends reviewing accounts with replication rights at least every 12 months.
• Secrets in a vault: passwords for application bind accounts belong in a secrets manager with an owner and a rotation schedule, never in scripts or shared drives. Group Policy Preferences passwords are a known example: the guidance says to remove all existing cpassword values from SYSVOL. See the Secrets Management Guide.
• Delegation: do not grant unconstrained delegation; use constrained or resource-based delegation where an application needs it, per the guidance.

For LDAP binds, RFC 4513 (Proposed Standard, June 2006) is the baseline:

Clients must verify the server's identity when starting TLS (RFC 4513 s3.1.3), so issue directory server certificates from a managed CA and track their expiry. The guidance also notes that enabling LDAP signing mitigates relay attacks on machine account creation.

Phase 4: onboarding clients, applications and data in waves

Whether this is a greenfield build or a move from an old directory, onboard in risk-ordered waves. For forest moves, see the Active Directory Domain and Forest Migration Guide.

• Migrate identities, not history: when moving accounts from an old directory, avoid carrying SID history longer than needed; ATT&CK tracks its abuse as T1134.005 SID-History Injection.
• Clean data in, not after: import only active accounts with an owner; disable stale and orphaned accounts in the source rather than migrating them.
• Non-human identities: inventory every service, computer and application account as it arrives, with owner and purpose. See How to build a service account inventory from Active Directory.

Phase 5: launch, recovery and rollback

1. Test before each wave: logon, group policy application, password change, account disable reaching downstream applications, and negative tests: a cleartext bind is refused, a user without join rights cannot add a computer, a lower-tier admin cannot log on to a directory server.
2. Audit-mode first for protocol changes: log weak binds and NTLM use before blocking them, then enforce by wave. The LDAP Security Deep Dive Guide covers the audit events.
3. Backup and offline restore: back up directory system state from more than one replica, keep at least one copy offline and isolated, and treat backups as tier 0 as the agencies recommend (NIST SP 800-53 CP-9). Run a full restore into an isolated network before go-live. See the Identity Recovery Guide.
4. Rollback: for a migration, keep the old directory able to authenticate each wave until that wave has run through a peak business cycle, with a named owner who can authorise rollback.
5. krbtgt and compromise readiness: the guidance recommends resetting the Kerberos ticket-granting account password every 12 months, and twice, with replication between resets, after a suspected compromise. Schedule the first routine reset and rehearse the double reset.
6. Incident readiness: agree the response to a domain compromise before go-live. See the Active Directory Domain Compromise Response Playbook.

The Cisco Active Directory Credentials Leak 2025 shows why rotation belongs in the run book: password hashes taken in a 2022 intrusion, reportedly including service accounts and the Kerberos ticket-granting account, were republished years later, and stolen hashes stay useful for as long as the accounts behind them are unchanged.

Decision guidance

Small versus large organisations: a small organisation can run a single domain with two replicas, a three-tier model enforced by policy and a managed backup. A large organisation needs an identity platform owner, a formal tier 0 asset register, OU-scoped delegation for regional teams, a change board for trusts and schema changes, and a dedicated directory monitoring capability. In both, tier 0 isolation, service account control and tested recovery come first.

Detection and measurement

From the pilot onward, monitor the events the joint guidance associates with the most common compromises:

For the full monitoring design see the Active Directory Security Monitoring and Event IDs Guide. Rollout metrics:

• Tier 0 membership: number of accounts with tier 0 rights against the approved list.
• Service account posture: percentage of service accounts that are managed or have rotated 30+ character passwords.
• Cleartext binds: unsigned or cleartext LDAP binds per week, trending to zero by wave 4.
• Stale identities: enabled accounts with no logon in 90 days, by type.
• Restore readiness: days since the last successful isolated restore test.

Once live, move to the quarterly Active Directory and LDAP Health Check.

Framework mapping

Common failure patterns

• Tier 0 sprawl: backup operators, monitoring agents and hypervisor admins gain effective control of the directory without being treated as tier 0.
• Service accounts as admins: an application account with an SPN is added to a privileged group "to make it work", turning a Kerberoast into domain compromise.
• Cleartext binds left on: appliances configured with simple binds over port 389 during the pilot are never moved to TLS.
• Defaults never changed: the machine account quota and legacy NTLM stay at their defaults because no one owned the build checklist.
• Untested backups: backups exist but have never been restored into an isolated network, or are reachable from the domain they protect.
• Trusts without owners: trusts created for a migration or acquisition stay in place with no review date.

Practitioner checklist

• Record the forest boundary, OU design, trust policy and authoritative source before building.
• Build directory servers, CAs, sync servers, hypervisors and backups as tier 0 with a managed baseline.
• Set machine account quota to 0, require Kerberos pre-authentication and disable NTLMv1 at creation.
• Create named tier 0 admin accounts used only from PAWs with phishing-resistant MFA.
• Enforce tier logon restrictions and delegate routine tasks with OU-scoped rights.
• Use managed service accounts or 30+ character rotated passwords; keep SPN accounts out of privileged groups.
• Reject unauthenticated and cleartext binds; require TLS and signing before applications connect.
• Forward directory, CA and PowerShell logs to the SIEM and alert on the events above.
• Complete an isolated restore test and rehearse the double krbtgt reset before go-live.
• Hand over to the quarterly health check with baseline metrics recorded.

Standards and references

• ASD, CISA, NSA and partners: Detecting and Mitigating Active Directory Compromises
• CISA: Detecting and Mitigating Active Directory Compromises resource page
• IETF: RFC 4513 LDAP Authentication Methods and Security Mechanisms
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0
• MITRE ATT&CK: Kerberoasting
• MITRE ATT&CK: DCSync

Related NHI Mgmt Group resources: Active Directory Security Checklist, Active Directory and LDAP Health Check, OpenLDAP Security, Active Directory Tiering vs Red Forest, Identity provider (IdP) and SSO platform rollout playbook.