> For the complete documentation index, see [llms.txt](https://learn.netmaker.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://learn.netmaker.io/integrations/endpoint-detection-and-response.md). # Endpoint Detection & Response Step-by-step instructions for connecting Microsoft Defender for Endpoint, CrowdStrike Falcon, SentinelOne, and Wazuh to Netmaker for endpoint trust verification. ## Overview Netmaker can pull endpoint health and security status from Endpoint Detection & Response (EDR) platforms, letting you enforce trust and compliance policies (like "device must have a healthy EDR agent") directly in Netmaker. Supported platforms: * Microsoft Defender for Endpoint * CrowdStrike Falcon * SentinelOne * Wazuh Each connector syncs endpoint status on a configurable interval. ## Configure an EDR Integration 1. Go to **Settings → Integrations → Endpoint Detection & Response**.

2. Select the provider you want to connect. 3. Enter the provider-specific connection details and credentials. 4. Test the connection. 5. Save the integration. ## Provider-Specific Configuration ### Microsoft Defender for Endpoint *** #### Part A: Create the App Registration (Entra admin center) **Step 1 — Open the right portal** Go to and sign in with an account that has **Global Administrator** or **Application Administrator** role. **Step 2 — Navigate to App registrations** \ Left sidebar → **Entra ID** → **App registrations**

Click **+ New registration**.

**Step 3 — Fill out the registration form** * **Name**: something identifiable, e.g. `Netmaker-MDE-Integration` * **Supported account types**: *Accounts in this organizational directory only (Single tenant)* Click **Register**. **Step 4 — Copy your identifiers** On the app's Overview page, copy and store safely: * **Application (client) ID** * **Directory (tenant) ID** *** #### Part B: Create a Client Secret **Step 5 — Go to Certificates & secrets** \ In the left sidebar of your app registration → **Certificates & secrets**

Click **+ New client secret**

**Step 6 — Configure the secret** * **Description**: e.g. `Netmaker sync` * **Expires**: pick an expiry (6 or 12 months recommended — note the date, since it will need renewing before it lapses) Click **Add**. **Step 7 — Copy the secret VALUE immediately** A new row appears with **Value** and **Secret ID** columns. Copy the **Value** column now — it's only shown once and disappears on refresh. Store it securely (password manager / secrets vault). *** #### Part C: Add API Permissions **Step 8 — Go to API permissions** \ Left sidebar → **API permissions**

Click **+ Add a permission**\ \ **Step 9 — Select the right API** Click **APIs my organization uses** Search for one of these: * **WindowsDefenderATP** Select it, then choose **Application permissions**. **Step 10 — Add the required permissions** Add: * **Machine.Read.All** Click **Add permissions**. **Step 11 — Grant admin consent** Back on the API permissions page, click **Grant admin consent for \[Your Directory]** \ Click **Yes** to confirm. Your API permissions should now look like: | API | Permission | Type | | ---------------------- | ---------------- | ----------- | | **WindowsDefenderATP** | Machine.Read.All | Application | Both should show a green checkmark under **Status**. > If **Grant admin consent** is greyed out, your account lacks consent-granting rights — a Global Admin will need to complete this step. *** #### Part D: Connect in Netmaker **Step 12 — Open** **Settings → Integrations → Endpoint Detection & Response (EDR) → Microsoft Defender for Endpoint → Connect**

**Step 13 — Enter credentials** * **Application (Client) ID** → paste the Application (client) ID from Step 4 * **Tenant ID** → paste the Directory (tenant) ID from Step 4 * **Client Secret** → paste the secret Value from Step 7 * Toggle **Enable periodic sync** on if you want ongoing polling * Set **Sync interval (minutes)** — 60 is a sensible default **Step 14 — Test and connect** \ Click **Test connection**. If credentials and permissions are correct, you'll see a success confirmation. Click **Connect** to finish. {% hint style="info" %} **Microsoft Defender for Endpoint** requires devices to be **Microsoft Entra ID** or **Hybrid Microsoft Entra ID** joined. Devices that are not joined cannot be matched, and their security status will not be available. {% endhint %} ### CrowdStrike Falcon *** #### Part A: Create an API Client (Falcon console) **Step 1 — Open the right portal** Go to your Falcon console (the URL depends on your cloud region): * US-1: * US-2: * EU-1: * US-GOV-1: Sign in with an account that has **Falcon Administrator** or **API Manager** privileges. **Step 2 — Navigate to API Clients** Left sidebar → **Support and resources** → **API Clients and Keys** Click **Create API client**. **Step 3 — Fill out the client form** * **Client name**: something identifiable, e.g. `Netmaker-Falcon-Integration` * **Description**: optional, e.g. `Endpoint risk sync for Netmaker` * **API scopes**: select the permissions you need (see Part B — you set scopes at creation time, not afterward) Click **Create**. **Step 4 — Copy your credentials** A dialog shows your credentials **once**: * **Client ID** * **Client Secret** Copy both immediately and store them securely (password manager / secrets vault) — the secret cannot be viewed again after you close this dialog. *** #### Part B: Set API Scopes Unlike Entra ID, CrowdStrike requires you to choose scopes **during client creation** (Step 3 above), not as a separate step afterward. If you need to change scopes later, you must delete the client and create a new one — the Client ID/Secret will change, so update Netmaker accordingly. **Step 5 — Select the required scopes** In the scopes list, check: | Scope | Permission | Purpose | | ------------------------- | --------------- | --------------------------------------------------------------- | | **Hosts** | Read | Retrieve device/host inventory and status | | **Detections** | Read | Retrieve detection and threat data | | **Alerts** | Read | Retrieve alert data (newer API, replaces some Detections calls) | | **Zero Trust Assessment** | Read (optional) | Pull device risk/compliance scores if Netmaker uses ZTA data | Only add **Write** scopes (e.g., Hosts: Write) if Netmaker will take response actions like host containment — not needed for pure risk/health visibility. **Step 6 — Confirm and create** Review the selected scopes, then click **Create** (if you haven't already in Step 3). The credentials dialog in Step 4 appears immediately after. *** #### Part C: Note Your Base URL CrowdStrike's API is region-specific — Netmaker needs to know which cloud your tenant lives in. **Step 7 — Identify your API base URL** Match your console URL from Step 1 to the corresponding API endpoint: | Console region | API base URL | | -------------- | ---------------------------------------- | | US-1 | `https://api.crowdstrike.com` | | US-2 | `https://api.us-2.crowdstrike.com` | | EU-1 | `https://api.eu-1.crowdstrike.com` | | US-GOV-1 | `https://api.laggar.gcw.crowdstrike.com` | You'll enter this in Netmaker alongside your Client ID and Secret. *** #### Part D: Connect in Netmaker **Step 8 — Open the integration** **Settings → Integrations → Endpoint Detection & Response (EDR) → CrowdStrike Falcon → Connect** **Step 9 — Enter credentials** * **API Base URL** → the region-specific URL from Step 7 * **Client ID** → from Step 4 * **Client Secret** → from Step 4 * Toggle **Enable periodic sync** on if you want ongoing polling * Set **Sync interval (minutes)** — 60 is a sensible default **Step 10 — Test and connect** Click **Test connection**. Netmaker will attempt an OAuth2 token request against the CrowdStrike API using your credentials — a success response confirms the scopes and region are correct. Click **Connect** to finish. ### SentinelOne *** #### Part A: Generate API Credentials (SentinelOne console) **Step 1 — Open the right portal** Go to your SentinelOne management console URL (this is tenant-specific, e.g. `https://.sentinelone.net`). Sign in with an account that has **Admin** or **IT** role privileges — API token generation requires elevated permissions. **Step 2 — Navigate to API token generation** Click your user icon (top right) → **My User** Scroll to the **API Token** section. **Step 3 — Generate the token** Click **Generate API Token** (or **Regenerate**, if one already exists). > ⚠️ Generating a new token immediately invalidates the previous one. If another integration is using the existing token, coordinate before regenerating — don't do this blind in production. **Step 4 — Copy the token immediately** The token is displayed **once**. Copy it now and store it securely (password manager / secrets vault) — you cannot view it again after leaving the page. *** #### Part B: (Recommended) Use a Dedicated Service User Instead Personal API tokens are tied to a human account — if that person leaves or their access is revoked, the integration breaks. For production integrations, SentinelOne recommends a dedicated service account. **Step 5 — Create a service user** Left sidebar → **Settings** → **Users** → **+ Add User** * **Email**: use a shared/service mailbox, e.g. `netmaker-integration@yourcompany.com` * **Role**: assign the least-privileged role that covers your needs — typically **Viewer** or a custom role scoped to read-only endpoint data (see Part C) * **Scope**: assign at the correct scope level — **Account** or **Site**, depending on which endpoints you want visible to Netmaker **Step 6 — Generate the token for this user** Log in as (or impersonate, if your console supports it) the service user, then repeat Steps 2–4 to generate its API token. *** #### Part C: Confirm Role / Scope Permissions SentinelOne doesn't use granular API scopes the way CrowdStrike or Graph do — access is governed by the **role and scope** assigned to the user whose token you're using. **Step 7 — Verify the role has the needed permissions** The role attached to your token (personal or service user) needs at minimum: | Capability | Purpose | | --------------------------- | ----------------------------------------------------------------- | | **View Agents / Endpoints** | Read device inventory, health, and risk status | | **View Threats** | Read detection and threat data | | **View Alerts** | Read alert data, if your Netmaker build pulls from the Alerts API | Only grant **Remediate/Mitigate** or **Manage Agents** permissions if Netmaker will trigger response actions — not needed for pure risk/health visibility. **Step 8 — Note the scope** Confirm whether the token's scope is **Global/Account-level** (sees all sites) or restricted to specific **Sites/Groups**. If Netmaker should only monitor a subset of endpoints, scope the service user accordingly rather than filtering after the fact. *** #### Part D: Note Your Management Console URL **Step 9 — Copy your console URL** Netmaker needs your full SentinelOne management console URL as the API base — this is the same URL you used to log in in Step 1, e.g.: `https://.sentinelone.net` This is tenant-specific; there's no shared regional endpoint like CrowdStrike's. *** #### Part E: Connect in Netmaker **Step 10 — Open the integration** **Settings → Integrations → Endpoint Detection & Response (EDR) → SentinelOne → Connect** **Step 11 — Enter credentials** * **Management Console URL** → from Step 9 * **API Token** → from Step 4 (or Step 6, if using a service user) * Toggle **Enable periodic sync** on if you want ongoing polling * Set **Sync interval (minutes)** — 60 is a sensible default **Step 12 — Test and connect** Click **Test connection**. Netmaker will call the SentinelOne API using the token to confirm it's valid and has the necessary read permissions. Click **Connect** to finish. ### Wazuh *** #### Part A: Locate Your Wazuh API Endpoint **Step 1 — Identify your Wazuh API endpoint** Netmaker integrates with Wazuh as an **EDR**, using the Wazuh REST API to retrieve managed devices and their inventory data. It does **not** integrate with Wazuh as a SIEM. * **Self-managed Wazuh:** The API is typically available at: `https://:55000` * **Wazuh Cloud:** Contact your Wazuh administrator or Wazuh support to obtain the correct external API endpoint. If external API access is not already enabled, Wazuh Cloud support may need to allow access from Netmaker's public IP address. If you're running Wazuh in a clustered setup, use the master node or a load balancer in front of the cluster. #### Step 2 — Confirm API access For **self-managed** deployments, the Wazuh API is enabled by default in Wazuh 4.x. If you cannot reach the API, verify that the Wazuh manager is running: ``` systemctl status wazuh-manager ``` Also verify that the API is enabled in: ``` /var/ossec/api/configuration/api.yaml ``` For **Wazuh Cloud**, ensure external API access has been enabled for your environment. *** #### Part B: Create a Dedicated API User Wazuh ships with a default `wazuh` API user, but using it for external integrations is not recommended — treat it the same as you would a root credential. Create a scoped user instead. **Step 3 — Access the Wazuh dashboard** Log in to the Wazuh dashboard (Kibana-based UI) as an administrator, typically at: `https://` **Step 4 — Navigate to** **Server management** → **Security** Go to the **Users** tab.

**Step 5 — Create the user** Click **Create user**

* **Username**: e.g. `netmaker-integration` * **Password**: generate a strong password (Wazuh enforces complexity requirements) and store it securely — this is what Netmaker will use to authenticate\

Click **Apply** *** #### Part C: Assign a Read-Only Role **Step 6 — Go to the Roles tab** Still under **Security**, click the **Roles** tab. Click **Create role** (or use an existing read-only role if one already fits). **Step 7 — Define role permissions** Name it something like `netmaker-readonly`, then attach policies that grant: | Resource | Action | Purpose | | ---------------------------- | ------------------------------------- | ------------------------------------------------------------------- | | **Agents** | `agent:read` | Read endpoint/agent inventory and connection status | | **Syscheck / Vulnerability** | `syscheck:read`, `vulnerability:read` | Read file integrity and vulnerability data feeding into risk status | | **Rules / Alerts** | `rules:read` | Read alert/detection data | | **Cluster / Manager status** | `cluster:read`, `manager:read` | Read overall health of the Wazuh deployment itself | Avoid `*:write` or `*:delete` actions — Netmaker only needs read access for risk/health verification. **Step 8 — Link the role to your user** Go back to the **Users** tab → select `netmaker-integration` → **Roles** → assign the `netmaker-readonly` role you just created. *** *** #### Part D: Connect in Netmaker **Step 10 — Open the integration** **Settings → Integrations → Endpoint Detection & Response (EDR) → Wazuh → Connect** **Step 11 — Enter credentials** * **API URL** → `https://:55000` (from Step 1) * **Username** → `netmaker-integration` (from Step 5) * **Password** → the password set in Step 5 * **Verify SSL** → toggle off only if your Wazuh manager uses a self-signed certificate you haven't added to a trusted CA chain (not recommended for production — see notes below) * Toggle **Enable periodic sync** on if you want ongoing polling * Set **Sync interval (minutes)** — 60 is a sensible default **Step 12 — Test and connect** Click **Test connection**. Netmaker will perform the JWT authentication handshake from Step 9 automatically and confirm read access. Click **Connect** to finish. *** --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://learn.netmaker.io/integrations/endpoint-detection-and-response.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.