Issue ingesting multiple affected users using Azure Sentinel Incident Ingestion Integration

[guythompson]

Hi

We're having a bit of trouble adding multiple affected users into SIR tickets using the Azure Sentinel Incident Ingestion Integration. We are able to ingest Sentinel Account entities (${Account: properties(displayName)}$) using a simple glide get query to find the username of the email address ingested but when we create a script using a for loop to make multiple queries no outputs in the destinationValue field are found. The script has been tested elsewhere in ServiceNow and works but doesn't seem to work in the integrations field translations. See current query below:

var usernamearray = [];

var affectedUser = "";

if(sourceValue != ""){

    splitvalues = sourceValue.split(", ");

    for (i in splitvalues){

    var gr = new GlideRecord('sys_user');

    gr.get('user_name', splitvalues[i]);

    usernamearray[i] = gr.sys_id;

    }

    affectedUser = usernamearray.join(", ");

}

destinationValue = affectedUser;

Any help would be appreciated.

[ShalluM]

Thanks for suggestion. I tried the logic that you have mentioned in sentinel field translation and also did the changes in AzureSentinelMappingUtils "evaluator.withEnforcedSecurity(false);"

However, I am still not getting the expected result.

To fix this issue, I did additional changes and wrote a logic to handle the user_id from ${Account: properties(additionalData(accountName))}$, something like below code in AzureSentinelMappingUtils.

if(destTable=='sys_user' && destination == "affected_user"){

searchGr = new GlideRecord('sys_user');

searchGr.addQuery('user_name', inputValue);

searchGr.setLimit(1);

searchGr.query();

if (searchGr.next())

result.refUniqueId = searchGr.getUniqueValue();

return result;}

with this I am getting the affected user values correctly. However, don't want to change the OOTB script include.

But if we need to change this evaluator.withEnforcedSecurity(false); line of code, to execute field translation script, then this will also be counted as customer update.  Please share your opinion.

[AJ_UK]

Hi @ShalluM 

The logic you are applying in both scenarios appears sound ie to convert from the user_name to the sys_id.

The challenge, I agree, is that somewhere a GR to sys_user is required to fetch a sys_id:

Either

1. In order to allow the GR to work from the Translation script we have to modify the EnforcedSecurity boolean - which is counted as a customer update.

Or

2. In order to add a method to the Mapping Utils to do the equivalent , it is also is counted as a customer update.

The default Display Value for sys_user is the name field (which is unlikely to be unique if it is actual names or Firstname Surname) so this can't be used for mapping

The only other option is to change in sys_user Table, for the field that contains the incoming unique reference value, and mark it's property of 'Display' as being 'true', however this is a Global change.

The final option (which would also be a 'customer update' to Mapping Utils!) would be to change the very final part of the method '_getDisplayField' where it looks for some 'defaults' and add the field name that you are using in the list of field names.

Any which way, we're a bit stuck between a rock and a hard place for achieving successful mapping without a 'customer update' of some sort.

It could do with a sys_property of the Field to use for affected_user mapping if you ask me.

I hope that is helpful, even if it doesn't 'solve' the exact problem, but gives a few options. AJ

[AJ_UK]

@guythompson @ShalluM @WiproG @prit123 , and anyone else who has/is also struggling with Affected User Mapping

I have created an 'Idea' in the Idea portal:

ServiceNow Idea Portal: Azure Sentinel affected_user Mapping Field sys_property 

To request a sys_property where the sys_user field that holds the matching incoming unique values can be defined, which would remove the necessity for GlideRecords, or customer updates to the ScriptIncludes.

Please Upvote if you can.

[WiproG]

Hi @AJ_UK  I also tried to update method '_getDisplayField by adding "user_name". However, it still don't worked for me. In logs, it was always checking for name (note: No display field set for sys_user). Finally, I am able to fix this issue by adding custom code in mappingutils. Now, I am using ${Account: properties(additionalData(MailAddress))}$ to get the correct user profile.

Indeed, ServiceNow should provide some option to map the required field without custom updates in OOTB script. Voted for the idea.