I have an application monitor set up to monitor SQL server health statistics using a specific query, so I'm using the SQL Server User Experience Monitor component to query SQL servers and return a value. At times the SQL service may not be running so the component just goes critical or down, not a big deal. Our security team noticed a lot of failed login attempt log entries to these servers where the SQL service was not running with the source user as the SolarWinds server name. This seemed odd so I ran a packet capture on the traffic and found that the SQL experience monitor component first tries to connect via standard TCP connection on port 1433 but then when that fails it starts an SMB2 connection and seems to try to query via SMB. I think the issue the security team is seeing is that SolarWinds eventually tries using the server name to authenticate and this is causing all of the failed login attempt logs. See the packet capture below.
Frames 38-85 have been removed as they are just a repeating pattern.
Frame 1-6 SolarWinds trying to open a connection on port 1433
Frame 7 SolarWinds starts an SMB connection, seems to try to do some kind of SQL query throughout the duration of the conversation
Frame 92-94 Looks like the SolarWinds server is trying to do some kind of authentication using the hostname. I think this is the attempt that is causing the failed login attempts logs.
Any idea why this SMB connection is trying to be used? Can it be stopped so that SolarWinds isn't flooding security logs when the SQL server service isn't running?
t