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)
@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.
@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.
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
@hardcorehead87 good to know. Glad it works!
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