After Microsoft Entra is connected, your organization can decide which email domains are allowed to sign in, whether new users receive a default role, and when single sign-on should become mandatory.
Who this is for
This article is for organization admins who are preparing to move from an optional Entra connection to a controlled identity policy for staff and invited users.
What these settings control
- Allowed email domains: limit organizational access to approved work domains
- Default role: assign a baseline Divorcepath role when a new Entra user joins
- Role mapping required: require users to match an explicit Entra group-to-role mapping before access is granted
- SSO enforced: require organization members to authenticate through Microsoft Entra instead of separate Divorcepath credentials
Recommended rollout order
- Connect Microsoft Entra and verify the tenant
- Set allowed domains for the organization
- Choose a default role or create explicit role mappings
- Test sign-in with a small pilot group
- Enforce SSO only after the pilot group is working correctly
How to set allowed domains
Add only the work domains your organization expects to use. If you leave the allowlist empty, Divorcepath will not restrict access by domain. If you populate it, users signing in through unapproved domains should be blocked before they gain organizational access.
How to choose between a default role and required mappings
If your organization wants a fast rollout, assign a conservative default role and review access after pilot sign-in. If your organization needs tighter control, require role mappings and map specific Entra groups to Divorcepath roles before broader deployment.
When to enforce SSO
Enforce SSO only after admins have confirmed the tenant connection, domain restrictions, and role behavior with real user accounts. Turning on SSO too early can lock users out if their domain or role mapping is not configured correctly.
What success looks like
- only approved domains can access the organization through Entra
- new users receive the intended default role or mapped role
- pilot users can sign in without fallback account confusion
- SSO enforcement does not block legitimate staff access
Common rollout mistakes
- enforcing SSO before allowed domains are confirmed
- turning on required role mappings before the mappings are created
- using a permissive default role longer than intended
- testing with Microsoft accounts that do not belong to the organization tenant
When to contact support
If users can authenticate through Microsoft but are blocked unexpectedly, or if enabling SSO creates access loops your admins cannot resolve, contact Divorcepath support at [email protected].
