Reassess delegated role-assignment denylists when roles change

Source facts

Microsoft’s example that permits most roles while excluding selected privilege-granting roles carries a specific warning: a newly added built-in or custom role containing role-assignment permission would not be blocked automatically. The condition would need updating to include that role.

The examples also distinguish add and remove operations because their condition attributes have different sources. Targeting both requires separate conditions rather than one shared expression. Microsoft Learn.

Applicability

Identify the delegate’s actual role assignments, condition expressions and intended permitted roles. Do not assume a list of familiar privileged role names exhausts every route to the same permission.

DSE recommendation

DSE recommends comparing an explicit approved-role set with a denylist approach before delegating assignment management. If exclusions are retained, assign responsibility for reviewing new and modified role definitions and for updating the condition when necessary. Review both creation and removal authority. Keep any examples’ identities and role identifiers separate from approved values for the real scope.

Verification

Use nonproduction identities to test an allowed assignment and a deliberately excluded assignment through both supported operation paths. Review a candidate role containing assignment-management permission before making it available to the delegate. Capture the evaluated condition and expected denial together; a successful test against yesterday’s role list is not continuing evidence for tomorrow’s catalog.

Official references

Microsoft Learn: Examples to delegate Azure role assignment management with conditions – Azure ABAC. Source retrieved September 9, 2026.