Service Accounts for Service Graph Connector

[Jeff16]

I'm looking for best practices when implementing a Service Graph Connector.  To run the Scheduled Jobs, a Run As is required.  While the Admin account would work, I was interested in determining if a Service Account would be a better choice, and if so, what roles are required to implement this service account.  I'm looking to implement the following Service Graph Connectors:

- Service Graph Connector for Microsoft Azure

- Service Graph Connector for Microsoft Intune

[vijaydodla]

Yes, using a dedicated Service Account (often referred to as an integration user) is the industry-standard best practice over using a standard admin account.

Using a personal or shared admin account introduces significant operational risks if the admin leaves the company, their password expires, or the account is locked, your integrations will immediately break. Furthermore, using an admin account violates the Principle of Least Privilege and makes auditing logs difficult.

 

When setting up a Service Account for Service Graph Connectors , you must configure both the ServiceNow internal user (the "Run As" user for the scheduled jobs) and the External Service Principal (the Azure App Registration that actually authenticates the connection).

[vijaydodla]

Follow these core best practices will ensure a healthy, reliable, and scalable CMDB:

 

• Use SGC Central & Guided Setup: Always manage your connectors through the Service Graph Connector Central workspace. Use the built-in Guided Setup or Playbooks for installation. These tools ensure you don't miss critical prerequisites, dependencies, or table permissions before data starts flowing.
• Never Bypass the IRE: All Service Graph Connectors are designed to route data through the Identification and Reconciliation Engine . Do not attempt to bypass this with custom transform logic. The IRE is what prevents duplicate Configuration Items and ensures that attribute values remain consistent when multiple data sources update the same CI.
• Set Discovery Sources: Ensure the connector correctly tags incoming data with its specific discovery_source (e.g., "SG-Azure" or "SG-Intune"). This maintains a clear lineage of where your CMDB data originated and allows you to set up reconciliation rules (e.g., trusting Azure for cloud metadata, but Intune for endpoint OS versions).
• Utilize the dashboard metrics in SGC Central to track "Ingested and Processed Data" and "Data Processing Performance." Regularly reviewing these charts helps you spot rising error rates, authentication failures, or API timeouts before they become systemic issues.
• Use Dedicated Service Accounts: As discussed previously, always use a dedicated, non-interactive integration user with the principle of least privilege (e.g., import_admin, cmdb_inst_admin, connection_admin) rather than a shared admin account.
• Collaborate with CMDB Owners: Involve your CMDB architect or librarian during the design phase. Third-party data ingestion must align with your organization's broader data governance strategy and CMDB Health metrics (Completeness, Compliance, and Correctness).