Architectural Vulnerabilities in Hybrid Environments

Hybrid environments that combine Entra ID and on-premises AD face a structural authentication mismatch that most deployment guides understate. When Entra ID credentials are rotated — whether through self-service password reset (SSPR), admin-initiated reset, or a privileged identity management (PIM) workflow — the expectation is that all associated authentication tokens and keys are updated across the stack.

They are not.

Kerberos keys cached on client devices may remain valid for the full duration of the Ticket Granting Ticket (TGT) lifetime, which defaults to 10 hours in most Active Directory environments. That window exists regardless of what happened in Entra ID. An attacker with access to a cached TGT before the password change can continue operating within that window without triggering any re-authentication event.

This occurs because Kerberos is a stateful, ticket-based protocol. The Key Distribution Center (KDC) — running on your on-premises domain controller — issues a TGT at login time. That TGT is cryptographically bound to the user's password hash at the moment of issuance. A subsequent password change in Entra ID updates the hash from here, but it does not reach back and revoke the already-issued TGT.

How Kerberos Ticket Issuance Works in a Hybrid Context

In a standard hybrid deployment using Entra Connect Sync (formerly Azure AD Connect), password hash synchronization (PHS) or pass-through authentication (PTA) handles cloud-side authentication. On-premises Kerberos authentication remains entirely within the AD domain controller infrastructure.

When a user authenticates to a domain-joined Windows device:

1. The client contacts the KDC on the domain controller and presents credentials.
2. The KDC issues a TGT encrypted with the krbtgt account's key and the user's long-term key (derived from the password hash).
3. The TGT is cached in the Local Security Authority Subsystem Service (LSASS) process memory.
4. The client uses the TGT to request Service Tickets (ST) for specific resources without re-authenticating.

When the password changes in Entra ID, step 2 onward is affected for new authentication events. But the TGT already sitting in LSASS on the endpoint is untouched. If the device is offline or the user's session is still active, that TGT continues to function until it expires or is explicitly purged.

Identifying Stale Kerberos Keys

Identifying stale Kerberos keys requires device-level inspection. The primary tool is klist, a built-in Windows utility that reads the Kerberos ticket cache from the current session.

klist

This outputs all cached tickets, their issue times, expiration times, and the encryption type used. Admins should cross-reference ticket issue times against the timestamp of the Entra ID password rotation event. Any TGT issued before the rotation and still within its validity window is a stale key.

For a more targeted query that surfaces only TGTs (as opposed to service tickets), run:

klist tgt

To enumerate tickets across multiple sessions on a shared or multi-user device, use:

klist sessions

This is particularly relevant for Azure Virtual Desktop (AVD) or Remote Desktop Session Host (RDSH) environments where multiple user sessions may be active simultaneously, each carrying its own Kerberos ticket cache.

Operational Impact of Stale Keys

The presence of stale Kerberos keys creates a concrete attack surface that persists beyond the point where most security teams believe the credential has been neutralized.

Offline Attack Scenarios

An attacker who extracts a valid TGT from LSASS — using tools such as Mimikatz or Rubeus — can perform a Pass-the-Ticket (PtT) attack. This involves injecting the stolen TGT into a new session on a different machine, impersonating the user without knowing the current password. The attack succeeds as long as the TGT has not expired and the krbtgt key has not been rotated.

A second scenario involves Kerberoasting, where an attacker with a valid TGT requests service tickets for accounts with Service Principal Names (SPNs) registered in AD. Those service tickets are encrypted with the service account's password hash and can be taken offline for cracking. A password rotation in Entra ID does nothing to protect service accounts whose SPNs are registered in on-premises AD and whose passwords have not been independently rotated there.

Both attack paths are well-documented in red team literature and are actively used in enterprise intrusion campaigns. The Entra ID rotation event creates a false signal of remediation while the on-premises Kerberos plane remains exploitable.

Monitoring and Mitigation Strategies

Mitigating stale Kerberos keys requires active cache management, not passive expiration. The most direct intervention is forcing a purge of the Kerberos ticket cache on affected devices immediately after a password rotation event.

klist purge

This discards all cached tickets in the current session. The user must re-authenticate to obtain a new TGT, which will be issued against the updated password hash.

For privileged accounts or accounts flagged as potentially compromised, combine the cache purge with a forced sign-out from all active Windows sessions. In environments using Microsoft Defender for Endpoint (MDE), the Live Response feature allows remote execution of klist purge on enrolled devices without requiring physical access or a separate remote management channel.

To detect stale ticket usage at scale, query Microsoft Defender for Identity (MDI) alerts for anomalous Kerberos activity. MDI monitors domain controller traffic and can surface TGT requests that follow unusual patterns — including requests from devices where the associated Entra ID credential was recently rotated.

Governance Considerations

Relying solely on Entra ID password rotation to satisfy compliance frameworks such as SOC 2 Type II, ISO 27001, or PCI-DSS v4.0 creates a documented control gap. These frameworks require demonstrable control over authentication processes, including the timely invalidation of stale credentials across all authentication planes — not just the cloud identity layer.

Compliance Risks and Audit Exposure

Auditors conducting technical testing in hybrid environments may enumerate Kerberos ticket lifetimes and cross-reference them against password change events. A finding that TGTs remained valid for hours after a credential rotation — particularly for privileged accounts — will typically surface as a control deficiency under access management domains.

PCI-DSS v4.0 Requirement 8.3 specifically addresses authentication factor management and requires that compromised credentials be invalidated immediately. A 10-hour TGT window following a rotation event is difficult to defend in a PCI audit if the rotation was triggered by a suspected compromise.

Implementing Effective Controls

Controls that address stale Kerberos keys must operate at both the policy and enforcement layers:

• Regular Cache Purging: Automate the purging of Kerberos ticket caches on domain-joined devices using Group Policy Preferences or Intune remediation scripts deployed to co-managed or Intune-managed devices.
• TGT Lifetime Reduction: Reduce the default TGT lifetime in AD from 10 hours to 4 hours or less for privileged user OUs. This limits the window of exposure without requiring manual intervention after every rotation event.
• Monitoring and Alerts: Configure MDI to alert on Kerberos anomalies and integrate those alerts into your Microsoft Sentinel workspace for correlation with Entra ID sign-in events.
• Policy Updates: Update your credential rotation runbooks to include explicit steps for on-premises Kerberos cache invalidation, not just Entra ID password reset confirmation.

Recommendations for Secure Entra ID Deployments

Automate Kerberos Cache Management at Rotation Time

The most reliable mitigation is automating cache purging as a post-rotation action. In environments using Microsoft Endpoint Configuration Manager (MECM) or Intune, deploy a remediation script that triggers klist purge on the target device within minutes of a password rotation event.

For Intune-managed devices, a Proactive Remediation (now called Remediations in the Intune admin center) script pair can detect stale tickets and purge them on a scheduled basis:

$tickets = klist | Select-String "End Time"
$stale = $tickets | Where-Object {
    $timeString = ($_ -split ":\s+")[1].Trim()
    $expiry = [datetime]::ParseExact($timeString, "M/d/yyyy H:mm:ss", $null)
    $expiry -lt (Get-Date).AddHours(-4)
}
if ($stale) { exit 1 } else { exit 0 }

klist purge
Write-Output "Kerberos ticket cache purged at $(Get-Date -Format 'u')"

Implement Continuous Monitoring with KQL in Sentinel

Deploy a Microsoft Sentinel analytic rule to correlate Entra ID password reset events with subsequent Kerberos authentication activity from the same device. The following KQL query surfaces devices where Kerberos authentication occurred more than two hours after an Entra ID password reset:

let PasswordResets = AuditLogs
| where OperationName == "Reset password (by admin)" or OperationName == "Self-service password reset"
| extend UPN = tostring(TargetResources[0].userPrincipalName)
| extend ResetTime = TimeGenerated
| project UPN, ResetTime;
SecurityEvent
| where EventID == 4768 // Kerberos TGT request
| extend UPN = tolower(TargetUserName)
| join kind=inner PasswordResets on UPN
| where TimeGenerated > ResetTime + 2h
| project TimeGenerated, UPN, Computer, ResetTime, EventID
| order by TimeGenerated desc

This rule will surface cases where a TGT was issued well after the password rotation — a strong indicator that a stale key was in use or that the rotation did not propagate correctly to the on-premises KDC.

Integrate with SIEM Solutions

Integrate Kerberos ticket monitoring with your SIEM to correlate events and detect potential security incidents. Microsoft Sentinel with the Microsoft Defender for Identity data connector provides domain controller-level Kerberos telemetry alongside Entra ID sign-in logs, enabling cross-plane correlation that neither system can provide independently.

Reduce TGT Lifetime for Privileged Accounts

Use Group Policy to configure a shorter TGT lifetime for privileged account OUs. Navigate to Computer Configuration > Windows Settings > Security Settings > Account Policies > Kerberos Policy and set Maximum lifetime for user ticket to 4 hours for tiers containing admin accounts. This does not eliminate the stale key window but reduces it substantially.

Conduct Regular Audits of Kerberos Policy Settings

Audit your AD Kerberos policy settings quarterly. Confirm that TGT lifetimes, renewal windows, and clock skew tolerances align with your current threat model. Use the following PowerShell command to retrieve the current domain Kerberos policy:

Get-ADDefaultDomainPasswordPolicy | Select-Object MaxTicketAge, MaxRenewAge, MaxClockSkew

Cross-reference these values against your compliance requirements and adjust Group Policy accordingly.