How to fix Error 1822 on Windows 11

by

Windows Error 1822: No Principal Name Registered — Troubleshooting Guide

Why This Error Happens

Error 1822 occurs when the Kerberos authentication system cannot locate a Service Principal Name (SPN) registered in Active Directory for the target service or machine account. This typically results from a corrupted or missing SPN registration, a mismatch between the service account and the domain controller’s records, or DNS resolution failures preventing proper name lookups. In Windows 11 domain-joined environments, this can also stem from stale Kerberos tickets or improperly configured service accounts.

Step-by-Step Resolution Guide

Step 1: Verify SPN Registration Status

  • Open Command Prompt as Administrator and run setspn -L <ComputerName> to list currently registered SPNs.
  • Check if the expected service (e.g., HOST, HTTP, or a custom service name) is missing from the output.
  • Note the exact service account or computer account tied to the failing service.

Step 2: Manually Register the Missing SPN

  • Run setspn -S <ServiceClass>/<HostName> <AccountName> to add the required SPN (the -S flag checks for duplicates before adding).
  • Example: setspn -S HTTP/webserver01.contoso.com contoso\svc_webapp
  • Confirm no duplicate SPNs exist elsewhere in the domain, as duplicates cause silent Kerberos failures.

Step 3: Flush DNS and Kerberos Ticket Cache

  • Run ipconfig /flushdns to clear stale DNS records that may be causing incorrect SPN lookups.
  • Run klist purge to clear all cached Kerberos tickets on the local machine.
  • Restart the affected service or reboot the Windows 11 machine to force ticket renewal.

Step 4: Check Domain Controller Time Sync

  • Verify time synchronization using w32tm /query /status, since Kerberos requires clock skew under 5 minutes between client and DC.
  • If drift exceeds the threshold, resync with w32tm /resync /force.

Step 5: Restart the Kerberos Key Distribution Center Service

  • Navigate to services.msc, locate Kerberos Key Distribution Center, and restart it on the domain controller.
  • This forces regeneration of ticket-granting tickets referencing the corrected SPN.

Alternative or Verification Steps

  • After completing the steps, re-run setspn -L <ComputerName> to confirm the SPN now appears correctly, then re-attempt the original authentication request to confirm Error 1822 no longer appears.
  • If the issue persists, use klist tickets to inspect active Kerberos tickets for anomalies, or consider running dcdiag /test:kerberos on the domain controller to identify deeper AD replication or trust issues.