Integration user getting locked out repeatedly – REST API calls from SolarWinds failing with “User i

[SunilkumarP1632]

Hi Team,

We are integrating SolarWinds with ServiceNow to create incidents via REST API (Basic Auth). We are facing repeated authentication failures resulting in the integration user getting locked out automatically.

Observed behavior:

REST API calls fail with error: “User is not authenticated / Required to provide Auth information”

SolarWinds UI shows: “Error querying ServiceNow Instance – Instance can be offline or not properly configured”

ServiceNow user audit history shows multiple failed login attempts logged as “Guest”, followed by automatic lockout

Integration user is active and has required roles (itil, etc.)

MID Server is up and healthy (used for other integrations)

Findings:

Failed attempts increment until lockout threshold is reached

Lockout is applied by system security policy

Requests appear to reach ServiceNow but fail authentication

Questions:

What are the common causes for REST API calls being logged as “Guest” and triggering failed login attempts?

Are there any ServiceNow security properties or auth policies that could cause this behavior with Basic Auth?

Is OAuth strongly recommended for SolarWinds integrations to avoid account lockouts?

Any best practices to prevent integration users from repeated lockouts?

Any guidance from similar integration experiences would be appreciated.

Thanks.

[Prathmeshda]

Hello @SunilkumarP1632 
Why REST API calls are logged as “Guest”
When ServiceNow logs failed REST requests as Guest, it usually means authentication credentials were either:

• Not received by ServiceNow at all, or

• Rejected before user resolution occurred

Common causes include:

• Incorrect Basic Auth header formatting (username/password not properly Base64-encoded)

• Special characters in the password not handled correctly by the calling application

• Requests being sent without the Authorization header (often due to proxy, load balancer, or TLS issues)

• Password mismatch due to recent credential rotation not updated in SolarWinds

Once ServiceNow cannot authenticate the request, it processes it as Guest, which still increments failed login attempts and ultimately triggers lockout.

ServiceNow security properties or policies affecting Basic Auth
Yes, several platform controls can influence this behavior:

• System Security → Authentication Policies enforcing stricter authentication rules

• glide.rest.auth.basic (if disabled or restricted)

• IP Access Controls or network ACLs blocking the source IP

• Brute force protection / lockout policies, which apply even to integration users

• Web Service Access Only flag – if enabled incorrectly, it may block UI but still allow REST (misconfiguration here can cause confusion)

OAuth vs Basic Auth
Yes, OAuth 2.0 is strongly recommended for SolarWinds–ServiceNow integrations:

• Prevents password-based lockouts

• Supports token rotation and expiration

• More secure and compliant with ServiceNow best practices

• Avoids failed login accumulation entirely

Best practices to prevent integration user lockouts
We recommend the following:

• Use OAuth 2.0 instead of Basic Auth wherever possible

• Create a dedicated integration user with only required roles

• Exclude integration users from aggressive lockout policies (if allowed by security standards)

• Limit retry attempts on the SolarWinds side

• Monitor syslog_auth and REST logs for early detection

• Validate credentials using a simple REST test (e.g., /api/now/table/sys_user?sysparm_limit=1) before production use
  If this response proves useful, please mark it as Accept as Solution and Helpful. Doing so benefits both the community and me. 👍🙂
  

[Vishal Khandve]

Hi,

Please check password is correct or not? Also inspect the integration calls which is causing the issue.

If all are ok, then you can write the BR(with condition for specific user) to prevent integration getting locked out repeatedly.

var gr = new GlideRecord("sys_user");
gr.addQuery("active", "true");
gr.addQuery("locked_out", "true");
gr.query();
if (gr.next()) {
gr.locked_out=false;
gr.update();
}

Thank you!

Vishal Khandve