Azure MSI Collisions

Ok maybe I was being silly, and this would never happen in a large corporate environment with good controls but I found out something useful and important.

So what am I on about, well I was working on a test environment, this was to be throw away so the resource naming did not really matter it was more about the arm template and all the resource interactions using System Assigned Managed Identity that I was concerned about. So I did what a normal person would do and just named all the resources the same. A KeyVault, Azure SQL, App Service Plan and App Service was create with the same name and then I enabled a system assigned MSI, all good so far. However when I tried to enable access between the various resources under the identity of the MSI everything failed. Why!!.

This is what was happening, under the hood when you enable a system assigned MSI, a new service principal is being created in Azure Active Directory with the same name as the resource. See the issue? I ended up with multiple service principals all with the same name, different GUID’s of course. So when a resource tried to validate an access request using the display name, which is what is happening under the hood, the request returns back multiple service principals and Azure does not know which one to validate. We could argue that Azure internally should always use the ObjectID, but it does not so that is pointless. As soon as I made sure the resource names were unique, within my Azure tenant, then everything worked as expected and I could continue working on making sure everything was deployed via my ARM template.

The learning, make sure that all your resources have a unique name within your tenancy, preferably globally.