SEC_E_NO_PA_DATA (0x8009033C): Real Fix for Kerberos PA-DATA Errors

You're logging into an application—maybe SQL Server Management Studio, maybe a SharePoint site—and instead of getting in, you see SEC_E_NO_PA_DATA (0x8009033C). The full message says something like “Expected to find PA data for a hint of what etype to use, but it was not found.” This usually happens right after you type your password and hit enter. The app tries to authenticate via Kerberos, and the domain controller basically says, “I can't find the pre-authentication blob I need.”

I've seen this on a client's terminal server last year. Their finance team couldn't access a custom ERP app every morning, but only after daylight saving time kicked in. That's the clue—clock skew. But it's not always the clock. Let's break down what's actually going on.

Root Cause in Plain English

Kerberos uses a timestamp encrypted with your password hash as pre-authentication data (PA-DATA). The domain controller decrypts it and checks if the timestamp is within 5 minutes of its own clock. If the clocks drift too much, the DC can't decrypt or validate the timestamp, so it won't send back the expected PA-DATA hint. That triggers 0x8009033C.

But there's another common cause, and it's not clock-related at all. When an application requests a service ticket, the client asks the KDC for a ticket to a specific Service Principal Name (SPN). If the SPN doesn't exist or is registered to the wrong machine, the KDC might not return the proper pre-authentication data structure. The client expected a specific encryption type hint, but got nothing. Result? The error.

So, two big culprits: time sync issues and bad SPNs. Less often, it's a DNS problem where the client can't resolve the KDC properly, but that usually throws a different error.

Fix #1: Check the Clock

Don't skip this. Even if you think your servers are synced, check. Here's how:

1. On the client machine and the server running the application, open a command prompt and run:

   w32tm /query /status

2. Look at the “Last Successful Sync Time” and the “Source.” If it says “Local CMOS Clock” or the sync time is old, that's your problem.
3. Force a resync:

   w32tm /resync

4. Make sure both machines point to the same time source. Ideally, the domain controller is the authority. On the DC, run:

   w32tm /config /manualpeerlist:pool.ntp.org /syncfromflags:manual /reliable:yes /update

   Then restart the time service.

For a quick test, set the client clock to within 30 seconds of the server and try again. If it works, you've got a sync issue. Permanent fix? Group Policy. Set “Configure Windows NTP Client” under Computer Configuration > Administrative Templates > System > Windows Time Service > Time Providers. Point it to the domain's time source.

Fix #2: SPN Troubleshooting

If the clock's fine, move to SPNs. This is where I spend most of my time on these tickets.

1. On the server hosting the application, run:

   setspn -L 

   or use the service account the app runs under. For SQL Server, it's usually the account running the SQL Service.
2. That lists all SPNs registered. You're looking for the service class and hostname. For SQL, it's something like MSSQLSvc/myserver:1433 or MSSQLSvc/myserver.corp.local:1433.
3. If the SPN is missing, register it:

   setspn -A MSSQLSvc/myserver.corp.local:1433 domain\sqlaccount

4. If it's registered to the wrong account or machine, delete and re-add:

   setspn -D MSSQLSvc/myserver:1433 domain\wrongaccount

   Then add it correctly.

Also, check for duplicates. Duplicate SPNs cause all sorts of weirdness. Run:

setspn -Q MSSQLSvc/myserver.corp.local:1433

For IIS or SharePoint, it's often the HTTP SPN. Same process, just different service class.

Fix #3: DNS and Hostname Mismatch

One client's issue was that the app was accessed via a short name like myserver, but the SPN was registered for the FQDN myserver.corp.local. The client was asking for a ticket with the short name, and the KDC couldn't find a matching SPN for that name. Simple fix: use the FQDN in the connection string or in the browser URL. Or register an SPN for the short name as well.

Check DNS:

ping myserver.corp.local

If It Still Fails

By now, if the error persists, you're dealing with something more exotic. Break out Kerberos logging—it's your best friend.

1. Enable Kerberos event logging on the client and server:

   reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos" /v LogLevel /t REG_DWORD /d 1 /f

2. Reboot or restart the relevant services to force a new logon session.
3. Reproduce the error, then check the System event log for Event ID 11 (Kerberos). It'll often show the requested SPN and the error details.

Look for the SPN in the event log. If it's exactly what you expect, then the issue is between the client and the DC. Try using klist to purge tickets:

klist purge

Also, if you're using any security software, occasionally it blocks the necessary network ports. Kerberos uses UDP/TCP 88. Make sure firewalls aren't dropping traffic.

One more thing—if you've recently migrated to a new domain or changed encryption types (like disabling RC4), you could run into this. Check the DC's supported encryption types under Group Policy: Network security: Configure encryption types allowed for Kerberos. Make sure AES is enabled and the client supports it. Old Windows 7 clients might need a patch.

I had a case where the issue was only on one client machine. Turned out the system clock was set to the wrong time zone, so even though UTC was correct, local time was off by hours. Double-check time zones.

If you've gone through all this and it still fails, take a packet capture with Wireshark or Netmon during the authentication attempt. Look for the Kerberos error reply from the KDC—it'll tell you the exact reason. Sometimes it's a KDC-only issue.

Bottom line: check the clock first—it's the easiest. Then SPNs, then DNS. 90% of the time it's one of those. The other 10% you'll need the event logs, but at least you'll know where to look.