SEC_E_INVALID_PARAMETER (0x8009035D) fix for Windows auth

When you'll see this error

You're trying to connect to a remote resource — maybe a file share, SQL Server, or an Outlook mailbox — and you get slapped with SEC_E_INVALID_PARAMETER (0x8009035D). The exact message: "One or more of the parameters passed to the function were invalid."

I've seen this most often during domain authentication over LDAP or when a web app tries to use Kerberos delegation. It's also common right after a daylight saving time change or when a VM boots from a snapshot that's a few hours old. The error is vague, but the fix isn't.

Root cause

The culprit here is almost always one of two things:

1. Clock skew between your machine and the domain controller. Kerberos has a 5-minute tolerance by default. If your system clock is off by more than that, authentication fails with this parameter error.
2. Corrupted Kerberos ticket cache. A stale ticket with garbled data gets passed to the security provider, and it chokes on the malformed structure.

Less common but worth mentioning: a busted SPN (Service Principal Name) on the target service account, or a misconfigured SSL certificate that causes Schannel to reject the parameter set during the handshake.

Step-by-step fix

Do these in order. Don't skip steps.

Step 1: Check and sync your system clock

Open an elevated Command Prompt and run:

w32tm /query /status

Look at the Source field. If it's Local CMOS Clock or blank, you're not syncing to a reliable NTP server. Fix it:

w32tm /config /manualpeerlist:"pool.ntp.org" /syncfromflags:manual /reliable:yes /update
net stop w32time && net start w32time
w32tm /resync

For domain-joined machines, you should sync from your domain controller:

w32tm /config /syncfromflags:domhier /update
net stop w32time && net start w32time
w32tm /resync

After the resync, check with w32tm /query /status again. The offset should be less than 1 second.

Step 2: Purge the Kerberos ticket cache

Still failing? The ticket cache is likely corrupt. Run this as an admin:

klist purge -li 0x3e7

That clears the computer account's tickets. Then purge the user's tickets too:

klist purge

Log off and back on. Try the failing operation again.

Step 3: Verify the SPN (for service-specific errors)

If you're hitting this against a specific service (like SQL Server), check the target service account's SPN:

setspn -Q servicePrincipalName

Replace servicePrincipalName with the actual SPN format, e.g., MSSQLSvc/sqlserver.domain.com:1433. If you get a duplicate SPN error, that's your problem. Remove the duplicate with setspn -D.

Step 4: Check Schannel / TLS parameters

This is rarer, but I've seen it with outdated systems trying to use SSL 3.0 or TLS 1.0. Check the event logs for Schannel errors (Event Viewer > Windows Logs > System). If you see Event ID 36874 or 36875, tighten the TLS configuration.

On the client machine, ensure you have the latest Windows Update rollup installed. For servers, verify that the target service's certificate matches the SPN and hasn't expired.

What to check if it still fails

If you've done all four steps and the error won't die, look harder at the environment:

• Check DNS. Run nslookup domaincontroller.yourdomain.com. If it returns a stale IP or fails, fix DNS first.
• Check the Kerberos event logs. Enable Kerberos logging (reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters /v LogLevel /t REG_DWORD /d 1), then reproduce the error and look for Event ID 503 or 505 in the System log.
• Is the target service actually listening? Don't assume. Use Test-NetConnection server.domain.com -Port 389 (or whatever port you're hitting).
• For web applications, check the application pool identity in IIS. It might be running under a local account that can't authenticate across the network.

One last thing — if this is happening after a domain migration or a rename, you might need to rejoin the domain. I know it's drastic, but I've had to do it twice in 14 years. It fixed it both times.