SWIS connection fails with audit event “unsuccessful attempt to log in”

In the SolarWinds Web Console under Events or Audit Events (or within the Orion Web Message Center), administrators may observe high volumes of authentication failure messages:
User admin made an unsuccessful attempt to login from a SolarWinds Information Service endpoint.
or:
User root made an unsuccessful attempt to login from a SolarWinds Information Service endpoint.

If account lockout thresholds are configured in Account Settings, these recurring attempts can cause user accounts (such as the default Admin account) to become locked out:
Account 'Admin' locked out for 15 minute(s) after failing 10 login attempt(s)

When a client connects to the SolarWinds Information Service (SWIS) on TCP port 17777 with invalid credentials, the platform denies authentication and creates an audit event. The audit event does not record the source IP address, so to troubleshoot, you need to capture network packets to match the event time to the client that started the connection.

Step 1: Note the time of the failed logins

1. Log in to the SolarWinds Platform Web Console as an administrator.
2. Go to Audit Events (/Orion/Audit/AuditEvents.aspx).
3. Find the entry “User <username> made an unsuccessful attempt to login from a SolarWinds Information Service endpoint”.
4. Note the date and time of the entries, including seconds and UTC offset.
5. Note how often the entries occur, for example every 5 minutes or every hour.

Step 2: Capture incoming SWIS traffic

1. Log in to the server that hosts the main polling engine. Repeat on each additional polling engine and additional web server if you have them.
2. Install Wireshark or another packet capture tool.
3. Start a capture on the primary network interface shortly before the next expected failed login.
4. After a new audit event appears in the Web Console, stop the capture.

Step 3: Find the source IP address

Apply a display filter in Wireshark that isolates outside traffic targeting SWIS port 17777 and connection resets, excluding internal traffic between SolarWinds servers.

1. In the Wireshark display filter bar, enter the following filter to show external traffic to port 17777 that ends in a connection reset:

   !(ip.src == 192.168.1.10 || ip.src == 192.168.1.11) && (ip.dst == 192.168.1.10 || ip.dst == 192.168.1.11) && tcp.dstport == 17777 && tcp.flags.reset == 1

   Note: Replace the example IP addresses with the addresses of your SolarWinds servers, including the main polling engine, additional polling engines, and additional web servers.

2. Find the packets whose timestamps match the time you noted earlier.
3. Check the source IP address (ip.src) of those packets. This is the client that started the failed SWIS connection.

Step 4: Resolve the issue on the source device

When you have identified the client IP address, complete these steps.

1. On the machine that uses the source IP address, look for:
   • Scheduled tasks that run custom API scripts (PowerShell, Python, or REST/SWIS)
   • Active Network Atlas, SWQL Studio, or other SolarWinds desktop utility sessions
   • Third-party monitoring or ITSM integrations that connect through the SolarWinds Information Service API
2. Update the credentials the machine uses to valid, active credentials.
3. If the connection is decommissioned or unauthorized, stop it and report it to your security team.