Active Directory Cleanup Without Breaking Anything

Every directory that has been running for a decade holds accounts for people who left, computers that were scrapped, and groups that nobody remembers creating. None of it causes an outage, which is exactly why none of it gets cleaned up.

Step 1Finding what is actually stale

Two attributes carry the answer, and they behave differently.

lastLogonTimestamp replicates between domain controllers and is what a cleanup should use. It is deliberately imprecise, updated only when the previous value is more than nine to fourteen days old, so an account that shows thirty days idle might be twenty. That is fine for finding things dormant for a year.

lastLogon is exact and does not replicate, so it is only correct on the domain controller that handled that sign in. Reading it from one controller and concluding an account is dormant is the classic mistake, and it deletes accounts that are in daily use somewhere else.

PriorityStart with the ones that can do damage

A list of four hundred stale accounts is not a work queue, it is a reason to put the job off. Sort it once and the first afternoon is worth more than the rest of the project.

The accounts to take first are stale and privileged: members of Domain Admins, Enterprise Admins, Account Operators and Backup Operators, and anything with delegated rights on an organizational unit.

An unused account with no rights is untidy. An unused account that can reset passwords across the domain is the one an attacker is looking for, and nobody is watching it precisely because nobody uses it.

That filter finds more than the current membership does, and the reason is worth knowing. When an account joins a protected group, the directory stamps adminCount to 1 and replaces the permissions on the object with a copy taken from AdminSDHolder. Removing the account from the group later does not undo either.

So a support account that spent a week in Domain Admins in 2019 still carries the stamp, still has permissions that do not inherit from its organizational unit, and still does not appear in any report based on current group membership.

Those are the accounts to disable first and to look hardest at, because the paperwork says they are ordinary and the directory does not.

MethodThe order that makes it safe

Deleting an object in Active Directory is not reversible in any convenient way, and the objects that look most disposable are often the ones a service depends on. The order below is slow on purpose.

Disable, do not delete. A disabled account that turns out to be needed is a two second fix. A deleted one means a restore, and the group memberships it held are gone even then.

Move disabled objects to a holding organizational unit. One place to look, one place to empty, and a Group Policy scope that applies to nothing.

Wait a full business cycle. Thirty days catches monthly processes. Ninety catches quarterly ones, and quarterly is where the surprises live: the account that only signs in to run the quarter end job.

Then delete, in batches, with an export taken first. A system state backup of a domain controller restores the directory and is the wrong tool for one wrong deletion.

An LDIF export of the holding organizational unit is a file, takes seconds, and holds every attribute of everything about to go. Take it, keep it with the change record, and the one time it is needed nothing else will do.

The trapWhat a computer account is carrying

A computer account looks like the safest thing in the directory to delete. The machine is scrapped, the object is dead weight, and nothing signs in as it. That is true right up until somebody needs the disk.

Several things are stored as part of the computer object rather than alongside it, and they go when it goes.

BitLocker recovery keys. When recovery information is escrowed to the directory it is written as a child object under the computer account. Delete the computer and the recovery key for that machine is gone, along with any chance of reading the drive that is still sitting in a cupboard waiting to be wiped or read one last time.

The local administrator password. Both the original and the current LAPS store the managed password as an attribute on the computer object. A machine that is genuinely gone does not care, and a machine that turns out to be in a drawer somewhere now has a local password nobody holds.

Certificates and the trust itself. Deleting an account and rejoining the same machine later gives it a new security identifier, so anything granted to the old one has to be granted again.

The rule that follows is short. Before deleting a computer account, export its BitLocker recovery information and its LAPS password to wherever those are kept for retired hardware, and only then delete the object. The disable and wait step exists for exactly this: a computer account disabled for a quarter costs nothing and keeps both.

GroupsWhy an empty one can still grant access

Groups are the objects most likely to look disposable and most likely to be load bearing, and there are three separate reasons a group that appears empty is not.

The primary group case catches people the most often. The member attribute does not list an account whose primaryGroupID points at that group, so a group can be someone's primary group and read as empty in every tool that lists members.

The search that matters is on the security identifier rather than the name. When a group is deleted, the entries it left behind on file servers and applications do not disappear, they turn into an unresolved identifier that most permission dialogs display as a raw string and most people ignore.

That is the trace to look for before deleting, and the mess to inherit after.

The hard partService accounts

These are where a cleanup goes wrong, because a service account signs in rarely, holds more privilege than it needs, and has a password set in 2014 that never expires. Every attribute that makes it look stale is also what makes it dangerous to disable.

Before touching one, find out what runs as it. Scheduled tasks, Windows services, application pools, and database connection strings are the usual four, and only the first two are easy to search. The account name in a sign in log, with the source address, tells you which machine to look at.

The right end state for the ones that survive is a managed service account, where the password rotates automatically and nobody knows it. That is a project rather than a cleanup task, but the cleanup is when you find out how many you need.

AfterwardsKeeping it clean

A cleanup that is not automated happens once. Three things keep the number near zero without anybody remembering to look.

A joiners and leavers process that actually disables accounts on the last day rather than eventually. This is the whole problem at the source, and everything else is compensation for not having it.

A scheduled report of accounts inactive for ninety days, sent to a person rather than a mailbox nobody opens. A short list monthly is read. A long list quarterly is not.

A policy that new service accounts are managed service accounts. It does not fix the existing ones, and it stops the pile growing while you work through them.

1. Query on lastLogonTimestamp, never lastLogon

   The exact attribute does not replicate, so reading it from one domain controller marks accounts as dormant that are in daily use against another.

2. Disable and move to a holding organizational unit

   One place to look and one place to empty. A disabled account that turns out to be needed is a two second fix, where a deleted one is a restore.

3. Wait a full quarter before deleting anything

   Thirty days catches monthly processes. Ninety catches the account that only signs in to run the quarter end job, which is where the surprises live.

4. Handle service accounts separately, and last

   Everything that makes them look stale is what makes them dangerous. Find what runs as each one before disabling it, then move the survivors to managed service accounts.

FAQQuestions from the comments