Group provisioning when using non-UPN username

Maximilian HENKENSIEFKEN 26 Reputation points
2022-09-12T07:21:40.027+00:00

Hi all,

QUESTION
"Is there a way to sync groups correctly through SCIM provisioning in an enterprise app, when mapping the mail attribute to the username attribute in the application, as opposed to the UPN?"

We are facing the following issue:

  1. We are using SCIM account provisioning and SAML SSO to admit users to an enterprise application of ours;
  2. Because some migrated users have a UPN with our domain, but maintained a primary email address with their domain, SSO didn't work, as it was using UPN for provisioning, but Mail for SSO;
  3. To fix this, we changed the attribute mapped for username from UPN to Mail;
  4. Everything is working now, except that these migrated users are being ignored from group syncing, as it looks like it determines group membership by UPN.

We would really hate to maintain these groups manually, so are grateful for anything we could try to fix?

Thank you all in advance,

Max

Microsoft Entra ID
Microsoft Entra ID
A Microsoft Entra identity service that provides identity management and access control capabilities. Replaces Azure Active Directory.
19,468 questions
0 comments No comments
{count} votes

Accepted answer
  1. Danny Zollner 9,521 Reputation points Microsoft Employee
    2022-09-12T15:00:08.923+00:00

    Group membership is not related to UPN - it is determined by the member's (user's) ObjectID value in AAD, which will then be translated to the ID value of that respective object in the connected SCIM directory. The user must be successfully provisioned across and managed by the AAD Provisioning Service in order for AAD Provisioning to have discovered the user's SCIM ID value, which is required for the AAD Provisioning Service to be able to translate from AAD ObjectID -> SCIM ID.

    The most likely scenario is that the users being excluded from group memberships were created in the other/SCIM system via some other means besides SCIM, and the AAD Provisioning service has not successfully started managing them, as outlined above. If that doesn't pan out, I'd suggest opening a support case with Microsoft via the Azure/Entra portal(s).

    1 person found this answer helpful.

0 additional answers

Sort by: Most helpful