SSPI handshake failed with error code 0x8009030c,

Question

SSPI handshake failed with error code 0x8009030c,

G Sunny

SSC Eights!

Points: 988
More actions
October 3, 2017 at 12:15 pm

#350198

Hello All,
Could anyone help fixing below error? I can see this error in SQL error logs and event logs also.
Message
Login failed. The login is from an untrusted domain and cannot be used with Windows authentication.
Message
Error: 18452, Severity: 14, State: 1.
Message
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. The logon attempt failed
Thanks in advance

Viewing 13 posts - 1 through 12 (of 12 total)

You must be logged in to reply to this topic. Login to reply

Sue_H SSC Guru Points: 90860 More actions · Answer 1

G Sunny - Tuesday, October 3, 2017 12:15 PM
Hello All,
Could anyone help fixing below error? I can see this error in SQL error logs and event logs also.
Message
Login failed. The login is from an untrusted domain and cannot be used with Windows authentication.
Message
Error: 18452, Severity: 14, State: 1.
Message
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. The logon attempt failed
Thanks in advance

It could be a lot of things - we would need more information to do things other than guess. Usually there are more error messages or additional information after what you posted which can point you in the direction of the issue.
So look for any additional messages in the SQL Server error log. Handshake failed usually indicates that the user couldn't be authenticated. You might also want to check the security event log on the server for any errors at the same time as those in the SQL Server error log.
Check the IP of the client since loop back issues usually have the local IP address for the client.

Sue

G Sunny SSC Eights! Points: 988 More actions · Answer 2

Sue,
Thanks for your reply,
I can not see any additional information in SQL error logs and application event log, there are no errors logged in security event log,
Thanks

sgmunson SSC Guru Points: 110640 More actions · Answer 3

G Sunny - Tuesday, October 3, 2017 12:15 PM
Hello All,
Could anyone help fixing below error? I can see this error in SQL error logs and event logs also.
Message
Login failed. The login is from an untrusted domain and cannot be used with Windows authentication.
Message
Error: 18452, Severity: 14, State: 1.
Message
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. The logon attempt failed
Thanks in advance

The bit about the "untrusted domain" is likely important, as it indicates that the security context attempting to log in is from an untrusted domain. That may mean that you have an intruder attempting to log in, but it could also be someone attempting to run a package on a developer workstation and using the local administrator account. You'll need to see if you can track down who might have been doing things and attempting connections to the SQL Server at the time of the error log entries.

Steve (aka sgmunson) 🙂 🙂 🙂
Rent Servers for Income (picks and shovels strategy)

Sue_H SSC Guru Points: 90860 More actions · Answer 4

You can get that error with just an expired password. Or if the host file gets edited and doesn't have localhost anymore. Or the localhost entry is incorrect. Or just not being able to contact AD. Or not having trusts between domains. And probably a ton of other things just related to not being able to resolve, authenticate the login.
It might be good to track down the IP and go from there if there are no other errors. The errors should have the IP.
And also check if it's just one IP address having the issue or if it's different ones on every login attempt. Or different ones sporadically.

Sue

Joe Torre SSChampion Points: 10248 More actions · Answer 5

Try setting up a SPN for the account under which SQL Server is running for the server you are connecting to that matches the server in your connection string. This may facilitate generating a valid SSPI context.

G Sunny SSC Eights! Points: 988 More actions · Answer 6

Sue_H - Tuesday, October 3, 2017 2:36 PM
You can get that error with just an expired password. Or if the host file gets edited and doesn't have localhost anymore. Or the localhost entry is incorrect. Or just not being able to contact AD. Or not having trusts between domains. And probably a ton of other things just related to not being able to resolve, authenticate the login.
It might be good to track down the IP and go from there if there are no other errors. The errors should have the IP.
And also check if it's just one IP address having the issue or if it's different ones on every login attempt. Or different ones sporadically.
Sue

Sue,

I checked the password of the account is not locked and not expired, host file is also not edited and the client and server are in same domain, I can see single IP in SQL error logs,
Do i need to check anything on the server where the IP logged in error logs?
Thanks
Sunny

G Sunny SSC Eights! Points: 988 More actions · Answer 7

sgmunson - Tuesday, October 3, 2017 2:25 PM
G Sunny - Tuesday, October 3, 2017 12:15 PM
Hello All,
Could anyone help fixing below error? I can see this error in SQL error logs and event logs also.
Message
Login failed. The login is from an untrusted domain and cannot be used with Windows authentication.
Message
Error: 18452, Severity: 14, State: 1.
Message
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. The logon attempt failed
Thanks in advance
The bit about the "untrusted domain" is likely important, as it indicates that the security context attempting to log in is from an untrusted domain. That may mean that you have an intruder attempting to log in, but it could also be someone attempting to run a package on a developer workstation and using the local administrator account. You'll need to see if you can track down who might have been doing things and attempting connections to the SQL Server at the time of the error log entries.

Steve,
login is attempting from a same domain,
Thanks, Sunny

G Sunny SSC Eights! Points: 988 More actions · Answer 8

Joe Torre - Tuesday, October 3, 2017 5:02 PM
Try setting up a SPN for the account under which SQL Server is running for the server you are connecting to that matches the server in your connection string. This may facilitate generating a valid SSPI context.

Joe,
I tried setting up a SPN for the account under which SQL Server is running, but no lock.
Thanks,Sunny

Sue_H SSC Guru Points: 90860 More actions · Answer 9

G Sunny - Wednesday, October 4, 2017 2:31 PM
Sue,
I checked the password of the account is not locked and not expired, host file is also not edited and the client and server are in same domain, I can see single IP in SQL error logs,
Do i need to check anything on the server where the IP logged in error logs?
Thanks
Sunny

Are the errors all coming from the same IP, client and login? It sounds like that's what you are saying. If that's the case, have you checked the event logs for that IP? Is it a user or an Application server? Have they tried different ways to connect to SQL Server?
Also check the Security event logs on the server where you have the errors. SSPI Handshake errors usually have something in those logs that can give you more information on what the issue it.
If it's always from the same IP then it's likely related to that Server or PC.

Sue

sgmunson SSC Guru Points: 110640 More actions · Answer 10

Sue_H - Wednesday, October 4, 2017 2:53 PM
G Sunny - Wednesday, October 4, 2017 2:31 PM
Sue,
I checked the password of the account is not locked and not expired, host file is also not edited and the client and server are in same domain, I can see single IP in SQL error logs,
Do i need to check anything on the server where the IP logged in error logs?
Thanks
Sunny
Are the errors all coming from the same IP, client and login? It sounds like that's what you are saying. If that's the case, have you checked the event logs for that IP? Is it a user or an Application server? Have they tried different ways to connect to SQL Server?
Also check the Security event logs on the server where you have the errors. SSPI Handshake errors usually have something in those logs that can give you more information on what the issue it.
If it's always from the same IP then it's likely related to that Server or PC.
Sue

Sunny,

Go with Sue here... she knows what she's talking about and I completely agree here.

Steve (aka sgmunson) 🙂 🙂 🙂
Rent Servers for Income (picks and shovels strategy)

G Sunny SSC Eights! Points: 988 More actions · Answer 11

Sue_H - Wednesday, October 4, 2017 2:53 PM
G Sunny - Wednesday, October 4, 2017 2:31 PM
Sue,
I checked the password of the account is not locked and not expired, host file is also not edited and the client and server are in same domain, I can see single IP in SQL error logs,
Do i need to check anything on the server where the IP logged in error logs?
Thanks
Sunny
Are the errors all coming from the same IP, client and login? It sounds like that's what you are saying. If that's the case, have you checked the event logs for that IP? Is it a user or an Application server? Have they tried different ways to connect to SQL Server?
Also check the Security event logs on the server where you have the errors. SSPI Handshake errors usually have something in those logs that can give you more information on what the issue it.
If it's always from the same IP then it's likely related to that Server or PC.
Sue

Sue,

We are still not fixed this issue yet, in Domain controller logs we identified one of service account is locked out, we have two domains and same service account names and passwords are different for each,
whenever we logged in to culprit server and stop sql services the account is not locked out. can you please advise how can we identify which particular process or job using wrong account details?
all service account details are correct and services are running but one of the culprit server is using other domain service account.

Thanks
Sunny

Sue_H SSC Guru Points: 90860 More actions · Answer 12

There really should be more in the logs on the servers, active directory, domain controller. It doesn't even sound like anyone really knows what or how something is happening to that account. Have you double checked the Windows security logs on the servers and made sure there really are no logins or login failures for that account anywhere? Not sure which logs you saw the account being locked out but you should be able to find dates and times for those which can help track things down. And a lot more than that.
Unfortunately, sometimes those who have access to getting that information may not look for anything. I'm not sure which server where in this mix is having the issues but there are still things you can do to monitor some of the security issues on the SQL Server side and check for that other domain login.

On SQL Server side, you'd want to have security audits enabled for at least failed logins.
A few things I can think of to check for references to an account in the other domain would jobs and job owners - something like:
SELECT SUSER_SNAME(owner_sid) as JobOwner, [name] as JobName FROM msdb.dbo.sysjobs
You could also check linked servers using something along the lines of :
SELECT s.name as LinkedServerName, s.data_source as LinkedServerSource, CASE WHEN uses_self_credential = 1 THEN 'Use Self' ELSE remote_name END as LinkedServerLogin FROM sys.servers s INNER JOIN sys.linked_logins l ON s.server_id = l.server_id

You could also run an extended events session for login failures. You can refer to this article on setting one up for this purpose:
Use Extended Events to Get More Information About failed SQL Server Login Attempts

But like I said earlier, there would be more information outside of SQL Server somewhere if the account is somehow being locked out and then no longer locked out. You could also query the ring buffers but I'd just check the above and try to track down more information on when and how this account gets locked out, how often it's happening, etc.

Sue