Hardening Active Directory Against CVE-2026-47288 and the Kerberos Attack Surface

CVE-2026-47288 targets the Windows Kerberos Key Distribution Centre — the authentication engine for all Active Directory environments. Patching is mandatory, but the patch alone does not harden the broader Kerberos attack surface that adversaries routinely exploit to persist in enterprise networks long after initial compromise. This article addresses both the immediate CVE remediation and the wider Kerberos hardening posture.

Immediate Post-Patch Verification

After applying the June 2026 patch to all domain controllers, verify:

Kerberos functionality check:

# From a domain-joined workstation
klist purge
# Test authentication — request a TGT
klist tgt
# Request a service ticket for a known SPN
klist get cifs/fileserver01.domain.local

DC event log review (look for errors following patch deployment):

• Event ID 4768: A Kerberos authentication ticket was requested — verify successful events continuing post-patch
• Event ID 4771: Kerberos pre-authentication failed — spike in failures may indicate patch compatibility issue with specific clients
• KDC event source errors in the System log: KerberosKdcError events indicate KDC startup or processing issues

Hardening the Kerberos Attack Surface

KRBTGT Account Management

The KRBTGT account is the service account whose password is used to sign all Kerberos TGTs. If an attacker obtains the KRBTGT password hash (achievable by compromising a domain controller), they can create arbitrary TGTs (Golden Tickets) for any user, with any privileges, with any validity period.

KRBTGT password rotation: Change the KRBTGT password immediately after any confirmed or suspected DC compromise, and as a routine quarterly practice. Rotation must be performed twice with a time interval between rotations — the first rotation invalidates existing TGTs, the second ensures old password hashes are fully retired from the Kerberos key table.

Microsoft’s KRBTGT Reset script is available in the Microsoft Security GitHub repository and handles the two-rotation sequence correctly.

Privileged Account Hardening

Protected Users security group: Add all Tier 0 accounts (Domain Admins, Enterprise Admins, KRBTGT, built-in Administrator) to the Protected Users security group. Protected Users:

• Cannot authenticate using NTLM (only Kerberos)
• Cannot use DES or RC4 encryption for Kerberos (only AES)
• Cannot use unconstrained delegation
• TGT lifetime is limited to 4 hours (not the default 10 hours)

These restrictions significantly reduce the window for TGT abuse if a Tier 0 account is compromised.

Tiered administration: Implement the Microsoft Enterprise Access Model (formerly Privileged Access Workstation model) with separation between Tier 0 (domain infrastructure), Tier 1 (servers), and Tier 2 (workstations). Tier 0 accounts should only authenticate from dedicated Tier 0 PAWs (Privileged Access Workstations), never from standard workstations or shared admin systems.

Service Principal Name (SPN) Management

Kerberoasting attack: Any domain user can request a service ticket for any SPN in the domain. Service tickets are encrypted with the password hash of the service account. Offline cracking of service tickets (Kerberoasting) reveals the service account password for any account with a weak password and an SPN.

Identify all SPNs in the domain:

Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties ServicePrincipalName |
  Select-Object Name, ServicePrincipalName
Get-ADComputer -Filter {ServicePrincipalName -ne "$null"} -Properties ServicePrincipalName |
  Select-Object Name, ServicePrincipalName

For each service account with an SPN:

• Enforce 25+ character randomly generated passwords
• Configure the account to require AES-only Kerberos encryption (prevents RC4 encryption which is faster to crack)
• Enable auditing of TGS requests for these accounts (Event ID 4769 with ticket options 0x40810010)

Managed Service Accounts (MSAs) and Group Managed Service Accounts (gMSAs): Replace manually managed service accounts with gMSAs wherever possible. gMSAs have 240-character randomly generated passwords that are automatically rotated by AD — eliminating Kerberoasting viability for gMSA accounts.

AS-REP Roasting Prevention

Accounts with Do not require Kerberos preauthentication enabled can have their AS-REP responses captured and cracked offline without requiring a valid password to initiate the exchange.

Find accounts with this setting:

Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} -Properties DoesNotRequirePreAuth |
  Select-Object Name, DistinguishedName

Remove this setting from all accounts except those with a documented technical requirement. For accounts that require it (rare legacy application compatibility), enforce strong passwords (20+ characters) to resist offline cracking.

Delegation Controls

Unconstrained delegation allows a service account to request Kerberos tickets on behalf of any user for any service — a broad capability that is abused in pass-the-ticket attacks when the delegated account is compromised.

Identify accounts with unconstrained delegation:

Get-ADComputer -Filter {TrustedForDelegation -eq $true} | Select-Object Name
Get-ADUser -Filter {TrustedForDelegation -eq $true} | Select-Object Name

Remove unconstrained delegation from all accounts except domain controllers (which require it by design). Replace with constrained delegation or resource-based constrained delegation (RBCD) where delegation functionality is genuinely required.