Why Securing Active Directory Is So Hard

You already know, from the last sub, that the common paths into a domain are not secrets. They are documented, talked about at every conference, and baked into free tools. So a reasonable person asks the obvious question: if everyone knows how Kerberoasting and DCSync work, why do domains keep falling to them, year after year? If you have ever read about an attack, understood it, and still found it alive in your own environment, you have felt the gap this sub is about.

The honest answer is that Active Directory is hard to secure for reasons that have little to do with not knowing the attacks. The knowledge is the easy part. The obstacles are structural, and they fall into a technical group and an organizational group. A defender who does not understand these obstacles will keep being surprised that the obvious fix never happens. A defender who does understand them designs a defense that works around them, which is what this course teaches.

It is worth saying plainly, because new defenders often blame themselves: if your domain has exposed paths despite your knowing better, you are not failing, you are running into the same structural walls everyone does. The skill is not heroically fixing everything. The skill is seeing the walls clearly, fixing what genuinely can be fixed, and building reliable visibility over the rest.

The technical challenges

Start with the technical reasons, because they are the ones that make the textbook fix impossible rather than merely difficult.

The first is legacy and backward compatibility. Active Directory has to keep decades of software working, so the safe choice is often the one that breaks something. You could disable the weak RC4 cipher that makes Kerberoasting easy, but an old application may depend on it, and when it fails nobody connects the outage to the security change. The directory's whole value is that everything keeps working, which is exactly the pressure that keeps weak settings alive.

NTLM is the starkest example. It is an old, weak authentication protocol Microsoft has wanted gone for years, yet it survives in almost every domain because some device, some application, or some integration still depends on it, and no one is sure which. Turning it off risks an outage with no obvious cause, so it stays, and with it stays a whole class of relay and replay attacks. The weakness persists not because anyone defends it but because removing it is genuinely dangerous.

The second is accumulated complexity. As the last sub showed, the attack surface is a graph that only grows: thousands of accounts, layers of group membership, permissions and trusts laid down over decades by people who have long since left. No one understands the whole of it. You cannot confidently fix what you cannot fully see, and untangling a permission that might be load-bearing for something is genuinely risky.

The fear is specific and rational: somewhere in that tangle, a permission or group membership that looks pointless is quietly holding up a critical application, and removing it breaks production at three in the morning with no clear cause. Faced with that risk, the safe move is to leave it, so the complexity is never reduced. Every administrator has a story about the cleanup that caused an outage, which is why so few attempt one.

The third is the visibility gap. The standard tools for running AD show objects one at a time and never the dangerous paths between them, and the native logs are quiet exactly where attacks are quietest, in reconnaissance and in actions that look like normal administration. You are defending something whose risky state and whose attacks are both hard to see without deliberate effort and the right tooling.

The organizational challenges

The technical obstacles would be enough, but the human and organizational ones are often what actually stops a fix.

The deepest organizational challenge is the tension between security and operations. Active Directory's reason to exist is to grant access and keep the business running. The people who run it are usually measured on uptime and on how fast they can onboard a user or fix a login, not on how locked down the domain is.

A hardening change that carries any risk of breaking authentication for the whole company is a frightening thing to approve, so it often is not. Weak but working beats secure but risky, every time the incentives are not deliberately changed.

The incentive structure quietly decides the outcome. The administrator who hardens a setting and breaks an application is visibly at fault for a company-wide outage. The administrator who leaves a weak setting in place and is later breached can point to a sophisticated attacker. That asymmetry in blame pushes hard toward inaction, and no amount of knowing the right answer overcomes it until someone changes what the organization rewards.

Close behind is the split in ownership and skills. In many organizations Active Directory is run by an IT operations team, while the threats against it are understood by a security team, and the two do not always speak the same language or report to the same leader. Worse, the people who deeply understand both how AD works and how it is attacked are rare. The knowledge needed to fix the problem is often spread across people who are not the ones who can make the change.

This split is also why people who can hold both halves at once, how AD works and how it is attacked, are so valuable and so rare. An operations admin may know every corner of the directory and not see the attack paths in it; a security analyst may know the attacks and not know which change is safe to make.

The defender this course is trying to build sits in the middle: fluent enough in the attack to recognize it in evidence, grounded enough in how AD works to reason about what a fix would cost. That combination is the point of the whole orientation you are reading.

And there is the simple fact that the directory can never be taken down. It is the most always-on system in the estate; if it stops, everyone stops. There is no comfortable maintenance window to rebuild it cleanly, so changes are made cautiously, incrementally, on a live and business-critical system, which slows real improvement to a crawl.

The most thorough fix of all, rebuilding into a fresh, clean forest and migrating to it, is so disruptive that organizations attempt it only after a serious compromise, and sometimes not even then. For everyone else, improvement means careful, incremental change to a system that must never stop, which is a slow and nervous way to work.

Why this means detection has to carry the load

Put the technical and organizational challenges together and you reach the conclusion this whole course is built on. For a large share of Active Directory weaknesses, you cannot simply remove the problem. The weak setting is load-bearing, the permission might break something, operations will not accept the risk, or no maintenance window exists. The textbook fix is real, but in the real environment it is frequently blocked.

That is the realistic picture, and it reframes the whole job. If you often cannot remove the weakness, then being able to see it being abused is not a second-best option. It is the core of the defense. Detection carries the load that hardening cannot. When you cannot disable RC4, you watch for the RC4 ticket request that signals Kerberoasting. When you cannot untangle every permission, you watch for the replication that signals DCSync. When you cannot close every path, you make sure that walking one is noticed.

This is why the course is built around detection and analysis, with hardening as the context that surrounds each technique rather than the sole answer. It is not that hardening does not matter; you reduce every exposure you realistically can. It is that a defense which depends only on removing weaknesses will fail in the real environments these challenges describe, while a defense that can see the abuse keeps working even when the weakness cannot be removed.

That shift, from "remove the weakness" to "see the abuse," is not a lowering of ambition. It is the discipline that matches reality. The best AD defenders are not the ones with perfectly hardened domains, which barely exist, but the ones who know precisely which weaknesses they are living with and have a tripwire on every one. Knowing what you cannot fix, and watching it closely, is a higher form of defense than pretending everything can be fixed.

It also explains the shape of a mature AD security practice. You reduce what you can, continuously, because the surface keeps regrowing. And you watch everything you cannot reduce, so that the weakness you were forced to live with becomes a tripwire instead of a silent door. Neither half is optional, and the balance between them shifts with every constraint your environment imposes.

In practice that looks like a rhythm rather than a project: periodically re-map the graph and cut the worst new paths, because the surface has grown again since last time, and keep a standing set of detections on the attacks you cannot design out, tuned as the environment changes.

A team that does both is defending honestly. A team that does only the first is hardening a surface that regrows behind them; a team that does only the second is watching for attacks it could have made far harder. This course teaches both halves, weighted toward the watching, because that is where reality forces the emphasis, and because watching is the half that keeps working when every other constraint in this sub blocks the fix.

You now understand why securing Active Directory is genuinely hard, and why this course leans on detection as heavily as it does. That closes the first arc of the orientation, the threat. The next four subs turn to the directory itself, the architecture and components you have to understand in order to defend it, starting with the structure: domains, forests, trees, trusts, and the controllers that serve them.