azure-cli: az aks create fails with service principal tenant mismatch

I’ve have recently moved my subscription to another tenant and removed all resources to recreate them anew. The recreating failed however. It would seem that the create aks command is using an incorrect tenant id. The create command will first create a new service principal in the correct tenant (afterwards it is there in the portal) but then will it look for that service principal to create the cluster in the incorrect (old) tenant.

az account show
{
  "environmentName": "AzureCloud",
  "id": "dd8e960a-3b91-4c33-ab40-***********",
  "isDefault": true,
  "name": "Visual Studio Professional",
  "state": "Enabled",
  "tenantId": "07287daf-e2f6-4594-90a6-***********",
  "user": {
    "name": "bjorn****************",
    "type": "user"
  }
}
az aks create --resource-group TestCluster --name TestCluster --node-count 1 --node-vm-size Standard_A2_v2 --kubernetes-version 1.8.1 --ssh-key-value .\clusterkey.pub
AAD role propagation done[############################################]  100.0000%
Operation failed with status: 'Bad Request'.
Details: Service principal clientID: 1b2e67f2-6ccd-4038-b76d-*********** not found 
in Active Directory tenant f56e47b2-0545-44e0-ae76-***********,
Please see https://aka.ms/acs-sp-help for more details.

Environment summary

MSI / azure-cli (2.0.23) / Windows 10 build 1709 (16299.192) / Powershell

azure-cli (2.0.23)

acr (2.0.17)
acs (2.0.22)
advisor (0.1.0)
appservice (0.1.22)
backup (1.0.3)
batch (3.1.7)
batchai (0.1.3)
billing (0.1.6)
cdn (0.0.10)
cloud (2.0.10)
cognitiveservices (0.1.9)
command-modules-nspkg (2.0.1)
configure (2.0.12)
consumption (0.2.0)
container (0.1.15)
core (2.0.23)
cosmosdb (0.1.15)
dla (0.0.15)
dls (0.0.18)
eventgrid (0.1.5)
extension (0.0.6)
feedback (2.0.6)
find (0.2.7)
interactive (0.3.11)
iot (0.1.15)
keyvault (2.0.15)
lab (0.0.13)
monitor (0.0.13)
network (2.0.19)
nspkg (3.0.1)
profile (2.0.16)
rdbms (0.0.9)
redis (0.2.10)
reservations (0.1.0)
resource (2.0.19)
role (2.0.15)
servicefabric (0.0.7)
sql (2.0.17)
storage (2.0.21)
vm (2.0.20)

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

Python (Windows) 3.6.1 (v3.6.1:69c0db5, Mar 21 2017, 17:54:52) [MSC v.1900 32 bit (Intel)]

About this issue

Original URL
State: closed
Created 6 years ago
Comments: 31 (14 by maintainers)

Most upvoted comments

@hardcorehead87 thx for trying it out.

I found a bug in our AKS/ACS rp code. It is a simple fix. I will request to get it deployed ASAP. I will update it with ETA later.

rjtsdl on Jan 11, 2018

@hardcorehead87 , i think can you check if your ~/.azure/acsServicePrincipal.json file exist. If so, can you remove it, and do retry.

The logic is, we cached the SPN in that file, and use Sub_id as the key. I guess, you moved your sub to new Tenant, the pre-created SPN doesn’t work anymore. Remove, and retry will create a new one for you.

rjtsdl on Jan 9, 2018

HI All

This thread is a bit old so not sure if anyone will see this. We were experiencing this exact issue and tracked it down with Microsoft’s assistance.

There is an issue (and it varies from region to region) with Azure AD sync / replication of service principals ie you create a service principal and it takes a short while (in our case Australia East more than 5 seconds) to be available in AD

When you run the command az aks create

the first thing it does is try to create and then use a service principal. Our solution was to do the following create the service principal

az ad sp create-for-rbac --name <<SPNname>> --skip-assignment

poll aad until the service principal was created

az ad sp list --spn <<appId>>

create the aks cluster with the service principal

az aks create --resource-group <<ResourceGroupName>> --name <<ClusterName>> --location <<location>> --service-principal <<appId>> --client-secret <<password>> d --node-count <<NodeCount>> --node-vm-size <<NodeSize>> --enable-addons monitoring --network-plugin azure --no-ssh-key --load-balancer-sku basic --kubernetes-version <<kubctlVersion>>

problem solved

Hope this helps someone

danherron on Oct 27, 2019

@hardcorehead87 good to know. Glad it works!

rjtsdl on Jan 24, 2018

Actually :latest was built 5 days ago, but the Docker tag for :dev is from last night. Looks like it has the changes from #5208, so it’s worth trying to see if that helps with this issue: docker run -v ${HOME}:/root -it azuresdk/azure-cli-python:dev

mboersma on Jan 11, 2018