161 views

Integrations should use local authentication instead of LDAP to avoid delays by the password validation

Problem

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:

 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.

 

Symptoms

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:"

Clear the source and set the password to avoid LDAP authentication

Note: Clear the source field and set the user password to start using the local authentication.

 

 

Article Information

Last Updated:2017-12-13 01:12:40
Published:2017-12-13