Domain Separation and Discovery
Summarize
Summary of Domain Separation and Discovery
Domain separation in Discovery enables ServiceNow customers, especially Service Providers (SPs), to segregate data, processes, and administrative tasks into logical groupings called domains. This separation controls user access and visibility, ensuring that users see only data pertinent to their domain or child domains. The SP typically manages the top-level domain, with visibility across all domains, while child domains do not have delegated administrative control. Discovery supports domain separation at a Standard support level, meaning configuration and business logic accommodate multiple tenants within a single instance.
Show less
How Domain Separation Works in Discovery
- A single MID Server can support multiple domains, enabling efficient domain segregation. Prior to the Kingston release, MID Servers supported only a single domain.
- Discovered Configuration Items (CIs) are assigned domains based on the MID Server user or, in multi-domain MID Servers, the user who schedules Discovery, maintaining accurate domain assignment.
- The MID Server impersonates its user during sensor processing to determine the correct domain for discovered data.
- Discovery configuration components such as classifiers, identifiers, probes, and sensors are not domain-separated.
- SPs commonly use IP-based Discovery, assigning distinct IP subnets per customer/domain to prevent overlap and maintain domain data isolation.
- In cases of overlapping IP address spaces, Network Address Translation (NAT) can be used to manage Discovery schedules without domain conflicts.
- Visibility of Discovery schedules is limited to users within their domains, except the SP with parent domain access who can see all schedules.
Domain Separation for MID Server Files
- MID Server policy files (MIB, JAR, Script Files) can be domain-separated by creating domain-specific versions of these records, restricting usage to MID Servers within the same domain.
- By default, these files belong to the global domain but can be overridden per domain as needed.
- Attachments on MIB or JAR files may not appear as expected due to attachment table domain separation, which restricts cross-domain access.
- Instructions for setting up domain separation through the MID Server are available to assist configuration.
Domain-Separated Tables
Records in all tables extending the Base Configuration Item (cmdb) table are domain-separated, including specialized tables such as Serial Number, TCP Connection, Fibre Channel Initiator/Targets, IP Address to DNS Name, Services, KVM Devices, Load Balancer VLAN interfaces, and Switch Ports. This ensures consistent data segregation across discovered and related CI data.
Configuring Domain-Separated Discovery Schedules
Setting the "Run as" user in Discovery schedules is critical to assigning discovered CIs to the correct domain, thereby maintaining data isolation. The chosen user’s domain determines the domain assignment of the discovered data.
Practical Benefits for ServiceNow Customers
- Enables secure multi-tenant environments by isolating customer data within a shared instance.
- Allows Service Providers to manage multiple customers with clear data boundaries and administrative controls.
- Supports flexible MID Server deployment strategies for managing discovery across multiple domains.
- Ensures compliance with organizational policies by controlling data visibility and access.
Domain separation is supported in Discovery. 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.
Support level: Standard
- Includes all aspects of Basic level support.
- Application properties are domain-aware as needed.
- Business logic: The service provider (SP) creates or modifies processes per customer. The use cases reflect proper use of the application by multiple SP customers in a single instance.
- The instance owner must configure the minimum viable product (MVP) business logic and data parameters per tenant as expected for the specific application.
Sample use case: An Admin must be able to make comments required when a record closes for one tenant, but not for another.
For more information on support levels, see Application support for domain separation.
Domain separation overview
Service Providers (SPs) use domain separation to segregate data for each customer. Users in a given domain have visibility only to the data in their own domains or in child domains. SPs typically control the top-level domain, which gives them visibility to data associated with all domains. Given that Discovery domain separation support is considered Standard there is no delegated administration to the child domains. The SPs must retain administrative control.
How domain separation works in Discovery
Multiple domains can be supported by a single MID Server. In releases prior to Kingston, each MID Server could support only a single domain. In newer releases, segregating domains by MID Server is useful when the domain is large, or when the domain's resources are held in a customer's data center rather than the SP's. For Discovery on MID Servers supporting a single domain, the discovered CIs are assigned to the domain of the MID User used to authenticated against the ServiceNow instance. In multi-domain MID Servers, the discovered CIs are assigned to the domain of the user who created the Discovery schedule.
Discovery implements data domain separation through the MID Server by impersonating the MID Server user during sensor processing. Discovery uses the domain, that the MID Server user is in, to determine which domain the discovered data should be put into. Discovery configuration information, including classifiers, identifiers, probes, and sensors, is not domain separated.
Service providers generally use IP-based Discovery. In cases where the SP controls the network addressing, they divide the address space among their customers to ensure that each domain has a distinct IP address space. The SP assigns one or more subnets to a customer or domain and creates Discovery schedules for those subnets.
If the SP is remotely managing their customer's data center, there will often be some overlap between address spaces different customers use. In these cases, the SP can use network address translation (NAT) on the IP range and run a Discovery schedule.
Once the CIs are assigned to the correct domain, the visibility and read/write access control are provided by the platform through the domain hierarchy. Schedules are visible to users in their respective domains. Cross-domain schedule visibility is not possible, except for the SP who controls the parent domain and has visibility to all domains.
Domain separation for MID Server files
- MID Server MIB File [ecc_agent_mib]
- MID Server JAR File [ecc_agent_jar]
- MID Server Script File [ecc_agent_script_files]
By default, all records in these tables are members of the global domain. A user can override the default global domain and create a version of these policies for use in the user's own domain.
See MID Server domain separation for instructions on setting up domain separation through the MID Server.
Domain-separated tables
- Serial Number [cmdb_serial_number]
- TCP Connection [cmdb_tcp]
- Fibre Channel Initiator [cmdb_fc_initiator]
- Fibre Channel Targets [cmdb_fc_target]
- IP Address to DNS Name [cmdb_ip_address_dns_name]
- Service [cmdb_ip_service_ci]
- KVM Virtual Device [cmdb_kvm_device]
- Load Balancer Service VLAN [cmdb_lb_service_vlan]
- Load Balancer VLAN Interface [cmdb_lb_vlan_interface]
- Switch Port [cmdb_switch_port]