Share via

Kerberos Authentication Error

Bryan Freeman 0 Reputation points
2026-04-08T19:39:39.3233333+00:00

We are having Kerberos Error and it is not allowing users to connect to an SQL Server on a server. I have checked Klist, time sync, as well as clearing the klist, resync the time. This is a domain account. I am at a lost.

Windows for business | Windows Server | Directory services | Active Directory
0 comments
Answer accepted by question author
  1. Domic Vo 18,955 Reputation points Independent Advisor
    2026-04-08T20:31:57.85+00:00

    Hello Bryan Freeman,

    Kerberos errors when connecting to SQL Server with a domain account usually indicate that the SPN (Service Principal Name) registration is either missing or incorrect. Since you’ve already checked time synchronization and ticket cache with klist, the next critical step is to verify the SPNs for the SQL Server service account. Kerberos authentication requires that the client can resolve the SQL Server service to a valid SPN in Active Directory. If the SPN is absent or duplicated, authentication will fail and you’ll see errors even though NTLM fallback might still work in some cases.

    From your remote session, run:

    setspn -L <SQLServiceAccount>

    and check whether the SPNs for MSSQLSvc/<hostname>:1433 and MSSQLSvc/<FQDN>:1433 are present. If they are missing, you need to register them with:

    setspn -A MSSQLSvc/<hostname>:1433 <SQLServiceAccount>

    setspn -A MSSQLSvc/<FQDN>:1433 <SQLServiceAccount>

    Replace <SQLServiceAccount> with the domain account running the SQL Server service. If you find duplicates across multiple accounts, you must clean them up because duplicate SPNs will also break Kerberos.

    Additionally, confirm that SQL Server is configured to allow TCP/IP connections on port 1433 and that the service account has the “Trusted for delegation” setting if constrained delegation is required. You can check this in Active Directory Users and Computers under the account properties.

    If the SPNs are correct and Kerberos still fails, enable Kerberos logging by setting the registry key HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters\LogLevel to 1 (DWORD) and then review the system event logs for detailed Kerberos errors. This will give you precise information about whether the ticket request is failing due to SPN resolution, delegation, or encryption type mismatch.

    Given that you’ve already ruled out time skew and ticket cache issues, the SPN configuration is the most likely root cause. Correcting the SPNs and ensuring they are unique should restore Kerberos authentication for SQL Server.

    I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

    Domic Vo.

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Q&A Assist
    2026-04-08T19:40:00.55+00:00
    AI generated content. This question contains an answer created with AI from Q&A Assist. Learn more

    Use a focused Kerberos/SQL checklist to narrow down the cause, since time sync and ticket cache have already been checked.

    1. Confirm whether tickets are expired or missing
    • On an affected client, run:
      • klist to confirm there is a valid TGT and a service ticket for the SQL SPN.
      • If you see KRB_AP_ERR_TKT_EXPIRED in KDC logs or traces, purge and reacquire tickets:
        • klist purge
        • Sign out/in or restart the client, then try to connect again.
    • If tickets are still expiring quickly or not renewing, investigate domain controller health and time sync across all DCs and SQL servers.
    1. Verify the SQL Server SPN and uniqueness
    • Kerberos to SQL requires a correct and unique SPN for the SQL service account.
    • On a domain controller (or admin workstation with RSAT), run:
      • setspn -Q MSSQLSvc/<SQLServerFQDN>:<port>
      • setspn -Q MSSQLSvc/<SQLServerNetBIOS>:<port>
    • Confirm:
    1. Check for KRB_AP_ERR_MODIFIED and related errors
    • On the SQL Server and domain controllers, review System/Security logs for:
      • KRB_AP_ERR_MODIFIED
      • KDC_ERR_PRINCIPAL_NOT_UNIQUE / KDC_ERR_S_PRINCIPAL_UNKNOWN
      • KRB_AP_ERR_SKEW
    • If KRB_AP_ERR_MODIFIED appears:
      • It usually indicates SPN or account mismatch (ticket encrypted for a different account than the one running SQL).
      • Correct the SPN and ensure SQL is running under the account that owns the SPN.
    • If KRB_AP_ERR_SKEW appears:
      • Reconfirm time sync using w32tm /resync /computer:<Target> /rediscover on clients, SQL Server, and DCs.
    1. Validate infrastructure and domain reachability
    • Ensure the client and SQL Server can contact domain controllers:
      • Check that required ports are open between client ↔ DC and SQL ↔ DC, especially:
        • Kerberos: 88/TCP, 88/UDP, 464/TCP/UDP, and dynamic RPC ports 49152–65535.
        • DNS: 53/TCP/UDP.
      • If domain controller discovery fails, errors like Event ID 5719, 1311, or 1355 may appear, indicating domain or DC not found.
    • Confirm both client and SQL Server are joined to appropriate domains (same forest or trusted forests).
    1. Check LSASS / SSPI handshake errors on SQL Server
    • In the SQL Server error log, look for entries such as:
      • SSPI handshake failed with error code 0x80090311 or 0x80090304.
    • These indicate issues with LSASS or contacting an authority for authentication.
      • Reconfirm SPN registration and DC reachability.
      • If LSASS is unresponsive, restart the server during a maintenance window.
    1. Use Network Monitor for deeper Kerberos tracing
    • If the issue persists and logs show Kerberos errors but the cause is unclear:
      • Install Network Monitor on both client and SQL Server.
      • Capture simultaneous traces while reproducing the failed connection.
      • Inspect Kerberos messages for:
        • Missing tickets in HTTP/TDS requests.
        • Specific KDC error codes (KDC_ERR_ETYPE_NOTSUPP, KRB_AP_ERR_MODIFIED, etc.).
    • Use the error codes from the trace together with the troubleshooting checklist to pinpoint the misconfiguration.
    1. Restart after changes
    • After fixing SPNs, time, or infrastructure issues:
      • Restart SQL Server service (so it re-reads SPNs and credentials).
      • If necessary, restart affected clients and/or domain controllers.
      • Test Kerberos connections again.

    If a specific Kerberos error code (for example, KRB_AP_ERR_TKT_EXPIRED, KRB_AP_ERR_MODIFIED, KDC_ERR_PRINCIPAL_NOT_UNIQUE) is identified in event logs or traces, focus on the corresponding row in the Kerberos troubleshooting checklist and remediate that condition before re-testing.

    References:

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.