Hi @elcuchi , Ok, I use basic auth instead of OAUTH so different scenario, OAUTH was not available on our first tested TA versions and we never moved away from it (which I should prioritize now). Di...
See more...
Hi @elcuchi , Ok, I use basic auth instead of OAUTH so different scenario, OAUTH was not available on our first tested TA versions and we never moved away from it (which I should prioritize now). Did you test basic or that is not an option? Thing is, for basic auth: Whenever you configure the ServiceNow account in the TA, you'll have to pass that account as parameter for the ServiceNow action commands OR reference it in the alert action (it is the first field it asks you to fulfill). That is the account the TA will use to open the REST connection with ServiceNow and push the data there (either event or incident). AFAIK, there is no configuration on the TA that uses the actual Splunk logged in user in the authentication context to ServiceNow to trigger those actions. Behind the scenes, every communication is done via the account configured in the TA, at least this is how it works for me while using this TA for the past 4-5 years. So, question: How are you testing this? (Based in your "when we test the creation of an incident from splunk interface" statement) For OAUTH it may be different, but according to the documentation I don't think it actually is. Documentation says that Oauth requires UI access to SNOW instance, which you mentioned you don't have: OAuth Authentication configuration requires UI access to your ServiceNow Instance. User roles that do not have UI access will not be able to configure their ServiceNow account to use OAuth. If this is using the person logged in to access ServiceNow instead of using whatever OAUTH config, it makes no sense for the TA to ask clientID and clienteSecret as the main purpose for those is to authenticate.