The account lifecycle: Creation, disabling, lockout, deletion, and orphaned accounts

1. Core mechanism

An account's lifecycle state is not stored in one place. Read ACCOUNTDISABLE (0x0002) in userAccountControl for enabled/disabled state. Assess lockout from lockoutTime and the policy/time-derived msDS-User-Account-Control-Computed view; do not read LOCKOUT (0x0010) as a persistent userAccountControl value. A deleted object enters Deleted Objects with isDeleted=TRUE; Recycle Bin configuration changes attribute preservation and the restore window. Stale is not a bit; it is an inference from an approximate timestamp such as lastLogonTimestamp. An audit event records a transition, a directory read from one DC shows that DC's view of current state, and replication convergence is a separate layer. Group membership remains in 07.x, password policy in 08.02, and ACL ownership in 05.x.

Interfaces and specifications

• userAccountControl: ACCOUNTDISABLE = 0x0002 makes a DC that has received the change reject new online domain authentication for this account; cached desktop logon and established sessions are separate paths. In AD DS, assess effective lockout from lockoutTime and ADS_UF_LOCKOUT (0x0010) in the computed msDS-User-Account-Control-Computed attribute; do not treat this as a persistent userAccountControl value.
• Account Lockout Policy: lockout applies when failed-password attempts reach the configured Account lockout threshold; Account lockout duration and Reset account lockout counter after determine the behavior.
• lastLogonTimestamp: a replicated, approximate indicator of domain logon activity. It updates only when its value is older than the configured msDS-LogonTimeSyncInterval. Common default behavior produces an update threshold of roughly 9–14 days; it is not an exact last-use proof. badPwdCount and lastLogon are non-replicated and maintained per DC.
• Deleted object: a deleted object is marked isDeleted=TRUE and enters Deleted Objects. If AD Recycle Bin was enabled before deletion, preserved attributes can be restored during the deleted-object lifetime; later recycled/tombstone and permanent-cleanup stages depend on tombstoneLifetime and configuration. Do not assume a universal 180-day default.
• Windows Security 4725 (disabled), 4722 (enabled), 4726 (deleted), 4740 (locked out), and 4767 (unlocked) are Audit User Account Management transition records; distinguish domain/DC and local-account event locations.

Five states, five different storage locations

Enabled/disabled state depends on ACCOUNTDISABLE (0x0002) in userAccountControl. Disable does not delete the object. New domain authentication at a DC that has seen the change is rejected; another DC’s older replica view and local cached logon without a DC are separate conditions. A cached desktop does not establish access to network resources requiring domain validation.

Locked is different: when failed-password attempts reach the configured Account lockout threshold, the system updates lockoutTime. In AD DS, assess effective lockout from lockoutTime and msDS-User-Account-Control-Computed; 0x0010 is not a persistent userAccountControl attribute. Lockout can clear when its duration expires; a manual unlock may separately produce event 4767.

Deleted changes the object's lifecycle; it does not mean immediate permanent destruction. If Recycle Bin was enabled before deletion, the deleted object's attributes can be preserved and restored during the deleted-object lifetime. Otherwise, or after that restore window, the object proceeds through different tombstone/recycled stages. These lifetimes vary with forest history and configuration. Stale is not a bit: an account may remain enabled while lastLogonTimestamp has not been refreshed for a long time; this is an inference, not proof of exact last use.

Transition record and current status are not the same thing

A 4725 record says 'op.admin disabled abdulvehhab'. This is a TRANSITION: who, when, what action. But 'Is abdulvehhab currently disabled?' The answer to the question is not in 4725, but in the current userAccountControl value of the object. Someone may have reactivated (4722) the account after 4725.

This distinction translates into a practical diagnostic rule: 'in what state is the object?' question is read from directory (userAccountControl, lockoutTime, isDeleted); 'How did this situation come to be?' question is read from the audit log (4725/4726/4740/4767). Audit log tells the past, quality tells the present.

It's a common mistake to confuse the two: seeing an old 4725 and thinking the account is still disabled, or seeing the current disabled bit and trying to read from the attribute when/by whom it was done. Each question is asked to its own layer.

State and session state are different layers

Disabling an account does not instantly terminate an established session or access token. New domain authentication at a DC that has seen the change is rejected; an existing service ticket, target context and offline cached desktop require separate assessment.

So 'I disabled the account' does not mean 'I cut off access immediately': an existing session or a ticket already accepted by a target may continue according to that target's session and reauthorization behavior. The result of a new ticket request depends on KDC account, policy, and replication checks; do not assume that an existing TGT guarantees continued access. Incident response should also address active sessions on target systems.

The same distinction applies to lockout: lockout rejects new authentication/logon attempts but does not itself terminate an already established session. Directory account state and live session/access state are separate layers.

Deletion, tombstone and 'orphaned' objects

Deletion is not immediate physical destruction. If Recycle Bin was enabled before deletion, the object can be restored with preserved attributes during the deleted-object lifetime; where this feature was not enabled, restoration options and remaining attributes differ. Deleted, recycled/tombstone, and final cleanup lifetimes depend on forest configuration, so do not treat '180 days' as universal.

Orphaned account is a separate concept: the object is not deleted, it is enabled, but there is no real owner behind it (departed employee, removed service). This account's identity is still valid; If the password is known or stored somewhere, it continues to generate access. Ownership is not a bit of a situation, but an inference of organizational fact.

These two concepts are the core of 08.01's Reject layer: the deletion window and the derelict-but-valid account are two typical sources of 'deemed closed but still generating identity' objects.

Access retained in five different places

Consider removing Finance membership. Directory membership, password-derived credentials, the client process token, ticket cache and the file server’s accepted session live in different places. A membership edit does not recreate an existing process token. A password change does not edit the group SIDs in that token. Fresh authentication must be evaluated against the actual DC view and applicable policy.

Read each comparison separately: account disable changes directory state, password change changes the credential epoch, and ticket-cache clearing changes the client cache. Clearing that cache does not automatically recreate an open target connection’s context. A controlled new target context provides a new observation, but another DC or permission path can produce the same outcome. 02.03 explains token creation, 06.02 the ticket path, and 10.07 replica freshness.

State and data flow

1. Start: DC01’s current attribute view is separate from existing token, ticket and target-session records.
2. The selected account change is applied to the fixture. Disable/enable use4725/4722; lockout/unlock use4740/4767 as distinct transitions.
3. Previously established tokens and target sessions are not retroactively rebuilt. Ticket endtime alone is not the session-termination time.
4. Evaluate the new authentication path separately: a current DC, an older replica view and an offline cached desktop are different decisions.
5. If a new target context is required, create and observe it separately. Cache clearing does not establish automatic renewal of the existing target connection.
6. Compare the evidence: which transition does the event history describe, what is the selected DC’s current attribute state, and what is the actual target-session result?

2. Exploitation

Broken trust assumption

The broken assumption is: 'If I disabled an account or it was locked out, access under that identity ends immediately.' Disable/lock can block new attempts but does not automatically revoke an existing session, access token, or ticket already accepted by a service. A deleted object is recoverable only under the relevant Recycle Bin and lifetime conditions; an orphaned account that remains enabled may still be valid if its password is accessible. The risk comes from treating account state and live session/resource access as the same thing.

Technical prerequisites

• Identify which DC receives new online domain authentication and whether it has seen the ACCOUNTDISABLE change. A DC with the current disabled state rejects that path; offline cached desktop and an older replica view are separate conditions.
• A session/access token established before disablement or lockout, or a service ticket already accepted by a target; existing access depends on the target session and ticket lifecycle. Do not infer that a new service-ticket request will succeed merely because a TGT exists.
• For restore risk, AD Recycle Bin must have been enabled before deletion, the deleted-object restore window must remain open, and the restoring principal must have sufficient permission; which attributes and memberships return depends on those feature/lifetime conditions.
• Stale account still carries privileged group membership; An unused but authorized account is a forgotten attack surface (membership is in 07.x).

Exploitation mechanism

The mechanism is the gap between account state and an access context already established on a resource. Disable sets ACCOUNTDISABLE and blocks new logon/authentication attempts; it does not retroactively erase an access token, open session, or a ticket already accepted by a service. Do not assume a TGT always yields a new service ticket: KDC account/policy checks on a new request matter. Lockout also does not automatically terminate an existing session. An orphaned enabled account with usable credentials remains a valid entry point. Restoring a deleted object's attributes and memberships depends on Recycle Bin having been enabled beforehand, the retention window, and restore authorization.

Disabled account, live session

Disabling an account does not immediately end a session that was already opened under that identity. A session, access token, or ticket already accepted by a target may persist according to its lifecycle. A new service-ticket request also depends on KDC and account-policy checks, so the existence of a TGT alone does not guarantee continued access. Incident response should review active sessions on target systems as well as the account state.

Shortening ticket lifetime limits future ticket use; it does not by itself close an already accepted target session. Actual interruption depends on the service’s reauthentication/session behavior and termination of established sessions. A fixed ticket-lifetime interval cannot be assigned between disable and access termination for every service.

Derelict and stale: the quietest surface

The orphaned account does not generate an alarm because technically everything is normal: enabled, password valid, perhaps 'working' regularly. The risk is that there is no human/service owner behind it and no one is monitoring it. If the password is old and never changes, it becomes a long-lived entry point in a leak.

The Stale account is similarly under the radar: lastLogonTimestamp has not been updated for months, but the account has not been deleted or disabled. If this account is stuck in a privileged group, it becomes an unused but authorized target. In both cases the 'weakness' is not a bit, but a managerial blind spot, which is exactly why it is covered by inventory/expiry controls (Blue).

Delete window and wrong restore: restoring privilege

Restoring a deleted identity is not remote exploitation: Recycle Bin must have been enabled before deletion, the deleted-object lifetime must remain open, and the restoring principal must have sufficient authority. If those conditions hold, preserved SID, group memberships, and other attributes may return. Retention values depend on forest configuration; do not assume 180 days everywhere.

The possible effect is that the restored identity returns with its old privileges: if the deleted account was in an administrator group, a naive restore will also restore that membership, and an undetected privileged account will produce re-access. The control that prevents this is to make deletion/restore a controlled process: consciously manage the Recycle Bin, tie restores to approval, and verify the membership of restored privileged accounts after restoration. This makes the deletion window a controlled lifecycle step, not an attack surface.

The risk boundary of this example

“We disabled the account” does not establish that access ended at every target. Identify where and when the context was created; an old TGT also does not guarantee acceptance of new requests.

3. Defense & Detection

Telemetry scope

• Use ACCOUNTDISABLE in userAccountControl for enabled/disabled state. For lockout, also inspect lockoutTime and the policy/time-derived msDS-User-Account-Control-Computed attribute; isDeleted and lastLogonTimestamp answer different lifecycle questions. A directory read shows the DC you queried; assess replication convergence separately. Audit events record transitions.
• Account management events such as 4725/4726/4740/4767 are linked to the Audit User Account Management subcategory and are generated on the computer where the accounting operation occurs: on the relevant DC for domain accounts, on the relevant member server/client for local (SAM) accounts. These do not require SACL, User Account Management control must be turned on.
• The 4740 (lockout) record is generated on the computer where the lockout of the account is recorded (the relevant DC in the domain account in this scenario). The failed attempt counter badPwdCount is not replicated and is kept separate on each DC (AD replication model); so the image of a single DC does not give the total of failed attempts of the entire forest.
• Review lastLogonTimestamp in bulk as an approximate stale-account signal rather than searching for one event. It updates only when older than msDS-LogonTimeSyncInterval; default behavior can yield a roughly 9–14 day update threshold, and the interval is configurable. Do not treat it as an exact last-use time.
• Event 4726 records an account-deletion transition; retention, restore, and final cleanup depend on whether AD Recycle Bin was enabled before deletion and on the deleted-object/tombstone lifetime configuration. Event 4726 does not prove physical destruction.

Events and relevant fields

• 4725 / SubjectUserName + TargetUserName: separates the actioner (Subject) and the affected account (Target) in the deactivation pass; TargetSid is the persistent ID, it is fixed even if the name changes.
• 4740 / TargetDomainName and Caller Computer Name are separate fields: for a domain account, TargetDomainName identifies the account domain; the source of the lockout-triggering attempt appears under Microsoft's Additional Information / Caller Computer Name. Do not map these fields to one SIEM column.
• 4740 / SubjectUserSid: usually S-1-5-18 (Local System) and DC account since the lockout is automatic; It is wrong to say a user 'locked out', the action is systemic.
• 4767 / TargetUserName: registers manual unlocking of an account; A repeated crash + rapid unlock pattern can be a sign of both misconfiguration and a possible brute-force.
• 4722 / TargetUserName: registers the reactivation of an account; When reading the disable history, it is necessary to evaluate 4725 together with the next 4722, not alone, otherwise the current status will be incorrect.

Which question is asked to which layer?

The first rule is to ask the right layer. Read ACCOUNTDISABLE in userAccountControl for current enabled/disabled state; lockoutTime and computed msDS-User-Account-Control-Computed for lockout; isDeleted for deletion; and lastLogonTimestamp for approximate activity. Ask the audit log who changed a state and when.

This distinction prevents a common misconception: seeing an old 4725 and thinking the account is still disabled. Correct reading means evaluating transition events in time order and always confirming the current situation qualitatively. The event tells the past; quality tells the present.

State       Current source                                  Transition event
----------  ----------------------------------------------  ---------------------
disabled    userAccountControl / ACCOUNTDISABLE              4725 / 4722
locked      lockoutTime + computed UAC view                   4740 / 4767
deleted     isDeleted + Deleted Objects lifecycle             4726
stale       lastLogonTimestamp (approximate inference)        -- no single event
orphaned    -- organizational ownership state                -- inventory/ownership

Separate replication state from control inference

If you query the status of an account across multiple DCs, you may see different responses due to replication latency: one DC account may still show enabled while another may show disabled. This is not a contradiction, but the fact that replication has not yet converged. Replicated attributes such as userAccountControl will eventually be the same on all DCs; Non-replicated attributes such as badPwdCount and lastLogon are separate in each DC and never converge to a single 'correct' value.

This requires careful inference of control. What the Directory replication protocol carries is object state (attribute values, version and originating information); The audit log is a separate channel and is kept on the DC that produces the events. If two account changes are made almost simultaneously in different DCs, which one 'wins' is determined by a conflict-resolution rule — but this rule is not the same as your 'who did it first' inference from the audit log. In this lesson, the internal metadata of the replication (version counters, originating DC) is not fabricated; Only this principle holds: the situation you see is the current state of a DC, not the absolute sequence of events.

Practical takeaway: base your 'who/when' inference on a single DC's audit log, but when answering the 'what state is the object now' question, take into account which DC you are asking and whether replication has converged. Reading a non-replicated attribute (badPwdCount) from a single DC and mistaking it for the truth of the entire forest is the most common inference error.

Validation after the change

Record current state at the changed DC, client cache and target session with separate times. Verify the same resource and requested right in a new context, while confirming that authorized users can still work.

Detection logic · Sigma

title: Account disable and automatic lockout transitions (account lifecycle)
id: 0801-account-lifecycle-transitions
status: experimental
description: >
  Selects User Account Management transitions (disable/lockout/unlock) as an
  observation point; it does not provide the current directory account state.
logsource:
  product: windows
  service: security
detection:
  transitions:
    EventID:
      - 4725   # disabled
      - 4740   # locked out
      - 4767   # unlocked
  condition: transitions
fields:
  - EventID
  - TargetUserName
  - TargetSid
  - TargetDomainName     # target account domain/computer context
  - CallerComputerName   # source computer for 4740; a separate field
  - SubjectUserName
falsepositives:
  - Routine account administration: planned disablement or legitimate unlock
  - A legitimate lockout caused by a stale saved password
level: low

Query assumptions

• Sigma logsource assumes windows/security channel; This rule is not a correlation, but a selection of observation points, and does not give the 'current situation', but only collects transition records.
• TargetDomainName is the target account's domain/computer context. Caller Computer Name in 4740 is separate additional information; a backend that collapses both fields loses the source distinction.
• Event 4740 is generated where the lockout is recorded; collect DC Security logs for domain-account coverage. badPwdCount is non-replicated and maintained per DC, so one DC's value is not the domain-wide total. Caller Computer Name can identify a source but does not guarantee an IP address.
• This selection was not run on a live system; The selectability of the fields was confirmed only on synthetic 4725/4740 samples of this course.

False positives

• Scheduled account deactivation (departed worker process) produces legitimate 4725; It is not an attack alone.
• A stale saved password can cause repeated failures and a legitimate lockout/4740; use the event's Caller Computer Name for the source, not TargetDomainName.
• Negative example: an orphaned but enabled and regularly used account produces no migration events; this filter can't see it. Stale/orphaned detection requires an attribute query, not an event.

Hardening

• Verify account disable with current DC read-back and inspection of active target sessions. A shorter ticket lifetime may limit future use; observe existing-session termination separately. Review service reauthentication behavior and session-termination policy together (06.07).
• perform regular stale-account inventory based on lastLogonTimestamp; Choose the threshold (e.g. 90 days) accordingly to account for the ~14 day update delay, avoid giving the wrong 'active' label with narrow windows.
• Clear stale and orphaned accounts in privileged groups first; An unused authorized account is the quietest attack surface. Verify dependencies (service, scheduled task) before uninstalling.
• Enable AD Recycle Bin and manage tombstone lifetime by policy; Make restoration after deletion a controlled process, and prevent a privileged identity from being revived through incorrect restoration.
• Adjust account lockout threshold/duration/observation window values ​​for balance; Too low a threshold locks out the legitimate user and causes DoS, too high a threshold opens up room for brute-force. Verify after change with a known workflow: legitimate input should not be locked, 4740 should be generated on threshold exceeding.
• Verify audit scope: Audit User Account Management should be open and Security logs of the computers where account transactions are generated (DCs for domain accounts) should be centralized; Otherwise, lockout and disabled transitions will be collected incompletely.

Read the examples

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-a5ba-3e3b0328c30d}" />
    <EventID>4725</EventID>
    <Version>0</Version>
    <Level>0</Level>
    <Task>13824</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8020000000000000</Keywords>
    <TimeCreated SystemTime="2026-09-29T08:12:03.7710000Z" />
    <EventRecordID>90114</EventRecordID>
    <Correlation />
    <Execution ProcessID="724" ThreadID="4360" />
    <Channel>Security</Channel>
    <Computer>DC01.outreason.example</Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="TargetUserName">abdulvehhab</Data>
    <Data Name="TargetDomainName">OUTREASON</Data>
    <Data Name="TargetSid">S-1-5-21-3623811015-3361044348-30300820-1188</Data>
    <Data Name="SubjectUserSid">S-1-5-21-3623811015-3361044348-30300820-1105</Data>
    <Data Name="SubjectUserName">op.admin</Data>
    <Data Name="SubjectDomainName">OUTREASON</Data>
    <Data Name="SubjectLogonId">0x3e9f1</Data>
  </EventData>
</Event>

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-a5ba-3e3b0328c30d}" />
    <EventID>4740</EventID>
    <Version>0</Version>
    <Level>0</Level>
    <Task>13824</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8020000000000000</Keywords>
    <TimeCreated SystemTime="2026-09-29T08:41:57.2030000Z" />
    <EventRecordID>90260</EventRecordID>
    <Correlation />
    <Execution ProcessID="724" ThreadID="5012" />
    <Channel>Security</Channel>
    <Computer>DC01.outreason.example</Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="TargetUserName">abdulvehhab</Data>
    <Data Name="TargetDomainName">OUTREASON</Data>
    <Data Name="CallerComputerName">WS-FIN07</Data>
    <Data Name="TargetSid">S-1-5-21-3623811015-3361044348-30300820-1188</Data>
    <Data Name="SubjectUserSid">S-1-5-18</Data>
    <Data Name="SubjectUserName">DC01$</Data>
    <Data Name="SubjectDomainName">OUTREASON</Data>
    <Data Name="SubjectLogonId">0x3e7</Data>
  </EventData>
</Event>

{
  "kind": "teaching-record",
  "synthetic": true,
  "scenario": "E01",
  "directoryView": "membership removed on A/B",
  "TGT": "issued before change",
  "serviceTicket": "issued before change",
  "targetToken": "accepted at 09:10",
  "applicationSession": "same connection at 10:05",
  "comparison": "fresh target context observed without Finance SID, old connection still usable",
  "sessionLifetimeBoundary": "Ticket endtime does not by itself establish target session termination; service reauthentication and session state are separate."
}

Two reality checks

Assumption: When I deactivate an account, all access for that identity immediately ends.

In fact: No. Disable sets ACCOUNTDISABLE (0x0002) in userAccountControl and blocks new logon/authentication attempts; it does not retroactively revoke an existing access token, session, or ticket already accepted by a service. The result of a new service-ticket request cannot be inferred from TGT presence alone; KDC account/policy checks also matter. Immediate cutoff may require addressing active sessions on target systems.

Assumption: TargetDomainName in event 4740 identifies the source computer.

In fact: No. In this domain-account example, TargetDomainName is the target account's domain context. Microsoft's 4740 documentation defines the source computer separately under Additional Information / Caller Computer Name. Do not confuse these fields in Event Viewer or a SIEM; the caller field may be absent/blank and does not guarantee an IP address. Subject commonly being Local System does not change the meaning of Target or Caller fields.

Sources

• Microsoft · How to use the UserAccountControl flags to manipulate user account properties (KB305144)
  Property flags table: ACCOUNTDISABLE = 0x0002; lockout state is read from the computed MS-ADTS attribute mapped separately.
• Microsoft · 4725(S) A user account was disabled
  Event XML (Version 0); Subject (SubjectUserSid/Name/LogonId) and Target (TargetUserName/TargetSid) fields; Audit User Account Management; can be generated on domain controllers, member servers, and clients (on the computer where the relevant account operation occurs).
• Microsoft · 4740(S) A user account was locked out
  Event XML: TargetDomainName is the target account's domain/computer context; Field Descriptions: Caller Computer Name is a separate Additional Information field; Subject and event generation scope.
• Microsoft · 4767(S) A user account was unlocked
  Audit record for the unlock transition; Subject and Target fields; Audit User Account Management subcategory.
• Microsoft · Account lockout threshold (security policy setting)
  badPwdCount threshold; relationship with Account lockout duration and Reset account lockout counter after; 0 = no lockout; DoS/brute-force tradeoff.
• Microsoft · Enable Active Directory Recycle Bin in Windows Server
  Recycle Bin is not enabled by default; when previously enabled, preserved link/non-link attributes and memberships may be restored after deletion; objects deleted before enablement cannot be recovered through this feature.
• Microsoft Open Specifications · msDS-User-Account-Control-Computed
  AD DS computed ADS_UF_LOCKOUT (0x0010) is derived from lockoutTime and effective lockout duration; it is not a stored userAccountControl bit.
• Microsoft · Bad-Pwd-Count attribute
  badPwdCount is non-replicated, maintained separately on each DC, and a value of 0 can mean unknown.
• Microsoft · Last-Logon-Timestamp attribute
  lastLogonTimestamp is an approximate replicated activity field; updates depend on its value being older than msDS-LogonTimeSyncInterval.
• Microsoft Open Specifications · Tombstone Lifetime and Deleted-Object Lifetime
  tombstoneLifetime and msDS-DeletedObjectLifetime values/configuration; defaults depend on forest history and attribute state.
• Access tokens
  Access token contents; primary and impersonation tokens
• RFC 4120 — Kerberos V5
  §3.2.1–3.2.3 AP exchange
• AD DS replication behavior
  Replication behavior overview
• Choose hybrid authentication
  Scope; PHS/PTA/federation; business continuity and account-state timing
• RFC 5280 — CRL profile
  §5.1.2.4–5.1.2.6 thisUpdate/nextUpdate/revokedCertificates
• Microsoft · Cached domain logon information
  Local cache verification versus domain-validated network access.
• Microsoft MS-SMB2 · Per Session
  Session.State/SecurityContext/ExpirationTime and reauthentication; not equal to a universal ticket endtime rule.