---
title: "How to synchronize AD users with EPM when using Azure SAML SSO"
slug: "epm-windows-sync-ad-users-azure-saml-sso"
updated: 2026-06-25T14:25:14Z
published: 2026-06-25T14:25:14Z
canonical: "docs.senhasegura.io/epm-windows-sync-ad-users-azure-saml-sso"
---

> ## 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 synchronize AD users with EPM when using Azure SAML SSO

Use this guide to configure **Segura®** and Azure so that users ingested from Active Directory (AD) are correctly recognized by **EPM Windows** on workstations. The issue occurs because the AD username attribute in **Segura®** must match the value Azure asserts as the SAML Unique User Identifier; when they differ, **EPM Windows** cannot bind workstation users to **Segura®** users.

## Requirements

- Admin-level access to **Segura®** Settings.
- Admin access to the Azure portal (Microsoft Entra ID).
- An existing AD integration configured in **Segura®** (see [How to manage group synchronization](/v4-2/docs/how-to-manage-group-synchronization)).
- An existing SAML SSO Enterprise Application configured in Azure (see [How to integrate with SAML 2.0](/v4-2/docs/settings-how-to-integrate-with-saml-20)).
- **Conditional — Entra ID (no On-Premise AD):** If your environment uses Entra ID SCIM provisioning instead of an On-Premise AD, you need Provisioning admin access to the Azure Enterprise Application.

## Procedure

### Scenario A — AD On-Premise + Azure SAML SSO

1. On **Segura®**, go to **Settings > Authentication > Active Directory**.
2. Open your existing AD integration.
3. In the **AD username attribute** field, enter the attribute whose value matches the **Unique User Identifier** configured in Azure. In most aligned tenants this is `sAMAccountName`, whose value equals the `mailnickname` in Entra ID.
4. Save the AD integration.
5. In the Azure portal, open the Enterprise Application you use for **Segura®** SAML SSO.
6. Go to **Single sign-on > Attributes & Claims**.
7. Set **Unique User Identifier (Name ID)** to `user.mailnickname`.

> Attention: The value sent by Azure in the SAML assertion as the Name ID must match exactly the value **Segura®** stores as the AD username. A mismatch silently prevents EPM user binding.
8. Save the claim configuration.
9. Trigger a manual AD synchronization on **Segura®** or wait for the next scheduled sync.

### Scenario B — Entra ID (no On-Premise AD) + Azure SCIM

1. In the Azure portal, open the Enterprise Application used for **Segura®** provisioning.
2. Go to **Provisioning > Attribute Mappings**.
3. Locate the mapping for the `userName` attribute in the customappsso column.
4. Set the **Microsoft Entra ID Attribute** to `mailNickname`.
5. Set **Matching precedence** to `1`.
6. Save the mapping.
7. In the **Segura®** Azure AD provisioning settings, confirm that the same `mailNickname` value will be used as the username after provisioning.

## Confirm Your Results

1. On **Segura®**, go to **Settings > Authentication > Active Directory > Synchronized users**.
2. Verify that usernames in the **Username** column match the `mailnickname` values for your users in Entra ID.
3. On a managed workstation with **EPM Windows** installed, log in as a synchronized user.
4. Confirm that **EPM Windows** recognizes the session — the user should appear in **EPM Windows** audit logs without binding errors.

## Troubleshooting

- **Problem:** Users are listed in Synchronized users but EPM Windows shows a binding error.
  - **Solution:** Confirm that the value in the **Username** column on **Segura®** matches exactly the value Azure sends as the SAML Name ID. Log the next SAML assertion (using browser developer tools on the SSO flow) and compare.
- **Problem:** After updating the AD username attribute, existing users have duplicate entries.
  - **Solution:** Run a full re-sync from the AD integration settings. Duplicate entries with mismatched attributes can be deactivated in **Settings > User Management**.
- **Problem:** Azure SCIM provisioning re-maps the attribute back to `userPrincipalName` after saving.
  - **Solution:** Check that no other provisioning policy in the Azure tenant overrides attribute mappings for this Enterprise Application. Save the mapping again and verify it persists before triggering a provisioning cycle.