0

I am facing a strange situation... On a SQL2016 on Windows 2019, I have an application running on windows2019 that connect to the SQL server using a domain service account (same domain as the SQL Server).

In the SQL server Log, I can see those errors:

Login failed. The login is from an untrusted domain and cannot be used with Integrated authentication. [CLIENT: x.x.x.x]
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 operating system error code indicates the cause of failure. The logon attempt failed   [CLIENT: x.x.x.x]

Well, the first error does not make sense as the login is in the same domain.

The weird thing is that when they reboot the app server, then suddently, those error goes away and are replaced by "login succeeded". And then, hours or days later, it start failling again.

If it was the spn, it would never work. If it was a TLS issue, I'm guessing it would never work as well.

What could it be that make it work for a certain time and then fail ?

Thank you.

0

2 Answers 2

1

this link is worth having a look:

Common ‘SSPI handshake failed’ errors and troubleshooting

From there I will post a quote that is exactly your situation:

To share some information about SSPI: SSPI (Security Support Provider Interface) is an interface between transport-level applications, such as Microsoft Remote Procedure Call (RPC), and security providers, such as Windows Distributed Security. SSPI allows a transport application to call one of several security providers to obtain an authenticated connection.

The following parameter is commonly used in connection strings for Windows authentication with trusted connection: Integrated Security=SSPI

There can be 2 variants in SSPI errors: “Cannot generate SSPI context “ and “SSPI Handshake Failed”

Cannot generate SSPI context: We generally get this error when the client is trying a Kerberos authentication and that fails but it does not fall back to NTLM. SSPI handshake failed: We get this when the user is not authenticated.

In the issue we worked on we were encountering “SSPI Handshake Failed” which indicates that the SQL Server was unable to authenticate the user.

the site goes on in showing ways to isolate the issue and deal with it.

What I would do in terms of isolating the issue is login into the sql environment using the account in question and see from there.

just yesterday I had a similar issue, and on my environment it turned out to be related to the latest microsoft patches that were waiting to be applied.

Having applied those patches, all the authentication started to flow as normal, in my case it was related to the replication - so it started to catch up...

0

maybe your account is being locked out... are you using it someplace else? Did you check in your DC for events for this account? You could use a SQL Server login instead of a domain account.

2
  • The error is different when the account is locked. I also fix the issue every time the app server/service is restarted (which would not fix a locked account). Using a SQL login would be my "workaround" if ever I'm not able to find the root cause of this issue. Thanks for your suggestion May 21, 2020 at 17:15
  • Actually I would look closer to the account. I've seen few times this error and it was related to locked account. So check the AD events for this account like mentioned by L.T.
    – Marcin
    Aug 16, 2022 at 13:12

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.