While monitoring system logs, a critical error was identified related to the Key Distribution Center (KDC). The logs flagged the presence of duplicate Service Principal Names (SPNs), an issue that can trigger non-secure authentication downgrades from Kerberos to NTLM or cause total connection failures to database instances.
Error Log:
"The KDC encountered duplicate names while processing a Kerberos authentication request. The duplicate name is MSSQLSvc/ZXCSY.local:1433"
"The KDC encountered duplicate names while processing a Kerberos authentication request. The duplicate name is MSSQLSvc/ZXCSY.local:1433"
Root Cause Analysis
In an Active Directory environment, an SPN must be unique and mapped to a single account (either user or computer). If the same SPN is registered across multiple objects, the Kerberos protocol cannot determine which cryptographic key to use for the service ticket, thus compromising the security of the transaction.
In an Active Directory environment, an SPN must be unique and mapped to a single account (either user or computer). If the same SPN is registered across multiple objects, the Kerberos protocol cannot determine which cryptographic key to use for the service ticket, thus compromising the security of the transaction.
Technical Resolution Procedure
Step 1: Identifying Duplicates
Using the setspn command-line tool with the -F (forest-wide search) and -Q (query) flags, I located the conflicting accounts: setspn -F -Q MSSQLSvc/ZXCSY.local:1433
The output confirmed that the SPN was registered to both the ZXCSY computer account and a dedicated domain service account.
Using the setspn command-line tool with the -F (forest-wide search) and -Q (query) flags, I located the conflicting accounts: setspn -F -Q MSSQLSvc/ZXCSY.local:1433
The output confirmed that the SPN was registered to both the ZXCSY computer account and a dedicated domain service account.
Step 2: Selecting the Correct Account
By checking the SQL Server service configuration via services.msc on the target server, I verified that the instance was running under a Domain User Account. Therefore, the SPN registered to the computer account was redundant and the primary cause of the conflict.
By checking the SQL Server service configuration via services.msc on the target server, I verified that the instance was running under a Domain User Account. Therefore, the SPN registered to the computer account was redundant and the primary cause of the conflict.
Step 3: Removing the Duplicate SPN
I proceeded to delete the incorrect entry from the computer account using the -D (Delete) parameter: setspn -D MSSQLSvc/ZXCSY.local:1433 ZXCSY
Conclusion and Verification
A follow-up query confirmed that the SPN is now exclusively associated with the service account. This resolution restored proper Kerberos authentication, eliminating insecure NTLM fallbacks and stabilizing infrastructure access for the SQL instance.
I proceeded to delete the incorrect entry from the computer account using the -D (Delete) parameter: setspn -D MSSQLSvc/ZXCSY.local:1433 ZXCSY
Conclusion and Verification
A follow-up query confirmed that the SPN is now exclusively associated with the service account. This resolution restored proper Kerberos authentication, eliminating insecure NTLM fallbacks and stabilizing infrastructure access for the SQL instance.