> ## Documentation Index
> Fetch the complete documentation index at: https://docs.livingsecurity.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Microsoft Entra ID integration setup
> Connect Microsoft Entra ID to Living Security for identity, sign-in, risk, device, and attack-simulation activity.
export const EgressIpAllowlistBothSets = ({system}) =>
{system} needs two sets of addresses, not one. Living Security mints this
integration's access token on its own infrastructure and refreshes it continuously, so setup
traffic and sync traffic leave from different networks. Allowlist both sets in {system}, and
keep both in place — this is not a setup-only requirement.
Integration sync traffic — the same in every region:
52.34.139.153/32, 54.69.127.183/32, 44.247.133.183/32,{' '}
52.26.211.56/32
Platform traffic — use only the row for the region that hosts your
organization:
United States: 98.91.60.249/32, 13.216.91.102/32
European Union: 34.246.236.210/32, 52.31.102.238/32
Allowlist only the sync set and setup never completes. Allowlist only the platform set and
setup succeeds while every sync fails. See{' '}
Configuring Integration Egress IP Addresses
{' '}
for both failure signatures and the change policy.
;
export const PublicIntegrationNextSteps = () => <>
Related resources
;
export const HandoffPaths = () =>
Invite the system admin into the platform with scoped permissions. They enter the
credentials directly; you never handle the secret.
Send the admin the provider page. They provision the credentials and return them to
you; you enter them in the Connect dialog.
;
export const ConnectInPlatform = ({tile, children}) =>
Completed by whoever holds Living Security access — the program owner, or the system
admin if they've been invited (delegated setup).
-
Go to Settings → Integrations → Catalog, find the{' '}
{tile} tile, click Connect.
-
Fill in the fields below, then click Connect.
{children}
;
export const SystemAdminBanner = ({system, recommendDelegated}) =>
This guide is for your {system} administrator. It covers creating API
credentials inside {system}, which requires admin access to {system} — not to the
Living Security Platform.
If you're the Living Security program owner and don't administer {system},
send this page to whoever does. They complete Part A and hand the credentials back to you
(or enter them directly if you've invited them into the platform).
{recommendDelegated && <>
{' '}Because setup produces sensitive key material, we recommend the{' '}
delegated setup path so the secret is never sent back to you.
}
;
## What this integration contributes
Microsoft Entra ID can contribute normalized identity, sign-in, risk, device, and attack-simulation activity. Reviewed examples include:
* `account.compromised` — account flagged as compromised
* `auth.login.unusual` — signs in from unusual contexts
* `phishing.simulation.clicked` — clicked a simulation without reporting
These are representative examples, not a guarantee that every event is available in every tenant. See [how integration data becomes signals](/signals/data-sources).
## What Living Security needs
| Credential | Description |
| ------------------ | ------------------------------------------------------------------------------------------------------------ |
| **Tenant ID** | The directory (tenant) UUID from your Microsoft Entra admin center |
| **Client ID** | The application (client) UUID assigned when you register the app |
| **Client Secret** | A secret credential generated under your app registration — the connect dialog labels this field **API Key** |
| **Graph API host** | The Microsoft Graph hostname (commercial: `graph.microsoft.com`) |
| **Authority host** | The Microsoft Entra authority hostname (commercial: `login.microsoftonline.com`) |
**Scopes (Application permissions):**
| Permission | Used for |
| ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- |
| `User.Read.All` | User directory |
| `SecurityAlert.Read.All` | Security alerts |
| `AuditLog.Read.All` | Sign-in logs and MFA registration details |
| `AttackSimulation.Read.All` | Attack Simulation Training results |
| `DeviceManagementManagedDevices.Read.All` | Intune managed devices |
| `IdentityRiskEvent.Read.All` | Identity Protection risk detections, including leaked credentials |
| `GroupMember.ReadWrite.All` | **Optional.** Group membership actions — lets a playbook add a person to, or remove them from, a Microsoft Entra ID group |
### You decide what this connection can do
This connection reads data. It can also *take action* in your directory, but only if you
choose to allow it.
Every permission above except the last one is read-only. Grant only those and the
connection can never modify anything in your tenant — the platform detects that and does
not offer group actions at all.
Add `GroupMember.ReadWrite.All` and group membership actions become available for use in
playbooks. Nothing starts happening on its own: you still have to choose which groups the
platform may touch (see below) and build a playbook that uses them.
You can change your mind at any time. Adding or removing a permission in Microsoft Entra ID
and re-granting admin consent is enough — there is no need to re-enter credentials in the
platform, and your data syncs keep running throughout. The change takes effect within about
an hour.
**Group membership actions are additionally limited to groups you designate.** After
connecting, an administrator chooses an explicit allowlist of groups on the connection.
Until that list exists, group actions are unavailable even with the permission granted —
so `GroupMember.ReadWrite.All` never means "any group in the tenant".
Choose those groups carefully: avoid any group that grants administrative roles,
privileged access, or licence entitlements.
**Required role:** **Application Administrator** or **Global Administrator** in Microsoft Entra ID
`IdentityRiskEvent.Read.All` is a newer addition. If you connected Microsoft Entra ID before it
appeared in this list, add it to your existing app registration and **re-grant admin consent** —
Microsoft requires consent to be re-granted whenever permissions change. Every other data stream
continues working normally in the meantime.
Reading risk detections also requires a **Microsoft Entra ID P1 or P2** license. Leaked-credential
detection itself is available at every tier including P1; the premium detections are reported as
`generic` below P2.
### Prerequisites
* You must have **Application Administrator** or **Global Administrator** access in Microsoft Entra ID to register applications and grant admin consent.
***
## Part A — In Microsoft Entra ID
*Your Microsoft Entra ID administrator completes these steps.*
1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com).
2. In the left navigation, browse to **Entra ID** → **App registrations**.
3. Click **New registration**.
4. Enter a meaningful name for the app, such as `Living Security Platform`.
5. Under **Supported account types**, select **Accounts in this organizational directory only**.
6. Leave **Redirect URI** blank — this integration uses the client credentials flow.
7. Click **Register**.
After registration, record the following values from the **Overview** page:
* **Application (client) ID**
* **Directory (tenant) ID**
1. On your app's **Overview** page, click **API permissions** in the left menu.
2. Click **Add a permission**.
3. Select **Microsoft Graph**.
4. Select **Application permissions**.
5. Search for and select each permission below, then click **Add permissions**:
* `User.Read.All`
* `SecurityAlert.Read.All`
* `AuditLog.Read.All`
* `AttackSimulation.Read.All`
* `DeviceManagementManagedDevices.Read.All`
* `IdentityRiskEvent.Read.All`
6. Add `GroupMember.ReadWrite.All` **only if** you want playbooks to be able to change group membership. Skip it to keep this connection read-only.
These are the minimum permissions for all data streams. If you only intend to enable a subset of streams, you can omit permissions for streams you won't use.
Application permissions require explicit admin consent.
1. On the **API permissions** page, click **Grant admin consent for \**.
2. In the confirmation dialog, click **Yes**.
3. Verify that every permission shows **Granted** under the **Status** column.
If the **Grant admin consent** button is grayed out, you need **Privileged Role Administrator** or **Global Administrator** privileges. Admin consent must be re-granted any time you add new permissions.
1. On your app's **Overview** page, click **Certificates & secrets** in the left menu.
2. Click the **Client secrets** tab, then click **New client secret**.
3. Enter a description (e.g., `Living Security Platform`).
4. Choose an expiration that matches your rotation policy.
5. Click **Add**.
**Copy the secret value immediately.** Microsoft Entra ID displays the full client secret only once. If you navigate away before copying it, you must delete the secret and create a new one.
Store the secret securely. Set a calendar reminder to rotate it before expiration — an expired secret causes syncs to fail with `401 Unauthorized`.
For most organizations on the commercial cloud, use the defaults:
| Field | Commercial cloud value |
| ------------------ | --------------------------- |
| **Graph API host** | `graph.microsoft.com` |
| **Authority host** | `login.microsoftonline.com` |
For government or sovereign clouds, use the appropriate endpoints for your environment.
The Graph API host and Authority host must match — tokens from one cloud's authority are not valid for another cloud's Graph endpoint.
***
## Part B — In the Living Security Platform
*The program owner completes this step, or the system admin if they were invited into the platform.*
| Field | Value |
| ------------------- | ------------------------------------------------------ |
| **API Key** | The Client Secret from Part A, Step 4 |
| **Azure tenant ID** | The Directory (tenant) ID from Part A, Step 1 |
| **Client ID** | The Application (client) ID from Part A, Step 1 |
| **Graph API host** | `graph.microsoft.com` (or your cloud's endpoint) |
| **Authority host** | `login.microsoftonline.com` (or your cloud's endpoint) |
You are now connected to Microsoft Entra ID (Client Credentials).
***
## Troubleshooting
The credentials are invalid or expired. Check:
1. Client Secret has not expired or been rotated
2. Tenant ID and Client ID are correct
3. Authority host matches your cloud environment
The app registration is missing permissions or admin consent was not granted. Verify:
1. All required permissions are listed in **API permissions**
2. Each permission shows **Granted** status (green checkmark)
3. Admin consent was granted after adding permissions
If you added new permissions after initial consent, you must re-grant admin consent.
The app may be missing the specific permission for that stream:
* No users → missing `User.Read.All`
* No security alerts → missing `SecurityAlert.Read.All`
* No sign-in logs → missing `AuditLog.Read.All`
* No attack-simulation results → missing `AttackSimulation.Read.All`
* No devices → missing `DeviceManagementManagedDevices.Read.All`
* No risk detections → missing `IdentityRiskEvent.Read.All`, admin consent not re-granted after
adding it, or the tenant is below the Microsoft Entra ID P1 license floor
The Graph API host and Authority host may be mismatched. Both must correspond to the same cloud environment (commercial, government, etc.).
Group membership actions are offered only when all three of these are true:
1. `GroupMember.ReadWrite.All` is on the app registration, with admin consent granted. If you added it recently, allow up to an hour.
2. An administrator has designated an allowlist of groups on the connection.
3. The connection is active and healthy.
If you granted the permission and the actions are still unavailable, re-grant admin consent — Microsoft requires it whenever permissions change.
If your tenant has a Conditional Access policy scoped by IP address, it can block requests
that carry this connection's credential. Most tenants are unaffected — Microsoft Graph does
not restrict by IP address by default. If you do enforce an IP-scoped policy for service
principals, this integration needs **two** sets of addresses allowlisted, because setup and
data sync leave from different networks.
Living Security mints this connection's access token itself and renews it continuously, so
token requests leave from the platform's own addresses, not from the addresses your data
syncs use.
Group actions are separate. By default they route the same way as your data syncs and leave
from the sync addresses. They move to the platform addresses only if an administrator
switches the connection to direct egress.
Add both sets to the **named location** that your Conditional Access policy trusts or
excludes. Token requests reach `login.microsoftonline.com` and data requests reach
`graph.microsoft.com`; both have to pass.
If only the sync addresses are allowlisted, setup fails while obtaining a token and no
connection is created. If only the platform addresses are allowlisted, setup succeeds and
every sync returns no records.