Protecting Active Directory comes down to three things: reducing the number of paths an attacker can take to privilege, making changes to the directory and its domain controllers visible and controlled, and having a tested way back if control is lost. Most environments have accumulated more paths than they realize and can close several without buying anything.
Reduce the paths to privilege
- 1. Run a configuration assessment. Several are free, including Purple Knight from Semperis and PingCastle from Netwrix, which runs checks mapped to MITRE ATT&CK and ANSSI frameworks. Do this before evaluating any product. Most environments have accumulated misconfigurations that can be closed at no cost, and the results reframe every other decision on this list.
- 2. Map your attack paths. Find the chains that lead from an ordinary account to Domain Admin. They exist. They accumulate through delegation nobody revisited. Closing three of them is worth more than most tooling purchases.
- 3. Audit privileged group membership. Domain Admins, Enterprise Admins, Schema Admins, and the built-in Administrators group. Most environments have members who should not be there, including service accounts added years ago for a reason nobody remembers.
- 4. Fix service account passwords. Service accounts with weak passwords and service principal names are what makes Kerberoasting work. Use group managed service accounts where you can, and long random passwords where you cannot.
- 5. Review delegation settings. Unconstrained delegation on a machine account is a standing escalation path. Check for it explicitly, because it does not surface on its own.
- 6. Check Active Directory Certificate Services. Certificate template misconfigurations let a low-privileged account request a certificate for a privileged one. This is a well-documented escalation route and it is frequently missed because AD CS sits outside the usual AD review.
Control and observe change
- 7. Implement tiered administration. Domain admin credentials should never authenticate to a workstation. This is difficult, it is disruptive, and it removes the single most common route from a compromised laptop to a compromised forest.
- 8. Audit changes through the replication stream, not just event logs. Techniques like DCShadow inject changes through replication precisely to avoid producing a log entry. AD auditing tooling that reads the replication stream captures changes that log-based approaches miss, which is a meaningful difference when evaluating products in this category.
- 9. Alert on the changes that matter, not all of them. Privileged group membership, group policy modification, ACL changes on sensitive objects, KRBTGT activity, and new domain controller registration. An alert on everything is an alert on nothing.
- 10. Enforce change on the domain controllers themselves. Establishing durable control usually requires modifying a DC: writing a binary, creating a service, adding a scheduled task. This is host-level change, and it can be evaluated against what that server is authorized to run rather than against who requested it. Mimic does this at the kernel, and it is the one item on this list where a valid privileged credential does not settle the question.
Be able to recover
- 11. Have a tested forest recovery plan. Not a backup. A tested recovery. AD forest recovery is a hard engineering problem, the manual process is long and error-prone, and dedicated tooling exists for good reason. The important word is tested.
- 12. Keep recovery infrastructure independent of the directory. If your recovery process authenticates against the AD you are recovering, you do not have a recovery process. This catches more organizations than it should.
If you do only three
Run the free configuration assessment. Fix privileged group membership. Test your recovery. Those three cost almost nothing, close the most common routes, and give you an accurate view of the problem before you spend anything.
This checklist stands on its own, but it sits inside the larger question of Active Directory security: who can act versus what can change. For what item 10 looks like in a production environment, see how REI defended its Active Directory.
Active Directory protection, answered.
What is the first thing to do to secure Active Directory?
+Run a configuration assessment. Free tools including Purple Knight and PingCastle scan for misconfigurations and attack paths against established frameworks. Most environments have accumulated issues that can be closed without buying anything, and the results tell you which of the remaining problems are actually yours before you evaluate products.
How do you stop Kerberoasting?
+Kerberoasting targets service accounts with service principal names and crackable passwords. Use group managed service accounts, which rotate automatically with long random passwords. Where that is not possible, use long random passwords manually and audit which accounts hold SPNs, since many have them without needing them.
What is tiered administration in Active Directory?
+A model where credentials are scoped to a tier of assets and never authenticate outside it. Domain admin credentials are used only on domain controllers, never on workstations. It is disruptive to implement and it removes the most common path from a compromised endpoint to a compromised forest.
How often should Active Directory be audited?
+Configuration assessment quarterly at minimum, and after any significant change to delegation or group structure. Change auditing should be continuous, because the changes worth catching are individual events rather than trends. The two answer different questions and neither substitutes for the other.
Why does event log auditing miss some Active Directory attacks?
+Some techniques inject changes through the replication process rather than through a logged administrative action, which produces no corresponding event log entry. DCShadow is the best-known example. This is why AD security tooling increasingly reads the replication stream directly rather than depending on logs.
What should an Active Directory recovery plan include?
+A tested restore procedure rather than a backup, recovery infrastructure that does not authenticate against the directory being recovered, documented steps for KRBTGT reset, and a known recovery time. The most common failure is discovering during an incident that the recovery process depends on the thing that is broken.
