Skip navigation

Developer Community

3 Posts authored by: Lalit Kumar Employee

LDAP Integration allows ServiceNow instances communicating with Active Directory (AD). This integration facilitates customers in following:

 

  1. Importing Users/Groups/Roles from AD to ServiceNow instance
  2. Schedule this import so as to keep the data in sync with AD
  3. Authenticate users from AD when login ServiceNow instance

 

Hence, ServiceNow does not store LDAP user’s password as they are authenticated from the AD. ServiceNow instance resides on cloud/on premise and AD is installed on a different server.

 

At times, LDAP connection to AD fails due to whatever reason and no LDAP user is able to login. This leaves a big impact on business and cause a P1 incident. The root cause of this connection failure can be anything like a local network outage in customer area, incorrect LDAP connection attempts post cloning, LDAP credentials change on AD etc.

 

ServiceNow datacenter hosts excellent monitoring tools which polls LDAP test connections in customer instances and if a test connection fails, it generates an alert which in turn generates a high priority incident. Be it an issue on ServiceNow instance side or in a local network on customer side, the major impact is LDAP users cannot login and cannot work unless the issue is fixed.

 

In order to mitigate the impact, ServiceNow has introduced LDAP One Time Password feature from Istanbul release onwards.

 

What is LDAP One Time Password?

 

This is a new feature introduced with ServiceNow Istanbul release assisting LDAP users generating a temporary local password to login ServiceNow when LDAP Server is down. This is available and enabled Out of the Box and requires no plugin activation. It is controlled using below system properties:

 

  1. glide.ldap.onetime.password.enabled - It's a boolean property used to enable/disable this feature
  2. glide.authenticate.onetime.password.validity - It's an integer property indicating temporary password validity in minutes

 

How Does This Feature work?

 

OLD Situation: Login error message when LDAP is unreachable:

Old_Situation.png

Error message on screen: Your account is configured to use LDAP authentication, and we cannot currently connect to the LDAP server. Please contact your ServiceDesk to resolve this issue.

 

New Situation: Login error message when LDAP is unreachable

New_Situation.png

Here is the difference in error message: Your account is configured to use LDAP authentication, and we cannot currently connect to the LDAP server. Please contact your ServiceDesk to resolve this issue. To obtain a password for one-time login, click here. An email message containing the password will be sent to you.

 

User clicks the hyper link click here and platform sends a one-time password to user’s email address for next login as shown in below screen:

Temp_Pass_Gen.png

Behind The Interface In Platform:

  1. When user clicks on link click here, platform generates a one-time password in security_nonce table which can be used once and expires after used.
  2. By default this password is valid for 10 minutes but can be configured with system property glide.authenticate.onetime.password.validity.
  3. Post one-time password generation, platform generates an event password.online.
  4. This event in turn triggers email notification OneTimePasswordEmailNotification.

 

Troubleshooting Tips when user does not receive One Time Password:

  1. Login as an admin and check password.online in event logs.
  2. If event log is there, make sure notification OneTimePasswordEmailNotification is enabled in user profile.
  3. User profile has a valid email address.
  4. Open a Hi incident when you see steps 1 to 3 are OK and user still missing one-time password email.

 

This is a small feature but I find it a great enhancement as it brings down the impact of LDAP user login issue tremendously when LDAP Server is down and generates a big value for ServiceNow customers in terms of business continuity.

 

Resources:

LDAP Integration Setup

LDAP Integration FAQs

LDAP Integration Troubleshooting

Brgds, LK

PS: Hit Like, Helpful or Correct if I was able to assist you

SOAP is one of the available Web Services that the ServiceNow platform offers and supports to integrate your instance (A) with another instance or third-party applications (B) that support SOAP. This post focuses on why and how to debug the SOAP integration when there is any interruption identified. If you are not too familiar with how SOAP integration works in ServiceNow, I highly suggest you take a look at the product documentation before reading ahead: SOAP web service

 

Why and how to debug a SOAP integration

When SOAP debug is enabled, the platform generates additional logs that allow you to see the SOAP transactions, be it inbound or outbound. Let's consider that SOAP integration is set up between instance A and B for the incident management process. Therefore, when an incident (INC00001) is created/updated on the A side, we expect our integration to perform the same on the B side. But what if no such incident is created/updated on the B side? What went wrong?

 

This is where debugging can provide some answers. When inbound SOAP debug is enabled on the B side, you can see the SOAP communication sent by the A side in your logs. When outbound SOAP is enabled on the A side, you can see what SOAP communication was generated on the A side logs and posted towards the B side.

 

Debugging inbound SOAP

Enabling inbound SOAP debug allows you to view the following information:

  • The SOAP message received in a ServiceNow instance
  • Time when the SOAP message was received
  • Whether it includes all the mandatory inputs to insert/update the target record

 

There is a system property glide.processor.debug.soapProcessor of type Boolean type (true/false). If you don’t see this property in your instance, you can create it.

inbound_soap_debug_prop.png

When you set this property value as true, platform will start logging all inbound soap transactions to your instance with source value as SOAPProcessor as shown below:

inbound_soap_debug_logs.png

Debugging outbound SOAP

Enabling outbound SOAP debug allows you to view the following information:

  • The SOAP message sent from ServiceNow instance
  • Time when the SOAP message was sent
  • Whether it includes all the data that your integration party expects

 

Outbound SOAP Envelopes can be seen in two ways:

  1. Using ECC Queue
  2. Generate debug logs using system property

 

There is a system property glide.soap.outbound.debug of type Boolean (true/false). If you don’t see this property in your instance, you can create it.

outbound_soap_debug_prop.png

When you set this property value as true, the platform will start logging all outbound SOAP transactions in system logs, which can be seen from a related instance node using one of following log utilities:

  • System Logs > Utilities > Node Log File Download

 

2017-07-12 05:16:04 (117) Default-thread-25 E81F6F5F4F73B200826B098D0210C7A2 DEBUG: SOAP Msg Outbound - SOAPMessageClient : Executing synchronous request
2017-07-12 05:16:04 (117) Default-thread-25 E81F6F5F4F73B200826B098D0210C7A2 DEBUG: SOAP Msg Outbound - SOAPMessageClient : Prepared requestBody for soap request:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap
/envelope/" xmlns:u="http://www.service-now.com/u_incident">
   <soapenv:Header/>
   <soapenv:Body>
      <u:insert>
         <active>true</active>
         <comments></comments>
         <short_description>Performance problems with CPU</short_description>
                 <description></description>
                 <correlation_id>SOAPINT00002</correlation_id>
                 <number>INC0020003</number>
      </u:insert>
   </soapenv:Body>
</soapenv:Envelope>
  • System Logs > Utilities > Node Log File Browser

outbound_soap_debug_logs.png

 

This is how SOAP debug assists in investigating issues and answering these questions:

  • Was the SOAP message sent successfully from the A side?
  • Was the SOAP message sent from the A side reached successfully on the B side?

Note: Enabling SOAP debug adds extra logging in system logs, but it helps and does not impact your instance performance, so you can decide whether to leave it active or enable it on demand. Just keep in mind that when you enable it on demand, it requires reproducing the issue again after enabling.

Related Links:

Brgds, LK

PS: Hit Like, Helpful or Correct if I was able to assist you

There are situations when your ServiceNow instance is up and operational but your users still cannot log in because they don't see the login page asking for a username and password. This article covers one of such situations where a user accesses a ServiceNow instance and, instead of the login page, the user is redirected to session_timeout.do. This redirection keeps on running in an infinite loop and you never see the login page.

 

Let's say your instance URL is https://instance.service-now.com and when you access it, you get redirected to https://instance.service-now.com/session_timeout.do infinite loop. This looks something similar to below image.

 

session_timeout.jpg

 

Troubleshooting the session timeout loop when logging in

When I began investigating this issue, my first attempt was to access the instance using side_door.do or let's say login.do to check if the default login displays. I was relieved to say, yes it does. As a workaround, users can access their instance using a suffix of login.do (https://instance.service-now.com/login.do) and bypass this issue. Now, Let's move further and look into this, ask ourselves what is it that is causing this issue and how to fix it.

 

Is the loop SSO related?

First I checked if Multi Provider SSO or old SAML plugin is enabled in the instance by verifying below system properties quickly:

 

Results from Multi Provider SSO: glide.authenticate.multisso.enabled

Results from SAML plugin: glide.authenticate.external

 

Both of the system properties appeared as false, which confirms this is not SSO related.

 

What can the transaction logs tell us?

Accessing an instance is also a type of transaction; therefore, I decided to check Transaction Logs where I see multiple transactions with below URLs one after another:

 

/nav_to_do?uri=welcome.do

/session_timeout.do

 

Transactions keep on generating as long as your browser is open because of infinite looping. In logs, I can see the related session as well as the node name. I checked the system logs considering Transaction Logs creation timings for keywords navpage.do and session_timeout.do transaction and this is what I see:

 

2017-07-07 14:25:27 (454) http-23 New transaction 3613CCCEDB73F2004159F37EAF96198D #25515 /navpage.do
2017-07-07 14:25:27 (460) Default-thread-57 3613CCCEDB73F2004159F37EAF96198D #25515 /navpage.do Parameters -------------------------
2017-07-07 14:25:27 (460) Default-thread-57 3613CCCEDB73F2004159F37EAF96198D *** Start  #25,515, path: /navpage.do, user: guest
2017-07-07 14:25:27 (479) Default-thread-57 3613CCCEDB73F2004159F37EAF96198D Memory transaction: 2mb total: 275mb free: 52%  Allocated: 571mb
2017-07-07 14:25:27 (479) Default-thread-57 3613CCCEDB73F2004159F37EAF96198D *** End  #25,515, path: /navpage.do, user: guest, total transaction time: 0:00:00.025, transactio
n processing time: 0:00:00.025, network: 0:00:00.000, chars: 13, uncompressed chars: 13, SQL time: 12 (count: 5), business rule: 0 (count: 0), phase 1 form length: 0, largest
 chunk written: 0, request parms size: 40, largest input read: 0

2017-07-07 14:25:27 (547) http-21 New transaction 3613CCCEDB73F2004159F37EAF96198D #25516 /sp/
2017-07-07 14:25:27 (552) Default-thread-55 3613CCCEDB73F2004159F37EAF96198D #25516 /sp/ Parameters -------------------------
    id=login
2017-07-07 14:25:27 (554) Default-thread-55 3613CCCEDB73F2004159F37EAF96198D #25516 /sp/ -- total transaction time: 0:00:00.000, transaction processing time: 0:00:00.000, tot
al wait time: 0:00:00.000, session wait: 0:00:00.000, semaphore wait: 0:00:00.000, source: 86.90.145.21, chars: 0, uncompressed chars: 0, SQL time: 1 (count: 3), business rul
e: 0 (count: 0), phase 1 form length: 0, largest chunk written: 0, request parms size: 64, largest input read: 0

2017-07-07 14:25:27 (631) http-28 New transaction 3613CCCEDB73F2004159F37EAF96198D #25517 /session_timeout.do
2017-07-07 14:25:27 (708) Default-thread-57 3613CCCEDB73F2004159F37EAF96198D #25517 /session_timeout.do Parameters -------------------------
2017-07-07 14:25:27 (708) Default-thread-57 3613CCCEDB73F2004159F37EAF96198D *** Start  #25,517, path: /session_timeout.do, user: guest
2017-07-07 14:25:27 (721) Default-thread-57 3613CCCEDB73F2004159F37EAF96198D [0:00:00.012] getRealForm
2017-07-07 14:25:27 (726) Default-thread-57 3613CCCEDB73F2004159F37EAF96198D Memory transaction: 4mb total: 281mb free: 51%  Allocated: 571mb
2017-07-07 14:25:27 (726) Default-thread-57 3613CCCEDB73F2004159F37EAF96198D *** End  #25,517, path: /session_timeout.do, user: guest, total transaction time: 0:00:00.095, transaction processing time: 0:00:00.095, network: 0:00:00.000, chars: 6,023, uncompressed chars: 20,143, SQL time: 4 (count: 11), business rule: 0 (count: 0), phase 1 form length: 52,115, largest chunk written: 9,636, request parms size: 40, largest input read: 0

 

Log statements 09 to 14 in above logs explains that Service Portal execution is happening immediately after navpage.do which then leads to session_timeout.do.

 

The id=login is referring to Service Portal Login page which is not public. The private portal page causes the login attempt to time out on a loop. When I enable public is true for the Login page, the issue no longer appears. If setting the page to public does not help, kindly check the following:

 

  1. There must be an active record for page $sp in sys_public record list.
  2. Check system property glide.entry.page.script value and related script includes which should use this login page.

 

Out of the Box, System property glide.entry.page.script value is new CMSEntryPage().getEntryPage() but you can always replace it based on your business requirements.

 

Hope this helps!

 

For more information:

Transaction Logs

6 ways to set up your Service Portal for redirection SUCCESS!

Brgds, LK

PS: Hit Like, Helpful or Correct if I was able to assist you

Filter Blog

By date: By tag: