SCIM provisioning of group memberships and resilience to external changes

Question

Hi,

I have observed across multiple SCIM integrations with Entra ID that API calls to my Groups/{groupId} endpoint explicitly exclude the 'members' attribute in its request.

This can lead to inconsistent group membership states, for example when changes are made directly in a SaaS-providers system instead of Entra ID, as Entra never seem to capture this.

It appears Entra sends a PATCH request to either add or remove a membership, and, upon receiving a 200 OK, doesn't ever re-verify group members later.

Since SCIM-linked group memberships in a SaaS-providers own system might still be modified locally (though it is discouraged), this can cause desyncs that go undetected — because Entra seemingly never requests the members field, or in any other way seem to check up on the state in the future.

My questions are:

Is it correct that Entra never includes the members attribute when fetching groups?

If yes, how can I ensure eventual consistency, and what workaround would you recommend?

Currently, I would advise customers to manually trigger re-provisioning of group memberships for individual users and groups by adding a membership inside Entra, waiting 45 mins for a provision cycle, then remove it and wait for a new cycle (or vice versa).

I'm also considering preventing membership edits in SCIM-managed groups on my side when SCIM is active.

If no, how often is this check performed? I'm yet to observe one. Might it be a bug or a performance consideration you've made? Is there an official resource I can inspect or refer customers technical departments to, that explains this limitation?

Thanks!

Answer 1

Hi @Frederik Østberg
I seem that you are trying to understand SCIM provisioning of group memberships and resilience to external changes.

it's accurate that when Entra ID makes calls to the SCIM endpoints, it typically does not include the members attribute when fetching information about groups. This can indeed lead to potential sync issues, especially if changes are made externally in a SaaS provider's system that aren't reflected back to Entra ID.

As you mentioned, triggering a manual re-provisioning cycle could help maintain consistency. This could involve making temporary group membership changes to kick off a sync. However, relying on manual processes can become cumbersome.

1. Scheduled Scripts: Automating the triggering of these provisioning cycles with scripts that regularly invoke changes might streamline the process.
2. Preventing Local Edits: Preventing changes in linked group memberships from the SaaS provider side while SCIM is active seems like a practical approach to avoid inconsistencies.
3. Settings for Periodic Synchronization: Look into if your integrations allow for setting up a custom sync frequency that might enable more frequent checks of the members attribute.

Follow the document for more information: https://learn.microsoft.com/en-us/entra/identity/app-provisioning/define-conditional-rules-for-provisioning-user-accounts?pivots=cross-tenant-synchronization
Hope this helps. Do let us know if you have any further queries.
If this answers your query, do click `Accept Answer` and `Yes`.

Answer 2

Hi @Frederik Østberg

Thanks for contacting Q&A Forum. Regarding your inquiries, I’d like to provide these following answers:

Microsoft Entra ID does not include the members attribute when performing a GET /Groups/{groupId} request during SCIM provisioning, this is by design. Instead, Entra ID only sends PATCH operations to add/remove group members. It does not perform a full reconciliation of group membership by re-fetching the current state from the SCIM endpoint. This is because Entra ID assumes it is the source of truth for group membership and does not re-fetch or validate the current state of group members from the SCIM endpoint. If changes are made locally in the SaaS system, Entra ID will not detect or correct them unless a new provisioning event is triggered.

In this case, I’d suggest you try the following troubleshooting methods:

• Change the command: your initial Graph API command is Get/Group/{groupid}. The correct one should be Get /Group/{groupid}/menbers

Reference: https://learn.microsoft.com/en-us/graph/api/group-list-members?view=graph-rest-1.0&tabs=http.

• Prevent local edits to SCIM-Managed Groups: Lock down group membership changes in your SaaS app when SCIM is active & mark SCIM-managed groups as read-only for membership edits.
• Trigger manual re-provisioning:

• Add a temporary member to the group in Entra ID.
• Wait for the provisioning cycle (typically 40–60 minutes).
• Remove the member to trigger another cycle.

This forces Entra to send PATCH operations and can help re-align the state.

For references, here is the official Microsoft document:

https://learn.microsoft.com/en-us/entra/identity/app-provisioning/use-scim-to-provision-users-and-groups

If you wish for a third-party app to modify the group membership, please contact the vendor and confirm whether they have sent the Graph API command ‘POST /groups/{group-id}/members/$ref', '

PATCH /groups/{group-id}/members’ and ’DELETE /groups/{id}/members/{id}/$ref‘ to Entra or not

Kindly let me know if you have any further questions or need any clarifications.

If I have answered your question, please accept this as answer as a token of appreciation and don't forget to give a thumbs up for "Was it helpful"!

Best regards,