RBAC assignment on AD group failing

[williamhbell]

az feedback auto-generates most of the information requested below, as of CLI version 2.0.62

Describe the bug When an AD group is created and a role is assigned quickly afterwards, the role assignment fails. The command returns the message

Check that you have the correct principal ID. If you are creating this principal and then immediately assigning a role, this error might be related to a replication delay. In this case, set the role assignment principalType property to a value, such as ServicePrincipal, User, or Group.  See https://aka.ms/docs-principaltype

However, setting the principalType does not help. For example:

az role assignment create --role Reader --assignee-object-id <guid of AD group> --assignee-principal-type Group --resource-group rg-prod-services --subscription <subscription name>

results in:

WARNING: The underlying Active Directory Graph API will be replaced by Microsoft Graph API in a future version of Azure CLI. Please carefully review all breaking changes introduced during this migration: https://docs.microsoft.com/cli/azure/microsoft-graph-migration
Principal <guid of AD group> does not exist in the directory <GUID of directory>. Check that you have the correct principal ID. If you are creating this principal and then immediately assigning a role, this error might be related to a replication delay. In this case, set the role assignment principalType property to a value, such as ServicePrincipal, User, or Group.  See https://aka.ms/docs-principaltype

If the command to assign a role is repeated a few minutes after the AD group has been created it works without issue.

To Reproduce Create an AD group and then try to assign a role to it quickly afterwards.

Expected behavior Ideally, the role assignment command should not fail.

Environment summary

$ az --version
WARNING: You have 2 updates available. Consider updating your CLI installation with 'az upgrade'

Please let us know how we are doing: https://aka.ms/azureclihats
and let us know if you're interested in trying out our newest features: https://aka.ms/CLIUXstudy
azure-cli                         2.34.1 *

core                              2.34.1 *
telemetry                          1.0.6

Extensions:
account                            0.2.2
azure-devops                      0.23.0
db-up                              0.2.6

Dependencies:
msal                              1.16.0
azure-mgmt-resource               20.0.0

Python location 'C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\python.exe'
Extensions directory 'C:\Users\....user...\.azure\cliextensions'

Python (Windows) 3.8.9 (tags/v3.8.9:a743f81, Apr  6 2021, 13:22:56) [MSC v.1928 32 bit (Intel)]

Legal docs and information: aka.ms/AzureCliLegal

Using Bash on Windows.

[yonzhan]

@jiasli for awareness

[williamhbell]

Repeating the test with the latest version of the Azure CLI (2.36.0), the issue is still present.

az --version   
azure-cli                         2.36.0

core                              2.36.0
telemetry                          1.0.6

Extensions:
account                            0.2.2
azure-devops                      0.23.0
db-up                              0.2.6

Dependencies:
msal                              1.17.0
azure-mgmt-resource               20.0.0

Python location 'C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\python.exe'
Extensions directory 'C:\Users\....user...\.azure\cliextensions'

Python (Windows) 3.10.4 (tags/v3.10.4:9d38120, Mar 23 2022, 22:57:10) [MSC v.1929 32 bit (Intel)]

Legal docs and information: aka.ms/AzureCliLegal

Your CLI is up-to-date.

Please let us know how we are doing: https://aka.ms/azureclihats
and let us know if you're interested in trying out our newest features: https://aka.ms/CLIUXstudy

[sethreidnz]

I can also confirm this occurs when using ARM templates as well. Has anyone had a chance to look into this?

[jiasli]

Without providing --assignee-principal-type, ARM needs some time to synchronize from Microsoft Graph.

However, since even when --assignee-principal-type is provided, you are still seeing error, let me follow up with ARM team internally.

[kiweezi]

Any update on this @yonzhan, @jiasli? I can confirm I'm having the same issue when --assignee-principal-type is set to Group, on the latest version of Azure CLI.

I'm getting this while running Pulumi, which uses Azure CLI under the hood. It seems to attempt to assign the group immediately after it's created, meaning this issue happens on the first deployment of the group and role assignment, consistently. Waiting a few seconds and running a second time, it will succeed with the role assignment. Pulumi has no handle that is capable of solving this, so for now our CD is broken.

It seems almost identical to this symptom listed in the Azure RBAC troubleshooting, only for groups instead of service principles.

az --version
azure-cli                         2.40.0

core                              2.40.0
telemetry                          1.0.8

Dependencies:
msal                            1.18.0b1
azure-mgmt-resource             21.1.0b1

Python location 'C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\python.exe'
Extensions directory 'C:\Users\...user...\.azure\cliextensions'

Python (Windows) 3.10.5 (tags/v3.10.5:f377153, Jun  6 2022, 15:58:59) [MSC v.1929 32 bit (Intel)]

Legal docs and information: aka.ms/AzureCliLegal

Your CLI is up-to-date.

[nani2ratna]

Hi,

I am also getting same error when I run terrform todo role assignment. Below is the error I am receiving ╷ │ Error: authorization.RoleAssignmentsClient#Create: Failure responding to request: StatusCode=400 -- Original Error: autorest/azure: Service returned an error. Status=400 Code="PrincipalNotFound" Message="Principal 04b077958ddb461abbee02f9e0bf7b46 does not exist in the directory a15ee07a-efa5-4fc0-9e41-b6522df67ecd. Check that you have the correct principal ID. If you are creating this principal and then immediately assigning a role, this error might be related to a replication delay. In this case, set the role assignment principalType property to a value, such as ServicePrincipal, User, or Group. See https://aka.ms/docs-principaltype" │ │ with module.core_app_configuration.azurerm_role_assignment.appconf_dataowner, │ on modules/app-configuration/role-assignment.tf line 3, in resource "azurerm_role_assignment" "appconf_dataowner": │ 3: resource "azurerm_role_assignment" "appconf_dataown

Is there any work around for this problem