Microsoft Defender for Identity
You can connect Incode identity verification to Microsoft Sentinel so that when Defender for Identity raises a suspicious activity incident, your security team can send the flagged user a biometric verification link. The result is posted back to Sentinel automatically, giving your team the identity confirmation they need to resolve or escalate the incident.
This integration is well-suited for Identity Threat Detection and Response (ITDR) workflows where you need to distinguish real security incidents from false positives caused by legitimate employees travelling, working from new devices, or logging in at unusual hours.
Prerequisites
Before you begin, ensure you have:
- An active Azure subscription with permissions to create Logic Apps and assign roles within a resource group
- A Microsoft Sentinel workspace
- Access to the Integrations page in Dashboard. Contact your Incode Representative if you do not see the Integrations page.
- Users to be verified must exist as directory records within the Incode integration before verification requests can succeed
How It Works
The integration runs on two Azure Logic Apps deployed in your Azure environment.
The first Logic App is a Sentinel automation playbook. When a Sentinel incident is created, the playbook calls the Incode API to generate a unique verification link for the flagged user and delivers it to your security team to send on.
The second Logic App is a webhook receiver. When the user completes their biometric check, Incode sends the result to this receiver. The receiver reads the result and updates the Sentinel incident — closing it as a false positive if verification succeeded, or escalating it to High severity if verification failed.
Both Logic Apps use a managed identity to authenticate against Azure Key Vault (for Incode credentials) and Microsoft Sentinel (to update incidents). No credentials are hardcoded.
Set Up Guide
Step 1: Create an Integration in Incode Omni
- Log in to Dashboard.
- In the left navigation, click Integrations.
- Click New integration.
- From the Custom tab, click API, then click Continue.
- Enter a Name for the integration (for example,
Microsoft Defender). - Click Save.
- Open the integration card and note the Integration ID. This is required for future steps.
Step 2: Collect Your Incode Credentials
You will store the following values securely in Azure Key Vault. See Find Integration Details for where to locate each one in the Omni Dashboard.
- Client ID: Your OAuth client identifier
- Client Secret: Generate a new one if you do not have one already
- API Key: Obtain from your Incode account team if you do not have one
- Integration ID: The value from Step 1
- Auth server URL:
https://auth.demo.incode.com(demo) orhttps://auth.incode.com(production) - API base URL:
https://demo-api.incodesmile.com(demo) orhttps://saas-api.incodesmile.com(production)
Step 3: Deploy the Azure Resources
Incode provides both Logic Apps as ready-to-deploy ARM templates. Click the Deploy to Azure button in the Incode GitHub repository to deploy both Logic Apps and an Azure Key Vault into a resource group in your Azure subscription in one step.
Note: If you do not have access to the ARM templates yet, contact your Incode account team.
Once deployed, store the following secrets in Key Vault using the exact secret names listed:
| Secret name | Value |
|---|---|
incode-client-id | Your Incode OAuth Client ID |
incode-client-secret | Your Incode OAuth Client Secret |
incode-api-key | Your Incode API Key |
incode-integration-reference | Your Integration ID from Step 1 |
incode-auth-url | Auth server URL from Step 2 |
incode-api-base-url | API base URL from Step 2 |
Note on storing secrets with special characters: Use the Azure Cloud Shell Python approach to avoid special characters being misread by bash:
python3 -c " import subprocess [subprocess.run](http://subprocess.run)(['az', 'keyvault', 'secret', 'set', '--vault-name', 'YOUR_KEYVAULT_NAME', '--name', 'incode-client-secret', '--value', 'YOUR_SECRET_VALUE_HERE']) " `
After storing all secrets, grant the Logic App managed identity Get and List permissions on Key Vault secrets.
Step 4: Assign the Sentinel Responder Role
The Logic Apps use a managed identity to update incidents in Sentinel. Grant this identity the Microsoft Sentinel Responder role from Azure Cloud Shell:
az role assignment create \
--assignee YOUR_MANAGED_IDENTITY_PRINCIPAL_ID \
--role "Microsoft Sentinel Responder" \
--scope /subscriptions/YOUR_SUBSCRIPTION_ID/resourceGroups/YOUR_RESOURCE_GROUPNote: Role assignments can take up to 10 minutes to propagate. Wait before testing.
Step 5: Configure Webhooks in Dashboard
The webhook receiver Logic App needs to receive session results from Incode when a user completes verification.
- In Dashboard, from the left navigation, click Configuration.
- Switch to the Webhooks tab.
- Find the Flow or Workflow associated with your integration.
- Add the webhook receiver Logic App URL as the endpoint for the
SESSION_SUCCEEDEDandSESSION_FAILEDevents.
To find the receiver Logic App URL, open the Logic App in the Azure portal, go to Overview, and copy the Workflow URL.
Note: Incode requires a webhook authentication secret to be configured before session webhooks are delivered. Contact your Incode account team to confirm the required format for your environment.
Step 6: Connect Sentinel to the Playbook
- In Microsoft Sentinel, create a new automation rule.
- Set the trigger to When an incident is created.
- Configure conditions to match the incidents you want to trigger verification for (for example, by severity or incident type).
- Set the action to Run playbook and select the playbook Logic App.
- Save the automation rule.
Step 7: Test the Integration
Verify the end-to-end flow from Azure Cloud Shell:
curl -s -X POST \
"YOUR_PLAYBOOK_TRIGGER_URL" \
-H "Content-Type: application/json" \
-d '{"incidentId":"TEST-001","severity":"Medium","userEmail":"[email protected]"}' \
| python3 -m json.toolA successful response includes a verificationUrl field and a status of verification_initiated. Open the URL to complete a test biometric check, then confirm the Sentinel incident was updated as expected.
Important Technical Notes
The api-version: 1.0 header is required. Every call to the Incode B2B onboarding endpoint (POST /omni/b2b/onboarding/request-new) must include the header api-version: 1.0. Without it the API returns HTTP 406 with no explanation.
externalCustomerId is required for incident correlation. Pass the Sentinel incident ID as externalCustomerId in every B2B onboarding request. Incode echoes this value back in the session webhook payload. Without it, the webhook receiver has no way to identify which incident to update.
Users must exist in the Incode directory before verification. If the loginHint (user email) does not match any record in the integration directory, the API returns error 5504: Employee by login factor cannot be found. Add the user to the integration directory in the Omni Dashboard before retrying.
Troubleshooting
Playbook fails at OAuth token step with HTTP 401.
The Client ID or Client Secret in Key Vault is wrong or has been rotated. Verify credentials manually from Cloud Shell:
curl -s -X POST "{auth_url}/oauth2/token" \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "grant_type=client_credentials&scope=openid&client_id={client_id}&client_secret={client_secret}"Playbook fails at B2B onboarding step with HTTP 406.
The api-version: 1.0 header is missing from the HTTP action in the Logic App.
Playbook fails with error 5504.
The user email passed as loginHint does not exist in the Incode integration directory. Add the user in the Omni Dashboard and retry.
Webhook receiver never fires after verification completes.
Three possible causes: session webhooks are not configured in Omni for the correct Flow or Workflow; the webhook auth secret is missing or incorrectly configured; or the webhook is configured at the wrong level (session webhooks are scoped to individual Flows or Workflows, not globally).
Webhook receiver fires but Sentinel update fails with HTTP 403.
The managed identity does not have the Microsoft Sentinel Responder role, or the role assignment has not yet propagated. Wait up to 10 minutes and retry.
Sentinel incident is not updated after verification completes.
The externalCustomerId in the webhook payload does not match a valid Sentinel incident ID. Confirm that the incident ID is being correctly passed in the original B2B onboarding request.
Supported Environments
| Environment | Auth server URL | API base URL |
|---|---|---|
| Demo | https://auth.demo.incode.com | https://demo-api.incodesmile.com |
| Production | https://auth.incode.com | https://saas-api.incodesmile.com |
Updated about 1 hour ago
