Domain separation and Microsoft Azure Sentinel integration
Summarize
Summary of Domain separation and Microsoft Azure Sentinel integration
This application supports domain separation, enabling ServiceNow customers to logically segment data, processes, and administrative tasks into distinct domains. This ensures controlled access and visibility tailored to different user groups or tenants. Domain separation operates at runtime, affecting the user interface, cache keys, reporting, rollups, and data aggregations.
Show less
Regarding the Microsoft Azure Sentinel integration, Microsoft has extended the deprecation of the Azure Sentinel experience in the Azure portal to March 2027. Customers currently using Azure Sentinel integration with Security Incident Response (SIR) are strongly advised to migrate to the new Defender portal integration. This new integration provides a built-in migration utility that converts existing Sentinel profiles to Defender profiles, maintaining incident continuity after migration.
Key Features
- Domain Separation Setup: Allows service providers to separate tenant data and interactions, such as chat responses, ensuring customers see the correct information within their domain.
- Role-Based Access: Requires creating users with the
snsi.adminrole within each domain using the domain picker at profile creation to manage Azure Sentinel profiles and settings correctly. - Scheduled Job Replication: Scheduled jobs related to Azure Sentinel (e.g., fetching alerts, syncing comments, status updates, data processing, and cleanup) must be disabled and then replicated per domain.
- Run As Configuration: Scheduled jobs should be configured to run as the domain-specific user with the
snsi.adminrole rather than the system user to maintain domain separation integrity.
Practical Considerations for ServiceNow Customers
- Ensure the instance owner configures domain separation properly to support multi-tenant scenarios and maintain data isolation across domains.
- When creating administrative users for Azure Sentinel integration, always select the correct domain at creation; avoid changing domains after creation.
- Migrate from Azure Sentinel integration to Defender portal integration promptly to comply with Microsoft’s extended deprecation timeline and benefit from the migration utility.
- Replicate and configure all Azure Sentinel scheduled jobs per domain to ensure consistent data processing and synchronization within each domain.
Domain separation is supported for this application. Domain separation enables you to separate data, processes, and administrative tasks into logical groupings called domains. You can control several aspects of this separation, including which users can see and access data.
Microsoft has extended the deprecation of the Azure Sentinel experience in the Azure portal from March 2026 to March 2027.
If you are currently using the Azure Sentinel integration with Security Incident Response (SIR), we strongly recommend migrating to the new Defender portal integration as soon as possible. The Defender integration includes a built-in migration utility that automatically converts your existing Sentinel profiles into Defender profiles, while ensuring continuity of incidents created through Sentinel after the transition. For more information, see Microsoft Sentinel to Defender Migration Guide.
Support level: Basic
- Business logic: Ensure that data goes into the proper domain for the application’s service provider use cases.
- The application supports domain separation at run time. The domain separation includes separation from the user interface, cache keys, reporting, rollups, and aggregations.
- The owner of the instance must set up the application to function across multiple tenants.
Sample use case: When a service provider (SP) uses chat to respond to a tenant-customer’s message, the customer must be able to see the SP's response.
For more information on support levels, see Application support for domain separation.
How domain separation works in the Microsoft Azure Sentinel integration
- Create a user with the sn_si.admin role in the respective domain. Note:When you create the profile, use the domain picker to select a domain. Do not create the user in the parent domain and later change the domain of the profile. You should have a user for each domain for your profile with the sn_si.admin role. Use this user to create or modify settings in the profile.
- Disable existing scheduled jobs.
- Replicate the following scheduled jobs for every domain:
- Azure Sentinel Fetching Alerts & Entities
- Azure Sentinel Comments Sync
- Azure Sentinel Status Update
- Azure Sentinel Profile Process
- Azure Sentinel Process Raw Data
- Azure Sentinel Data Cleanup
- Azure Sentinel Historic Comment Pull
- Change the Run as from the system user to the user with the sn_si.admin role in the respective domain and then run the scheduled job.
The following example shows how to replicate the Azure Sentinel comments and Status update job and run the job as a system user.