Entra ID setup

This walks through connecting Microsoft Entra ID (Azure AD) to Intric, in the Entra admin center (entra.microsoft.com). It assumes you have Cloud Application Administrator, Application Administrator or Global Administrator rights in your tenant. Menu names below are as they appear in the admin center’s left menu; if Microsoft has moved one, the search bar at the top finds it by name.

Running Intric on your own servers

The redirect URI below, https://login.intric.ai/idps/callback, is for Intric’s hosted login service. If your installation runs its own identity provider on your own infrastructure, use your own login host instead — same /idps/callback path, your domain — and check the Callback URL shown on your IdP’s configuration page to confirm it.

Create the app registration

App registration

1. In the Entra admin center, go to Entra ID›App registrations.
2. Click New registration.
3. Give it a name your admins will recognize, for example Intric.
4. Under Supported account types, choose Accounts in this organizational directory only (single tenant).
5. Leave Redirect URI empty here — add it under Authentication in the next step, as a Web redirect URI.
6. Click Register.

Add the redirect URI

Authentication

1. On the app’s Authentication page, click Add a platform.

2. Choose Web — not Single-page application and not Mobile and desktop applications.

3. Under Redirect URIs, add exactly:

   https://login.intric.ai/idps/callback

4. Leave Logout URL empty.

5. Under Implicit grant and hybrid flows (on the newer page layout, under the Settings tab), leave both boxes (Access tokens, ID tokens) unchecked.

6. Click Configure or Save.

Caution

This is the one redirect URI to add, as a Web platform entry, and nothing else. Registering it under Single-page application instead causes Entra to issue SPA-only tokens that Intric’s server-side code exchange then rejects with AADSTS9002327 — the app looks correctly configured, but every login fails at the last step. See Troubleshooting if you hit this.

Create a client secret

Certificates & secrets

1. Go to Certificates & secrets›Client secrets.
2. Click New client secret, give it a description (for example intric-prod) and an expiry.
3. Click Add.
4. Copy the Value shown immediately after creation — not the Secret ID next to it. The Value is shown once; if you miss it, delete the secret and create a new one.
5. Note the expiry date somewhere you’ll see it again. Logins stop working the day it lapses.

Important

Plan for rotation before the secret expires: create the new secret, send Intric the new value, wait for us to confirm the swap, then delete the old secret. Doing it in that order means there’s never a gap where neither secret is valid.

API permissions

API permissions

1. Go to API permissions.
2. Confirm the delegated Microsoft Graph permission User.Read is listed — a new registration has it by default. Intric also asks for the standard sign-in permissions openid, profile and email. They don’t have to be listed, but you can add them under Add a permission → Microsoft Graph → Delegated permissions if your policy is to list every permission.
3. Click Grant admin consent for <your organization>. This is recommended, and required if your tenant doesn’t let users consent to apps themselves — otherwise users are stopped at a “Need admin approval” screen.

Make sure every user has an email address

Intric links a login to an Intric account by email address, taken from the user’s mail attribute — not the UPN. An account with no mail value can’t be linked and won’t be able to sign in.

mail is most often empty for accounts without an Exchange Online mailbox, and for accounts synced from an on-premises Active Directory where mail isn’t set. Check this for every account you plan to let sign in. Guest accounts normally have mail set; check any that fail.

If you plan to change many users’ email addresses at once, for example after a domain change, tell us beforehand.

Control who can sign in

Enterprise application

1. Go to Entra ID›Enterprise apps and open the application (same name as your app registration).
2. Under Properties, set Assignment required? to Yes.
3. Under Users and groups, add the users or groups who should be able to sign in. Assigning groups needs Entra ID P1 or P2; on a free tenant you can only assign individual users.

With assignment required set to Yes, a user who isn’t assigned sees AADSTS50105 rather than being let in. Assignment doesn’t pass down to nested groups: members of a group inside an assigned group can’t sign in until their own group is assigned too. Assigning a group here is also the first of the two steps below if you’re using Intric’s group-based access.

Groups (optional)

If you want group membership from Entra ID to control access to Spaces in Intric, configure both of the following — both are required, and in this order:

Groups claim

1. Assign the groups to the application. Entra ID›Enterprise apps›your app›Users and groups — add exactly the groups Intric should know about. Security groups and Microsoft 365 groups can be assigned; distribution lists can’t. This needs Entra ID P1 or P2 — a free tenant can’t assign groups to an application.
2. Add the groups claim, limited to those groups. Entra ID›App registrations›your app›Token configuration → Add groups claim → select Groups assigned to the application → Save. Leave “Customize token properties by type” alone — its default already sends group object IDs, which is what Intric matches on.

Caution

Do not choose Security groups or All groups instead. Both ignore the assignment list and send every group the user belongs to, which creates a flood of groups in Intric you didn’t ask for, and risks the 200-group limit below.

A few things to know before you turn this on:

• Nested groups aren’t included. With “Groups assigned to the application”, a group only appears in the token for users who are direct members of the assigned group — membership through a nested group doesn’t count. If a group you assign has other groups as members rather than users, assign those child groups directly as well, or their members will sign in with no groups and lose their access.
• Assign people through groups, not one by one. A user assigned individually, who isn’t in any assigned group, signs in with an empty groups claim and has no group-based access in Intric.
• There’s a 200-group limit per token. If a user belongs to more groups than that, Entra replaces the groups claim with an overage indicator instead of the list — which Intric can’t use, so that user syncs no groups at all and loses access to everything the groups granted. Limiting the claim to “Groups assigned to the application” keeps the count to what you actually assigned, which is normally well under the limit.
• Don’t add a claims-mapping policy, and don’t switch to sending group names instead of object IDs. Either one can break sign-in outright (AADSTS50146) or silently recreate every group in Intric under a new identity — see User groups and Troubleshooting.

Conditional Access, MFA and offboarding

Your Conditional Access and MFA policies apply every time a user signs in to Intric through Entra. Once signed in, a user’s Intric session renews itself in the background without going back to Entra, until it expires or the user signs out. So a policy change, and a change in group membership, takes effect at the user’s next sign-in, not mid-session.

The same goes for offboarding. Disabling a user in Entra ID stops their next sign-in, but doesn’t end an Intric session they already have open. To cut someone off immediately, also deactivate them in Intric’s user administration. If you need group changes and deactivations to reach Intric without waiting for a sign-in, ask us about directory sync (see User groups).

Pre-flight checklist

Before you send anything to Intric, confirm:

• App registration is single tenant
• Redirect URI is https://login.intric.ai/idps/callback, registered as Web, and nothing else is registered (no SPA, no mobile, no logout URL)
• Implicit grant is off (both boxes unchecked)
• You’ve copied the client secret’s Value, not its Secret ID, and noted its expiry
• User.Read is listed and admin consent is granted
• Every user who needs to sign in has a non-empty mail attribute
• If you’re restricting sign-in: Assignment required? is Yes and the right users/groups are assigned
• If you’re using groups: they’re assigned to the enterprise app and the groups claim is set to “Groups assigned to the application”
• You have one pilot user ready to test with

Send this to Intric

Fill in and send through a secure channel agreed with Intric support — never by plain email, since this includes a secret.

Directory (tenant) ID:
Application (client) ID:
Client secret value:
Client secret expiry date:
Using groups (yes/no):
Groups (name → object ID), if used:
  -
  -
Pilot test user (email):
Address your users open Intric at:
Technical contact (for secret expiry and changes):