A disabled Active Directory account may retain some access through previously issued tickets or an existing session. Disabling the account remains an essential control, but it should not be mistaken for an instruction that instantly terminates every connection, application session or offline sign-in. The result depends on the access path and the controls involved.
The earlier version of this article used the label “Zombie Users” and described a universal ten-hour window. That was too broad. This revised explanation distinguishes account status, Kerberos tickets, application sessions and cached sign-in, without claiming that Impulsec discovered a new Windows vulnerability.
How Kerberos tickets relate to account access
In a Windows domain, the Key Distribution Center, or KDC, runs on a domain controller. A client obtains a ticket-granting ticket, usually shortened to TGT, and uses it to request tickets for particular services. The client presents a service ticket to the target service. Microsoft explains this sequence in its Kerberos authentication overview.
These are different stages. A check made when issuing a new ticket is not necessarily repeated for every operation in an already established connection. To understand continued access, identify which stage is occurring rather than describing every action as a new login.
Does disabling an account immediately revoke every ticket?
No. Microsoft’s account-revocation specification explains that Windows Kerberos extensions add account checks to reduce exposure. It states that KDCs in the account domain must check accounts when the TGT is more than 20 minutes old.
The important distinction is the age of the TGT, not a universal 20-minute countdown beginning when an administrator disables the user. This ticket-request check is also not a promise that all existing service sessions end at that point.
Account status, ticket validity and session termination should therefore be investigated separately. Deleting an account should not be treated as a substitute for a complete access-removal procedure either.
Why “ten hours of access” is not a universal rule
Microsoft’s user-ticket lifetime documentation describes ten hours as a default domain-policy value. That explains the number often quoted in older discussions, but it does not establish a guaranteed period of continued access after disablement.
Effective ticket settings, the ticket’s existing age, account checks and the behaviour of the service all matter. An application session may have its own lifetime. Administrators should examine the actual configuration and access path instead of assuming that waiting ten hours is either necessary or sufficient.
Separate these four situations
| Situation | What it means | What to investigate |
|---|---|---|
| A new authentication attempt | The user is attempting to establish fresh authenticated access. | Account status, the identity system contacted and authentication results. |
| An existing Kerberos ticket | The client already holds credential material issued earlier. | Ticket type, lifetime and applicable account checks. |
| An existing application or remote session | Access was established before the account changed. | The service’s session-termination and revalidation behaviour. |
| Cached offline Windows sign-in | The device is validating previously cached information locally. | Device connectivity, cached-logon policy and access to local data. |
Is cached offline sign-in the same problem?
No. Microsoft documents that Windows can use cached domain logon information when a domain controller is unavailable. This can allow access to a local desktop without a fresh domain validation. It does not automatically provide access to network resources that require domain validation.
For that reason, a former employee reaching the desktop of an offline laptop and a disabled identity obtaining new server access are different observations. Record exactly what remained accessible. Offboarding also needs to account for device custody and information already stored locally.
A practical access-removal checklist
My recommendation is to define offboarding by the access that has actually ended, not simply by completion of the “disable account” action. The same principle applies during an incident, although containment may require a faster and broader response.
- Identify the scope. List the user’s directory identities, remote access, business applications, active devices and separate local accounts.
- Apply identity controls. Disable the relevant accounts and follow the organisation’s credential-reset procedure where compromise is suspected.
- Address existing sessions. Ask application and infrastructure owners to terminate applicable sessions through supported controls.
- Check devices and data. Establish whether the user still possesses an offline device or local copies of sensitive information.
- Verify access removal. Use authorised test accounts and service records to check representative access paths, including sessions established before disablement.
- Document completion. Record what was changed, by whom, when it took effect and which exceptions remain.
For hybrid organisations, Microsoft’s emergency access-revocation guidance addresses both on-premises Active Directory and Microsoft Entra ID. Cloud sign-in blocking, refresh-token revocation and application deprovisioning are separate parts of that process. Application-managed sessions may need additional action.
For supported cloud applications, Continuous Access Evaluation can react to events such as account disablement before normal token expiry. Its effectiveness depends on supported clients and resources; it is not a universal switch for ending every on-premises Kerberos session.
What can event logs tell you?
Logs are useful evidence. Windows Event 4725 records account disablement when the relevant auditing is configured. It establishes the account-change event, not proof that every service has ended the user’s access.
Correlate that time with Kerberos service-ticket events and the logs of the application involved. Preserve the account identifier, affected service and source device. A ticket request is not the same as successful access to business data, so check the service-side evidence too.
A SIEM can help join those records. Its usefulness depends on which events are collected, their quality and the investigation rules. The absence of an alert does not prove access ended, but it is equally wrong to say that logs cannot help investigate this behaviour.
How this differs from the RC4-HMAC issue
Access revocation concerns what happens to credentials and sessions after an identity’s status changes. The historical Active Directory RC4-HMAC issue concerns the use of stolen password-derived keys. Resolving one does not automatically resolve the other.
Both sit within identity and privacy protection, but the right response begins with a precise account of what happened. Specify the identity, resource and access mechanism before choosing a remediation.
Frequently asked questions
Can a disabled Active Directory user still access resources?
Some previously authorised access may continue through existing tickets or sessions. The result depends on the service, authentication flow and relevant controls; it is not guaranteed for every disabled account.
Does disabling an account log the user out everywhere?
No. Account disablement is not a universal session-termination command. Review the connected applications, remote sessions, cloud identities and devices separately.
Do Kerberos tickets always last ten hours after disablement?
No. Ten hours is a documented default user-ticket lifetime, not a countdown that starts when an account is disabled. Effective policy, ticket age and service behaviour matter.
What does the Kerberos 20-minute check mean?
Microsoft describes an account check by KDCs in the account domain when the TGT is more than 20 minutes old. It does not mean every session is terminated 20 minutes after disablement.
Does cached offline sign-in prove the domain account is active?
No. Windows may validate cached information locally when a domain controller cannot be reached. That differs from fresh domain authentication and access to resources requiring domain validation.
Can event logs help investigate access after disablement?
Yes. Correlate account-disablement events with authentication and application records. A single event does not establish the status of every session.
Share this article
Stuart Kerr Spindlow is Impulsec’s Publisher, Chief Editor and Lead Reviewer. He writes and maintains coverage of consumer cybersecurity and digital-safety software, with a focus on practical suitability, limitations and the evidence behind product claims. Read Stuart’s full profile.