SOAP/REST/ODBC Integrations should use local authentication instead of LDAP to avoid delays by the password validation - Support and Troubleshooting

SOAP/REST/ODBC Integrations should use local authentication instead of LDAP to avoid delays by the password validation Issue When users connect to an instance, ServiceNow authentication follows the Authentication mechanisms available. However, the LDAP authentication could cause additional overhead (for example, some latency between the instance and the LDAP server), especially if the amount of requests are significant on integration users.

The following example uses SOAP UI, for a 'get' operation using /incident.do?SOAP on the very same record.

With a user authenticating with local credentials :

Mon Dec 11 19:21:03 GMT 2017:INFO:Got response for [ServiceNowSoap.get:Request 1] in 208ms (502 bytes) Mon Dec 11 19:21:04 GMT 2017:INFO:Got response for [ServiceNowSoap.get:Request 1] in 211ms (502 bytes) Mon Dec 11 19:23:05 GMT 2017:INFO:Got response for [ServiceNowSoap.get:Request 1] in 209ms (502 bytes) Mon Dec 11 19:24:50 GMT 2017:INFO:Got response for [ServiceNowSoap.get:Request 1] in 210ms (502 bytes) Mon Dec 11 19:27:51 GMT 2017:INFO:Got response for [ServiceNowSoap.get:Request 1] in 213ms (502 bytes) Mon Dec 11 19:29:18 GMT 2017:INFO:Got response for [ServiceNowSoap.get:Request 1] in 209ms (502 bytes)

That is an average of 210 ms. Note the times are consistent.

With a user authenticating via

LDAP server gives a different performance :

Mon Dec 11 20:15:30 GMT 2017:INFO:Got response for [ServiceNowSoap.get:Request 1] in 2034ms (502 bytes) Mon Dec 11 20:15:46 GMT 2017:INFO:Got response for [ServiceNowSoap.get:Request 1] in 719ms (502 bytes) Mon Dec 11 20:15:54 GMT 2017:INFO:Got response for [ServiceNowSoap.get:Request 1] in 685ms (502 bytes) Mon Dec 11 20:18:11 GMT 2017:INFO:Got response for [ServiceNowSoap.get:Request 1] in 927ms (502 bytes) Mon Dec 11 20:19:14 GMT 2017:INFO:Got response for [ServiceNowSoap.get:Request 1] in 3131ms (502 bytes) Mon Dec 11 20:19:40 GMT 2017:INFO:Got response for [ServiceNowSoap.get:Request 1] in 1010ms (502 bytes)

That is an average of 1418 ms. Note the times are not consistent and it has an extra 1208 ms. Note : Some operations will use the authentication cached data. However, after a few minutes, the delay is again visible. You can force the delay by performing a /cache.do on the instance.

You will recognize this problem because: The user record on the sys_user table has the source field defined with value starting with "ldap:" Integrations using this user have a longer response times and, for the same data, times are not consistent. Some inbound integrations like Web Services could timeout even when the instance does not have outages, for example, java.net.SocketTimeoutException: Read timed out. These integrations timing out will not appear on the transaction logs. Integration could show errors of invalid passwords even if the password has not changed or looks valid. You could see 'read timeout' or general timeouts (for example, LDAP: connection timeout) on the instance logs from calls to the LDAP Server, especially from the LDAP monitoring system. Some integrations start queuing up and causing contention on the semaphores available on the API queue from the instance. Cause External authentication requires a call to the external LDAP server to validate the user password. If the connection times out or has a delay, the validation can take up to the timeout set on the LDAP connection properties .

Resolution Ensure that users used on integrations are using local authentication instead of LDAP authentication. If you still want to use a local database, ensure the sys_user.source field is empty or does not start with "ldap:"

Note : Clear the source field and set the user password to start using the local authentication. Also ensure the user is not refreshed by the LDAP server, otherwise, the Source will be reset on the next LDAP update.