Unexpected SCIM Group Membership Updates in Azure: Receiving Replace Operations Instead of Add

Question

Hello!

I've been troubleshooting an issue with group membership updates in our SCIM app and am seeing some unexpected behavior from Microsoft Entra. Specifically, I have a group with four members, so I anticipate four separate PATCH requests to the group's endpoint, each with an add operation for a new member.

However, instead of add operations, I frequently receive four replace operations. This causes only one user to be added to the group, as each replace operation overwrites the members field with a single new entry. Here’s an example request body:

{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
  "Operations": [
    {
      "op": "replace",
      "path": "members",
      "value": [{ "value": "<user_id>" }]
    }
  ]
}

My questions are:

1. Why would Entra send replace operations for each member instead of add operations?
2. Is this expected behavior, or could it be a known issue with group membership updates?

According to this related Q&A, Entra should not be sending replace operations in this scenario. Is there a recommended workaround to ensure correct group membership synchronization?

Answer 1

@Peter Seely Thank you for reaching out to us, As per our documentation - https://learn.microsoft.com/en-us/entra/identity/app-provisioning/use-scim-to-provision-users-and-groups#update-group-add-members:~:text=204%20No%20Content-,Update%20Group%20%5BAdd%20Members%5D,-Request

above mentioned behavior seems to be incorrect, would appreciate for further investigation, would recommend to open a support ticket with us.

Let me know if you have any further questions, feel free to post back.

Answer 2

I’ve identified the issue: Entra sends replace operations instead of add if the GET response for the group includes the members field. Since Entra includes members in the excludedAttributes argument for the GET request, it should not be returned, and the issue is thus resolved.

In short, respecting the attributes and excludedAttributes arguments for SCIM groups GET requests, as described in the RFC 7644 solved the issue for me.