Bug Report: Custom CAF Roles Conflict with Entra ID Role Assignment Conditions

[AErmie]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Versions

terraform: 1.9.7

azure provider: 3.116.0

module: 6.2.0

Description

Describe the bug

Some of the custom Roles (ie. Subscription-Owner and Application-Owners) conflict with Entra ID's requirement to include role assignment conditions for Privileged Administrator Roles.

This is due to these custom roles having the following notActions:

        "permissions": [
            {
                "actions": [
                    "*"
                ],
                "notActions": [
                    "Microsoft.Authorization/*/write", 
                ],
                "dataActions": [],
                "notDataActions": []
            }
        ],

And because these are "privileged" roles, Entra ID enforces the setting of a condition (any of which require/allow the User to "assign roles"), which conflicts against the custom Role's notActions.

This produces the following error when attempting to assign either of these roles:

Failed to add ACCOUNT_NAME as Application-Owners for MANAGEMENT_GROUP: Action pattern Microsoft.Authorization/roleAssignments/write is not referenced in role 14d60bd1-0929-5ae1-adb9-9c1c8cabf951.

Failed to add ACCOUNT_NAME as Subscription-Owner for MANAGEMENT_GROUP: Action pattern Microsoft.Authorization/roleAssignments/write is not referenced in role c7358265-e8fc-5b81-a9de-676f2d5bdbde.

Note

The Role GUID reference corresponds to the roleDefinition object, as it's been created in the target environment.

Steps to Reproduce

1. Deploy the CAF, inclusive of the custom Roles
2. Attempt to assign the Subscription-Owner or Application-Owners roles
3. The Azure portal throws the aforementioned error

Screenshots

Additional context

By removing the notActions: "Microsoft.Authorization/*/write" from the custom Role, this resolved the error, and allowed assigning the role.

Request

It would be helpful to understand the original intent of these custom Roles, and if this approach is being maintained or abandoned.

[matt-FFFFFF]

Hi, transferring to Enterprise-Scale as this currently hosts the definitions

[AErmie]

Hey @matt-FFFFFF, did you mean you want me to open an issue in the Enterprise-Scale repo? Or that you were going to transfer this issue to that repo? Because I don't see it in the ES repo issue's list currently.

[matt-FFFFFF]

I have already moved the issue 😊

[Springstone]

@AErmie thanks for raising the issue. Those custom roles are from before my time, @jtracey93 do you have any thoughts?

[jtracey93]

Just investigating this and will try to repro.

@AErmie can you confirm that the identity trying to make the role assignment of one of these custom role defs had permissions like Owner, User access admin or rbac admin to do a write on role assignments at the scope desired?

[AErmie]

Just investigating this and will try to repro.

@AErmie can you confirm that the identity trying to make the role assignment of one of these custom role defs had permissions like Owner, User access admin or rbac admin to do a write on role assignments at the scope desired?

Hey @jtracey93, yes I can confirm that (it's my own account). I have Owner permissions at the Management Group level where I'm trying to assign this custom role to a user.

From my testing, if the notActions has "Microsoft.Authorization/*/write" while the actions has "*", this is what causes the custom Role to be identified as a Privileged Administrator Role, and thus forces conditions to be specified. And, all of the Conditions (even the least privilege one), requires the Microsoft.Authorization/roleAssignments/write permission (which is blocked by the notAction).

If we remove the "*" from the actions, then it works, but that means we'd have additional operational overhead to list all of the services/access we want to allow. It's far easier to say "User can do 'all the things', except for XYZ". Instead of "User can do A, B, C, D ... " Because every time there's a new Azure service (or potential change), we'd have to update that list.