Identity and device connectors

Identity and device connectors pull your organisation’s own record of people and computers into Shield360 on a schedule. Shield360 uses them to match each person it sees using AI to a directory entry (department, job title, manager, office) and to show each computer’s owner, OS, compliance, risk and open alerts. Person and computer pages, team budgets and reports by department all read from this data.

Connector	Syncs
Microsoft Entra ID	People, and Intune managed devices with their owners
Okta	People
Google Workspace	People
Microsoft Defender for Endpoint	Devices, risk level, open alerts, last signed-in user
CrowdStrike Falcon	Devices, open alerts, last signed-in user
SentinelOne	Devices, active threats, last signed-in user
Jamf Pro	Managed Macs and their assigned users
Kandji	Managed Apple devices, assigned users and blueprints
Rapid7 InsightVM	Asset risk scores and vulnerability counts
Datadog	Hosts the Datadog Agent reports, with OS and integrations

Every connector only reads. Shield360 never writes to your directory or devices.

Add a connector

Open Connectors

Go to Connectors (/connectors). Pick the project and environment in the header first: a connector belongs to one project and environment and writes to every database of that pair, and no other.

Add the connector

Select Add connector and choose the type from the Identity & security category.

Fill in the form

Follow the section for your provider below. Every form also has Sync every (Hour, 6 hours or Day, default 6 hours), which sets how often Shield360 pulls the source.

Sync now with the test button

The test button runs a full sync straight away rather than only checking the connection. The result appears under the connector: Synced with the time and counts, for example Synced 1200 people and 950 devices. 310 of 340 people Shield360 sees are matched to the directory., or Sync failed with the error. Hover over the line to read the full message.

Note

Each secret field (client secret, API token, API key, service account key) has a matching … from the Vault (optional) field. Name a Vault entry there instead of pasting the secret into the connector, and rotate it in one place. The Vault entry can itself point at your own secrets manager.

How syncing works:

• Each run replaces the connector’s people and devices. A person or computer the source no longer lists is removed.
• A failed run is retried within the hour instead of waiting for the full Sync every interval.
• Deleting the connector removes everything it synced.
• If the environment has no database yet, the sync fails with No database in <environment> to write to.
• Shield360 calls each provider from its servers over HTTPS. Instance URLs (Okta, Jamf Pro, Kandji, SentinelOne) must be reachable from the Shield360 server, and plain HTTP is refused. Private or localhost addresses are refused unless the connector has Allow private or localhost endpoints switched on. Jamf Pro, Kandji and SentinelOne have this switch for self-hosted instances on a private network. It is off by default, only someone who can create or update connectors can turn it on, and cloud metadata addresses stay blocked when it is on.

Errors that any connector can return:

Message	Fix
The vault has no entry called <name>.	Create the Vault entry in this organisation, or correct the name in the … from the Vault field.
The request timed out.	The provider did not answer within 30 seconds. Check the URL and try again.
The response was not JSON.	The URL points at a web page instead of the API. Check the instance or console URL.
Host "<host>" is not allowed	The URL resolves to a private, loopback or cloud metadata address. Use the provider’s public HTTPS URL, or, for a self-hosted Jamf Pro, Kandji or SentinelOne on a private network, switch on Allow private or localhost endpoints. Cloud metadata addresses are always refused.
Could not resolve host "<host>"	The host name is wrong. Check the URL for typos.

Microsoft Entra ID

Syncs every user in your Entra ID tenant (display name, user principal name, email, department, job title, office, employee id, on-premises account name, enabled state and manager). With Include Intune devices on, it also syncs each Intune managed device with its owner, OS, compliance state, serial number and last check-in.

Shield360 signs in with an app registration’s client credentials and calls Microsoft Graph:

• POST https://login.microsoftonline.com/<tenant>/oauth2/v2.0/token with scope https://graph.microsoft.com/.default
• GET /v1.0/users with $select of the fields above and $expand=manager
• GET /v1.0/deviceManagement/managedDevices, only when Include Intune devices is on

What you’ll need

• An Entra ID role that can register apps and grant admin consent (for example Privileged Role Administrator or Global Administrator)
• The User.Read.All application permission, plus DeviceManagementManagedDevices.Read.All if you sync Intune devices
• A client secret, and a reminder to rotate it before it expires

Entra ID tenant and client ids

Register an application

In the Microsoft Entra admin center, go to App registrations and create a new registration, for example “Shield360 directory”. Choose Accounts in this organizational directory only. No redirect URI is needed. See Microsoft’s Register an application guide.

Copy the ids

On the app’s Overview page, copy the Directory (tenant) ID and the Application (client) ID. They go in the Shield360 fields Directory (tenant) id and Application (client) id.

Entra ID permissions

Add User.Read.All

In the app’s API permissions, add a permission: Microsoft Graph, Application permissions, User.Read.All. This is the only permission needed to read users and their managers. Use application permissions, not delegated ones: Shield360 syncs without a signed-in user.

Grant admin consent

Select Grant admin consent for your tenant. Until consent is granted, Graph refuses the calls with HTTP 403.

You can remove any default delegated User.Read permission; Shield360 does not use it. See Microsoft’s List users permissions table.

Entra ID Intune permission

Only needed when Include Intune devices is on (the default).

Add DeviceManagementManagedDevices.Read.All

In API permissions, add Microsoft Graph, Application permissions, DeviceManagementManagedDevices.Read.All.

Grant admin consent again

Select Grant admin consent so the new permission takes effect.

If you don’t use Intune, or don’t want to grant this permission, switch Include Intune devices off in Shield360. See Microsoft’s List managedDevices reference.

Entra ID client secret

Create a client secret

In Certificates & secrets, add a new client secret. Pick an expiry that matches your rotation policy; Microsoft allows up to 24 months.

Copy the value

Copy the secret’s Value straight away; it is shown only once. Do not copy the Secret ID, which is a different value and fails sign-in.

Plan the rotation

When the secret expires, syncs fail with a sign-in error. Before it expires, create a new secret, paste it into Shield360 (or update the Vault entry), run the test button, then delete the old secret.

Connect Entra ID in Shield360

Field	Value
Directory (tenant) id	The tenant ID from the app’s Overview page
Application (client) id	The client ID from the app’s Overview page
Include Intune devices	On to sync Intune managed devices; off if you did not grant DeviceManagementManagedDevices.Read.All
Sync every	How often to sync
Client secret from the Vault (optional)	A Vault entry holding the secret, instead of pasting it below
Client secret	The secret value

Select the test button. A good result reads Synced <n> people and <n> devices. followed by how many people Shield360 has matched to the directory.

Entra ID troubleshooting

Message	Cause and fix
Set the tenant id, client id and client secret.	One of the three is empty, or the Vault entry is empty.
Microsoft sign-in failed: HTTP 400 … AADSTS90002	The tenant ID is wrong.
Microsoft sign-in failed: HTTP 400 … AADSTS700016	The client ID is wrong, or the app is registered in another tenant.
Microsoft sign-in failed: HTTP 401 … AADSTS7000215	The client secret is wrong. Check you pasted the secret Value, not the Secret ID.
Microsoft sign-in failed: … AADSTS7000222	The client secret has expired. Create a new one.
Reading Entra ID users failed (needs User.Read.All): HTTP 403 …	User.Read.All is missing, is delegated instead of application, or admin consent was not granted.
Reading Intune devices failed (needs DeviceManagementManagedDevices.Read.All, or switch Intune off): HTTP 403 …	Grant DeviceManagementManagedDevices.Read.All with admin consent, or switch Include Intune devices off.

Okta

Syncs every user in your Okta org: login, email, display name, department, title, manager, city, employee number and status. Active, password-expired, recovery and locked-out users count as enabled.

Shield360 calls GET <org URL>/api/v1/users (200 users per page) with the header Authorization: SSWS <token>, and follows Okta’s pagination links only while they stay on your org’s host.

What you’ll need

• Your Okta org URL, for example https://contoso.okta.com
• An Okta admin with the Read-Only Administrator role to create the token
• An API token created while signed in as that admin

Okta API token

Use a read-only admin

An Okta API token acts with the permissions of the admin who creates it. Create the token while signed in as a dedicated admin account (a service account is best) that has only the Read-Only Administrator role. Listing users needs nothing more.

Create the token

In the Okta Admin Console, go to Security, API, Tokens and create a token, for example “Shield360”. Copy the token value; Okta shows it only once. See Okta’s Create an API token guide.

Keep it alive

Okta revokes a token that has not been used for 30 days, and when the admin who created it is deactivated. A Sync every of a day or less keeps it in use. If you restrict tokens by network zone, allow the addresses Shield360 calls from.

Connect Okta in Shield360

Field	Value
Okta org URL	Your Okta domain, for example https://contoso.okta.com (not the -admin URL)
Sync every	How often to sync
API token from the Vault (optional)	A Vault entry holding the token
API token	The token value

Select the test button. A good result reads Synced <n> people.

Okta troubleshooting

Message	Cause and fix
Set the Okta org URL and API token.	One of them is empty.
Reading Okta users failed (check the org URL and token): HTTP 401 …	The token is wrong, revoked or expired after 30 days unused. Create a new token.
Reading Okta users failed (check the org URL and token): HTTP 403 …	The token’s admin cannot list users, or a network zone restriction blocks Shield360.
Reading Okta users failed (check the org URL and token): HTTP 404 …	The org URL is wrong. Use the Okta domain without the -admin suffix.
Reading Okta users failed (check the org URL and token): HTTP 429 …	Okta rate limit reached. The next sync retries within the hour; consider a longer Sync every.
Okta sent a next page on another host.	The org URL differs from the host Okta uses for paging, for example a custom domain. Use the host Okta itself returns, usually https://<org>.okta.com.

Google Workspace

Syncs every user in your Workspace directory: primary email, full name, department, title, manager, building, employee id, and whether the user is suspended or archived.

Shield360 signs in as a service account with domain-wide delegation, acting as a Workspace admin you name:

• POST https://oauth2.googleapis.com/token (JWT bearer grant) with scope https://www.googleapis.com/auth/admin.directory.user.readonly
• GET https://admin.googleapis.com/admin/directory/v1/users?customer=my_customer&projection=full

What you’ll need

• A Google Cloud project with the Admin SDK API enabled
• A service account and its JSON key
• Super admin access to set up domain-wide delegation
• A Workspace admin user that can read users, for the service account to act as

Google Workspace domain wide delegation

Enable the Admin SDK API

In the Google Cloud console, pick or create a project and enable the Admin SDK API.

Create a service account and key

Create a service account in that project (it needs no Google Cloud roles), then create a key of type JSON and download it. If your organisation policy blocks key creation, an organisation policy admin must allow it for this project. See Google’s Create access credentials guide.

Copy the service account's client ID

On the service account’s details, copy its numeric Client ID (also called the OAuth 2 client ID). It is also the client_id value in the JSON key.

Authorise the scope

As a super admin, in the Google Admin console go to Security, Access and data control, API controls, Manage Domain Wide Delegation and add a new client. Enter the client ID and exactly this one scope:

https://www.googleapis.com/auth/admin.directory.user.readonly

See Google’s Control API access with domain-wide delegation. A new delegation usually works within minutes but can take up to 24 hours.

Choose the admin to act as

The service account reads the directory as this user. Use an admin whose role can read users, for example a custom role with the Admin API privilege Users, Read. A super admin also works but grants more than needed.

Caution

A service account key does not expire by default. Store it in the Vault, restrict who can create keys for the project, and rotate it by creating a new key, updating Shield360, running the test button, then deleting the old key.

Connect Google Workspace in Shield360

Field	Value
Act as admin	The admin’s email, for example it-admin@contoso.com
Sync every	How often to sync
Service account key from the Vault (optional)	A Vault entry holding the JSON key
Service account key (JSON)	The full contents of the JSON key file

Select the test button. A good result reads Synced <n> people.

Google Workspace troubleshooting

Message	Cause and fix
Name the Workspace admin the service account acts as.	Act as admin is empty.
The service account key is not valid JSON. …	Paste the whole key file, including the braces.
The service account key has no client_email or private_key. …	The pasted file is not a service account key (for example an OAuth client file). Create a JSON key for the service account.
The service account's private key could not sign. …	The private_key value was altered when copying. Paste the file again unchanged.
Google sign-in failed: HTTP 401 … unauthorized_client …	Domain-wide delegation is missing for this client ID or scope, or has not taken effect yet. Check the client ID and the exact scope.
Google sign-in failed: HTTP 400 … invalid_grant …	Act as admin is not an active user in your Workspace, or the key was deleted.
Reading Workspace users failed: HTTP 403 …	The Admin SDK API is not enabled in the project, or the admin you act as cannot read users.

Microsoft Defender for Endpoint

Syncs every machine Defender for Endpoint knows: DNS name, OS platform and version, last seen, health status and risk level. It also counts each machine’s open (not resolved) alerts and looks up its most recent signed-in user.

Shield360 signs in with an app registration’s client credentials and calls the Defender for Endpoint API:

• POST https://login.microsoftonline.com/<tenant>/oauth2/v2.0/token with scope https://api.securitycenter.microsoft.com/.default
• GET /api/machines
• GET /api/alerts filtered to status ne 'Resolved'
• GET /api/machines/<id>/logonusers, for up to 500 machines per sync

What you’ll need

• An Entra ID role that can register apps and grant admin consent
• WindowsDefenderATP application permission Machine.Read.All
• Optional: Alert.Read.All for alert counts, User.Read.All for last user
• A client secret, and a reminder to rotate it before it expires

Register an application and create a client secret exactly as in Entra ID tenant and client ids and Entra ID client secret. You can reuse the Entra ID connector’s app registration and add the Defender permissions to it, or keep a separate app.

Defender API permissions

Add the WindowsDefenderATP permissions

In the app’s API permissions, add a permission, choose APIs my organization uses and search for WindowsDefenderATP. Choose Application permissions and add:

Permission	Needed for
Machine.Read.All	Required. Lists machines.
Alert.Read.All	Optional. Open alert counts; without it every count is 0.
User.Read.All	Optional. Last signed-in user; without it that field stays empty.

User.Read.All here is the WindowsDefenderATP permission, not the Microsoft Graph permission of the same name.

Grant admin consent

Select Grant admin consent. See Microsoft’s Create an app to access Defender for Endpoint without a user.

Connect Defender in Shield360

Field	Value
Directory (tenant) id	The tenant ID from the app’s Overview page
Application (client) id	The client ID from the app’s Overview page
Sync every	How often to sync
Client secret from the Vault (optional)	A Vault entry holding the secret
Client secret	The secret value

Select the test button. A good result reads Synced <n> devices.

Defender troubleshooting

Message	Cause and fix
Set the tenant id, client id and client secret.	One of the three is empty.
Microsoft sign-in failed: …	Wrong tenant ID, client ID or secret, or an expired secret. The AADSTS codes in Entra ID troubleshooting apply.
Reading Defender machines failed (needs Machine.Read.All): HTTP 403 …	Machine.Read.All is missing or not consented, or it was added under Microsoft Graph instead of WindowsDefenderATP.
Reading Defender machines failed (needs Machine.Read.All): HTTP 401 …	The tenant has no Defender for Endpoint subscription or is not onboarded.
Every device shows 0 open alerts	Alert.Read.All is missing. The sync succeeds without it.
No last signed-in user	User.Read.All (WindowsDefenderATP) is missing, or the machine is beyond the first 500 looked up per sync.

CrowdStrike Falcon

Syncs every host with the Falcon sensor: host name, serial number, platform, OS version, last seen, status and last signed-in user, plus a count of each host’s open (not closed) alerts.

Shield360 signs in to your Falcon cloud with an API client and calls:

• POST /oauth2/token
• GET /devices/queries/devices/v1 and POST /devices/entities/devices/v2
• GET /alerts/queries/alerts/v2 (up to 1,000 open alerts) and POST /alerts/entities/alerts/v2

What you’ll need

• A Falcon role that can create API clients (Falcon Administrator)
• Your Falcon cloud: US-1, US-2, EU-1 or US-GOV-1
• An API client with Hosts: Read and Alerts: Read

CrowdStrike API client

Create an API client

In the Falcon console, open API clients and keys (under Support and resources) and add a new API client, for example “Shield360”.

Choose the scopes

Tick Read only for:

Scope	Needed for
Hosts	Required. Lists hosts.
Alerts	Optional. Open alert counts; without it every count is 0.

Leave every other scope and every Write box unticked.

Copy the client id, secret and base URL

Copy the Client ID and Secret; the secret is shown only once. The Base URL shown with them tells you your cloud: api.crowdstrike.com is US-1, api.us-2.crowdstrike.com is US-2, api.eu-1.crowdstrike.com is EU-1 and api.laggar.gcw.crowdstrike.com is US-GOV-1.

Rotate the secret

Falcon API client secrets don’t expire on their own. To rotate, reset the secret on the API client, then update Shield360 and run the test button.

See CrowdStrike’s Getting access to the CrowdStrike API.

Connect CrowdStrike in Shield360

Field	Value
Falcon cloud	US-1, US-2, EU-1 or US-GOV-1, matching the base URL
API client id	The client ID
Sync every	How often to sync
Client secret from the Vault (optional)	A Vault entry holding the secret
API client secret	The secret

Select the test button. A good result reads Synced <n> devices.

CrowdStrike troubleshooting

Message	Cause and fix
Set the API client id and secret.	One of them is empty.
Falcon sign-in failed (check the cloud and the API client): HTTP 401 …	Wrong client ID or secret, or the secret was reset.
Falcon sign-in failed (check the cloud and the API client): … with another status	Falcon cloud does not match your account. Check the base URL on the API client.
Listing Falcon hosts failed (needs Hosts: Read): HTTP 403 …	Add Hosts: Read to the API client.
Reading Falcon host details failed (needs Hosts: Read): …	Reading host details was refused. Check Hosts: Read is still on the client.
Every host shows 0 open alerts	Alerts: Read is missing. The sync succeeds without it.

SentinelOne

Syncs every endpoint with the SentinelOne agent: computer name, serial number, OS and revision, last active time, network status, last logged-in user and active threat count. An infected endpoint is shown as high risk, one with active threats as medium.

Shield360 calls GET <console URL>/web/api/v2.1/agents (1,000 per page) with the header Authorization: ApiToken <token>.

What you’ll need

• Your management console URL, for example https://usea1-contoso.sentinelone.net
• An Admin user who can create service users
• A service user with the Viewer role and its API token

SentinelOne service user

Create a service user

In the SentinelOne management console, open the users settings and create a service user, for example “Shield360”. A service user is not tied to a person, so its token keeps working when staff leave.

Give it the Viewer role at the right scope

Assign the Viewer role. Shield360 only reads agents. Set the scope to the account (or the sites) whose endpoints you want synced; the token only sees agents in that scope.

Set an expiry and copy the token

Choose the token’s expiration date, then copy the API token; it is shown only once.

Rotate before expiry

When the token expires, syncs fail with HTTP 401. Before then, generate a new token for the service user, update Shield360 and run the test button.

SentinelOne’s documentation is in the customer portal; search it for “service users” for the current steps.

Connect SentinelOne in Shield360

Field	Value
Management console URL	The address you sign in to, for example https://usea1-contoso.sentinelone.net. Only the scheme and host are used.
Sync every	How often to sync
Allow private or localhost endpoints	Off by default. Switch on only for a self-hosted instance on a private network. Cloud metadata addresses stay blocked.
API token from the Vault (optional)	A Vault entry holding the token
API token	The service user’s token

Select the test button. A good result reads Synced <n> devices.

SentinelOne troubleshooting

Message	Cause and fix
Set the SentinelOne console URL.	The URL is empty or not a valid URL.
Set the SentinelOne API token.	The token is empty.
Reading SentinelOne agents failed: HTTP 401 …	The token is wrong, expired or revoked.
Reading SentinelOne agents failed: HTTP 403 …	The service user’s role or scope does not allow viewing endpoints.
Reading SentinelOne agents failed: The response was not JSON.	The console URL is wrong.
Fewer endpoints than expected	The service user’s scope covers only some sites. Widen it to the account.

Jamf Pro

Syncs every computer in Jamf Pro: name, serial number, OS name and version, last contact time, whether it is managed, and the assigned user’s email or username.

Shield360 signs in with an API client’s client credentials and calls:

• POST <Jamf Pro URL>/api/oauth/token
• GET <Jamf Pro URL>/api/v1/computers-inventory with the General, User and Location, Hardware and Operating System sections

What you’ll need

• Your Jamf Pro URL, for example https://contoso.jamfcloud.com
• A Jamf Pro admin who can manage API roles and clients
• An API role with only the Read Computers privilege
• An API client using that role, and its client secret

Jamf API client

Create an API role

In Jamf Pro settings, open API roles and clients. Create an API role, for example “Shield360 read”, with the single privilege Read Computers.

Create an API client

Create an API client, assign the role, and enable it. The access token lifetime can stay at the default; Shield360 requests a new token on every sync.

Generate the client secret

Generate a client secret and copy the Client ID and Client Secret; the secret is shown only once.

Rotate the secret

To rotate, generate a new client secret on the client (the old one stops working), update Shield360 and run the test button.

See Jamf’s Client credentials guide.

Connect Jamf Pro in Shield360

Field	Value
Jamf Pro URL	Your instance, for example https://contoso.jamfcloud.com. Only the scheme and host are used.
API client id	The client ID
Sync every	How often to sync
Allow private or localhost endpoints	Off by default. Switch on only for a self-hosted instance on a private network. Cloud metadata addresses stay blocked.
Client secret from the Vault (optional)	A Vault entry holding the secret
API client secret	The client secret

Select the test button. A good result reads Synced <n> devices.

Jamf Pro troubleshooting

Message	Cause and fix
Set the Jamf API client id and secret.	One of them is empty.
Set the Jamf Pro URL.	The URL is empty or not a valid URL.
Jamf sign-in failed: HTTP 401 …	Wrong client ID or secret, the secret was regenerated, or the API client is disabled.
Reading Jamf computers failed (needs Read Computers): HTTP 401 … or HTTP 403 …	The API role lacks Read Computers.
Host "<host>" is not allowed …	The Jamf Pro server is on a private network. Switch on Allow private or localhost endpoints if Shield360 should reach it there, or use an internet-reachable HTTPS address.

Kandji

Syncs every device in Kandji: name, serial number, platform, OS version, last check-in, assigned user and blueprint.

Shield360 calls GET <Kandji API URL>/api/v1/devices (300 per page) with the header Authorization: Bearer <token>.

What you’ll need

• Your Kandji API URL, for example https://contoso.api.kandji.io
• A Kandji admin who can create API tokens
• An API token with only the Device list permission

Kandji API token

Find the API URL

In Kandji, open Settings, then Access. Your API URL is shown there, for example https://contoso.api.kandji.io, or https://contoso.api.eu.kandji.io for EU tenants.

Create a token

On the same page, add an API token, for example “Shield360”, and copy it; it is shown only once.

Limit its permissions

Configure the token’s API permissions and enable only Device list under Devices. Shield360 needs nothing else.

Rotate the token

To rotate, create a new token with the same permission, update Shield360, run the test button, then revoke the old token.

See Kandji’s Kandji API article.

Connect Kandji in Shield360

Field	Value
Kandji API URL	The API URL from Settings, Access. Only the scheme and host are used.
Sync every	How often to sync
Allow private or localhost endpoints	Off by default. Switch on only for a self-hosted instance on a private network. Cloud metadata addresses stay blocked.
API token from the Vault (optional)	A Vault entry holding the token
API token	The token

Select the test button. A good result reads Synced <n> devices.

Kandji troubleshooting

Message	Cause and fix
Set the Kandji API token.	The token is empty.
Set the Kandji API URL.	The URL is empty or not a valid URL.
Reading Kandji devices failed: HTTP 401 …	The token is wrong or revoked.
Reading Kandji devices failed: HTTP 403 …	The token lacks Device list.
Reading Kandji devices failed: … with a not-found or not-JSON error	The API URL is wrong. Use the API URL (with .api.), not the web app address.

Rapid7 InsightVM

Syncs every asset in InsightVM with its host name, OS, last assessment time, risk score and critical and severe vulnerability counts. Shield360 bands the risk score: 20,000 and above is critical, 5,000 high, 1,000 medium, anything lower low.

Shield360 calls the cloud Integration API v4, POST https://<region>.api.insight.rapid7.com/vm/v4/integration/assets (500 per page) with the header X-Api-Key.

What you’ll need

• InsightVM with the Insight platform (cloud) connected
• Your Insight data region, for example US, EU or CA
• A user API key (or organisation key) with read access to InsightVM

Rapid7 API key

Choose a key type

A user key acts with one user’s permissions; create it as a dedicated user with read-only access to InsightVM. An organisation key has full access to the organisation and needs a platform admin, so prefer a user key.

Create the key

On the Insight platform, open API key management, generate a new key, name it “Shield360” and copy it; it is shown only once. See Rapid7’s Managing platform API keys.

Find your region

Your region is the data region of your Insight organisation, shown in the platform’s settings and in the host name you use, for example us, us2, us3, eu, ca, au or ap.

Rotate the key

Platform API keys don’t expire on their own. To rotate, generate a new key, update Shield360, run the test button, then delete the old key.

Connect Rapid7 in Shield360

Field	Value
Insight region	Your data region (US, US2, US3, EU, CA, AU or AP)
Sync every	How often to sync
API key from the Vault (optional)	A Vault entry holding the key
Insight platform API key	The key

Select the test button. A good result reads Synced <n> devices.

Rapid7 troubleshooting

Message	Cause and fix
Set the Insight platform API key.	The key is empty.
Reading InsightVM assets failed (check the region and key): HTTP 401 …	The key is wrong or deleted, or it belongs to an organisation in another region.
Reading InsightVM assets failed (check the region and key): HTTP 403 …	The key’s user cannot read InsightVM.
Reading InsightVM assets failed (check the region and key): … with another error	Insight region does not match your organisation.

Datadog

Syncs every host the Datadog Agent reports: host name, platform, last reported time, whether it is up, and up to 50 integrations running on it. These are mostly servers, which is useful for knowing what an AI workload runs on; laptops rarely carry the Datadog Agent.

Shield360 calls GET https://api.<site>/api/v1/hosts?include_hosts_metadata=true (1,000 per page) with the headers DD-API-KEY and DD-APPLICATION-KEY.

What you’ll need

• Your Datadog site, for example datadoghq.com or datadoghq.eu
• An API key
• An application key scoped to hosts_read only

Datadog application key

Find your site

Your site is in the address you sign in at: app.datadoghq.com is datadoghq.com, us3.datadoghq.com is us3.datadoghq.com, app.datadoghq.eu is datadoghq.eu, and so on.

Create or pick an API key

In Organization Settings, API Keys, create a key named “Shield360” so you can revoke it on its own.

Create a scoped application key

In Organization Settings, Application Keys (or your personal settings), create an application key named “Shield360”. Edit its scopes and allow only hosts_read. An unscoped application key has every permission of the user who owns it, so always set the scope. Copy the key; it is shown only once.

Mind the owner

An application key stops working when its owner is disabled. Create it as a service account or a long-lived user. To rotate, create a new key with the same scope, update Shield360, run the test button, then revoke the old key.

See Datadog’s API and application keys.

Connect Datadog in Shield360

Field	Value
Datadog site	Your site
Sync every	How often to sync
API key from the Vault (optional)	A Vault entry holding the API key
Application key from the Vault (optional)	A Vault entry holding the application key
API key	The API key
Application key	The scoped application key

Select the test button. A good result reads Synced <n> devices.

Datadog troubleshooting

Message	Cause and fix
Set both the API key and the application key.	One of the keys is empty.
Reading Datadog hosts failed (check the site and keys): HTTP 403 …	A key is wrong or revoked, the application key lacks hosts_read, or Datadog site does not match your account.
Reading Datadog hosts failed (check the site and keys): HTTP 401 …	The application key’s owner is disabled, or the keys belong to another site.

Related

Connectors overview

How connectors are scoped to projects and environments.

Vault

Keep connector secrets in one place and rotate them without editing connectors.