Principals of type Application cannot validly be used in role assignments.

[rnkhouse]

Getting below error on terraform apply: Using object ID.

2 error(s) occurred:

* azurerm_role_assignment.ra1: 1 error(s) occurred:

* azurerm_role_assignment.ra1: authorization.RoleAssignmentsClient#Create: Failure responding to request: StatusCode=400 -- Original Error: autorest/azure: Service returned an error. Status=400 Code="PrincipalTypeNotSupported" Message="Principals of type Application cannot validly be used in role assignments."
* azurerm_kubernetes_cluster.test: 1 error(s) occurred:

* azurerm_kubernetes_cluster.test: Error creating/updating Managed Kubernetes Cluster "aks-cluster1" (Resource Group "aksrg1"): containerservice.ManagedClustersClient#CreateOrUpdate: Failure sending request: StatusCode=400 -- Original Error: Code="ServicePrincipalNotFound" Message="Service principal clientID: xxxxx-xxxxx-xxxxx-xxxxx not found in Active Directory tenant xxxxx-xxxxx-xxxxx-xxxxx, Please see https://aka.ms/acs-sp-help for more details." 

I also tried with using tenant ID but getting PrincipalNotFound error.

[alanold]

I'm getting the same error (Principals of type Application cannot validly be used in role assignments) when trying to add deploy role assignments via ARM template

I've tried parsing the appId and objectId of the service principle Any update on this ?

[dabasejumper]

Getting the same errors as well.

[audunsolemdal]

Same issue in ARM template for type "Microsoft.Network/virtualNetworks/providers/roleAssignments"

[uolter]

I had the same issue. Paying more attention to the name of the variable in my terraform.tfvars definition I realized I was using the wrong object_id. Indeed it is required the one related to my subscription instead of the application object id. I hope this is helpful.

[christian-vorhemus]

And as an additional input for everyone else stumbling into this: When you create a new "app registration" in the Azure portal, actually two objects are created: An application object and a service principal object. The object ID which appears in the Azure portal is the application object ID, not the service principal object ID. So what you can do is:

Create a SP: az ad sp create-for-rbac -n "sample-sp"

List details for the newly created SP: az ad sp list --filter "displayName eq 'sample-sp'"

Use the object ID from the CLI as the object ID you enter in Terraform.

[RobertoBorges]

And as an additional input for everyone else stumbling into this: When you create a new "app registration" in the Azure portal, actually two objects are created: An application object and a service principal object. The object ID which appears in the Azure portal is the application object ID, not the service principal object ID. So what you can do is:

Create a SP: az ad sp create-for-rbac -n "sample-sp"

List details for the newly created SP: az ad sp list --filter "displayName eq 'sample-sp'"

Use the object ID from the CLI as the object ID you enter in Terraform.

So why not to show in the portal the Service Principal Object ID ? Every day many folks have the same problem not just with AKS but with many other services in Azure!

[severity1]

You can also find the object id through the Enterprise Application.

[thenakulchawla]

And as an additional input for everyone else stumbling into this: When you create a new "app registration" in the Azure portal, actually two objects are created: An application object and a service principal object. The object ID which appears in the Azure portal is the application object ID, not the service principal object ID. So what you can do is:

Create a SP: az ad sp create-for-rbac -n "sample-sp"

List details for the newly created SP: az ad sp list --filter "displayName eq 'sample-sp'"

Use the object ID from the CLI as the object ID you enter in Terraform.

I tried this, but there was no key ObjectId in my json output.

[ArnWEB]

same issue

[thenakulchawla]

same issue

I found the answer. The json response has an id key, which is actually the objectId.

[alexivanov-danone]

I have to agree this is missleading. Application_id i understand, but ojbect_id i don't. And things changed, as this requires the object_id (id) or the service principal runnning behind the application (App registration) https://learn.microsoft.com/en-us/cli/azure/role/assignment?view=azure-cli-latest#az-role-assignment-create-optional-parameters: --assignee-object-id Use this parameter instead of '--assignee' to bypass Graph API invocation in case of insufficient privileges. This parameter only works with object ids for users, groups, service principals, and managed identities. For managed identities use the principal id. For service principals, use the object id and not the app id.

[PLsergent]

I don't know if it's going to be useful but after creating an app registration you can access the service principal object Id from the enterprise application and this solved it for me. The object id of the enterprise application is different from the one in the app registration.