There is a directory somewhere in your organization that has not been touched in three years. It authenticates everyone. It has never gone down. Nobody thinks about it.
Everyone is very relieved about this.
They shouldn’t be.
The irony hiding in plain sight
In 1983 Lisanne Bainbridge wrote a short paper called Ironies of Automation. Her subject was industrial process control, but the argument outlived the context. The more reliable you make a system, the less its operators practice running it. And so the better it runs, the worse they get at handling it the day it finally misbehaves. Reliability doesn’t just remove the failures. It removes the reason to stay competent.
Directories are the purest expression of this irony you will ever meet, because they combine three properties that almost nothing else does at once:
- Load-bearing. Everything authenticates against it. Mail, VPN, the wiki, the badge readers, the thing nobody documented in 2014.
- Invisible. When it works, and it works nearly always, no human looks at it. There is no dashboard anyone opens for fun.
- Genuinely stable. A well-built OpenLDAP or Active Directory deployment will run for years with no meaningful intervention. That is not marketing. That is the technology keeping its promise.
Put those three together and you get a machine that is critical, ignored, and durable. That is
the exact recipe for evaporated knowledge. The person who understood the ACL logic has left. The
syncrepl topology is fine right up until a provider dies and nobody remembers whether it
recovers by delta or by full refresh. The TLS cert on slapd expires every couple of years,
and every couple of years it is a small emergency, because whatever anyone learned last time
decayed in the interval.
None of this is because the directory is bad. It is happening because the directory is good.
The seductive wrong answer
Say the paradox out loud and someone will follow it to its logical, dangerous conclusion: well, then, the more things break, the more people know how to fix them. So break more things. Keep the muscle warm. Run toward the fire.
This has a respectable name. It’s the instinct behind chaos engineering and the game-day drill: inject failure on purpose so the failure never surprises you. And for a stateless, horizontally-scaled web tier, it is genuinely good practice. Kill a node, watch the system shrug, learn something.
You cannot do this to the directory of record.
The thing that authenticates everything is precisely the thing you do not get to break for practice. Chaos engineering assumes graceful degradation. It assumes a bounded blast radius, a system built to lose pieces. Your directory was built to be believed. When it lies or vanishes, nothing degrades gracefully; everything stops at once. “Break it to stay sharp” is sound advice aimed at exactly the wrong system.
So the forcing function can’t be failure. But you still need a forcing function, because Bainbridge is still right. Left alone, the knowledge rots. The trick is to find something that puts hands on the system on a schedule without betting the business to do it.
Kaizen: improvement as the forcing function
Borrow the idea from the least glamorous place imaginable: the Toyota factory floor. Kaizen. Continuous, small, deliberate improvement. Not a transformation. Not a project with a steering committee. One small thing, on a cadence, forever.
The move is quietly clever. Chaos engineering keeps skills sharp by injecting failure. Kaizen keeps them sharp by injecting improvement. And the side effect is identical. Every quarter, or every six months, someone opens the directory on purpose, understands one corner of it well enough to make it a little better, and closes it having refreshed exactly the knowledge you will need in the emergency you can’t schedule. You get the rehearsal without the risk. You reduce real debt instead of manufacturing artificial failure. The system gets better and the humans stay fluent, from the same hour of work.
Make it concrete. The best first candidate is almost always access control, because ACLs
are the single most notorious “nobody remembers how this works” artifact in any directory.
So: one quarter, you sit down and actually read the access rules. You find the to * clause
that grants more than anyone intended. You find the service account that got manage because
it was easier than reasoning about the right scope, five years ago, under deadline. You narrow
it. You write down why. You leave the ruleset smaller and the reasoning legible.
You have now done three things at once. You closed a real security gap. You wrote the documentation that didn’t exist. And here is the part that matters most and shows up least on any report. You put a human back in contact with how the directory actually thinks, so that the next time something breaks at 2 a.m., the knowledge is warm instead of archaeological.
Next cycle it’s something else. Rotate the cert as a rehearsed drill instead of a fire. Prune the privileged group membership that outlived its reason. Test the failover you’ve never tested. Retire one piece of schema sprawl. It is never dramatic. That’s the point.
Boring is still the goal
The whole promise of a directory is that it is boring. It recedes, keeps working, and lets you think about other things. That promise is real, and it’s worth defending. But there are two ways to be boring. One is the quiet rot: untouched, unremembered, one expired cert away from a crisis nobody is equipped to handle. The other is boring on purpose, a system that stays stable because a competent human visits it on a schedule and leaves it a little better each time.
Same calm surface. Completely different thing underneath.
Kaizen is how you get the second one. It is not exciting, and it is not supposed to be. It’s just the discipline that keeps “it’s been running for years” from turning, one silent quarter at a time, into “and nobody here knows why.”