Active Directory Hardening: Closing the Paths Attackers Love

Active Directory hardening does not fail because teams lack settings. It fails because powerful identity paths remain usable after the checklist passes.

A domain can meet most of a benchmark and still be one reused local password, nested administrator group, unsigned LDAP client, or forgotten service account away from full compromise. Active Directory is a control plane. If an attacker owns it, they can change access, push Group Policy, copy directory secrets, and turn ordinary recovery work into a business outage.

Microsoft's October 2025 identity research reported more than 7,000 password attacks per second in 2024. It also found that 66 percent of attack paths involved some form of identity compromise. Those numbers make the priority plain. Close routes to privilege before polishing a compliance score.

What should Active Directory hardening protect?

Protect the ability to authenticate, authorize, administer, and recover the business. That includes domain controllers, privileged groups, administrative workstations, Group Policy, directory permissions, service identities, certificate services, federation, synchronization, DNS, backups, and the people allowed to change them.

Start with the system hardening operating model, then apply it to identity paths. The approved state should answer four questions for every sensitive object: who owns it, who can change it, where those credentials can be used, and how the team will restore trust. A setting without those answers is configuration, not control.

How do you find the paths that matter first?

Inventory control relationships before changing policy. List every forest and domain, each domain controller, trust, privileged group, delegated organizational unit, Group Policy editor, certificate authority, federation service, synchronization server, backup operator, and application that binds to LDAP. Record operating system versions and support dates. Old identity infrastructure rarely announces itself in the project plan.

Read nested membership, not just the visible top level. A help desk group can inherit domain power through three layers of delegation. The following commands use the official Active Directory module and replication tooling. Run them with a read only assessment account and store the output as evidence.

Repeat the collection after each material change. A snapshot answers who had access at collection time. It does not prove that access stayed narrow, replication stayed healthy, or a delegated permission did not reopen the path.

How should privileged access be separated?

Treat domain and forest administration as a separate job with separate identities and devices. Daily email, browsing, chat, and software development accounts should never hold domain power. An administrator who needs to manage a workstation does not need rights over domain controllers. An application owner does not need permission to edit the organizational unit above every production server.

Keep permanent membership in the most powerful groups close to zero. Grant time limited elevation for a named task, log the approval, and remove it automatically. Use dedicated administrative workstations for the identity tier. Deny those credentials from lower trust systems. The least privilege implementation guide shows how to narrow access without blocking routine operations.

Review every delegation as a path, not a label. Rights to modify a group, reset a privileged password, change a Group Policy object, enroll a dangerous certificate template, or write a service principal name can be more useful to an attacker than direct group membership. The security team needs the resulting reachability, while directory owners need the exact permission and repair.

Which credentials should you fix before password policy?

Shared local administrator passwords come first because one stolen value can move across a fleet. Use Windows LAPS, restrict who can read stored passwords, encrypt them in Active Directory where the domain supports it, and alert on retrieval. Replace ordinary service accounts with group managed service accounts where applications allow it. For accounts that cannot move, use long random passwords, narrow logon rights, record the owner, and set a migration date.

Rotate secrets after exposure, not on a calendar alone. A password changed every 60 days is reusable for 59 days after theft. Protect service hosts so privileged credentials never land on systems with ordinary user activity. Remove inactive accounts and stale computer objects only after ownership and dependency checks. Deleting first and asking later teaches operations to resist the next hardening change.

How do LDAP, Kerberos, and NTLM fit into AD hardening?

Protocol changes need observation before enforcement. Microsoft's January 2026 LDAP signing guidance says new Windows Server 2025 Active Directory deployments require LDAP signing by default. Older deployments can still accept unsigned binds, and upgrades preserve existing policy. That difference is exactly why an inventory of server version and effective policy matters.

Monitor Event ID 2887 for clients making unsigned LDAP binds. Use the channel binding events to find clients that cannot meet the target state. Fix or isolate each dependency, then require signing and the chosen channel binding level in a staged rollout. Do the same for NTLM reduction and Kerberos encryption. Count the applications that still depend on the old protocol, name their owners, and give every exception an expiry.

Do not confuse encryption with identity assurance. TLS protects a connection. It does not repair a broad service account, unsafe delegation, weak certificate template, or credential entered on an untrusted host. Protocol policy closes one family of paths. The directory permissions and credential boundaries close the rest.

What belongs on a hardened domain controller?

Very little. Domain controllers should run the identity role, required security controls, backup software, and approved management agents. Remove browsers, productivity tools, extra server roles, unused services, and direct internet access. Restrict interactive logon. Allow management only from the administrative tier. Protect DNS and time because Kerberos and directory discovery depend on both.

Apply the Windows Server hardening checklist to the operating system, then add domain controller policy. Patch in rings, watch replication and authentication health, and keep at least one known recovery path. Application allow rules, endpoint protection, security logs, directory change auditing, and backup alerts belong on every controller. A controller that stops reporting is unknown, not healthy.

How should Group Policy and certificate changes be controlled?

Group Policy can change thousands of systems from one console. Give each production object an owner and a narrow group allowed to edit it. Back up the object before change, review both its settings and links, test in a canary organizational unit, and confirm the resulting policy on target machines. Watch creation, deletion, link changes, permissions, filters, and edits to sensitive policy. A correct setting linked to the wrong scope is still an incident.

Treat Active Directory Certificate Services as part of the identity control plane. Inventory certificate authorities, templates, enrollment agents, published templates, web enrollment, and every group with rights to change them. A certificate that supports authentication can become a credential. A template with broad enrollment and dangerous subject options may create a route to privilege even when passwords and group membership look clean.

Apply the same discipline to federation and directory synchronization. Protect the servers, service identities, connectors, and configuration with the identity tier. Alert when a new credential, certificate template, trust, synchronization rule, or Group Policy editor appears. Review the change against an approved request, then verify the effective path. Sensitive control plane changes should never rely on a quarterly scan for discovery.

Why does attack path closure beat a larger checklist?

Microsoft published a useful case in April 2026. A threat actor entered through an internet facing IIS server. Within 24 hours, the actor used privileged accounts to create a scheduled task on a domain controller and collect directory credential material. Later, one password spray reached at least 14 servers through password reuse.

That recent incident connects the controls. Patch and isolate the edge host. Keep domain credentials off it. Remove password reuse. Restrict remote administration. Watch privileged group and domain controller actions. A checklist organized by product settings can scatter those decisions across five teams. An attack path gives them one owner and one closure test.

Can you prove the forest is recoverable?

Backups are necessary. A rehearsed forest recovery is the control. Microsoft's Active Directory forest recovery guide calls for restoring at least one domain controller in every domain from a trusted backup. The forest root comes first. Build the runbook around your actual domains, DNS, certificates, privileged access, backup custody, and network isolation.

Test in an isolated environment. Measure the time to restore authentication for a critical service. Verify that backup administrators cannot also alter production directory policy. Keep offline copies of the steps and the credentials needed to start recovery. Domain compromise is a trust failure. Restoring virtual machines without proving a clean identity boundary can restore the attacker too.

What does unchecked privilege cost?

Suppose 18 permanent administrators each use a powerful account on four ordinary servers. That creates 72 places where a domain credential can be exposed. Move administration to three dedicated workstations and issue elevation only when needed. The standing exposure drops from 72 host relationships to three controlled ones. That is a 96 percent reduction before buying another detection tool.

Use the same math for service accounts, local passwords, LDAP clients, and Group Policy editors. Count paths to control, not people trained or documents approved. The security misconfiguration guide explains how effective state and exposure should change remediation order.

Which Active Directory hardening mistakes create outages?

Enforcing LDAP signing before finding old clients can break authentication. Removing nested access without tracing ownership can stop payroll or backup. Applying a domain wide Group Policy without a canary can lock out every administrator at once. Rotating a service password without changing the consuming task creates a silent dependency failure.

The answer is staged control, not permanent delay. Observe. Assign the dependency. Test the target state. Preserve recovery. Deploy to a narrow ring. Verify authentication and replication from the running environment, then widen. Every exception needs an owner, reason, compensating control, and expiry date.

Frequently asked questions

What is the first step in Active Directory hardening?

Map paths to domain and forest control. Inventory privileged groups, delegated permissions, administrative devices, service identities, domain controllers, certificate services, trusts, and recovery access before changing settings.

Should Domain Admins be empty?

Keep standing membership as close to zero as operations allow. Use separate administrative identities and time limited elevation for approved tasks. Monitor every membership change and every use of domain power.

Does Windows Server 2025 fix LDAP security automatically?

New deployments require LDAP signing by default, but upgrades preserve existing policy. Channel binding and client compatibility still need review. Read effective policy and audit client behavior before enforcement.

How often should Active Directory hardening be reviewed?

Review sensitive membership and changes continuously. Recheck the full baseline after server, schema, trust, federation, certificate, or policy changes. Exercise forest recovery at a cadence tied to business recovery needs.

The executive takeaway

Pick one route to domain control this week and close it end to end. Remove the reusable credential, narrow the permission, isolate the administrative session, verify the effective state, and test recovery. Deep endpoint context with AI driven analysis can show which hosts and identity paths make a weakness reachable, but directory ownership still needs a named operator. Measure fewer paths to control. That is the result that matters.