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)]

[rjtsdl]

@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]

@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.