Setting up Microsoft Entra single sign-on for DeXMI: a guide for your IT team and your Company Admin

DeXMI can sign your people in with their Microsoft Entra ID work account, so they don't need a separate DeXMI password. Two people set it up together: a DeXMI Company Admin, who works in DeXMI, and an Entra administrator, who works in the Microsoft Entra admin center. Allow about 45 minutes, plus however long your DNS change takes to publish.

This guide follows the steps in the order DeXMI's Settings → Single sign-on page shows them. Nothing changes for your people until you choose Optional or Required in step 4, apart from the break-glass admins you choose in step 5, who must then use a passkey.

At a glance

Before you start

You'll need:

• A DeXMI Company Admin. Single sign-on is set up in DeXMI under Settings → Single sign-on, which only Company Admins can open. Each change there needs a second factor from the last 15 minutes: DeXMI asks them to Confirm it's you with their DeXMI passkey or authenticator app, or with a fresh Microsoft sign-in.
• An Entra administrator who can grant admin consent. DeXMI asks only for delegated sign-in permissions, so a Cloud Application Administrator or an Application Administrator can approve it, as can a Privileged Role Administrator [1].
• Access to your DNS, to publish one TXT record for each email domain.
• An email address on a verified domain for everyone who'll sign in. At a person's first Microsoft sign-in, DeXMI links their existing account, or creates one, using the email address Microsoft sends from their Email property, and only when Microsoft says its domain is verified in your tenant [6]. Accounts with an Exchange Online mailbox have one already. For a cloud-only account without a mailbox, set Email under the user's Properties → Contact information in the Entra admin center; for an account synced from on-premises Active Directory, set its mail attribute there.
• Matching addresses. To link someone's existing DeXMI account, their Entra email must be the address their DeXMI account uses. If it's different, DeXMI can't link them, and with Create accounts on first sign-in on it creates a second account. Check your people's addresses before you switch Microsoft sign-in on.
• MFA at Microsoft for everyone who'll use DeXMI. Microsoft's Security defaults alone isn't enough: see Require MFA at Microsoft.
• The right licences. Assigning DeXMI to individual people works on every Entra ID edition. Assigning it to groups needs Microsoft Entra ID P1 or P2 [3], and so does Conditional Access [5].

Require MFA at Microsoft

Microsoft tells DeXMI how each person signed in, in the token's amr claim [6]. With Also require multi-factor sign-in at Microsoft for everyone on, which is the default, DeXMI accepts a Microsoft sign-in only when amr contains mfa. Leave it on: with it off, DeXMI still requires MFA from Microsoft wherever a password sign-in would ask for a second factor, for example from anyone who has set up their own DeXMI second factor. Anyone refused is told: "Microsoft didn't ask you for a second factor, and your organisation requires one. Ask your IT administrator to require multi-factor authentication for DeXMI in Microsoft Entra."

So Microsoft has to ask for MFA every time someone signs in to DeXMI. Use one of these.

With Microsoft Entra ID P1 or P2: Conditional Access (recommended). P1 is included in Microsoft 365 Business Premium and E3, and E5 includes P2.

1. In the Microsoft Entra admin center, open Entra ID → Conditional Access → Policies, and create a policy, or start from Microsoft's Require multifactor authentication for all users template [4].
2. Users: include All users, or the people and groups assigned to DeXMI. Exclude your emergency access accounts [9].
3. Target resources: All resources, or DeXMI. Don't exclude DeXMI from an "All resources" policy [4].
4. Grant: Require authentication strength, with the built-in Multifactor authentication strength [8]. If your MFA comes from a third-party provider through Entra's external authentication methods, use Require multifactor authentication instead [4]. If you'll turn on Also require a passkey or security key at Microsoft for everyone in DeXMI, choose the built-in Phishing-resistant MFA strength [8].
5. Enable policy: Microsoft suggests starting in Report-only [4]. While a policy is report-only, Microsoft doesn't ask anyone for MFA [11], so DeXMI refuses their Microsoft sign-ins: switch the policy On before you choose Optional or Required in step 4.

Without P1: per-user MFA. This is Microsoft's legacy setting. Microsoft no longer recommends it, but it's still available on every Entra ID edition [12]. People it covers are asked for MFA every time they sign in [13].

1. In the Microsoft Entra admin center, as at least an Authentication Policy Administrator, open Entra ID → Users → Per-user MFA [14].
2. Select everyone who'll use DeXMI and choose Enable MFA. Each person moves to Enforced once they've registered a method; people who are already registered can be set to Enforced straight away [13].

Microsoft documents per-user MFA as an alternative to Security defaults, not an addition to it [12]. We've tested it with Security defaults left on: Microsoft then asked those people for MFA at every sign-in. If you use Conditional Access, don't use per-user MFA as well [13].

Security defaults alone isn't enough. Security defaults makes everyone register for MFA, but Microsoft then asks ordinary users for it only "when necessary", based on factors such as location, device, role and task [10]. Sign-ins where Microsoft didn't ask reach DeXMI without mfa, and DeXMI refuses them.

Also check your exceptions. Exempting trusted locations or IP ranges from MFA, or excluding DeXMI from your MFA policy, leaves those sign-ins without MFA, and DeXMI refuses them.

Check the result with the test sign-in (step 3), using an ordinary account: the test passes whether or not Microsoft asked for MFA, so check that its sign-in methods include mfa. Under Security defaults Microsoft asks administrators for MFA at every sign-in anyway [10], so an administrator's test can show mfa when your people's sign-ins wouldn't.

What DeXMI asks Microsoft for

DeXMI signs people in with OpenID Connect. Its app asks only for the sign-in scopes openid, profile and email, which let it sign a person in and read their name and email address [7]. It asks for no access to mail, files, calendars or your directory. People type their password, and complete MFA, on Microsoft's own sign-in page, so DeXMI never sees their Microsoft password.

Microsoft's consent page also shows "Maintain access to data you have given it access to". Microsoft shows that line on every consent page: it stands for offline_access, and doesn't let DeXMI read anything beyond sign-in, basic profile and email [7].

From the token Microsoft sends at sign-in, DeXMI reads:

For your security review

The application ID is the one Microsoft's consent page shows. Check it there before you accept.

Step 1: connect your Microsoft tenant

Your Company Admin selects Connect Microsoft Entra ID. The browser goes to Microsoft's admin consent page, login.microsoftonline.com/organizations/v2.0/adminconsent, with DeXMI's application ID. There, an administrator with one of the roles above signs in, reviews the permissions and accepts [1]. Accepting adds DeXMI to your tenant's Enterprise apps, and DeXMI records your tenant ID.

The consent has to finish within 10 minutes, in the browser that started it, because DeXMI ties each request to that browser. If your Company Admin doesn't hold one of the roles, do this step at their computer and have your Entra administrator sign in on Microsoft's page. When it's done, sign the Entra administrator out of Microsoft in that browser, so the Company Admin's next Microsoft sign-in isn't made as them.

Consent alone switches nothing on. The connection waits 7 days for a test sign-in (step 3); after that, connect again.

Then, in the Microsoft Entra admin center, open Entra ID → Enterprise apps → DeXMI:

1. Properties: set Assignment required to Yes, then save. Only the people and groups you assign can then sign in to DeXMI. Left at No, every user in your tenant can, and so can any external user you invite [2].
2. Users and groups: assign each person or group one of DeXMI's two app roles.

A group assignment covers its direct members only: nested groups aren't followed [3]. A Microsoft sign-in creates a DeXMI account only for someone with one of these roles, and Company Admin wins if a person has both. With Roles from Entra on (the default), someone without a role is refused, and a person's Company Admin or Company User role follows their assignment each time they sign in; any custom DeXMI roles they hold are left alone. Entra can't demote your last active Company Admin: that sign-in is refused instead.

Global Administrators can sign in to any app whatever Assignment required says [2]. With Roles from Entra on, DeXMI still refuses anyone without one of its app roles.

Step 2: verify your email domains

In Settings → Single sign-on, your Company Admin adds each email domain your people sign in with, such as example.com.au (up to 20). DeXMI shows a TXT record to publish:

Once the record is published, the Company Admin selects Verify. Only a verified domain sends its people to Microsoft sign-in, and a Microsoft sign-in can link or create an account only for an email on a verified domain.

Each domain is verified on its own: verifying example.com.au doesn't cover mail.example.com.au. A verified domain belongs to one DeXMI organisation. If you can't change DNS quickly, add the domain anyway, then email support@dexmi.ai: we can verify it by hand once we've confirmed the request with you.

If you also use DeXMI Data Core, keep its record too: see If you also use DeXMI Data Core.

Step 3: run a test sign-in

Within 7 days of the consent, your Company Admin selects Run a test sign-in. Microsoft's account picker opens: sign in with an ordinary account from your tenant that's assigned DeXMI, a member rather than a guest, whose email is on a domain you verified in step 2. The test signs nobody in to DeXMI. It shows what Microsoft sent: name, email, account type, app roles, sign-in methods (amr), when they signed in to Microsoft, and your tenant and object IDs.

A successful test switches the connection on. On a first set-up, nobody is offered Microsoft sign-in until you choose Optional or Required in step 4; if you're reconnecting, the mode you chose before applies as soon as the test passes. The test proves that the tenant you consented from is really yours, which is why it must be done by a member of your tenant.

Use an ordinary account, not an administrator's. Microsoft treats administrators differently: under Security defaults it asks them for MFA at every sign-in [10], and Global Administrators get past Assignment required [2]. So an administrator's test can show MFA when your people's sign-ins wouldn't.

If the test fails, DeXMI shows the reason, such as no email address from Microsoft, a domain Microsoft doesn't vouch for, or a guest account. A test can pass and still show something that would stop your people: check that the app roles include Company Admin or Company User, and that the sign-in methods include mfa. Without mfa, Microsoft didn't ask for a second factor: see Require MFA at Microsoft. Then test again.

Step 4: choose how DeXMI uses Microsoft sign-in

Optional and Required become available once a test sign-in has passed.

Before you choose Required:

• DeXMI needs at least one break-glass admin (step 5).
• Everyone active, people you've invited included, must have an email on one of your verified domains, apart from your break-glass admins. If anyone doesn't, DeXMI refuses and says how many: verify their domains, or deactivate them, first.
• DeXMI warns you about people who haven't signed in with Microsoft yet.

When Required is on:

• invitations send a "sign in with Microsoft" email instead of an activation link, and only addresses on your verified domains can be invited;
• for everyone except your break-glass admins, passwords are kept but refused, "Forgot password?" sends no link, and password sessions end at their next refresh;
• a domain people use can't be removed, and your last break-glass admin can't be unmarked or deactivated.

To switch Microsoft sign-in off: set the mode to Off, or turn it off in step 1. Everyone who signed in with Microsoft is signed out at once; password sessions carry on. Moving between Optional and Required signs out nobody who signed in with Microsoft, but moving to Required ends other people's password sessions at their next refresh, apart from your break-glass admins'.

Step 5: choose break-glass admins

Up to two Company Admins keep a DeXMI password and a passkey, for when Microsoft sign-in is unavailable or misconfigured. Required mode needs at least one. Each must be an active Company Admin with their own DeXMI password and a registered passkey. A Company Admin without a password sets one first with Forgot password? on DeXMI's sign-in page while the mode isn't Required, then registers a passkey in DeXMI.

While flagged, a break-glass admin's password sign-in always needs a passkey, never a recovery code or an authenticator code, so a second passkey is their backup, and another admin can't reset their MFA. Signing in with Microsoft, they need what any Company Admin needs. Assign them Company Admin in Entra: with Roles from Entra on, a Microsoft sign-in as Company User makes them a Company User and removes their break-glass flag. Their password sign-ins are logged, and in Required mode each one alerts DeXMI's security team.

What your people see

• The sign-in page asks for their email first, then Continue.
• On a verified domain, in Optional or Required mode, they see Sign in with Microsoft and select Continue with Microsoft. Microsoft's own page then asks for their password and MFA.
• In Optional mode, Use a password instead keeps their DeXMI password available. In Required mode, Administrator sign-in is for your break-glass admins only.
• At their first Microsoft sign-in, DeXMI links their existing account by email, or creates one if Create accounts on first sign-in is on and they have an app role. After that, DeXMI recognises them by their Microsoft identity.
• Your Company Admins see a Microsoft badge on people who sign in with Microsoft, and a Break-glass badge on break-glass admins. Unlink Microsoft identity ends someone's sessions; their next Microsoft sign-in links them again by email.
• If DeXMI refuses someone, the sign-in page says why. For example: "Your organisation hasn't given you access to DeXMI. Ask your IT administrator. Guest accounts and personal Microsoft accounts can't sign in to DeXMI with Microsoft." (such as no app role, a guest or personal account, an email problem, or no DeXMI account while Create accounts on first sign-in is off), or "Microsoft didn't ask you for a second factor, and your organisation requires one. Ask your IT administrator to require multi-factor authentication for DeXMI in Microsoft Entra."

If you also use DeXMI Data Core

DeXMI and DeXMI Data Core are separate apps with their own Microsoft connections. To use Microsoft sign-in in both:

• Consent twice. Data Core has its own application in Microsoft, "DeXMI Data Core", with its own application ID. Each appears separately in Enterprise apps.
• Assign people in each app. Data Core's roles are Administrator and Viewer.
• Publish both TXT values. Both apps use the same record name, _dexmi.<your domain>, with different values: DeXMI's starts dexmi-domain-verification= and Data Core's starts dexmi-data-core-domain-verification=. A TXT record name can hold several values, so add the second one beside the first. Replacing one with the other breaks the first app's verification.
• Choose settings in each app. Modes, options and break-glass admins are set separately in each.

Data Core has its own setup guide.

What the first version doesn't support

• Guests and personal Microsoft accounts. Microsoft sign-in to DeXMI is for members of your tenant (acct 0) [6]. B2B guests and personal Microsoft accounts are refused. If guests need DeXMI, keep the mode at Optional, and they can keep a DeXMI password with DeXMI's own MFA.
• More than one identity provider. Each DeXMI organisation connects one Microsoft Entra tenant, and a Microsoft tenant can be connected to one DeXMI organisation. To connect a different tenant, select Turn off Microsoft sign-in in step 1 (setting the mode to Off isn't enough), then Connect a different tenant. DeXMI connects with OpenID Connect only, not SAML.
• Automatic provisioning. DeXMI doesn't support SCIM. Accounts are created at first sign-in, and with Roles from Entra on, roles are updated at each sign-in.
• Instant removal from Entra. When you unassign someone, or block their sign-in, DeXMI refuses their next Microsoft sign-in, at the latest about 15 minutes after their session length runs out. In Optional mode, anyone who also has a DeXMI password can still sign in with it. To end someone's access at once, a Company Admin also deactivates them in DeXMI.

Getting help

Email support@dexmi.ai. Tell us your organisation's name in DeXMI, what you were doing, the time, and what DeXMI showed. Never send us passwords or one-time codes.

If Microsoft sign-in is broken and none of your break-glass admins can sign in, we can switch it off for your organisation once we've confirmed the request with you.

How DeXMI helps

DeXMI is an auditable decision-intelligence platform for mining. With Microsoft sign-in, your people use the work account your IT team already manages, with the MFA you require at Microsoft, and access follows the assignments you make in Entra. DeXMI adds its own checks on top: verified domains, members only, the MFA rules your Company Admin chooses, sessions that check back with Microsoft, and a recent second factor (Confirm it's you) before a Company Admin changes a sensitive setting.

FAQ

Does DeXMI see our users' Microsoft passwords? No. People type their password, and complete MFA, on Microsoft's own sign-in page. DeXMI receives a signed token that says who they are and how they signed in [6].

Do we have to send DeXMI a client secret, a certificate or our tenant's details? No. You approve DeXMI's application in your own tenant (step 1), and DeXMI records your tenant ID from that consent. DeXMI proves itself to Microsoft with its own certificate, so nothing secret passes between us.

Do people need DeXMI's own MFA as well? No. A Microsoft sign-in is never followed by a DeXMI second-factor prompt, and DeXMI doesn't ask people who sign in with Microsoft to set up its own MFA: the MFA they complete at Microsoft is what DeXMI checks. Before a sensitive change, such as a Company Admin's settings, DeXMI asks them to Confirm it's you, which a fresh Microsoft sign-in with MFA does; anyone who also has a DeXMI passkey or authenticator app can use that instead.

Can guests or personal Microsoft accounts sign in with Microsoft? Not in the first version. Microsoft sign-in is for members of your tenant. While the mode is Optional, guests can keep a DeXMI password with DeXMI's own MFA.

What happens when someone leaves? Remove their assignment, or block their sign-in, in Entra. DeXMI refuses their next Microsoft sign-in, at the latest about 15 minutes after their session length runs out (24 hours unless you change it). In Optional mode they can still use a DeXMI password if they have one, so deactivate them in DeXMI too, which also ends their access at once.

Do we need Microsoft Entra ID P1? Not to sign in with Microsoft or to assign individual people. Assigning groups and Conditional Access need P1 or P2 [3][5]. Without P1, use per-user MFA to make Microsoft ask for MFA (see Require MFA at Microsoft).

What if Microsoft sign-in is unavailable? Your break-glass admins use Administrator sign-in with their DeXMI password and a passkey. They can set the mode to Optional, after which people can set a DeXMI password with Forgot password? and sign in with it. If none of them can sign in, email support@dexmi.ai.

References

1. Microsoft, "Grant tenant-wide admin consent to an application", Microsoft Learn. https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/grant-admin-consent
2. Microsoft, "Properties of an enterprise application" (Assignment required), Microsoft Learn. https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/application-properties
3. Microsoft, "Manage users and groups assignment to an application", Microsoft Learn. https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/assign-user-or-group-access-portal
4. Microsoft, "Require MFA for all users with Conditional Access", Microsoft Learn. https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-all-users-mfa-strength
5. Microsoft, "Microsoft Entra Conditional Access: Zero Trust policy engine" (licence requirements), Microsoft Learn. https://learn.microsoft.com/en-us/entra/identity/conditional-access/overview
6. Microsoft, "Optional claims reference" (acct, email, xms_edov, and the AMR values for Microsoft Entra authentication methods), Microsoft Learn. https://learn.microsoft.com/en-us/entra/identity-platform/optional-claims-reference
7. Microsoft, "Scopes and permissions in the Microsoft identity platform" (the OpenID Connect scopes and offline_access), Microsoft Learn. https://learn.microsoft.com/en-us/entra/identity-platform/scopes-oidc
8. Microsoft, "Overview of Conditional Access authentication strengths" (built-in and custom strengths), Microsoft Learn. https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-strengths
9. Microsoft, "Manage emergency access admin accounts", Microsoft Learn. https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-access
10. Microsoft, "Configure security defaults for Microsoft Entra ID", Microsoft Learn. https://learn.microsoft.com/en-us/entra/fundamentals/security-defaults
11. Microsoft, "Conditional Access report-only mode", Microsoft Learn. https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-report-only
12. Microsoft, "Set up multifactor authentication for Microsoft 365" (legacy per-user MFA), Microsoft Learn. https://learn.microsoft.com/en-us/microsoft-365/admin/security-and-compliance/set-up-multi-factor-authentication
13. Microsoft, "Enable per-user Microsoft Entra multifactor authentication to secure sign-in events", Microsoft Learn. https://learn.microsoft.com/en-us/entra/identity/authentication/howto-mfa-userstates
14. Microsoft, "Configure Microsoft Entra multifactor authentication settings", Microsoft Learn. https://learn.microsoft.com/en-us/entra/identity/authentication/howto-mfa-mfasettings