Finding and Disabling Stale Computer Accounts in Active Directory

What This Script Is For

Machines leave an environment constantly: a laptop gets re-imaged with a new name, a server is decommissioned, a VM template is spun up once for testing and never touched again. The computer account each of those machines created in Active Directory does not leave with them. It sits in its OU, still enabled, still a valid Kerberos principal, until someone notices or an audit flags it.

Think of a stale computer account as an unlocked door to an office that closed months ago — nobody is using it, but it still answers a knock. Finding those accounts is a straightforward filter on inactivity. Deciding what to do with them safely is where most home-grown scripts go wrong, usually by deleting on the first pass and finding out later that one of them was a cluster name object.

Why Disable, Not Delete

Remove-ADComputer is one cmdlet away and looks tempting once you have a clean list of candidates. The problem is that deletion is not reversible in any practical sense — a deleted computer object goes to the AD Recycle Bin if it is enabled, but restoring it correctly means also rebuilding SID history, group memberships, and any Group Policy or delegation that referenced it, none of which the Recycle Bin restores automatically. Disabling costs nothing to undo: Enable-ADAccount flips the same flag back.

This script only disables. Treat deletion as a separate, later exercise against the accounts that stayed disabled through at least one full review cycle — that is a process decision for your environment, not something a script should decide unattended.

Why Active Directory Cares About Stale Computer Accounts

A computer account is a full security principal with its own password, its own Kerberos service tickets, and — if nobody has cleaned it up — a machine account password that AD still considers valid until it stops rotating on its own. An account nobody is monitoring is exactly the kind of object that turns up in an attack path: it can be a target for resource-based constrained delegation abuse, it can be re-used if an attacker manages to rejoin a device under the same name, and every stale object left in place is one more thing dragging out a domain migration or a permissions audit.

There is a cost even without an attacker involved. Stale objects inflate the domain’s object count, confuse anyone reading Get-ADComputer -Filter * output for capacity or licensing purposes, and leave dangling references in Group Policy security filtering long after the machine they applied to is gone.

The Detection Signals: LastLogon vs LastLogonTimestamp vs PasswordLastSet

Three attributes look interchangeable and are not. LastLogon is accurate to the second but only updated on the one domain controller that handled the logon — it is never replicated, so checking it on a single DC can make an active machine look stale simply because it authenticated against a different DC. LastLogonTimestamp (exposed by the AD module as the friendlier LastLogonDate) is replicated to every DC, but Active Directory only updates it when the existing value is older than the current time minus msDS-LogonTimeSyncInterval, which defaults to 14 days minus a random 0–5 day jitter — so in practice it lags real activity by roughly 9 to 14 days. PasswordLastSet tracks the computer account’s own password rotation, which happens automatically roughly every 30 days while the machine is joined, powered on, and reachable.

The Script

The script runs in three logical passes over the same candidate list: find, review, and — only when explicitly asked — disable. Search-ADAccount -AccountInactive -ComputersOnly does the initial filtering using the replicated lastLogonTimestamp attribute described above. Every candidate is then re-queried with Get-ADComputer for the extra properties needed to decide whether it is genuinely safe to touch: domain controllers (PrimaryGroupID 516 or 521) and anything carrying a cluster-related ServicePrincipalName are skipped outright, and any account whose password changed more recently than the inactivity threshold is flagged for manual review instead of being treated as a clean candidate. Nothing gets disabled unless -Disable is passed, and even then Disable-ADAccount runs behind $PSCmdlet.ShouldProcess, so -WhatIf previews the exact set of accounts before any of them are touched.

[CmdletBinding(SupportsShouldProcess = $true, ConfirmImpact = 'High')]
param(
    [Parameter(Mandatory = $false)]
    [ValidateRange(1, 3650)]
    [int]$InactiveDays = 90,

    [Parameter(Mandatory = $false)]
    [string]$SearchBase,

    [Parameter(Mandatory = $false)]
    [ValidateNotNullOrEmpty()]
    [string]$ReportPath = "C:\Temp\Reports\StaleComputerAccounts",

    [Parameter(Mandatory = $false)]
    [switch]$Disable
)

Set-StrictMode -Version Latest
Import-Module ActiveDirectory -ErrorAction Stop

if (-not (Test-Path -LiteralPath $ReportPath)) {
    New-Item -ItemType Directory -Path $ReportPath -Force | Out-Null
}

$cutoffDate = (Get-Date).AddDays(-$InactiveDays)

# Step 1: find candidates using the replicated lastLogonTimestamp attribute
$searchParams = @{
    AccountInactive = $true
    TimeSpan        = (New-TimeSpan -Days $InactiveDays)
    ComputersOnly   = $true
}
if ($SearchBase) { $searchParams['SearchBase'] = $SearchBase }

$candidates = Search-ADAccount @searchParams
$results = [System.Collections.Generic.List[pscustomobject]]::new()

foreach ($candidate in $candidates) {

    # Step 2: pull the extra properties Search-ADAccount does not return,
    # so every row can be reviewed before anything is disabled
    $computer = Get-ADComputer -Identity $candidate.DistinguishedName `
        -Properties LastLogonDate, PasswordLastSet, OperatingSystem, Enabled, PrimaryGroupID, ServicePrincipalName

    $isDomainController = $computer.PrimaryGroupID -in 516, 521

    $isClusterObject = $false
    foreach ($spn in $computer.ServicePrincipalName) {
        if ($spn -match 'MSClusterVirtualServer|MSServerClusterMgmtAPI') {
            $isClusterObject = $true
            break
        }
    }

    $result = [pscustomobject]@{
        Name              = $computer.Name
        DistinguishedName = $computer.DistinguishedName
        LastLogonDate     = $computer.LastLogonDate
        PasswordLastSet   = $computer.PasswordLastSet
        OperatingSystem   = $computer.OperatingSystem
        Status            = 'Unknown'
        Detail            = ''
    }

    if (-not $computer.Enabled) {
        $result.Status = 'Skipped'
        $result.Detail = 'Account is already disabled'
    }
    elseif ($isDomainController) {
        $result.Status = 'Skipped'
        $result.Detail = 'PrimaryGroupID indicates a domain controller (516/521) - never touched automatically'
    }
    elseif ($isClusterObject) {
        $result.Status = 'Skipped'
        $result.Detail = 'ServicePrincipalName suggests a cluster name object - verify manually before touching'
    }
    elseif ($computer.PasswordLastSet -and $computer.PasswordLastSet -gt $cutoffDate) {
        $result.Status = 'Review'
        $result.Detail = 'PasswordLastSet is more recent than the inactivity threshold - confirm before disabling'
    }
    else {
        # Step 3: disable only when explicitly requested; ShouldProcess honours -WhatIf and -Confirm
        if ($Disable) {
            if ($PSCmdlet.ShouldProcess($computer.DistinguishedName, 'Disable stale AD computer account')) {
                try {
                    Disable-ADAccount -Identity $computer.DistinguishedName -ErrorAction Stop
                    $result.Status = 'Disabled'
                    $result.Detail = "Disabled after $InactiveDays+ days of inactivity"
                }
                catch {
                    $result.Status = 'Failed'
                    $result.Detail = $_.Exception.Message
                }
            }
            else {
                $result.Status = 'Skipped'
                $result.Detail = 'WhatIf - no account disabled'
            }
        }
        else {
            $result.Status = 'Candidate'
            $result.Detail = 'Re-run with -Disable to act on this account'
        }
    }

    $results.Add($result)
}

# Always export a CSV of what was found and what happened to it, before anything else
$timestamp = Get-Date -Format 'yyyyMMdd_HHmmss'
$csvPath = Join-Path -Path $ReportPath -ChildPath "StaleComputerAccounts_$timestamp.csv"
$results | Export-Csv -LiteralPath $csvPath -NoTypeInformation

$results | Format-Table -AutoSize
$summary = $results | Group-Object Status | Select-Object Name, Count
Write-Output "`nSummary:"
$summary | Format-Table -AutoSize
Write-Output "Report written to: $csvPath"

Run it like this:

# Report only - lists candidates and writes the CSV, changes nothing (the default)
.\Disable-StaleADComputer.ps1 -InactiveDays 90

# Preview exactly which accounts would be disabled, without changing anything
.\Disable-StaleADComputer.ps1 -InactiveDays 90 -Disable -WhatIf

# Disable for real once the WhatIf output and CSV both look correct
.\Disable-StaleADComputer.ps1 -InactiveDays 90 -Disable

Reading the Results

Troubleshooting Cheat Sheet

Final Thoughts

The hard part of this script was never finding inactive computer accounts — Search-ADAccount does that in one line. The hard part is making sure the accounts it finds are actually safe to touch, and making the touching itself reversible by default.

Run the report-only mode first, every time, against a directory you have not audited before. Read the CSV. Only add -Disable once the candidate list matches what you expected to see.