SQL server error 10054 often triggers during remote database connection at the client-side. It generally triggers due to issues with Service Principal Name (SPN) for the SQL Server service.
As a part of our Server Management Services, we help our Customers to fix SQL related errors regularly.
Today we’ll take a look at the cause for this error and how to fix it.
What causes the error SQL server error 10054?
A service principal name (SPN) is a unique identifier of a service instance. SPNs are used by Kerberos authentication to associate a service instance with a service logon account. In short, an SPN mapping allows service on a particular server to be associated with an account responsible for the management of the service, thereby permitting mutual Kerberos authentication.
SQL server error 10054 triggers normally during remote database connection at the client-side. A typical error message looks like:
The major reasons for this error message include:
- Failure to register a Service Principal Name (SPN) for the SQL Server service
- Duplicated SPNs
- Dynamic ports
- SQL Server got installed with Window Authentications only
- SSL certificates at the client-side
Let us now look at how to fix this error in detail.
How to fix the error SQL server error 10054?
SQL Server always attempts to create an SPN for the instance upon startup. Unless the service account is specifically given the Read and Write ServicePrincipalName permissions, this will fail. Thus it may lead to SQL error 10054. Let us now look at the steps to fix this error.
Check if SPN is registered by SETSPN tool.
To check the SPNs that are registered for a specific computer, you can run the following commands from a command prompt:
setspn -L hostname - Substitute the actual hostname for the computer.
setspn -L localhost- This command will check registrations for the account localhost.
If the SPN is not registered, we need to provide the service account permissions to read/ write the SPN and register an SPN by running SETSPN with the -S option.
For instance, to register the http service on the standard port on a computer named test in the help.example.com domain using a service account named test1, use the following command:
setspn -s http/test.help.example.com help\test1
Check for duplicated SPNs
As we listed out earlier, another reason for the 10054 SQL error is duplicated SPNs. We can use the setspn command with a -X option to list out all the duplicated SPNs.
setspn –X
Once the duplicated SPNs are identified, we need to delete all of the duplicated SPN and recreate it. It can be performed with the setspn commands. Format to be used for these operations are:
setspn -s service/namehostname // adding SPN
setspn -r hostname //resetting spn
setspn -d service/name hostname //removing SPN
Disable SYN flooding attack protection
Another fix for the 10054 error would be to disable the SYN flooding attack protection. This can be done by adding the following registry key.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\SycAttackProtect{DWORD} = 0
Once the key is added, we need to reboot the server for the changes to take effect.
Alternate Solutions
Apart from the fixes discussed above, there are some alternate fixes that can help to resolve the issue. The SQL error 10054 can be triggered due to the use of dynamic ports. It is possible to bind SPN to an instance when using dynamic ports. Thus using specific ports can help to fix the error.
The SSL certificate installed at the client end can sometimes cause hindrance and can trigger the 10054 error. Thus it would be a good idea to remove the SSL certificate at the client end temporarily. It would help to confirm if this was the reason behind the error.
Further, changing the authentications to “SQL Server and Window authentication” might also help to fix the problem.
[Need any further assistance in fixing SQL errors? – We’re available 24*7]
Conclusion
In short, SQL server error 10054 often triggers during remote database connection at the client-side due to issues with Service Principal Name (SPN). Today, we saw how our Support Engineers fix this error.
0 Comments