DESCRIPTION: SSPI handshake failed with error code 0x8009030c, state 14 while establishing a connection with integrated security; the connection has been closed. Reason: AcceptSecurityContext failed. The Windows error code indicates the cause of failure. [CLIENT: 10.XXX.XX.XX} ***The client address is different on different occasion

Can i refer this problem to my network admin? is this a network issue or a sql server issue. Is there any other way other then changing the registry ? Can i safely ignore this error ?


8 Answers 8


WORKAROUND/SOLUTION Loopback check can be removed by adding a registry entry as follows:

Edit the registry using regedit. (Start –> Run > Regedit ) Navigate to: HKLM\System\CurrentControlSet\Control\LSA Add a DWORD value called “DisableLoopbackCheck” Set this value to 1


To address the issue:

We added the account “contoso\sqlaccount” to “Access this computer from the network” local security policy (secpol.msc) on the SQL Server box and post which we were successfully able to connect to the instance from the application.

To address the SSPI Handshake failed errors, always review the security logs post enabling Audit Logon events. Security logs would give a good amount of information needed to address this issues.


In my situation the issue was connected to user password expiration. User left session on remote desktop with running application connected to sql server. When password expired for that user I started getting SSPI handshake error alerts.

My solution to this problem was to locate user on server a.b.c.d with expired password and manually sign off user.


I was using a gMSA for the SQL Server service. Reverting back to a regular service account solved the issue for me.


Tried all the suggestions, did not work. My issue was resovled by connecting from ssms 2014 instead of latest 2018 SSMS.


Well I encountered this error when I tried to connect to a Registered server in my SSMS app on my desktop. I had a session already running but I had to change the password for that administrator account as it was due to expire. I had started the SSMS session under the old password. So this error can be as simple as that it seems! If you have a connection coming in from somewhere, and the password for that account has been changed, it can throw up this error. So I would advise to consider that before registry changes etc.


An old post but I'll add my solution. My scenario is that I have two AD domains, one on the internal lan and one on the DMZ. The domains are separate but the accounts shadow each other (each user has the same username and password on each domain). The lan can authenticate with the sql server on the DMZ using windows authentication. (It has been working for over 20 years). Suddenly I got the above error for one user. The user has an azure AD for the lan domain. I believe the error occurred when I added the azure AD user to the DMZ as a new user but I'm not sure this caused the issue. Anyway I deleted both accounts from the DMZ domain and added back the lan user to the DMZ domain and the error disappeared.


I've had users that had this issue with SSMS locally on their laptop - when there domain passwords expired that they used in SSMS. Typically had them close down SSMS or reboot their laptop. Its like something in SSMS was cached on local laptop. As they have no issues using SSMS on Windows Server App server (RDP) using same user domain account with new password. Reboot of laptop always seems to fix it - assuming using local install of SSMS.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.