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

Prev Next

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).
  • An existing SAML SSO Enterprise Application configured in Azure (see How to integrate with SAML 2.0).
  • 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.