The Day Everyone Became Root

The alert read: "247 users added to Domain Admins group in 90 seconds."

The Problem

At 10:47 on a Tuesday morning, my monitoring dashboard lit up like a Christmas tree having an existential crisis. The security logs showed something that shouldn't be possible: our Active Directory group membership had just experienced what could only be described as aggressive expansion.

Domain Admins: 247 members.
Server Operators: 247 members.
Enterprise Admins: 247 members.

For context, yesterday these groups had a combined membership of three. Me, the TTY, and one service account that I trust more than most humans.

The TTY appeared at my desk with the expression of someone who'd just discovered that "undo" isn't always an option.

TTY: "I may have done something."

In my experience, sentences that begin this way rarely end with "fixed the coffee machine."

Investigation & Escalation

According to the logs—those beautiful, immutable arbiters of truth—the TTY had received a ticket from Patricia in Accounting. She needed access to a shared folder. A simple permission change. A five-second task.

But the TTY, bless his learning curve, had discovered the Active Directory Users and Computers console. And within it, the seductive "Add to Group" button.

TTY: "I wanted to make sure she had enough permissions. So I added her to a few groups."

OPERATOR: "Define 'a few.'"

TTY: "Well, all of them. Just to be safe."

And then—this is where it gets theatrical—he'd apparently discovered the "Select All" function. Combined with the "Add Members" dialog. Applied to our entire user base.

Every employee, contractor, and one intern who'd started that morning now had the keys to the kingdom. The TTY had democratized infrastructure access with the enthusiasm of someone who'd never heard of the principle of least privilege.

The phone started ringing. Not unusual. What was unusual was the nature of the calls.

Janet from HR: "I can see everyone's salary information now. Is this normal?"

Normal? No, Janet. This is spectacular.

Dave from Marketing: "I accidentally rebooted something called 'SQL-PROD-01.' Should I be worried?"

Yes, Dave. We should all be worried.

The TTY had created a scenario that security textbooks use as cautionary tales. Except this wasn't theoretical anymore. This was 247 people with administrative rights and the dangerous combination of curiosity and confidence.

Someone in Sales had discovered they could install software. They'd chosen to install seventeen different cursor customization tools. On the domain controller.

The intern—remember the intern?—had found the Exchange server and was experimenting with mail flow rules. Every email now had the subject prefix "EXCITING: " and he thought he was helping with engagement.

The Theatrical Solution

I pulled the TTY aside, away from the growing queue of increasingly concerning incidents.

OPERATOR: "We're going to fix this. And you're going to learn why security boundaries exist."

First, the immediate triage. I crafted a PowerShell script—simple, elegant, devastating. It would remove everyone from administrative groups except the original three members. The TTY watched as I built in logging, validation, and a rollback mechanism.

OPERATOR: "Always have an undo button. Unlike what you did."

But before executing it, I made him document every single change that had occurred in the last hour. Every rebooted server. Every modified setting. Every installed cursor pack.

OPERATOR: "This is what happens when you give everyone root access. Chaos isn't malicious. Chaos is 247 people who now have the ability to help."

The TTY's eyes widened as the list grew. Nineteen server restarts. Thirty-four software installations. Seven people had attempted to "optimize" network settings. Two had found the backup deletion tools.

I executed the remediation script. Group memberships rolled back. Permissions reverted. The cursors remained—some battles aren't worth fighting.

Then came the educational moment. I showed the TTY the security model. Least privilege. Role-based access. The concept that users should have exactly enough permission to do their job and not a single bit more.

OPERATOR: "Patricia needed read access to a folder. Not the ability to delete the domain."

Resolution & The Lesson

By 14:30, the environment was stable. The administrative groups were back to their original three members. The intern's email rule had been removed, though several people admitted they'd miss the excitement.

Patricia got her folder access. Properly scoped. Documented. Audited.

The TTY learned about Active Directory security groups, the principle of least privilege, and why "just to be safe" is never a valid justification for granting excessive permissions.

I documented the incident with the thoroughness it deserved. Not as punishment—as education. The TTY would remember the day he made everyone root. He'd remember the chaos that followed. And most importantly, he'd remember that security boundaries exist for a reason.

The moral of the story? Access control isn't about trust. It's about limiting the blast radius when trust meets the "Apply to All" button.

The TTY is learning.

The Operator's Notes

Three days later, Patricia submitted another ticket. This time she needed access to a different folder. The TTY's response was textbook perfect: specific NTFS permissions, documented in the ticket, validated before implementation.

I almost felt proud. Then I checked the logs and found he'd spent twenty minutes researching whether he could automate permission removal "just in case." The paranoia is setting in nicely.

Server Rack #7 remains suspiciously quiet. I don't trust it. Documented for posterity. Such is infrastructure.