This publication is a collection of various common attack scenarios on Microsoft Entra ID (formerly known as Azure Active Directory) and how they can be mitigated or detected.
I have read ConsentGrant.md, and I would like to bring your attention to the following issue concerning the mitigation option "Create a “permission grant condition set” for all users on the specific application" (l. 498):
This adds a specific client ID to a condition set in order to allow user consent to this particular application. However, there is an undocumented limitation to Consent Policies which only allows 99 client IDs to be used in Consent Policies tenant-wide, regardless of how these IDs are distributed over condition sets/policies. (The same is true for tenant ID.)
Unfortunately, this limitation was introduced secretly, and we have discovered it by accident during testing. Investigation with Microsoft is pending, but at the moment, this is a serious drawback for this mitigation option.
Do you know of any other option which preserves user consent while maintaining relatively fine control? Permission classification seems too coarse since a lot of permissions can be very harmful in illicit consent attacks while having proper use cases for other apps (e.g., MS Graph Mail.Read permission). I have also read the linked blog post, but this approach is not suitable for a large number of consents.
Hello,
I have read
ConsentGrant.md, and I would like to bring your attention to the following issue concerning the mitigation option "Create a “permission grant condition set” for all users on the specific application" (l. 498):This adds a specific client ID to a condition set in order to allow user consent to this particular application. However, there is an undocumented limitation to Consent Policies which only allows 99 client IDs to be used in Consent Policies tenant-wide, regardless of how these IDs are distributed over condition sets/policies. (The same is true for tenant ID.)
Unfortunately, this limitation was introduced secretly, and we have discovered it by accident during testing. Investigation with Microsoft is pending, but at the moment, this is a serious drawback for this mitigation option.
Do you know of any other option which preserves user consent while maintaining relatively fine control? Permission classification seems too coarse since a lot of permissions can be very harmful in illicit consent attacks while having proper use cases for other apps (e.g., MS Graph Mail.Read permission). I have also read the linked blog post, but this approach is not suitable for a large number of consents.
Looking forward to hear your thoughts on this.
Best,
Alex