Create domain-separated imports for an integration

If you require imported data to be in a specific domain, the user assigned to run the integrations must belong to that domain.

Before you begin

Role required:

import_admin and the configure integration role for your specific integration, for example, sn_vul.configure_r7_integration or sn_vul_tenable.configure_integration.

About this task

This set of tasks requires coding or advanced ServiceNow expertise.

The import queues contain data attachments that the scheduled jobs (integrations) process. In a domain-separated environment, you must match the scheduled job with the correct import queue.

Procedure

1. Create a domain.

2. For every domain you create, create a user and assign the user to that domain.

   Think of this user as a run_as placeholder for the domain in your vulnerability integration. It is the equivalent to the VR.System user in the global domain. This user needs access to data sources, transform maps, and vulnerability data.

   Note: Do not use this user for any other purpose.

3. Create a scheduled job in each domain.

   For more information on additional precautions and settings, see Additional settings for domain separation.

   1. Navigate to All > System Definition > Scheduled Jobs.

   2. Copy Scheduled Vulnerability Data Source Processor into the domain.

   3. To identify the scheduled job, append the domain to the name.

4.  In the **Run as** field, change the **run\_as** user to the user you created in the Step 2.

Starting from v20.1 of Vulnerability Response, the following script changes are shipped with the base system.

1. Note: Edit the following UI action so that the integration runs in the run_as user domain.

   Edit the Execute Now UI action in the Qualys Host Detection Integration integration job to add this code block to the top of the file.

   //sys id below is of host detection integration
   if(current.sys_id == "5d9cf0daff540300c68c9f783894fa4d"){
   current.run_as = gs.getUserID
   ();
   }
   

2. Note: Edit the following script includes so that integration run in the run_as user domain.

   Edit the VulnerabilityIntegrationUtils script include method addIntegrationRun to add the highlighted code

1. Edit the VulnerabilityIntegrationUtils script include method, addProcessRun to add the highlighted code in the following image.

   addProcessRun code

1. Edit the VulnerabilityIntegrationUtils script include method, copyProcess to add the highlighted code in the following image.

   copyProcess code

1. Edit the DataSourceVulnReportRefreshProcessor script include method _processFromDataSourceGroups to change this original code:

   Original _processFromDataSourcesGroups code

To:

Edited \_processFromDataSourcesGroups code

1. Edit the VulnerabilityDSAttachmentManager script include method, queueItem to add the following highlighted code blocks

   queueItem

\_getNext

\_processQueueEntry function

At this point, you are ready for domain-separated imports.

**Note:** If you have multiple deployments of a Vulnerability Response or Application Vulnerability Response integration, repeat this process for each deployment.

• Create and support multiple domains in the background jobs framework
  Background jobs in vulnerability response products are designed to run for long periods of time to perform multiple processes on your records. The background job processors are shipped with the base system that run via the system user and create records in the global domain.

Parent Topic:Advanced Vulnerability Response configuration tasks