Access to Azure KeyVault from an app in another Azure ActiveDirectory tenant

3
votes

I have an Azure subscription in which I have all the resources for my web application. I have created another ActiveDirectory tenant, defined a AD Application in the tenant, and set it up as the authentication provider for my AppService. Now, I want to create a KeyVault resource in my subscription and give my AD Application access to the KeyVault.

The Azure KeyVault documentation says to run the following PS command:

Set-AzureRmKeyVaultAccessPolicy -VaultName <KVName> -ObjectId <ClientId> -PermissionsToKeys get

However, this returns the following error:

Cannot find the Active Directory object '<ClientId>' in tenant '<MyDefaultTenantId>'

The issue seems to be that my KV is not in the same AD tenant as my AD application, but Set-AzureRmKeyVaultAccessPolicy command does not seem to have a TenatId argument.

Is there any way I can achieve what I want? Do I have to move my AD application to my default AD tenant?

3
azureazure-active-directoryazure-keyvault
what is the clientid you used here? objectid should be the service principal id corresponding to the ad application in your destination subscription - sqlnewbie

3 Answers

5
votes

No. A key vault will accept identities only from the tenant it is in.

2
votes

You can of course make your application multi-tenant, consent the application into the Azure AD directory in the subscription containing the Key vault and then add the application as a principal with access permissions to Key vault in the portal.

Your application can then access the Key vault on behalf of users from that directory or on its own behalf using client credentials.

2
votes

I had the same situation and requirement (never going to get back these 8 hours :-) but you can easily make this consent by calling a specific URL and continue granting the application identity the necessary permissions in the key vault

in short...

GET https://login.microsoftonline.com/{tenant}/adminconsent?
client_id=6731de76-14a6-49ae-97bc-6eba6914391e
&state=12345
&redirect_uri=http://localhost/myapp/permissions

Always run in private browser window to not get all tangled up in the different identities during your browser day life time.

Read more here: https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-scopes#using-the-admin-consent-endpoint