SCIM PATCH group membership throttling

Question

SCIM PATCH group membership throttling

Kyle Besecker 21

I have an enterprise application with 10k users under 5 groups. The groups and users have been successfully provisioned. However, for the group membership, the requests get throttled. It looks like each time the group attempts to get their assignments, the entire membership appears to get re-assigned, but this causes requests to get throttled. Is there a reason why the memberships need to be entirely replayed each time Azure AD attempts to re-synchronize the users?

Danny Zollner 10,571 Reputation points Microsoft Employee

2023-01-26T23:01:14.39+00:00

What do you mean by throttled? Is the SCIM server responding with 429s? And what do you mean by "the memberships are being entirely replayed"?
Kyle Besecker 21 Reputation points

2023-02-01T00:13:06.4266667+00:00

Yes, the SCIM server is returning with 429 as the status code. It appears that when Azure attempts to re-submit the member patch requests for the security group, it's retrying the single member updates for each member in the group which had its patch requests throttled.
Kyle Besecker 21 Reputation points

2023-02-03T00:07:59.96+00:00

@Anonymous Did I answer your questions?
Kyle Besecker 21 Reputation points

2023-02-03T00:08:17.1033333+00:00

@Anonymous Did I answer your questions (not sure if you get notified of all comments)?
Givary-MSFT 35,456 Reputation points Microsoft Employee

2023-02-09T09:05:11.3833333+00:00

@Kyle Besecker Just checking in to see if below information was helpful. If you have any further updates on this issue, please feel free to post back.

1 answer

Your answer

Danny Zollner 10,571 Reputation points Microsoft Employee

2023-01-26T23:01:14.39+00:00

What do you mean by throttled? Is the SCIM server responding with 429s? And what do you mean by "the memberships are being entirely replayed"?
Kyle Besecker 21 Reputation points

2023-02-01T00:13:06.4266667+00:00

Yes, the SCIM server is returning with 429 as the status code. It appears that when Azure attempts to re-submit the member patch requests for the security group, it's retrying the single member updates for each member in the group which had its patch requests throttled.
Kyle Besecker 21 Reputation points

2023-02-03T00:07:59.96+00:00

@Anonymous Did I answer your questions?
Kyle Besecker 21 Reputation points

2023-02-03T00:08:17.1033333+00:00

@Anonymous Did I answer your questions (not sure if you get notified of all comments)?
Givary-MSFT 35,456 Reputation points Microsoft Employee

2023-02-09T09:05:11.3833333+00:00

@Kyle Besecker Just checking in to see if below information was helpful. If you have any further updates on this issue, please feel free to post back.

Answer 1

What you're describing is working by design from the Azure AD side. The behavior of the generic SCIM connector offered with custom non-gallery applications is to send group memberships one per request. If the attempt to PATCH add/remove a group membership fails, it will be saved and retried later. Are you able to either temporarily or permanently increase the number of requests per second that your SCIM endpoint can accept so that the initial population of the group memberships can be done without the SCIM server sending 429s? There aren't many options on the client(Azure AD) side of this that will help you out here, unfortunately - the group memberships need to be sent over, and the 429s are going to cause that to take an incredibly long time as the generic SCIM connector doesn't have any request rate limiting available on it.

Share via

SCIM PATCH group membership throttling

1 answer

Your answer