Introduction

Azure customers of all sizes are using ARM templates, Powershell, and CLI in order to create Registered Applications/Service Principals and then assign them to an Access Policy in the Key Vault in order to perform operations. In performing these assignments, it is frequent that customers call into Key Vault support trying to understand why their Service Principal is receiving an HTTP 403 (Forbidden) when attempting to access the Key Vault data plane. I want to clear up what's going on with this so that you have a better understanding and can avoid this problem.





Key Vault Access Policy In the Portal

Let's review a Registered Application that I've newly created using the portal. We can clearly see all of the GUIDs associated with this Registered Application which are important to creating the Access Policy.

So now I create an Access Policy for this Registered Application in my Key Vault:

Next, let's get an access token using the Application ID (Client Id) and Client Secret (Key) that I created in the Application Registration blade in AAD:

Request

Response (some info removed)





Now that I've got the token, I can make a successful request to Key Vault for a secret:



Request





Response (some info removed)



You may be looking at this and wondering why I am walking you through a standard setup and request/response. It's because I want to show you that this works as expected, even though the next step is the confusing part - the values that are kept in the Key Vault for an access policy.





Key Vault Properties

Now look at the Key Vault using Powershell:





And more specifically, check out the Access Policy for the AKVAccessPolicyServicePrincipal:



There are three important things to note here:

There is no Application Id listed as a property of this Access Policy

The ObjectID listed here (92ba...) does not match the ObjectId (7da4...) shown in the registered application (see above)

The Application Id (70a3...) of the registered application from above is shown in the Display Name section

At this point you should be wondering what is going on with this, so let's figure out where the ObjectID 92ba... came from.





Enterprise Applications

Go back into the Azure portal, AAD Service, then into the "Enterprise Registrations" (have you ever even looked here before?):





Now we see that this Enterprise Application - with the same name and Application Id as my registered application - but a different ObjectID - is what we've registered in the Key Vault Access Policy! But what in the world is an Enterprise Application?



Here are a couple of important definitions from official documentation:

Application objects - Although there are exceptions, application objects can be considered the definition of an application.

Service principals - Can be considered an instance of an application. Service principals generally reference an application object, and one application object can be referenced by multiple service principals across directories.

One additional really important piece of information from the above link:

You can manage service principals in the Azure portal through the Enterprise Applications experience.





Now we understand - a Service Principal is NOT the same as a Registered Application and for Key Vault, we do not give an access policy to a Registered Application but to a Service Principal related to the Registered Application.

Key Vault Access Policy via Powershell





Let's get back to Powershell and properly creating Access Policies. I am going to delete the above Access Policy and attempt to recreate it using Powershell. There are three ways of creating an Access Policy:

Set-AzureRmKeyVaultAccessPolicy [-VaultName] <String> [-ApplicationId <Guid>] -ObjectId <String> -PermissionsToKeys all Set-AzureRmKeyVaultAccessPolicy [-VaultName] <String> -PermissionsToKeys all -ServicePrincipalName <String> Set-AzureRmKeyVaultAccessPolicy [-VaultName] <String> -PermissionsToKeys all -UserPrincipalName <String>

For most people with an Application Id and Object Id, #1 might seem to do the trick, so let's see what happens when we use this. Let's also have a reminder of what it looks like when properly created in the portal:









Upon running this cmdlet, we are immediately met with a request for an ObjectId. I can put in the ObjectId of the Registered Application and it seems fine until I try to use it (I won't show that). Let's see what that looks like in the Key Vault:





So that really might look ok to most people, but as you noticed above, that's not what we really want. The Object Id is not correct (we know that now), and the correct working Access Policy does not have an Application Id but this one does. I reminded you what a properly registered Access Policies looks like, so let's look at the one we just created:







You can see that the name is correct, but the icon and coloring is different. This should be a clue that something is wrong. Let's look at doing this correctly in one of two ways:

Use the Object ID of the Enterprise App. This is identical to the Access Policy we created earlier in the portal, and the icon looks correct:





Use the Application Id of the Registered Application as the Service Principal name. This automatically extracts the Enterprise Application Object ID and places it into Object ID of the Key Vault properties, and also populates the Display Name - exactly like above.



Application Id

At this point you are probably asking what an Application Id is for in an Access Policy. Go back to the portal and into the new Access Policy blade. Notice the "Authorized Application" part at the bottom of this image:







The Application Id property of a Key Vault refers directly to that "Authorized Application" part of an Access Policy. This is for On-Behalf-Of Authorization scenarios which means that authorization is granted to a specific user only via a specific application. Without other Access Policies, the user cannot access the Key Vault without the app, and the app cannot access the Key Vault without the user. Most organizations will not use this feature, but I know that some have.





Conclusion

It's important to know exactly the correct Object ID to use in an Access Policy. The difference between a registered application and an Enterprise App/Service Principal seems to be the #1 most confusing part of this. However, I hope this blog post clears up the issues around this and makes your life easier when troubleshooting your Access Policy issues.



Finally: I want to thank Scott Cottrille, Principal Group Software Engineering Manager of Azure Key Vault for the inspiration for this post.

I hope this helps you out when using the Azure Key Vault! Please follow us on Twitter and retweet!

@WinDevMatt @AzIdentity