> For the complete documentation index, see [llms.txt](https://herd-security.gitbook.io/herd-security-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://herd-security.gitbook.io/herd-security-docs/microsoft-entra-id-azure-ad/azure-active-directory-user-and-group-sync.md). # Entra ID User and Group Sync How to connect Herd to your Microsoft Entra ID (Azure AD) to automatically sync users and groups. ### Overview of Microsoft Entra ID (Azure AD) User and Group Sync This section walks you through connecting Herd to your Microsoft Entra ID (Azure AD) to automatically sync users and groups, so your Herd roster always reflects who is actually in your organization. By using Entra ID as the source of truth for identities and group membership, you can reduce manual user management, keep access tightly aligned with your directory, and support clean onboarding and off-boarding as people join, move, or leave. There are two ways to connect: * **Connect without a client secret (recommended).** Send a one-time consent link to your Global Administrator. They approve Herd's own Entra app in your tenant, and the first sync starts on its own. No secret is entered into or stored in Herd. * **Use your own app registration and client secret.** Create an app registration in Entra ID, then enter its tenant ID, client ID and client secret in Herd. Use this if your tenant doesn't allow consent to Herd's app, if you are on GCC High, if you can't meet the rules in [Who can create the link](#who-can-create-the-link), or if you use Herd's SharePoint policy library. Either way, Herd regularly pulls in users and groups from your Entra ID tenant, so you can target the right people, avoid stale accounts, and keep a consistent security posture across your environment. It also syncs group memberships and managers, and lists your enterprise applications for the Stack section in **Settings → Context**. Access is read-only. Directory sync is separate from single sign-on and from the Teams app. Connecting it does not change how anyone signs in. It is also separate from Entra's SCIM provisioning. If you provision people into Herd over SCIM and give app access through [your identity provider's app-access role](/herd-security-docs/users/users/app-access.md#scim-provisioning), map `AppRoleAssignmentsComplex([appRoleAssignments])` to `roles` in the provisioning attribute mappings. Entra sends each app role as JSON, and Herd reads the role's `value` from it, so an app role value that equals one of your app-access claim values grants access. ## Option A: Connect without a client secret ### Prerequisites * A Herd administrator account with permission to manage integrations (**org.integrations**). * A **Global Administrator** or **Privileged Role Administrator** in your Microsoft tenant to approve the link. They do not need a Herd account. * A tenant in Microsoft's commercial cloud. Herd's app is not available to GCC High tenants; the consent link is not shown for them, so use Option B. ### Who can create the link Herd connects a directory only when it can show that the person who asked for the connection belongs to that directory. Two rules follow. **1. You must be signed in to Herd in a way that proves your email address.** Either of these works: * **Email and password**, on an account whose email address is verified. * **Your organization's Microsoft Entra single sign-on.** If your organization's Entra sign-in settings in Herd were changed after you signed in, sign out of Herd and back in through Microsoft before you create the link. Other sign-ins cannot create a link: single sign-on through Okta or Google Workspace, a session opened from Slack, or a Herd support session. Sign in with email and password, or use Option B. **2. The email you sign in to Herd with must be your Microsoft sign-in name.** Herd looks that address up in the directory that approves the link. It must be the **user principal name** of an enabled **member** account there. A guest account does not count, and a matching **mail** address or alias does not count either. With single sign-on, the email Microsoft sends Herd must be that sign-in name, not a different mail address. ### Who can approve the link * A **Global Administrator** or **Privileged Role Administrator**. These are the Microsoft roles that can grant application permissions for a whole tenant. Herd checks the role from the administrator's Microsoft sign-in and refuses anyone else. * An administrator of **the same directory the link's creator belongs to**. A consent granted in any other tenant is refused and nothing is connected. If the link was created through your organization's Entra single sign-on, the approval must also happen in that same tenant. * **One Microsoft tenant connects to one Herd organization.** A tenant already connected to another Herd organization is refused, whichever option that organization used. ### Step 1: Create the consent link 1. In Herd, go to **Settings → Integrations** and open the **Microsoft Entra ID** card (in the **Identity** section). 2. Under **Connect without a client secret**, select **Create consent link**. 3. Select **Copy link** and send it to your Microsoft administrator. If you hold the role yourself, open it in your own browser. {% hint style="info" %} Each link works once and expires after 24 hours. Creating a new link cancels any earlier one. {% endhint %} ### Step 2: The administrator approves it 1. The administrator opens the link and signs in to Microsoft, if they are not already signed in. 2. Microsoft shows a **Permissions requested** screen for Herd's directory sync app, listing the read permissions in [What Herd can read](#what-herd-can-read). They select **Accept**. 3. The browser returns to Herd for a moment and then goes back to Microsoft to sign the administrator in. This sign-in is how Herd confirms which tenant approved and that the person holds an administrator role. Microsoft may show a second, smaller consent prompt for the sign-in itself; accept it. 4. Herd shows a confirmation page: > Microsoft Entra ID is connected to the Herd organization "*your organization*". The first directory sync has started; you can close this tab. The administrator should check that the organization named is yours. {% hint style="warning" %} Until Herd completes Microsoft's publisher verification, the consent screen marks Herd's app as **unverified**. Tenants that only allow consent to apps from verified publishers will block the link; use Option B. {% endhint %} ### Step 3: Check the first sync The first sync starts on its own. Back in Herd, the tile shows **Connected with: Herd's Entra app, approved by your Global Administrator (no secret stored in Herd)**, then the last sync time and the number of users and groups synced. **Sync Users & Groups** runs a sync at any time. ## Option B: Use your own app registration and client secret On the **Microsoft Entra ID** card, expand **Use your own app registration and client secret instead** to see the form used in Step 6. ### What You'll Need * Admin access to your Microsoft Entra ID (Azure AD) tenant * About 10 minutes ### Step 1: Create an App Registration 1. Go to [Azure Portal](https://portal.azure.com) 2. Navigate to **Microsoft Entra ID (Azure AD)** > **App registrations** 3. Click **+ New registration** 4. Fill in: * **Name**: `Herd User Sync` (or any name you prefer) * **Supported account types**: Select "Accounts in this organizational directory only" * **Redirect URI**: Leave blank 5. Click **Register** ### Step 2: Note Your IDs After creating the app, you'll see the **Overview** page. Copy these values, because you'll need them later: | Field | Where to Find It | | --------------------------- | -------------------------- | | **Application (client) ID** | Overview page, top section | | **Directory (tenant) ID** | Overview page, top section | ### Step 3: Create a Client Secret 1. In your app registration, go to **Certificates & secrets** 2. Click **+ New client secret** 3. Add a description (e.g., "Herd Sync") 4. Choose an expiration (recommended: 24 months) 5. Click **Add** 6. **Copy the secret value immediately.** You won't be able to see it again ### Step 4: Add API Permissions 1. Go to **API permissions** 2. Click **+ Add a permission** 3. Select **Microsoft Graph** 4. Select **Application permissions** (not Delegated) 5. Search for and add these permissions: | Permission | Purpose | | -------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `User.Read.All` | Read all users | | `Group.Read.All` | Read all groups | | `GroupMember.Read.All` | Read group memberships | | `Application.Read.All` | Recommended. Lists enterprise apps for the Stack section in **Settings → Context**. User and group sync work without it. | | `AuditLog.Read.All`, `Domain.Read.All`, `IdentityRiskyUser.Read.All` | Recommended. Let Herd read [account posture signals](#account-posture-signals) for risk scoring. `AuditLog.Read.All` also feeds the [device posture signals](#device-posture-signals). User and group sync work without them. | | `DeviceManagementManagedDevices.Read.All` | Recommended. Lets Herd read your Intune device inventory for the [device posture signals](#device-posture-signals). Needs a Microsoft Intune subscription. User and group sync work without it. | 6. Click **Add permissions** {% hint style="info" %} If the Stack app sync in **Settings → Context** finds 0 apps, Herd now names the missing permission. Add `Application.Read.All` and grant admin consent again. {% endhint %} ### Step 5: Grant Admin Consent After adding permissions, you must grant admin consent: 1. Still on the **API permissions** page 2. Click **Grant admin consent for \[Your Organization]** 3. Click **Yes** to confirm 4. Verify all permissions show a green checkmark under "Status" ### Step 6: Configure in Herd 1. Log into Herd as an admin 2. Go to **Settings → Integrations** and open the **Microsoft Entra ID** card (in the **Identity** section) 3. Expand **Use your own app registration and client secret instead**, then enter: * **Tenant ID (Directory ID)**: From Step 2 * **Application (Client) ID**: From Step 2 * **Client Secret**: From Step 3 4. Click **Save Configuration**. Herd automatically runs a connection test as part of saving, and there is no separate "Test Connection" button. If the test fails, the configuration is not saved and an error is shown. {% hint style="info" %} **One Microsoft tenant, one Herd organization.** A tenant can be connected to only one Herd organization, whichever way it is connected. If the tenant is already connected elsewhere, the save or the consent is refused. {% endhint %} ## What gets synced Herd syncs the **member** accounts in your tenant. Entra **B2B guest** accounts (user type *Guest*) are skipped: they are not created as Herd users, do not receive trainings or simulations, and are not counted in your roster. The same rule applies to the [Microsoft Teams](/herd-security-docs/getting-started/teams-setup.md) directory sync and to Teams app installs. {% hint style="info" %} Guests are skipped, never removed. A guest account that was synced before this rule took effect keeps its Herd record, assignments, and group memberships; only its Entra details stop updating. If you model real staff as guest accounts, let your Herd contact know so those people are not left out. {% endhint %} ## How often Herd syncs * **User changes every 15 minutes.** New hires, deactivations and profile changes in Entra reach Herd in about 15 minutes. Herd asks Microsoft Graph only for what changed since the last check, so a quiet round reads almost nothing. * **Groups, memberships and managers every 2 hours.** * **A full listing once a day,** overnight (Pacific time), which re-reads every user and catches anything the incremental rounds can't see. With a [sync scope](#sync-scope-syncing-only-selected-groups) set, the 15-minute rounds don't apply: group membership changes don't show up in Graph's change feed, so each 2-hourly run lists every user in full instead. **Sync Users & Groups** on the tile always runs a full sync straight away. ## Sync scope: syncing only selected groups By default Herd syncs every member account in your tenant. To bring in only part of it, scope the sync to chosen Entra groups. Members of groups nested inside a selected group count too. Scoping works with either connection option and needs no extra permission: it reads memberships under **GroupMember.Read.All**, which both already hold. It is available on every plan. Once Entra is connected, the tile shows the current scope (**Sync scope: entire tenant (all users).** by default) with an **Edit sync scope** button. 1. Click **Edit sync scope** to open the **Entra sync scope** dialog. Use **Search groups** to filter by group name and tick the groups to keep in sync. Leaving every group unticked syncs the whole tenant. 2. Click **Review changes**. Herd shows what applying the scope would do before anything is written: how many users are in the selected groups and how many would be excluded by sync scope. 3. Click **Apply scope** to save and start a sync, or **Back** to change the selection. Users who leave every selected group are **excluded by sync scope: hidden, not deleted**. Adding them back to a selected group restores them. To return to a full-tenant sync, open the dialog, click **Clear selection** and then **Clear scope**; the sync that follows restores everyone the scope excluded. See [Okta's sync scope](/herd-security-docs/okta/okta-group-and-app-sync.md#sync-scope-syncing-only-selected-okta-groups) for what an excluded user keeps. Disabling the integration clears its sync scope and releases the people it excluded. ## What Herd can read Both options use the same Microsoft Graph **application** permissions. All are read-only: Herd cannot create, change or delete anything in your directory, and cannot read mail or files through them. **AuditLog.Read.All** lets Herd read each user's MFA registration and latest sign-in time, and the device each successful sign-in came from (see [Device posture signals](#device-posture-signals)). | Permission | What Herd uses it for | | ------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **User.Read.All** | The user list: name, user principal name and mail addresses, job title, department, office location, city, state and country, phone numbers, employee ID and type, account status, user type, created date, assigned licenses, and each person's manager. | | **Group.Read.All** | The group list: name, description, mail address and group type. | | **GroupMember.Read.All** | Group memberships, so group targeting stays current and a sync scope can be limited to chosen groups. | | **Application.Read.All** | The names and publishers of your enterprise applications, for the Stack section. Herd's app always requests it. On your own app registration it is optional. | | **AuditLog.Read.All** | Account posture: whether each user has registered MFA and with which methods (the authentication methods registration report), and each user's latest sign-in time, for the [account posture signals](#account-posture-signals). Device posture: the device each successful sign-in came from (the sign-in log), for the [device posture signals](#device-posture-signals). Recommended. Sign-in activity and the sign-in log need Microsoft Entra ID P1 or P2. | | **Domain.Read.All** | Account posture: which of your domains are managed and which are federated, so Herd only judges MFA for users whose MFA Entra can see. Domain names and sign-in type only. Recommended. | | **IdentityRiskyUser.Read.All** | Account posture: whether ID Protection rates a user at risk or has confirmed them compromised, and the risk state and level. Read only; Herd never dismisses or confirms risk. Recommended. Needs Microsoft Entra ID P2. | | **DeviceManagementManagedDevices.Read.All** | Device posture: Microsoft Intune's managed-device inventory, meaning each device's primary user, name, operating system, Entra device ID, compliance state and last check-in. Read only; Herd never wipes, retires or changes a device. Recommended. Needs a Microsoft Intune subscription. | Herd's app requests the last four as well. On your own app registration they are optional; without them, the signals they feed are not measured. With Option A, the sign-in in step 2 asks only for **openid**, which lets Herd read the administrator's tenant and directory roles from that one sign-in. Herd stores your tenant ID and no credential of yours: it authenticates with its own app's secret, against your tenant only. To review the access in Microsoft: **Entra admin center → Enterprise applications → Herd Directory Sync → Permissions** (Option A), or **App registrations → your app → API permissions** (Option B). ## Account posture signals With **AuditLog.Read.All**, **Domain.Read.All** and **IdentityRiskyUser.Read.All**, Herd reads four account-posture signals from Entra each night, before risk scores are recalculated. They count toward the **Account & access hygiene** [risk factor](/herd-security-docs/intelligence/intelligence.md#risk-score), at the same weights as the matching Okta signals: | Signal | Counts while | | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | No MFA registered | Entra's registration report says the user hasn't registered MFA. Only users on a managed (not federated) domain, and not also linked to Okta in Herd, are checked, because MFA done at a federated identity provider is invisible to Entra. | | Only phishable MFA | Every method the user has registered is a phone, email or security-question method. | | Dormant account | The account is enabled and its latest sign-in of any kind is 90 or more days old. An account with no recorded sign-in isn't scored. | | Account at risk | ID Protection rates the user at risk at medium or high, or has confirmed them compromised. | Each signal stops counting as soon as the condition clears. If Herd can't read a signal because a permission or licence is missing, that signal is **not measured**: it counts for nobody, and the Entra tile lists each unmeasured signal with the permission or licence it needs. It is never shown as an error, and user and group sync are unaffected. {% hint style="info" %} **Connected before these permissions were added?** Microsoft keeps an existing tenant's earlier grant until a Global Administrator approves again. On the Entra tile, select **Re-approve Herd's access** and have it approved in the same tenant. With your own app registration (Option B), add the three permissions and grant admin consent again. The same applies to **DeviceManagementManagedDevices.Read.All** for the [Intune device inventory](#intune). {% endhint %} ## Device posture signals With **AuditLog.Read.All**, Herd also reads the successful sign-ins logged since its last read (at most the last week) from the Entra sign-in log each night. For a very busy tenant it reads only the most recent sign-ins, up to a fixed amount a night. From each entry it keeps only who signed in, when, and the device: its name, operating system, browser family, and whether your organization manages it and it is compliant. It keeps no IP address, location or application. Two signals count toward the **Account & access hygiene** [risk factor](/herd-security-docs/intelligence/intelligence.md#risk-score): | Signal | Counts while | | ------------------------------------ | --------------------------------------------------------------------------------------------------------------- | | Signed in from an unmanaged device | The person signed in from a device your organization does not manage at least once in the last 30 days. | | Signed in from a noncompliant device | The person signed in from a managed device that fails your compliance policy at least once in the last 30 days. | Failed sign-ins are ignored: a sign-in your Conditional Access policy blocked because the device is unmanaged is the control working. A device stops counting 30 days after its last sign-in, or as soon as it signs in managed and compliant. The first time Herd sees a person sign in from a new unmanaged device (a browser on a device Entra does not know counts), it also raises a **Sign-in from an unmanaged device** event (Microsoft 365) that you can map under **Settings → Event workflows** to assign a training (the BYOD and Device Hardening trainings are suggested) or notify admins. The first night's read is taken as the starting inventory and raises no events, and at most 100 events go out a night; the rest follow on later nights. The sign-in log needs **Microsoft Entra ID P1 or P2**. Without it, or without **AuditLog.Read.All**, the Entra tile shows the device signal as not measured, its signals count for nobody, and sync is unaffected. ### Intune With **DeviceManagementManagedDevices.Read.All**, Herd also reads your Intune device inventory each night and records every device against its primary user (matched by their Entra account, or by user principal name against their email). An Intune device is managed by definition; its compliance comes from Intune: | Intune compliance state | Counts as | | -------------------------------------------------------------------- | ------------------------------ | | Compliant | Compliant | | Not compliant, or Conflict | Noncompliant | | In grace period, Unknown, Error, or managed by Configuration Manager | Not known (counts for nothing) | Where Intune and the sign-in log describe the same device (Intune's Entra device ID), Intune's verdict is the one that counts. This is how a hybrid-joined PC is judged: the sign-in log reports those as noncompliant whenever no compliance policy evaluated them, so Herd ignores the sign-in log's compliance for them and uses Intune's evaluation instead. Where Intune's state counts for nothing, a definite verdict from the sign-in log still stands. A complete Intune read is the whole inventory: a device Intune no longer lists for a person (retired, deleted, a new primary user) stops counting for them on that read. A tenant without an Intune subscription, or one that has not granted the permission, shows **Intune devices** as not measured on the Entra tile. Intune's earlier rows stop counting at once, and sync and the other signals are unaffected. A tenant that consented to Herd's app before this permission was added keeps its earlier grant until a Global Administrator selects **Re-approve Herd's access**. ## Switching between options * **Client secret → Herd's app.** On a tile connected with your own app, **Switch to Herd's app and stop sharing a client secret** offers the same consent link. Have it approved in the **same** Microsoft tenant: the connection moves to Herd's app and Herd deletes the stored secret. A link approved in a different tenant is refused. * **Herd's app → client secret.** Open **Use your own app registration and client secret instead** and save the form with your app's details. * **Re-approve.** On a tile connected with Herd's app, **Re-approve Herd's access** creates a fresh link for the same tenant. * **A different directory.** A consent link never replaces an active connection with another tenant: select **Disable Integration** first, then create the link. The client-secret form has no such check. Saving it with a different tenant ID re-points the sync at that directory straight away, so change the tenant ID only when you mean to switch directories. ## Revoking access Do both of these to end the connection completely: 1. **In Herd:** on the Entra tile, select **Disable Integration**. Syncing stops and any sync scope you set is cleared. Users and groups already synced stay in Herd. 2. **In Microsoft:** in the Entra admin center, go to **Enterprise applications → Herd Directory Sync → Properties** and select **Delete**. This removes Herd's app and its permissions from your tenant, and Herd can no longer read the directory. With Option B, delete the client secret or the app registration instead. Disabling the integration in Herd does not release your tenant for use by a different Herd organization. Contact Herd support if you need to move a tenant to another organization. ## Troubleshooting ### Creating the link | Message in Herd | What to do | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | The tile shows no **Create consent link** button | Herd's app is not available for your organization's Microsoft cloud (GCC High). Use Option B. | | **Only a Herd admin who signs in with a verified email and password, or through this organization's Microsoft Entra single sign-on, can create a consent link.** | You are signed in another way: through Okta or Google single sign-on, from Slack, or on an account whose email is not verified. Sign in with email and password, or use Option B. | | **Your single sign-on session predates a change to this organization's Microsoft Entra sign-in.** | Sign out of Herd, sign back in through Microsoft and create the link again. | | **Herd's Entra app is available only for the commercial Microsoft cloud** | Use Option B. | | **Could not create an admin consent link. Try again shortly.** | A temporary fault on Herd's side. Try again in a minute. | ### Approving the link The administrator sees these as a plain page after approving. Unless the message says otherwise, the link is spent once Microsoft has signed the administrator in: create a new one before trying again. | Message | What it means and what to do | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **This Herd consent link is invalid or has expired.** | The link is older than 24 hours or was altered when it was copied. Create a new link. | | **This Herd consent link has already been used or was replaced by a newer one.** | Links work once, and a new link cancels the earlier ones. Create a new link and send only that one. | | **This Herd consent link has expired.** | The link was created before a Herd update. Create a new link. | | **Consent was not granted, so Herd cannot sync your directory yet.** | The administrator cancelled, or Microsoft refused the consent, for example because your tenant blocks apps from unverified publishers. The same link can be opened again while it is still valid. | | **Only a Global Administrator or Privileged Role Administrator can connect your directory to Herd.** | The person who approved does not hold either role in that tenant. If the role is assigned through Privileged Identity Management, activate it first. Then create a new link. | | **This consent was granted in a different Microsoft tenant than the one the person who created this link signs in to Herd through…** | The link was created through your organization's Entra single sign-on and approved in another tenant. Have it approved in your own tenant. | | **…the email the link's creator signs in to Herd with is not a member's sign-in name (userPrincipalName) in your Microsoft directory.** | The creator signed in through single sign-on, and the email Microsoft sent Herd is their mail address, not their user principal name. Create the link from an account whose email is its user principal name, or from an email-and-password sign-in with that address. | | **This consent link was created by someone who is not a member of your Microsoft directory…** | The creator's Herd sign-in email is not the user principal name of an enabled member of the approving directory: it may be a guest, a disabled account, an alias, or someone outside your organization. If you did not expect the link, do not retry. | | **Herd could not yet confirm that the person who created this link belongs to your Microsoft directory; Microsoft can take a few minutes to apply a new consent.** | Microsoft had not finished applying the consent when Herd checked. Wait a few minutes, create a new link and approve again. | | **This Microsoft tenant is already connected to another Herd organization. Contact Herd support.** | One tenant connects to one Herd organization. Contact Herd support. | | **This Herd organization is already connected to a different Microsoft directory.** | Select **Disable Integration** on the Entra tile, then create a new link. | | **Herd could not check this consent link just now. Open the same link again in a minute.** | A temporary fault on Herd's side. The link is still valid; open it again. | | **Herd could not confirm the consent.** | Herd could not verify Microsoft's sign-in response. Create a new link and try again. If it repeats, contact Herd support. | | **Invalid admin consent response.** | The page was opened without Microsoft's response, for example from a bookmark. Open the consent link itself. | | **Herd's Microsoft Entra app is not configured. Contact Herd support.** | Contact Herd support. | {% hint style="danger" %} When Herd refuses a consent, Microsoft has usually already added Herd's app to the tenant that approved it. Herd has not connected that directory and does not sync it. If the link was unexpected, remove the app: **Entra admin center → Enterprise applications → Herd Directory Sync → Properties → Delete**. {% endhint %} ### After connecting * **The Stack section lists no Entra apps (Option B).** Grant **Application.Read.All** to your app registration and grant admin consent again. User and group sync are unaffected. * **The SharePoint policy library says it needs your own Azure AD app registration.** Herd's directory sync app reads users and groups only and cannot be given SharePoint access. Connect with Option B and grant your app **Sites.Read.All** and **Files.ReadWrite.All**. * **Warning: consecutive sync failures.** Check that Herd's app (or your own app and its secret) still exists in your tenant and still has its permissions, then select **Sync Users & Groups**. ### Client secret errors (Option B) #### Error: 403 Forbidden This means permissions are missing or not consented: 1. Go back to **API permissions** in Azure Portal 2. Verify all 3 permissions are listed 3. Check that each has **Application** type (not Delegated) 4. Click **Grant admin consent** again 5. Wait 5-10 minutes for changes to propagate 6. Retry the connection test #### Error: Invalid Client The Client ID or Client Secret is incorrect: 1. Double-check the Client ID matches exactly 2. Create a new Client Secret and try again 3. Make sure you copied the secret **Value**, not the Secret ID #### Error: Unauthorized Client Admin consent was not granted: 1. Go to **API permissions** 2. Click **Grant admin consent for \[Your Organization]** 3. Ensure you're signed in as an Azure AD admin ### Security Notes * Both Herd's app and your own app registration only have **read** permissions; neither can modify your directory * With Option A, no secret is stored in Herd. You can revoke access at any time by removing Herd's app from **Enterprise applications** in Entra ID * With Option B, we recommend setting a calendar reminder to rotate the client secret before it expires * With Option B, you can revoke access at any time by deleting the app registration ## Questions? Contact for assistance.