--- title: "How to set up Azure AD identity provisioning" slug: "user-management-azure-ad-provisioning" updated: 2026-09-03T19:42:32Z published: 2026-09-03T19:42:32Z canonical: "docs.senhasegura.io/user-management-azure-ad-provisioning" --- > ## Documentation Index > Fetch the complete documentation index at: https://docs.senhasegura.io/llms.txt > Use this file to discover all available pages before exploring further. # How to set up Azure AD identity provisioning This document provides information about how to set up the integration and identity provisioning from Azure Active Directory (Azure AD) to **Segura® Platform** using the SCIM protocol. To perform Azure AD identity provisioning in the **Segura® Platform**, it needs to be open to the Internet. If you do not wish to open it to the Internet, you can allow only the Azure AD IPs that perform the communication. More information about the IP range in [Azure IP Ranges and Service Tags – Public Cloud](https://www.microsoft.com/en-us/download/details.aspx?id=56519) and [IP Ranges](https://www.microsoft.com/en-us/download/details.aspx?id=56519). Info Segura® Platform now assigns app roles that a user inherits from an Azure group. After SCIM creates the user, Segura® Platform asks Azure to resend that user's roles. A check also runs every 30 minutes and assigns roles to users left without one, including users provisioned before you configured the credential below. This check never changes a role you assigned manually. This applies only to providers that use the SCIM protocol with Azure AD, and only after you register the Microsoft Graph credential described in Requirements. Without that credential, synchronization keeps working as before, and Segura® Platform does not assign inherited roles. ## Requirements - Administrative access to **Segura® Platform** to create an access provider. - Established network connection between Azure and **Segura® Platform** for token request and user provisioning on the SCIM API. - A configured enterprise application in Azure. - Groups created in Azure must have exactly the same name as the existing user groups in **Segura® Platform**. Avoid spaces in group names. - In Azure, assign each app role to the group whose members must receive it. Users inherit the role through group membership, which is what Azure sends to Segura® Platform in the `entitlements` attribute. - The **Display name** of each Azure app role must match the name of the corresponding role in Segura® Platform exactly, including capitalization. For this comparison, `PAM user` and `PAM User` are different roles. Segura® Platform matches the app role by its **Display name**, never by its **Value**. - A credential registered in Segura® Platform for the Azure app registration, to be selected on the provider. Register it with **Username** as the Application (client) ID, **Additional information** as the Directory (tenant) ID, and **Password** as the client secret. See [How to set up a credential](/v4-2/docs/pam-credential-how-to-set-up-a-credential-in-senhasegura). - The Azure app registration must have the application permissions `Application.Read.All`, `Synchronization.ReadWrite.All`, and `User.ReadBasic.All`, with admin consent granted. Grant them with type **Application**; permissions of type **Delegated** are not sufficient. Do not grant broader read permissions such as `User.Read.All`, `Directory.Read.All`, or `Group.Read.All`. They are not needed, and granting them breaks the least-privilege requirement. - **Segura® Platform** must have a DNS with a valid certificate published. - The system URL in **Segura® Platform** must be correctly configured. Info Azure rejects spaces in an app role **Value**. Roles whose names contain spaces, such as `PAM User` and `System Auditor`, can therefore only be matched by their **Display name**. ## Create a provider in the Segura® Platform 1. On **Segura® Platform**, in the navigation bar, hover over the **Products Menu** and select **Settings**. 2. In the side menu, select **Provisioning > Identity Management (IGA) > Providers**. 3. Click **+ Add**. 4. In the **Name *** field, enter a name for the provider. 5. In the **Protocol *** field, select the **SCIM** protocol. 6. In the **Add users to Domum? ***, select the type of **Domum** connection. 7. In the **Enabled *** field, select to enable or disable the provider. 8. Optional: In the **Description** field, enter a description for the provider. 9. Optional: In the **Tags** field, enter tags to identify the provider. 10. In the **Authentication method *** field, select **OAuth 2.0** as the provider’s authentication method. 11. In the **Date/Time Expiration** field, enter the expiration date and time of the authentication. 12. In the **Allowed IPs (Put * to allow any IP)** table, click **+ Add** to enter the allowed IPs. 13. In the **Allowed HTTP referrers (empty list for any source)** table, click **+ Add** to enter the allowed HTTP referrers. 14. Optional: In the **Azure app registration credential (Microsoft Graph)** field, select the credential you registered for the Azure app registration. Segura® Platform assigns roles inherited from groups only when this field is filled in. 15. Click **Save**. After creating the provider, save the **Client ID** and **Client Secret** values. Segura® Platform generates these two values, and they differ from the Application (client) ID and the client secret of the app registration used in the Microsoft Graph credential. You enter them directly in Azure during the enterprise application setup. Info Segura® Platform uses the **Azure app registration credential (Microsoft Graph)** for outbound access: it authenticates with Microsoft Graph to request a user's roles from Azure. This is separate from the inbound authentication Azure uses to reach the SCIM API, which you configure through the **Authentication method** field. ## Create an enterprise application in Azure 1. Access [Azure’s platform](https://portal.azure.com/#home). 2. Login to your Azure account. 3. Locate the **Microsoft Entra ID** service. 4. In the side menu, click **Manage > Enterprise applications**. 5. Click **New application**. 6. Click **Create your own application**. 7. Enter a name for your application, and select **Integrate any other application you don’t find in the gallery (Non-gallery)**. 8. In your enterprise application, click **Manage > Provisioning**. 9. In the overview of your application, click **Manage > Provisioning**. 10. In the **Provisioning Mode** field, select **Automatic**. 11. In the **Connectivity** tab, fill the following fields: 1. In the **Select authentication method** field, select **OAuth2 client credentials grant**. 2. In the **Tenant URL *** field, enter the **Base URL** value obtained from viewing the details of the provider in the **Segura® Platform**. Example: `https://<your-segura>/iso/scim/v2`. 3. In the **Token endpoint *** field, enter the Segura® token endpoint. Example: `https://<your-segura>/iso/oauth2/token`. 4. In the **Client identifier *** field, enter the **Client ID** obtained in the [Create a provider in Segura®](/v4-2/docs/user-management-azure-ad-provisioning#create-a-provider-in-segura%C2%AE) section. 5. In the **Client secret *** field, enter the **Client Secret** obtained in the [Create a provider in Segura®](/v4-2/docs/user-management-azure-ad-provisioning#create-a-provider-in-segura%C2%AE) section. 6. Click **Test connection** to validate the connection with **Segura® Platform**. Azure sends a request to **Segura® Platform** to validate the credentials and the token endpoint. 12. Continue the setup in the [Configure user mappings](/v4-2/docs/user-management-azure-ad-provisioning#configure-user-mappings) section. Info With **OAuth2 client credentials grant**, Azure requests and refreshes the access token automatically using the **Client ID** and **Client Secret** generated by **Segura® Platform**. No external tool is required to obtain the token. ## Configure user mappings 1. After creating the enterprise application, click **Provision Microsoft Entra ID Users**. 2. In the **Attribute Mappings** section, delete the `entitlements.value` parameter. 3. Tick the **Show advanced options** checkbox and click **Edit attribute list for customappsso**. 4. In the new window, create the following attributes. 1. In the `userName` attribute, tick the checkbox in the **Required?** column. 2. In the `email` attribute, do not tick any checkbox. 3. In the `displayName` attribute, do not tick any checkbox. 4. In the `name.givenName` attribute, do not tick any checkbox. 5. In the `name.formatted` attribute, do not tick any checkbox. 6. In the `active` attribute, do not tick any checkbox. 7. A new attribute called `entitlements`, **String** type, and tick the **Multiple values?** checkbox. 5. Click **Save**. 6. Back to the **Attribute Mappings** section, click **Add new mapping**, and add the following attributes as mappings: 1. `userName` attribute: 1. In the **Mapping type** field, select **Direct**. 2. In the **Source attribute *** field, select `userPrincipalName`. 3. In the **Target attribute *** field, select `userName`. 2. `email` attribute: 1. In the **Mapping type** field, select **Direct**. 2. In the **Source attribute *** field, select `mail`. 3. In the **Target attribute *** field, select `email`. 3. `displayName` attribute: 1. In the **Mapping type** field, select **Direct**. 2. In the **Source attribute *** field, select `displayName`. 3. In the **Target attribute *** field, select `displayName`. 4. `name.givenName` attribute: 1. In the **Mapping type** field, select **Direct**. 2. In the **Source attribute *** field, select `givenName`. 3. In the **Target attribute *** field, select `name.givenName`. 5. `name.formatted` attribute: 1. In the **Mapping type** field, select **Expression**. 2. In the **Source attribute *** field, select `Join(“ “, [givenName], [surname])`. 3. In the **Target attribute *** field, select `nameFormatted`. 6. `active` attribute: 1. In the **Mapping type** field, select **Expression**. 2. In the **Source attribute *** field, select `Switch ([isSoftDeleted], , “False”, “True”, “True”, “False”)`. 3. In the **Target attribute *** field, select `nameFormatted`. 7. `entitlements` attribute: 1. In the **Mapping type** field, select **Expression**. 2. In the **Source attribute *** field, select `AssertiveAppRoleAssignmentsComplex([appRoleAssignments])`. 3. In the **Target attribute *** field, select `entitlements`. 7. Click **Save** and go back to the provisioning menu informed in step 9. of the [Create an enterprise application in Azure](/v4-2/docs/user-management-azure-ad-provisioning#create-an-enterprise-application-in-azure) section. Attention Segura® Platform reads roles from the `entitlements` attribute only. If you map the expression to `roles` instead, Segura® Platform assigns no role and shows no warning. ## Enable provisioning In the initial provisioning configuration screen, enable the **Provisioning status** field. From this point on, provisioning will run, synchronizing users from Azure AD with **Segura® Platform**. Attention Large-scale user synchronization can lead to slow processing and increased machine resource usage. We recommend conducting provisioning in smaller, more manageable batches to minimize performance impact. ## If roles are not assigned When a user is created but receives no role, check the following, in this order: 1. Confirm that the app role **Display name** in Azure and the role name in Segura® Platform are identical, including capitalization. 2. Confirm that the `entitlements` attribute is mapped with the `AssertiveAppRoleAssignmentsComplex([appRoleAssignments])` expression, as described in the Configure user mappings section. 3. Confirm that the **Azure app registration credential (Microsoft Graph)** field on the provider has a credential selected. 4. Confirm that the app registration permissions are granted with type **Application** and have admin consent. After correcting any of these, wait for the next check or, to apply the role immediately to a specific user, provision that user on demand from Azure. To be notified when the automatic role resend fails, add a notification that includes the types **Azure credential rejected during role reinforcement** and **Role reinforcement exhausted attempts**. In these notification types, "role reinforcement" refers to the automatic role resend described in this article. See [How to manage notifications](/v4-2/docs/notification-how-to-manage-notifications). Attention Without a notification configured for these types, the alert is not stored, and no record of the failure is available in the interface.