This blog post is about a very particular problem you might have with some Azure services if your Azure subscription is tied to a personal account and not an Office 365 or Microsoft 365 identity. And the set of Azure services is not random. It is a set of Azure services that rely an Azure Active Directory for credential management – referred to as Managed Identity.

I ran into this when working with the Azure Key Vault, but you might hit it with Azure Blob Storage or some other services.

I want to first describe how my Microsoft and Azure accounts are set up and how I encountered the problem then share how I was able to solve it.

I have also written an article on using Azure Key Vault from an ASP.NET Core application but I chose a simpler path for the article which was to use an Azure Subscription that was tied to an Office 365 account. That article is in the Code Magazine May/June 2021 issue. (I’ll share the link when it’s live). In this blog post I am going to focus on the problem of the personal account. You can find details about accessing the Key Vault from the application in the article.

My Microsoft and Azure Accounts

My Azure Subscriber account is my personal Microsoft account that is associated with live.com. It’s not a live.com email address. You see the big difference when you log into a Microsoft property. You enter your email address and then specify that it’s either a work/school account or a personal account. Mine is one of those personal accounts.

I log in to visualstudio.com, my Visual Studio subscription and my Microsoft MVP account with that same personal account.  I’ve been working this way for a very long time.

Working with an Azure Active Directory dependent service: Azure Key Vault

I was writing a small ASP.NET Core app and wanted to store its secrets– some connection strings – in an Azure Key Vault to keep them out of my source code.

I started by creating a key vault in Azure. Key vaults are accessed through an access policy — a combination of an Azure Active Directory user and a selected set of permissions. When you create a new Key Vault and your Azure subscription account is an O365 account, a new access policy will be automatically be created giving the subscriber account’s identity broad access to that key vault.  Because my subscription was not tied to an O365 identity, I had to manually create an access policy for the user that is the subscription owner.

Back in Visual Studio, I wove the Azure.Extensions.Aspnetcore.Configuration.Secrets package into my application to let it  read from the key vault. This also requires referencing the  Azure.Identity NuGet package.

The secrets API asks the identity API to discover any managed identities on your machine if they are not fed directly to the application.

Here’s the critical code for accessing the key vault that I added into my app:

config.AddAzureKeyVault(
   new Uri("https://fourtwentyfive.vault.azure.net"),
   new DefaultAzureCredential());

This tells my app to communicate with my particular Azure Key Vault and use whatever credentials it can find. In my case, debugging in Visual Studio, that is the credentials I used to log in to Visual studio.

The Error of My Ways

And this is where the problem begins! When the debugger attempts to access the key vault with those credentials it throws an error.                 

Azure.Identity.AuthenticationFailedException: 'SharedTokenCacheCredential authentication failed: AADSTS9002332: Application ‘[application’s id]'(Azure Key Vault) is configured for use by Azure Active Directory users only. Please do not use the /consumers endpoint to serve this request.

That’s because even though the key vault created an access policy with my Live account, it’s a trap. It won’t work. Azure Active Directory cannot manage Live accounts. It can only manage Office 365 or Microsoft 365 accounts. Full stop.

I do have an O365 account. But I didn’t want to change my subscriber account to one of my two identities tied to my O365 account for fear of messing up everything that’s dependent on my old Live login–my MVP access, my visualstudio.com access, etc.

Therefore I needed to add one of my Office 365 identities into my Azure Active directory.

Tying an O365 Identity to my Azure Subscription

I have two identities in my O365 account – julia and jlerman. The jlerman account has the same exact email address as my Live account. Let me help you avoid suffering through another failure. Don’t try to add in an O365 identity that has the same email address as the personal identity. This was the first path I chose. The code failed in the same place but this time I got an HTTP 401 error result — Unauthorized client access.

But I was successful when using my other identity: julia.

How to do this was complicated and I would never have figured it out on my own. I’m grateful for guidance from a fellow Microsoft Regional Director, Joe Homnick, (rd.microsoft.com/en-us/joe-homnick) who is a lot more experienced with Azure security than I ever want to be! In fact, I didn’t understand the problem very well and I’m sure my explanation to him was very misleading, but he was able to figure out what I was trying to describe. Unfortunately, Joe couldn’t just point me to a document because apparently none exists. He documented the steps for me in an email along with screenshots. That’s a pal!

So the rest of this blog post is simply relaying what Joe taught me.

Also, I’m doing this via the Azure portal rather than a lot of mysterious Azure CLI commands. But you can achieve the same using the Azure CLI or PowerShell.

Step 1: Adding the O365 email address as a guest user with Global Administrator privileges

In the portal, go the Azure Active Directory, then Users.

• Select New guest user
• Select Create user. (Not “invite user”).
• Under identity, add a user name. I called mine julia365. Azure will populate the domain name tied to your subscription’s Azure Active Directory.
• Give your user a name. Mine is “Julia 365”. Xoru5917
• Set a password for this user. You can let the portal auto-generate or supply your own.
• The only other task (an important one) on this page is to set a role for this user. Click on User next to Roles and filter on global to select Global Administrator.

Then you can create the user.

The user principal name will be funky looking. It is formatted as an email address with the name of the user (with no spaces) and the domain is a compressed version of the identity for the subscription and then onmicrosoft.com.

So if my subscriber identity is [email protected], the new user’s principal name will be [email protected]. It’s not an email address, just an identity.

The identity issuer is also jlermansomedomain.onmicrosoft.com.

Step 2: Adding the new guest as a secondary subscription owner on the account

Having the user is not enough for the authentication to take place though. The user has to be recognized as a subscription owner. Azure allows you to set up secondary subscription owners.

You’ll need to start by going to the subscription properties. You can find Subscriptions in the search bar if needed. If you have multiple subscriptions, be sure to select the one you intend to use for your application. Once in the subscription properties, select the Access control (IAM) option. Then from it’s menu, Role assignments and then Add.

In the Add role assignment form, select Owner from the Role drop-down. Leave the Assign access to option at its default (User, group, or service principal). You’ll see all of the users listed. Select the newly created one and then save. It will get added very quickly.

Step 3: Log in to the portal with the new identity

If you click on your login info on the top right corner of the portal, you may already have an easy option available for switching to the new account for logging in.

Otherwise, you’ll need to sign out then sign in with the new credentials.

Step 4: Add the new identity to the service’s access policies.

In my case, I returned to the key vault and created a new access policy for the new identity.

Step 5: Switch Visual Studio user to the new identity in order to run/debug from VS

This is important since remember that when running or debugging from Visual Studio, the Azure Managed Identities API will read that login as a possible credential source. You’ll first need to sign out and then sign in again with the clunky identity you created in AAD. With my example, that would be [email protected].

With these changes, not only did I finally get past that failing line of code, but the app accessed the key vault and read my secrets (a database connection string in my case) and was able to use the secret to connect to the database.

I hope this helps someone else down the road!

  Sign up for my newsletter so you don't miss my conference & Pluralsight course announcements!