Attempt to create service principal for RBAC with contributor role fails with "WARNING: Role assignment creation failed."

Siegfried Heintze 1,861

I'm trying to follow these instructions: https://learn.microsoft.com/en-us/azure/developer/github/connect-from-azure?tabs=azure-cli%2Cwindows#create-a-service-principal

az ad sp create-for-rbac --name spad_ServiceBusSimpleSendReceive002 --role contributor --scopes /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx7db/resourceGroups/rg_ServiceBusSimpleSendReceive002

WARNING: Creating 'contributor' role assignment under scope '/subscriptions/acc26051-92a5-4ed1-a226-64a187bc27db/resourceGroups/rg_ServiceBusSimpleSendReceive002

'

WARNING:   Role assignment creation failed. 

WARNING:   role assignment response headers: {'Content-Type': 'text/html; charset=us-ascii', 'Date': 'Sat, 27 Apr 2024 22:39:51 GMT', 'Connection': 'close', 'Content-Length': '324'}

ERROR: Operation returned an invalid status 'Bad Request'

Also: I don't understand the --json-auth. I could not determine what this is for from the documentation.

Thanks

Siegfried

1 answer

Marcin Policht 12,320 Reputation points MVP

2024-04-28T00:26:53.5366667+00:00

Verify that the value of the --scopes parameter is correct and that you have sufficient permissions to the target Entra tenant and the corresponding Azure subscription.

The --json-auth parameter results in the JSON output which can be added directly to GitHub as a secret and referenced in GitHub Actions that require access to the target Azure subscription

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin
Please sign in to rate this answer.
Siegfried Heintze 1,861 Reputation points

2024-04-30T18:55:11.2366667+00:00

Marcin,

Sorry for the delay. I'm trying to think of how to follow your suggestion since I'm not cutting and pasting the scope.

This script is generated by an emacs script I've been using for years. Here is the bash script produced by emacs:

export id=`az group show --name $rg --query 'id' --output tsv` echo "id=$id" export sp="spad_${name}" echo az ad sp create-for-rbac --name $sp --role contributor --scopes $id --json-auth az ad sp create-for-rbac --name $sp --role contributor --scopes $id --json-auth

Since I'm using a script, there is no opportunity to get the scope wrong... Unless the script is wrong. Does it look wrong to you.

Here are today's results from running that script with an existing service principal:

id=/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/rg_ServiceBusSimpleSendReceive az ad sp create-for-rbac --name spad_ServiceBusSimpleSendReceive --role contributor --scopes /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/rg_ServiceBusSimpleSendReceive --json-auth WARNING: Option '--sdk-auth' has been deprecated and will be removed in a future release. WARNING: Found an existing application instance: (id) xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx. We will patch it. WARNING: Creating 'contributor' role assignment under scope '/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/rg_ServiceBusSimpleSendReceive ' WARNING: Role assignment creation failed. WARNING: role assignment response headers: {'Content-Type': 'text/html; charset=us-ascii', 'Date': 'Tue, 30 Apr 2024 17:58:23 GMT', 'Connection': 'close', 'Content-Length': '324'} ERROR: Operation returned an invalid status 'Bad Request'

That is weird: it says --sdk-auth has been deprecated but I did not use --sdk-auth.

This is a little different than my initial post because I was experimenting with a different (new) resource group then because I thought maybe there was a problem with creating a service principal that already exists. Using a new resource group without an existing service principal did not help.

Anyway, I just used "az group list" to confirm that both resource groups exist. And now both of service principals spad_ServiceBusSimpleSendReceive and spad_ServiceBusSimpleSendReceive002 also exist.

I'm thinking this should work whether the service principal already exists according to the error message.

I tried this and I received no errors:

$appid=(az ad sp list --display-name "spad_ServiceBusSimpleSendReceive" --query "[0].appId" --output tsv) write-output "appid=$appid" az role assignment create --role "Contributor" --assignee $appid --scope "/subscriptions/acc26051-92a5-4ed1-a226-64a187bc27db/resourceGroups/rg_ServiceBusSimpleSendReceive"

Then I tried to confirm that it worked (see https://learn.microsoft.com/en-us/azure/role-based-access-control/role-assignments-list-cli#list-role-assignments-for-a-managed-identity) where I specified the objectid of the service principal.

az role assignment list --assignee xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx []

Apparently it did not work.

Shucks!
Sign in to comment