Fix ERROR_SERVER_SID_MISMATCH (0X00000274) on Windows Server

Quick answer: The service or process you're trying to reach is running under a security identifier (SID) that doesn't match what the client expects. The fix is usually resetting the service account's password or re-registering its SPN.

What's Actually Happening Here

This error (0X00000274) means the server process — could be SQL Server, IIS app pool, or any Windows service running under a domain account — has a SID that the client didn't expect. The SID is baked into the service's security context when it starts. If the account's SID changed (e.g., you restored a VM from backup, or recreated the domain account), the service still holds the old one in its token. The client compares that against what it knows (from SPN lookup, Kerberos ticket, or local cache), and they don't match.

I've seen this most often after restoring a domain controller from backup, or when moving a service account between domains. The client gets a ticket for SID_A, but the service presents SID_B. Windows refuses the connection.

Step-by-Step Fix

1. Identify the service account. Open Services.msc, find the service that's failing (e.g., SQL Server, IIS Admin). Look at the "Log On" tab — note the account name.
2. Check the SID of that account. On a domain controller, run Get-ADUser <account> -Properties sid in PowerShell. Compare that to what the service is using. On the server itself, run sc qsid <service_name> — this shows the service's configured SID type (win32process, unrestricted, etc.).
3. Reset the service account password. This forces the service to re-acquire its token. On the DC: Set-ADAccountPassword -Identity <account> -Reset -NewPassword (ConvertTo-SecureString "NewPass123!" -AsPlainText -Force). Then update the service in Services.msc with that new password.
4. Restart the service. Run Restart-Service <service_name>. Check the Application log for error 0X00000274 — if it's gone, you're good.
5. Re-register SPNs if needed. If the service uses Kerberos, run setspn -D <service/name> <account> to remove stale SPNs, then setspn -A <service/name> <account> to add fresh ones. This syncs the SID in Active Directory's SPN cache.
6. Reboot the server. Annoying, but it clears any cached tokens in the LSA.

Alternative Fixes If the Main One Fails

• Check group membership changes. If the account was moved between OUs or groups, its token SID may change. Add it back to the necessary groups explicitly.
• Review the registry. Look at HKLM\SYSTEM\CurrentControlSet\Services\<service> — the ObjectName value should match the account's username. If it's a local account like 'LocalSystem' or 'NetworkService', the SID is built-in and shouldn't mismatch unless the system is seriously corrupted.
• Recreate the service account. If the account was deleted and recreated, its SID changed. You need to create a new account with the same name — but this won't reuse the old SID. Instead, grant the new account the same permissions, update the service, and move on.
• Dual-boot or system restore point: Only as a last resort. If a recent update caused it, roll back the KB.

Prevention Tip

Never delete and recreate domain service accounts. Always reset the password or disable/enable the existing account. Back up the SID with Get-ADUser -Identity <account> -Properties sid | Export-CliXml before any migration. If you're restoring a server from backup, do a sysprep /generalize first to avoid SID duplication — but this is a separate mess you don't want to deal with.

This error is almost always about a stale token or a mismatched SPN. Don't reinstall the service — that's a waste of time. Fix the account identity first.