Fix STATUS_NO_PA_DATA (0XC00002F8) Kerberos Error

Quick Answer

Run klist purge on the client, then verify the target service's SPN with setspn -L serviceaccount and check time sync. If that doesn't work, adjust the encryption types allowed on the service account in Active Directory Users and Computers.

What This Error Actually Means

You're trying to authenticate to a service—maybe SQL Server, IIS, or a file share—and the Kerberos exchange hits a wall. The error says: "I expected to find PA data (pre-authentication data) that tells me what encryption type to use for this ticket, but it's not there." Translation: the domain controller sent back a ticket that doesn't include the encryption type info the client needs. This usually happens when the service's SPN is wrong or the encryption types don't match between the client and the service account.

I ran into this last month with a client who moved their SQL Server to a new domain. The service account had the old SPN still attached, and the new account didn't support AES256—only RC4. The moment they flipped to AES on the client side, the whole thing fell apart because the service account couldn't handle it.

Fix Steps

1. Purge cached tickets on the client. Open a command prompt as admin and run klist purge. Then try the connection again. If it works, you had a stale ticket that didn't match the current config.
2. Check the service principal name. Find the service account name and run setspn -L domain\accountname. Look for the SPN that matches the service you're hitting (e.g., MSSQLSvc/servername.domain.com for SQL). If it's missing or points to the wrong account, fix it with setspn -A or setspn -D.
3. Verify encryption types. On the domain controller, open Active Directory Users and Computers, find the service account, go to the Account tab, and under Account options, check "This account supports Kerberos AES 128/256 bit encryption." If the client is asking for AES but the account only has RC4, you'll get this error. Enable both AES options, then force a password reset on the account for the changes to take effect.
4. Sync the clocks. Run w32tm /query /status on the client and the server. If either is more than 5 minutes off from the domain controller, Kerberos will reject tickets. Use w32tm /resync to fix, or check your time source settings.
5. Reboot the service account's host. Sometimes the ticket cache on the server-side needs a clean slate. A reboot forces all Kerberos tickets to be reissued.

Alternative Fixes If the Main Steps Don't Work

• Check Group Policy for encryption type restrictions. Go to Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options. Look for "Network security: Configure encryption types allowed for Kerberos." If it only allows one type (e.g., AES256) and the service account doesn't support it, the error will pop. Uncheck the unsupported types or enable all.
• Review event logs on the domain controller. Event ID 4768 and 4769 in the Security log will show why the KDC rejected the request. Look for "Encryption Type" or "Failure Code" 0x12 (STATUS_NO_PA_DATA).
• Use a different service account. If the current account is ancient or coming from a migrated domain, create a new one with modern encryption support. It's faster than debugging a mess.

Prevention Tip

When you set up a service account, always enable AES128 and AES256 support upfront. Run a script after creation to check: Get-ADUser accountname -Properties msDS-SupportedEncryptionTypes. If it returns 0 or 1 (RC4), you're asking for trouble. Set it to 8 (AES128) or 24 (AES128+256) with Set-ADUser. Also, keep your clocks synced—Kerberos won't tolerate even 5 minutes of drift.

Real talk: I spent three hours chasing this error on a file server once. Turned out the admin had manually set the encryption registry key on the server to only allow DES, and the domain controller was trying to send AES. Always check both sides.