I've tried to create an incident in Service-Now using Splunk add on for Servicenow.
This failed when it tried to get the password to Service-Now.
127.0.0.1 - user [23/Mar/2019:05:02:53.239 +0100] "GET /servicesNS/nobody/SplunkTAsnow/storage/passwords/https%5C%3A%252F%252Fservicenow instance%3Adummy%3A HTTP/1.0" 403 228 - - - 0ms
How do I make this URL available, so it is possible to create incidents?
Have you installed the Integration application into your Service Now tenant?
This configures the relevant permissions and update sets so the integration can work - you are getting a 403, which might suggest the permissions are not yet configured correctly (or the credentials are incorrect)
Yes, the ServiceNow integration is installed and configured.
The problem is not on the ServiceNow side, it is on the Splunk side.
This is URL that has the problem:
GET /servicesNS/nobody/SplunkTAsnow/storage/passwords/https%5C%3A%252F%252Fservicenow instance%3Adummy%3A
Called with https://127.0.0.1:8089, as the host
Just checking - do you have proxy servers? A similar issue came up the other day where requests were being proxied - the proxy was requesting the resource from 127.0.0.1 (itself) instead of the Splunk server where the request originated.
No, no proxy.
For me it looks like the alert-script is requesting the credentials to Service-now from the Splunk-ta-snow app with the searchs user, and gets a http request denied.
Assuming you are on a linux system and have access to the service Now API to create ticket/incident, would you be able to run a curl command using the creds (configured in the add-on) to create a ticket? if it works, its likely that 'user' making the call to passwords/username stored SplunkTAsnow/local is unable to get the correct creds [. You may want to delete files under local, restart the instance, ensure there is no stale contents in Comfiguration->General -> Credential management and re-configure the app.
I'm on a windows system.
It is spot on, that the 'user' making the call to passwords/username stored in SplunkTAsnow is unable to get the correct creds. The user making the call gets a HTTP returncode 403, when they try to call /servicesNS/nobody/SplunkTAsnow/storage/passwords/
So Splunk is preventing the 'user' from getting the passwords. I don't think that is done by ACLs on the filesystem.
Sometimes it helps to try to do the request instead of just looking, at the logs.
I was missing the liststoragepasswords capability in the roles.