How to trace security_error_ring_buffer_recorded errors in SQL Server 2014 Express

Question

Just so everyone doesn't have a high expectation of my level of knowledge on this topic, I'm not a DBA; I'm a .NET developer who has to try and figure this out by virtue of being "the one most likely to be able to figure it out".

We're running SQL Server 2014 Express in Mixed Mode for an e-commerce website, and I've noticed several thousand security_error_ring_buffer_recorded errors in the space of 7 days.

• There aren't any corresponding errors that I can see in any SQL Server or windows logs.
• There are no logs which correlate the session_id and SPIDs.
• There's no information on any particular entry other than the details listed below (and other than the timestamp, session_id, and call stack, they're all identical).
• There are no 139F or 5023 error codes in any logs as well. No State 11 errors, either.
• I don't see either an SQL Server user or a Windows user associated with these entries.
• The SQL Server itself is behind a Windows firewall and only a small number of IPs have access to it (approx. 20, and I can account for all of them). The RDP to the server is restricted to the same IPs.

So my questions are these:

1. Is this something I should be concerned with (I tend to be just given the volume of entries)?

2. How else can I debug these errors to figure out where the underlying problem is?

Thanks.

Answer 1

Take a look on this article: Troubleshooting ImpersonateSecurityContext in RING_BUFFER_SECURITY_ERROR

The error message 5023 details are:

“The group or resource is not in the correct state to perform the requested operation”

According to Microsoft documentation “The ImpersonateSecurityContext function allows a server to impersonate a client by using a token previously obtained by a call to AcceptSecurityContext (General) or QuerySecurityContextToken. This function allows the application server to act as the client, and thus all necessary access controls are enforced.”

Basically this function is called when impersonation is required. To do so, there must already be a valid context handle.

Analyse error logs to identify Login failures and report on the state number.

Some reasons I've spotted are:

1) A service (set as Local System) on a server attempting to log on to SQL Server and not having access

2) IP registered on the DNS server with the same FQDN

You can also check SQL Server error log to check if SPN was successfully registrated.