AD Disabled Computer WhenChanged Review: Establish Disable Provenance

What Is an AD Disabled Computer WhenChanged Review?

An AD disabled computer whenChanged review starts with a computer account that is currently disabled and an old directory modification timestamp. It asks whether the account should remain in Active Directory, who owns that decision, and what evidence supports its retirement. The timestamp helps prioritize investigation; it does not establish when the account was disabled.

This distinction matters when a cleanup list becomes a deletion queue. A disabled account may belong to a retired workstation, a temporarily isolated machine, a service identity or infrastructure awaiting a separate decommissioning procedure. An audit finding supplies none of those business decisions. Keep current account state, disable provenance and retirement approval as separate evidence.

The review described here follows the COMPUTER_DISABLED_NOT_DELETED finding in etc-collector. It does not introduce a universal deletion schedule or establish an attack from an old timestamp. The result is a documented decision for an identified object: retain it with an accountable reason, investigate missing evidence, or retire it through an approved procedure after its dependencies are resolved.

How It Works: Last Modification Is Not Disable Provenance

Microsoft's whenChanged attribute reference defines the value as the object's last change date. The system updates it whenever the object changes. The value is not replicated, so record which domain controller supplied the observation and when you read it.

Setting the disabled state changes the object, but the current whenChanged value does not identify that operation. A subsequent modification can replace the earlier timestamp even while the account remains disabled. Reading a recent value therefore does not establish a recent disable action; reading an old value does not supply its actor, reason or approval. Treat the attribute as a modification observation from the chosen DC, rather than a dedicated disable-date field.

Keep these distinctions in the review record:

Our Active Directory computer-object hygiene guide provides the broader lifecycle context, including domain controllers, LAPS and stale computer objects. Its illustrative cleanup cadences do not prove a disabled date and are not adopted as thresholds for this review. A last-logon or machine-password observation would answer another question; neither is substituted for evidence of disabling the account here.

Detection: Establish Current State and Investigate the Transition

Step 1: Read the Exact Object From a Named DC

Use the ActiveDirectory module on an authorized administration workstation. Microsoft's Get-ADComputer reference documents -Identity, -Properties and -Server. Request the LDAP attributes explicitly and name a directory server rather than relying on an implicit selection:

$computer = Get-ADComputer -Identity 'PC01' -Server 'dc01.contoso.com' -Properties whenChanged,userAccountControl,objectClass -ErrorAction Stop
$computer | Select-Object DistinguishedName,ObjectGUID,SID,Enabled,whenChanged,userAccountControl,objectClass

The projection uses Microsoft's documented Select-Object syntax. Preserve the computer identity, chosen DC, read time and collection outcome alongside the displayed fields. A failed query is incomplete evidence. An unavailable attribute is not a reliable negative result merely because the collection process returned an object.

The reviewed LDAP parser derives Disabled from the ACCOUNTDISABLE bit, 0x0002, in directory userAccountControl. The displayed Enabled property and the raw attribute provide current-state observations to reconcile. They do not record how long the account has been disabled. If the current read conflicts with the audit, investigate collection time, target identity and DC observations before acting on the older finding.

Step 2: Use Event 4742 Only Where Its Evidence Applies

Microsoft documents event 4742, a computer account was changed, in the Audit Computer Account Management subcategory. It is generated on domain controllers. Review the relevant DC Security logs or their collected copies, with audit configuration and retention sufficient to cover the suspected transition.

In a SIEM, scope the investigation to event 4742 and the changed account's TargetSid. Inspect the raw event, not only a normalized summary. Preserve the event time, emitting DC, record identifier, target identity, subject identity, OldUacValue, NewUacValue and changed account-control information. Compare any claimed disable transition with the approved change or incident record and the current directory read. A matching account name alone is weaker context than the verified target SID.

The event documentation explicitly says that some changes do not generate 4742. Other events can contain dashes for all displayed changed attributes, leaving the changed attribute unidentified. A 4742 entry for the object is therefore not automatically proof of disabling it. It might document a different account change, and a log search might not cover the DC or period that matters.

The old and new UAC fields in 4742 use the SAM implementation of account flags, whose definitions differ from LDAP userAccountControl. Do not apply the LDAP 0x0002 mask to those event fields to claim a disable transition. Interpret the recorded transition using the event's documented account-flag definitions and retain the raw values for review.

Step 3: Correlate the Evidence With Ownership

Ask the accountable owner whether the machine is still required, temporarily isolated, replaced or formally decommissioned. Link the response to the exact directory identity. Preserve the reason for disabling, the available transition evidence and the retirement decision separately. When historical evidence is missing, describe that gap directly rather than constructing a date from the latest object modification.

An unexplained change affecting a critical identity needs investigation before lifecycle cleanup. Conversely, an approved retention decision may be legitimate even when the detector continues to flag the object. Record who will revisit that decision and what condition would justify retirement. Clearing the finding is not itself a business requirement to delete the account.

Remediation: Validate Dependencies Before Approved Removal

Step 1: Classify the Object and Resolve Unknowns

Confirm the object class and operational role before choosing a retirement procedure. The detector does not explicitly exclude domain controllers or group managed service accounts. A domain controller needs its appropriate decommissioning process; a service identity needs its service dependencies checked. A generic workstation removal example is not authorization to apply the same action to every object returned by the collector.

Reconcile current account state, owner response and decommissioning records. Keep unresolved cases on hold with an accountable next action. This process does not assign a new generic aging period: elapsed time cannot establish that services, records or recovery needs have ended.

Step 2: Inventory Children and Recovery Dependencies

Read the immediate children of the verified computer object using Microsoft's documented Get-ADObject search parameters. This example uses the $computer returned above and requests identifiers and object classes, rather than recovery secrets:

Get-ADObject -LDAPFilter '(objectClass=*)' -SearchBase $computer.DistinguishedName -SearchScope OneLevel -Server 'dc01.contoso.com' -ErrorAction Stop |
    Select-Object DistinguishedName,ObjectGUID,ObjectClass

OneLevel searches immediate children only. If a child has its own descendants or the inventory is incomplete, investigate that structure and its purpose before proceeding. An empty result with unverified visibility does not prove that no dependent objects exist. Record access failures and uncertain scope as unresolved inventory items.

Include BitLocker recovery information in the dependency review. Our BitLocker AD recovery verification guide: match the directory record to the current volume protector explains why a recovery object must correspond to the recovery protector actually present on the volume. Its presence alone does not establish usable recovery, and its date does not establish when the computer account was disabled.

Agree how required recovery information and other child data will remain available under the organization's approved recovery and retention process before computer removal. Keep secrets out of cleanup tickets and SIEM records. Record the dependency decision and the responsible owner, rather than copying recovery passwords into the evidence. This is a retirement dependency check; the linked guide supplies the separate volume and protector verification procedure.

Step 3: Preview and Perform Only the Approved Single-Object Removal

After ownership, decommissioning, dependency and recovery checks are complete, use Microsoft's Remove-ADComputer syntax for the verified object. The documentation supports GUID identity, an explicit server and -WhatIf. The following preview does not execute removal:

Remove-ADComputer -Identity $computer.ObjectGUID -Server 'dc01.contoso.com' -WhatIf

Review the target and preview against the approved retirement record. A preview does not verify that the machine is unused, that recovery data is preserved or that the action has been approved. Re-read the current object before the authorized operation if the evidence may have changed.

Only after that validation, the single-object command retains an explicit confirmation prompt:

Remove-ADComputer -Identity $computer.ObjectGUID -Server 'dc01.contoso.com' -Confirm

If children, protection or another error prevents removal, stop and resolve the specific cause through the approved procedure. Do not turn a failure into a recursive deletion of the computer and its descendants. Preserve the actual command outcome; an attempted operation is not proof that the account was removed.

Step 4: Close the Review With Evidence

Record the final disposition, approver, dependency decisions and operation outcome. Verify the directory result through an authorized read of the exact identity on the recorded DC, preserving any error and its meaning. Confirm that required recovery information remains available through the agreed process. For a retained object, document the retention reason and remaining investigation instead of reporting remediation as completed.

How EtcSec Detects This

At reviewed collector commit 20268a321609c193b79c5da6764f3f56950449cb, COMPUTER_DISABLED_NOT_DELETED is a Low finding. Its Detect() examines collected computers and includes an object only when Disabled is true, WhenChanged is nonzero, and WhenChanged.Before(Now.AddDate(0, 0, -30)) is true. The comparison is strict: a timestamp equal to the cutoff is excluded.

The cutoff subtracts 30 calendar days from the audit's Now. It is an etc-collector operational hygiene benchmark, not a deletion deadline required by Microsoft or another named standard. A subsequent object modification moves whenChanged forward and can postpone this signal while the account remains disabled.

In the reviewed LDAP provider, missing or invalid whenChanged becomes a zero time, which this detector skips. Missing or syntactically invalid userAccountControl becomes zero, so the parser does not mark that object disabled. The default computer filter is (objectClass=computer). Although the parser can identify a gMSA class, this Detect() has no explicit domain-controller or gMSA exclusion.

The detector does not establish the disable date, owner, decommissioning approval, child objects, recovery dependencies or a supporting event history. A positive finding opens the evidence review described above. A zero count cannot close those independent questions, especially where collection or attribute availability is uncertain.