> ## Documentation Index
> Fetch the complete documentation index at: https://support.legora.com/llms.txt
> Use this file to discover all available pages before exploring further.

# IT Admin guide: Legora’s global authentication

> Move your organization to Legora’s global authentication yourself from the Authentication migration page in Settings.

## Overview

This guide is for Admins and IT administrators who move their organization to Legora’s global authentication. You run the migration yourself from the **Authentication migration** page in Settings. Global authentication gives your organization its own sign-in address and one sign-in setup across Legora.

The migration has six steps. Steps 2 to 5 depend on how your organization uses Legora, so check the table to see which ones apply to you. Make every change in addition to your existing configuration. Do not remove existing URLs or settings until the migration is complete.

> [!NOTE]
>
> You need the **Let members configure SSO and IP restrictions** permission, which the Admin role includes by default. The **Authentication migration** page appears only when self-serve migration is turned on for your organization. If you have more than one Legora organization, migrate each one separately. You don’t have to migrate them at the same time.

| Step | When you need it |
| - | - |
| [1. Review your organization’s dedicated domain](#review-your-dedicated-domain) | Always |
| [2. Set up how members sign in](#update-your-identity-provider) | Your organization uses single sign-on (SSO). Without SSO, only confirm email and password sign-in |
| [3. Update integration callback URLs](#update-integration-callback-urls) | Your organization uses iManage on-premises, SharePoint, Google Drive, or Microsoft 365 with your own Entra app |
| [4. Install the Global Word and Outlook add-ins](#reinstall-word-and-outlook-add-ins) | Your organization uses the Word or Outlook add-in |
| [5. Update firewall rules](#update-firewall-rules) | Your network restricts traffic to Legora |
| [6. Enable global authentication](#enable-global-authentication) | Always, as the last step |

The **Authentication migration** page in Settings guides you through the whole migration, one step at a time and in the same order as this guide. It shows which tests have passed and what’s still missing before you can complete the migration.To open the page, from your name on the menu, select **Settings** > **People** > **Authentication migration**.

![The Authentication migration page in Settings, showing step 1 with the custom URL and the start of step 2 with existing SSO connections](https://mintcdn.com/legora/B_L1bW11lJVpQpe5/images/it-admin-guide-authentication-migration-page.png?fit=max\&auto=format\&n=B_L1bW11lJVpQpe5\&q=85\&s=0cae621dc0142902a187f2ed80aa61af)

***

## Step 1: Review your organization’s dedicated domain

This step sets the address your users sign in at after the migration. The **Authentication migration** page shows it as **Custom URL**, for example `https://acme.app.legora.com`.

> [!NOTE]
>
> **When you need this step:** Always.

1. On the **Authentication migration** page, review **Custom URL**. Legora fills it in for your organization.
2. To change it, select the edit icon next to **Custom URL**, enter a new **Subdomain**, and select **Save**.

The subdomain must be unique across Legora. Use lowercase letters, numbers, and hyphens, up to 63 characters. It can’t start or end with a hyphen. You can’t change the custom URL after you complete the migration, so choose it now.

**Check it:** **Custom URL** shows your new address, and **Complete migration** no longer asks you to set a custom URL.

***

## Step 2: Set up how members sign in

This step sets up sign-in for global authentication. You register Legora’s global sign-in service with your identity provider, such as Okta or Microsoft Entra ID, and choose whether members keep email and password. Your existing connections keep working while you prepare the new ones.

> [!NOTE]
>
> **When you need this step:** Your organization uses SSO. If it doesn’t, skip the identity provider changes and only confirm [email and password sign-in](#email-and-password-sign-in). You can’t complete the migration without that confirmation.

Legora uses one callback URL for each sign-in protocol. Add the one that matches your connection:

* **SAML:** `https://sso.legora.com/api/oauth/saml`
* **OpenID Connect (OIDC):** `https://sso.legora.com/api/oauth/oidc`

Add the callback URL in the right place for your provider:

* **Okta:** Okta supports SAML and OIDC. Add the URL for the protocol you use for Legora to **Sign-in redirect URIs** in the Legora application settings.
* **Microsoft Entra ID:** Use OIDC. Add the OIDC callback URL to the redirect URIs of the Legora app registration. See [Integration Overview - Entra ID Single Sign-on](https://support.legora.com/en-US/integration-overview-entra-id-single-sign-on.md).
* **Other identity providers:** Add the callback URL for your provider’s protocol, following your provider’s documentation.

### SAML connections

A SAML app registration is tied to Legora’s Entity ID, so you can’t point your existing SAML app at global authentication. Create a new one instead:

1. In your identity provider, create a new SAML app registration.
2. Copy **Legora entity ID** and **Legora ACS URL** from **New SAML app settings** on the **Authentication migration** page into the new app registration:
   * **Entity ID, Audience URI, or Identifier:** `https://sso.legora.com`
   * **ACS URL, Single Sign-On URL, or Reply URL:** `https://sso.legora.com/api/oauth/saml`
3. Add the attributes from [SAML attribute statements](#saml-attribute-statements).
4. Leave your existing SAML app as it is. It keeps serving sign-ins until you complete the migration.

Legora does not support more than one SAML app registration in the same Microsoft Entra tenant. If you have several, move those connections to OIDC instead of creating new SAML apps.

### SAML attribute statements

Legora reads each member’s email address and name from the SAML assertion. It matches attributes by their exact name, and it can’t sign a member in without an email address.

In Okta, set these values on the new SAML app:

| Okta setting | Value |
| - | - |
| **Name ID format** | `EmailAddress` |
| **Application username** | `Email` |
| Attribute statement `email` | `user.email` (required) |
| Attribute statement `given_name` | `user.firstName` (recommended) |
| Attribute statement `family_name` | `user.lastName` (recommended) |

Name the email attribute `email`. Legora doesn’t read other names, such as `mail`.

In other identity providers, send the member’s work email in an attribute named `email`. Send the first and last name as `given_name` and `family_name`.

### OpenID Connect scopes and claims

If your identity provider asks which OIDC scopes Legora needs, enable these:

* `openid`: Required for OIDC sign-in.
* `profile`: Provides the user’s name.
* `email`: Provides the user’s work email address.

Legora needs an email address after sign-in. Given name and family name are recommended. You don’t need a group scope. Legora organization membership controls access, and directory sync is set up separately.

If your identity provider asks for a client type, choose a standard OIDC client with the Authorization Code flow.

### Connect and test

1. Under **Existing connections**, select **Move** next to each OIDC connection to carry it over.
2. Under **New connections**, select **Add** to add each new SAML connection.
3. Select **Run test** on each connection and sign in with your identity provider.

### Email and password sign-in

This setting decides whether members can sign in with email and password after the migration. The **Email and password** card appears when members sign in with a password today. Changes apply to the new sign-in page right away, and members keep using your current sign-in page until you complete the migration.

* **Your organization uses SSO:** Under **Keep email-and-password sign-in after migration?**, choose **Yes, keep email and password** or **No, use SSO only**, then select **Save**.
* **Your organization doesn’t use SSO:** Select **Confirm** to keep email and password.

Members who keep email and password must reset their password the first time they use the new sign-in page.

**Check it:** Every active SSO connection shows **Passed**, and the **Email and password** card shows your choice.

***

## Step 3: Update integration callback URLs

This step lets your integrations send users back to Legora after they connect. You add a new redirect URL in each integration’s admin settings.

> [!NOTE]
>
> **When you need this step:** Your organization uses iManage on-premises, SharePoint, Google Drive, or Microsoft 365 with your own Entra app. Step 3 on the **Authentication migration** page lists iManage on-premises, SharePoint, and Google Drive when you need to update them. Microsoft 365 isn’t listed there, so check its **Entra app** setting yourself.

Add the new URL as an allowed redirect URI. Keep your existing URLs in place.

| Integration | URL to add | Where to add it |
| - | - | - |
| iManage on-premises | `https://app.legora.com/imanage` | Your iManage configuration, as an allowed callback URL. See [Enabling the iManage integration](https://support.legora.com/en-US/enabling-the-imanage-integration-as-an-admin-for-your-organization.md). |
| SharePoint | `https://app.legora.com/sharepoint` | Your Microsoft app registration, as a redirect URI. See [Enabling the SharePoint integration](https://support.legora.com/en-US/enabling-the-sharepoint-integration-for-your-organization.md). |
| Google Drive | `https://app.legora.com/google-drive` | Google Workspace admin, as a redirect URI. See [Google Drive integration overview](https://support.legora.com/en-US/integration-overview-google-drive.md). |
| Microsoft 365, customer-managed | `https://app.legora.com/integrations/microsoft-graph/oauth/callback` and `https://app.legora.com/integrations/microsoft-graph/admin-consent/callback` | Your own Entra app registration, as redirect URIs. Only needed when **Entra app** is set to **Customer-managed (BYO Entra app)**. |
| iManage Cloud | No action needed | Legora updates this for you. |
| Microsoft 365, Legora-managed | No action needed | Legora updates this for you. |

Use these exact URLs, even though your users sign in at your custom URL.

**Check it:** In step 3 on the **Authentication migration** page, select **Run test** for each integration and complete the sign-in in the pop-up. Each one shows **Passed**. If your browser blocks the pop-up, allow pop-ups for Legora and try again.

***

## Step 4: Install the Global Word and Outlook add-ins

This step prepares the Global Word and Outlook add-ins, which replace the regional add-ins. The regional add-ins stop working as soon as you complete the migration, and the Global add-ins work only after it.

> [!NOTE]
>
> **When you need this step:** Your organization uses the Legora Word or Outlook add-in. Deploy the Global add-ins before you enable global authentication in step 6.

The Global add-ins are separate installs. You can install them alongside the regional add-ins. Installing them doesn’t remove or change the regional add-ins, so you can deploy them ahead of step 6. Users sign in to the Global add-ins after you complete the migration. Keep the regional Word Add-in installed until users have exported their Assistant chats.

Choose the method that fits your organization:

* **Centrally managed by IT:** Deploy the Global add-ins from Microsoft AppSource. See [Outlook add-in for admins](https://support.legora.com/en-US/outlook-add-in-for-admin.md) and [How do I enable the Word Add-in for users in my Legora org?](https://support.legora.com/en-US/how-do-i-enable-the-word-add-in-for-users-in-my-legora-org.md).
* **Installed by users:** Ask users to install the [Global Word Add-in](https://marketplace.microsoft.com/en-us/product/WA200010705?tab=Overview) and the [Global Outlook Add-in](https://marketplace.microsoft.com/en-us/product/saas/wa200010806?tab=overview) from Microsoft AppSource.
* **On-premises:** Deploy the [Global Word manifest](https://word-addin.legora.com/manifests/manifest-legora-global.xml) and the [Global Outlook manifest](https://outlook-addin.legora.com/manifests/outlook-addin-manifest-global.xml).

Word Assistant chats aren’t moved to the Global Word Add-in. Let users know they can export them from the regional Word Add-in. See [What happens to Assistant and Agent chats?](#what-happens-to-assistant-and-agent-chats)

**Check it:** After step 6, open the Global add-ins in Word and Outlook and sign in.

***

## Step 5: Update firewall rules

This step lets your network reach the global sign-in services. Apply the rules to outbound traffic, and to inbound traffic where your network, proxy, or firewall setup needs it.

> [!NOTE]
>
> **When you need this step:** Your network, proxy, or firewall restricts traffic to Legora.

Allow HTTPS (TCP 443) to these domains:

* Your custom URL from step 1, for example `https://acme.app.legora.com`
* `https://app.legora.com`
* `https://login.legora.com`
* `https://identity.legora.com`
* `https://token.legora.com`
* `https://sso.legora.com`, if you use SSO
* `https://auth.legora.com`
* `https://word-addin.legora.com`, for the Global Word Add-in
* `https://outlook-addin.legora.com`, for the Global Outlook Add-in

Your custom URL is the only domain specific to your organization. The others are the same for every organization. Keep your regional Legora domains, such as `auth.eu.legora.com`, allowed. For the full list, see [Legora network and domain requirements](https://support.legora.com/en-US/legora-network-and-domain-requirements.md#global-domains).

**Check it:** From a device on your corporate network, open your custom URL and sign in. Then ask a small group of users to do the same and confirm their usual work, including integrations, still works.

You can also open [connectivity.legora.com](https://connectivity.legora.com) from your corporate network. It checks the global sign-in domains and creates a report that you can send to [support@legora.com](mailto:support@legora.com).

***

## Step 6: Enable global authentication

This step switches your whole organization to global authentication. You can’t undo it, so plan it outside working hours and tell your users beforehand.

> [!NOTE]
>
> **When you need this step:** Always, after you finish the steps that apply to you.

1. Select your custom URL to open the new sign-in page in a new tab. Sign in to check that your setup from [step 2](#update-your-identity-provider) works. Members keep using your current sign-in page until you complete the migration.
2. If your organization requires two-factor authentication, choose **Transfer MFA settings** to keep the requirement, or **Skip transfer**.
3. Select **Complete migration**.
4. Review the custom URL in the confirmation, then select **Complete migration**.

**Complete migration** stays unavailable until all of these are true. Its description tells you what is still missing.

* Your custom URL is set.
* Every active SSO connection shows **Passed**.
* At least one sign-in method is active, and your email and password setting is saved.
* You’ve made an MFA choice, if your organization requires two-factor authentication.

Integration checks from [step 3](#update-integration-callback-urls) don’t block **Complete migration**. Run them anyway before you complete the migration, to confirm your integrations keep working.

### What happens when you complete the migration

The change applies to everyone in your organization at once:

* **Users stay signed in.** No one is signed out when you complete the migration.
* **SSO users** keep signing in through SSO and won’t notice a difference.
* **Email and password users** set a password the next time they sign in. Legora emails them a code from **Reset your Legora password**, and the new password must be at least 15 characters. For the user steps, see [Why can I not log in to Legora?](https://support.legora.com/en-US/why-can-i-not-log-in-to-legora.md#reset-a-legora-password).
* **Two-factor authentication:** If you transferred MFA settings, members set up two-factor authentication again after the migration.
* **Regional URLs:** Users who open a regional Legora URL while signed in are forwarded to your custom URL.
* **Add-ins:** The regional Word and Outlook add-ins stop working and ask users to switch. If you haven’t deployed the Global add-ins from [step 4](#reinstall-word-and-outlook-add-ins) yet, roll them out now.
* **Settings:** The **Authentication migration** page is removed. You manage sign-in from **Settings** > **People** > **Authentication**. See [How do I manage authentication for my organization?](https://support.legora.com/en-US/how-do-i-manage-authentication-for-my-organization.md).
* **Profile:** On every member’s **Settings** > **Personal** > **Profile** page, **Sign-in** under **Workspace access** shows **Global**. Use it to confirm the migration applied.

Share your custom URL with your users so they go there directly.

***

## FAQ

These answers cover common questions from Admins and users during and after the migration.

### How do users sign in on the mobile app?

After the migration, users sign in to the Legora mobile app again. On the sign-in screen, they select **Global** as the data region, then sign in with their usual method. See [Legora mobile app FAQ](https://support.legora.com/en-US/legora-mobile-app-faq.md).

### What happens to Assistant and Agent chats?

Agent chats and Outlook Assistant chats are stored in Legora, so they stay available in the Global add-ins. Users don’t need to do anything.

Word Assistant chats, including Playbook results, are stored in the regional Word Add-in and aren’t moved. Users can export them from the regional Word Add-in and import them into the Global Word Add-in. The regional add-in still offers **Export now** after the migration. See [How to move your Word Add-in Assistant history to the Global Add-in](https://support.legora.com/en-US/exporting-word-add-in-assistant-threads-to-the-global-add-in.md).

### Can we still invite other Legora customers to our Portal?

Yes, once both organizations are on global authentication. Until then, Portal invitations to another Legora customer don’t work. Invitations to clients who don’t use Legora aren’t affected.

### Can I undo the migration?

No. After you select **Complete migration**, your organization stays on global authentication and you can’t change the custom URL.

### Do I need to migrate all my Legora organizations at the same time?

No. Migrate each organization from its own **Authentication migration** page, whenever it’s ready.

### Why does `https://sso.legora.com` show “404 Not Found”?

`sso.legora.com` is a sign-in service, not a website, so its root address shows **404 Not Found** by design. SSO still works. Use the full callback URLs from [step 2](#update-your-identity-provider) and test with **Run test**.

### Why does a SAML connection fail its test?

Check that the assertion sends the member’s email address in an attribute named exactly `email`. Other names, such as `mail`, aren’t read. For the Okta values, see [SAML attribute statements](#saml-attribute-statements).

### Why is **Complete migration** unavailable?

Check the description under **Complete migration**. It shows what’s missing: a custom URL, an SSO connection test that hasn’t passed, your sign-in settings, or an MFA choice. After you fix the setup, run any test that shows **Failed** or **Not tested** again.