Sspi handshake failed with error code 0x80090311

SSPI handshake failed with error code 0x80090311, 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. No authority could be contacted for authentication.

Login failed. The login is from an untrusted domain and cannot be used with Windows authentication

A handful of my SQL Servers began losing connecting with the domain controllers after recent Windows Patches.  The only resolution was a reboot of the SQL Server, which obviously incurred downtimes.  The issue hit two non-production VMs and also a Windows SQL Server Cluster.  Oddly, both nodes in the cluster were affected simultaneously, even though SQL wasn’t running on the passive node.  After some troubleshooting with Microsoft, we identified the issue and I wanted to share it here.  A fix is pending, targeted for July.

The issue affects Windows Server 2012 OSes utilizing iSCSI storage and was introduced with KB4012216, a March security roll-up.  The total amount of ephemeral ports on the system becomes exhausted over time.  I won’t spend too much time showing you how to isolate the specific data we collected for Microsoft.  I feel that if you are experiencing this issue after a recent application of patches, and you are running Server 2012 with iSCSI, that is probably proof enough.

UPDATE:  We observed this behavior on servers not using iSCSI, but iSCSI was still enabled and causing the problem.  We also found corresponding Event IDs 4227 in the System log.

TCP/IP failed to establish an outgoing connection because the selected local endpoint was recently used to connect to the same remote endpoint. This error typically occurs when outgoing connections are opened and closed at a high rate, causing all available local ports to be used and forcing TCP/IP to reuse a local port for an outgoing connection. To minimize the risk of data corruption, the TCP/IP standard requires a minimum time period to elapse between successive connections from a given local endpoint to a given remote endpoint.

You can view some details about ports in use with the following commands, the first being a PowerShell command:

1Get-Nettcpconnection | Group-Object -Property State, OwningProcess | Sort Count 
2netstat -anoq

There is no permanent solution, but the following are options for workarounds until a patch is released.

1. The most obvious would be to uninstall the patches.  We uninstalled all 3 roll-up patches that we applied, but Microsoft indicates that it is part of KB4012216.
2. You can stop using iSCSI.  Not a viable solution for most.

Increase the number of available TCP ephemeral ports and modify TCP Time Wait Delay to increase the time it takes for the issue to manifest.  Type the following from a command line prompt and restart the server:

1netsh int ipv4 set dynamicport tcp start=1025 num=64500
2reg add HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters /v TcpTimedWaitDelay /t REG_DWORD /d 0x0000001E /f

I hope you are able to use this information to fix any recurring issues you’ve experienced in your environments.  I spent the last 3 or 4 nights rebooting SQL Servers after hours, but not tonight!

Sspi handshake failed with error code 0x80090311

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Answered by:

Question

Error: 17806, Severity: 20, State: 2.
SSPI handshake failed with error code 0x80090311 while establishing a connection with integrated security; the connection has been closed. [CLIENT: 1.2.3.4]

Error: 18452, Severity: 14, State: 1.
Login failed for user ». The user is not associated with a trusted SQL Server connection. [CLIENT: 1.2.3.4]
Error: 17806, Severity: 20, State: 2.

SSPI handshake failed with error code 0x80090311 while establishing a connection with integrated security; the connection has been closed. [CLIENT: 1.2.3.4]

Error: 18452, Severity: 14, State: 1.
Login failed for user ». The user is not associated with a trusted SQL Server connection. [CLIENT: 1.2.3.4]

Error: 17806, Severity: 20, State: 2.
SSPI handshake failed with error code 0x80090311 while establishing a connection with integrated security; the connection has been closed. [[CLIENT: 1.2.3.4]

This computer was not able to set up a secure session with a domain controller in domain XXX due to the following:

The remote procedure call was cancelled.

This may lead to authentication problems. Make sure that this computer is connected to the network. If the problem persists, please contact your domain administrator.

If this computer is a domain controller for the specified domain, it sets up the secure session to the primary domain controller emulator in the specified domain. Otherwise, this computer sets up the secure session

Источник

sspi handshake failed with error code 0x80090311

I was configuring a new server as a 2019 Domain Controller to replace a 2008 R2 one. In addition I have two other DC’s for a total of 3. All in different sites.

One with all FSMO roles which is what is referred to as PDC back in the day running 2012 R2. The other running Windows Server 2019 and now the new one that I mentioned above that replaced the 2008 R2 also running 2019.

The problem I ran into is that I forgot to raise the domain functional level from 2008 R2 to 2012 R2 before I demoted it. Once that happened I started to receive errors from a couple of servers regarding the SSPI handshake and after researching this, I found that it’s most likely or I can honestly say it’s probably close to 100% that what I did caused this error.

So, I took the same server and brought it back to 2008 R2 Domain Controller status but what’s weird is that even prior to completing this task, the errors seemed to stop. but accessing some of our applications didn’t work until I fully brought it back.

My goal is to raise the domain functional level to 2012 R2 then test to make sure that the new DC in that site works for authentication of the SQL and application servers running there. I was wondering if shutting down the 2008 R2 DC temporarily and monitoring to make sure no errors are thrown is a good way to make sure my environment is ready to demote the 2008 R2 DC once and for all?

I appreciate any help I can get and thanks in advance!

Источник

Sspi handshake failed with error code 0x80090311

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Asked by:

Question

Yesterday, all of a sudden, I received 15 alerts from my sql2k8 R2 64bit with the same content as follows:

DATE/TIME: 9/27/2010 8:54:01 PM

DESCRIPTION: SSPI handshake failed with error code 0x80090311, 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: ].

How can this be troubleshooted. I can access my sql withoiut any problem through sharepoint or SSMS.

Thqnlks in advance

I just checked eventviewer, security log and found 7 scurity failure for a user running a service for almost more than 1 year withoiut no issues which is a user to run Biztalk services and has full domain rights to access sql, otherwise my Biztalk would have never worked. How can this be tracked if it happens again.

Uereunder the log :

Log Name: Security
Source: Microsoft-Windows-Security-Auditing
Date: 9/27/2010 8:54:05 PM
Event ID: 4625
Task Category: Logon
Level: Information
Keywords: Audit Failure
User: N/A
Computer: mysql2k8.mydomain.net
Description:
An account failed to log on.

Subject:
Security ID: NULL SID
Account Name: —
Account Domain: —
Logon ID: 0x0

Account For Which Logon Failed:
Security ID: NULL SID
Account Name: btsuserrun
Account Domain: SALAM

Failure Information:
Failure Reason: An Error occured during Logon.
Status: 0xc000018d
Sub Status: 0x0

Process Information:
Caller Process ID: 0x0
Caller Process Name: —

Network Information:
Workstation Name: BTS2K9
Source Network Address: —
Source Port: —

Detailed Authentication Information:
Logon Process: NtLmSsp
Authentication Package: NTLM
Transited Services: —
Package Name (NTLM only): —
Key Length: 0

This event is generated when a logon request fails. It is generated on the computer where access was attempted.

The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).

The Process Information fields indicate which account and process on the system requested the logon.

The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.

The authentication information fields provide detailed information about this specific logon request.
— Transited services indicate which intermediate services have participated in this logon request.
— Package name indicates which sub-protocol was used among the NTLM protocols.
— Key length indicates the length of the generated session key. This will be 0 if no session key was requested.
Event Xml:

Источник

Sspi handshake failed with error code 0x80090311

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Answered by:

Question

I get this error and i know it comes from my Linux server in an IPA domain.

Error: SSPI handshake failed with error code 0x80090311

But i want to trust this connection. How do i do this?

Answers

0x80090311 error refers to «No authority could be contacted for authentication» which means the user cannot contact AD to get a ticket. I suggest turning on Kerberos logging and using Netmon to trace the authentication routes. You can find detailed info on how to troubleshoot Kerberos here.

There are probably some network issue on your system and you lost the connectivity to AD from time to time. Please let your network administror investigate any possible network issue.

Hope the below threads could be helpful for you:

Источник

Sspi handshake failed with error code 0x80090311

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Asked by:

Question

Yesterday, all of a sudden, I received 15 alerts from my sql2k8 R2 64bit with the same content as follows:

DATE/TIME: 9/27/2010 8:54:01 PM

DESCRIPTION: SSPI handshake failed with error code 0x80090311, 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: ].

How can this be troubleshooted. I can access my sql withoiut any problem through sharepoint or SSMS.

Thqnlks in advance

I just checked eventviewer, security log and found 7 scurity failure for a user running a service for almost more than 1 year withoiut no issues which is a user to run Biztalk services and has full domain rights to access sql, otherwise my Biztalk would have never worked. How can this be tracked if it happens again.

Uereunder the log :

Log Name: Security
Source: Microsoft-Windows-Security-Auditing
Date: 9/27/2010 8:54:05 PM
Event ID: 4625
Task Category: Logon
Level: Information
Keywords: Audit Failure
User: N/A
Computer: mysql2k8.mydomain.net
Description:
An account failed to log on.

Subject:
Security ID: NULL SID
Account Name: —
Account Domain: —
Logon ID: 0x0

Account For Which Logon Failed:
Security ID: NULL SID
Account Name: btsuserrun
Account Domain: SALAM

Failure Information:
Failure Reason: An Error occured during Logon.
Status: 0xc000018d
Sub Status: 0x0

Process Information:
Caller Process ID: 0x0
Caller Process Name: —

Network Information:
Workstation Name: BTS2K9
Source Network Address: —
Source Port: —

Detailed Authentication Information:
Logon Process: NtLmSsp
Authentication Package: NTLM
Transited Services: —
Package Name (NTLM only): —
Key Length: 0

This event is generated when a logon request fails. It is generated on the computer where access was attempted.

The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).

The Process Information fields indicate which account and process on the system requested the logon.

The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.

The authentication information fields provide detailed information about this specific logon request.
— Transited services indicate which intermediate services have participated in this logon request.
— Package name indicates which sub-protocol was used among the NTLM protocols.
— Key length indicates the length of the generated session key. This will be 0 if no session key was requested.
Event Xml:

Источник

Error: 18452, Severity: 14, State: 1 is a notoriously difficult SQL Server error code to troubleshoot.  If associated with  Error: 17806, Severity: 20, State: 2  , another layer of complication is added.  A typical combination of these error codes would appear in the SQL Server Error Log , such as :

Login failed for user ''. The user is not associated with a trusted SQL Server connection. [CLIENT: xxxxxxx]
Error: 17806, Severity: 20, State: 2.
SSPI handshake failed with error code 0x80090311 while establishing a connection with integrated security; the connection has been closed. [CLIENT:xxxxxx]
Error: 18452, Severity: 14, State: 1.

• Breaking these codes down into smaller parts helps the troubleshooting process
• Error: 18452, Severity: 14, State: 1 — The login may use Windows Authentication but the login is an unrecognized Windows principal. An unrecognized Windows principal means that Windows can’t verify the login. This might be because the Windows login is from an untrusted domain.
• Error: 17806, Severity: 20, State: 2 (0x80090311) — 0x80090311 error  refers to «No authority could be contacted for authentication» which means the user cannot contact Active Directory to get a ticket.

• Troubleshooting this error code in different environments, these are some patterns. It may provide some context for troubleshooting
• The client is having issues communicating with the domain controller.. In this situation , an immediate fix maybe to restart the client . If it doesn’t solve the problems – network support is your next call. Read How to list Domain Controllers in a Domain with nltest , this will guide you how to create a list of domain controllers available
• Between trusted domains, both networks are having issues communicating between each other. Contact network support
• Network is under heavy load. Start an investigation to identify the source of extra load and decrease load or increase capacity.
• This set of errors indicates to not being able to reach a domain controller to login. The error appears because the domain controller cannot pass the Kerberos token to the process to use in the SSPI part

Read More

Routing OSPF and Network Team

SQL Server – netstat monitoring and tuning performance

Author: Tom Collins (http://www.sqlserver-dba.com)

Share: