I spent three hours last Tuesday staring at a legacy service account that hadn’t been touched since the 2014 migration, and it hit me: most “security audits” are just expensive ways to feel productive. Everyone wants to buy a shiny new IAM suite or follow some bloated enterprise framework, but they completely miss the point of how to review user accounts periodically in a way that actually works. I’ve seen too many admins treat account reviews like a checkbox exercise, letting stale credentials sit in the directory like dormant malware just because they’re too busy to actually dig through the Active Directory logs.
I’m not here to sell you on a subscription service or a theoretical whitepaper. I’ve spent seventeen years managing Windows fleets for a regional council, and I’ve learned that real maintenance is often boring, manual, and slightly tedious. In this post, I’m going to show you the exact, no-nonsense workflow I use to scrub my user lists without wasting my entire weekend. I’ll skip the cargo-cult nonsense you find on forums and give you the practical steps that actually reduce your attack surface without breaking your existing permissions.
Stop the Bloat With Real Privilege Creep Prevention
The biggest headache I see in regional councils isn’t the hardware; it’s the “temporary” permissions that become permanent. Someone needs access to a folder for a single project, you grant it, and then—poof—that permission stays there for five years. This is how you end up with privilege creep prevention becoming a theoretical concept rather than a reality. Most admins think they’re safe because they have a policy on paper, but if you aren’t actively stripping away rights that are no longer needed, you’re just building a massive, invisible attack surface.
You don’t need a complex, expensive suite of tools to start fixing this. You just need to actually follow the security principle of least privilege instead of treating it like a suggestion. I’ve seen people try to automate everything with fancy software, but if your underlying logic is flawed, you’re just automating chaos. Start by looking at your most “senior” users; they usually have more access than they’ve actually used in a decade. It’s not about being a gatekeeper; it’s about keeping the environment clean enough that you actually know what’s happening on your own network.
Applying the Security Principle of Least Privilege Properly
The problem with most implementations of the security principle of least privilege is that they’re treated as a “set and forget” task. People grant a user local admin rights to solve a ticket quickly, and then that permission just lives there forever. In my experience, “least privilege” shouldn’t be a static state; it’s a constant struggle against the natural tendency of permissions to expand. If you aren’t actively stripping back access that is no longer required for a specific job function, you aren’t actually practicing least privilege—you’re just managing a growing list of vulnerabilities.
Instead of relying on gut feeling, you need to integrate this into your standard identity and access management best practices. I don’t care how many fancy tools you’ve bought; if you don’t have a repeatable way to verify that a user actually needs the level of access they currently hold, your security posture is an illusion. It’s about moving away from the “just give them access so they can work” mindset and moving toward a model where access is treated as a temporary loan rather than a permanent right.
Five ways to actually clean up your user list without losing your mind
- Stop looking for “active” users and start looking for “stale” ones. I don’t care if they logged in once three months ago; if they haven’t touched a resource in ninety days, they shouldn’t have an account. Set a filter for last logon timestamp and treat anything older than a quarter as a candidate for deletion.
- Audit your local administrator groups, not just the domain admins. Everyone forgets about the “shadow admins”—those local accounts created by a tech three years ago to fix a printer and then left running with full rights. If it’s in a local admin group and isn’t a service account, it’s a liability.
- Look for the “service account” sprawl. I see it in every council environment I’ve managed: accounts named ‘svc_sql’ or ‘backup_admin’ that have been given interactive login rights. Service accounts should be locked down to specific tasks and absolutely shouldn’t be able to log in via RDP like a human user.
- Check for orphaned accounts in third-party apps. Your Active Directory might be clean, but your legacy HR software or that one random CAD tool probably still has a list of users from 2018. If you aren’t syncing your app permissions with your central directory, your periodic review is a lie.
- Automate the report, don’t manual-check the list. If you’re sitting there scrolling through a CSV of 500 users, you’re going to miss something. Write a PowerShell script that flags accounts with non-expiring passwords or those that haven’t changed their credentials in a year. Let the script do the heavy lifting so you can actually focus on the weird outliers.
The bottom line
Stop treating account audits like a yearly checkbox exercise; if you aren’t scrubbing dormant accounts and checking privilege creep every few months, your security posture is just a suggestion.
Don’t fall for the “just give them local admin” trap to save yourself a support ticket; it’s a lazy habit that creates more work for you when a single compromised account turns into a fleet-wide nightmare.
Use actual data to drive your reviews—check the last logon timestamps and group memberships against current job roles rather than just blindly trusting your existing Active Directory structure.
Cutting Through the Noise
Look, at the end of the day, auditing accounts isn’t about checking a box to satisfy some auditor who hasn’t touched a command line in a decade. It’s about realizing that every stale account and every “temporary” admin right you forgot to revoke is just a ticking time bomb waiting for a script kiddie to find it. You can’t just set it and forget it. If you aren’t actively hunting down privilege creep and scrubbing your user lists, you aren’t actually managing a system; you’re just watching it decay. Stop relying on the cargo cult advice you find on some dusty forum and start looking at your actual directory data.
It’s easy to feel like you’re just spinning your wheels in a sea of endless Microsoft updates and shifting security paradigms, but there is a quiet satisfaction in a clean, lean environment. When you finally get your provisioning and deprovisioning cycles tight, you’ll notice the difference in how much less noise you have to deal with during a crisis. Don’t let the complexity of modern Windows environments intimidate you into laziness. Do the work, test your assumptions, and keep your environment tight and predictable. It’s better to be the admin who actually knows what’s on their network than the one who’s just guessing.
Frequently Asked Questions
How do I actually automate this without buying some overpriced enterprise identity management suite?
You don’t need a six-figure IAM suite to do this. If you’re in an AD environment, just use PowerShell. I’ve got a script that pulls all users with “Domain Admin” or “Local Admin” rights and spits them into a CSV every Monday. If the list grows without a corresponding ticket in your system, you know someone’s been playing fast and loose. It’s not fancy, but it’s better than trusting some expensive vendor’s dashboard.
If I find a service account with local admin rights that's been there for years, do I risk breaking a legacy app by stripping it back?
You absolutely risk it. I’ve seen it happen—you strip a service account of its local admin rights, and suddenly a legacy ERP system from 2008 stops writing to its own log directory. Don’t just pull the plug. Use Process Monitor to see what files or registry keys that account is actually touching. If it’s been sitting there for years, it’s likely a crutch for bad coding. Verify the requirements first, then tighten the screws.
What's the realistic frequency for these reviews—is once a quarter enough, or am I just setting myself up for a massive manual headache?
If you try to do a manual deep-dive every quarter, you’ll burn out by July. Honestly, quarterly is fine for a high-level spot check, but you shouldn’t be manually hunting for every stray permission. That’s a fool’s errand. I aim for monthly automated reports to catch the obvious bloat, then a proper, manual audit once or twice a year. If you aren’t automating the discovery, you aren’t auditing; you’re just playing whack-a-mole.
