Power Platform Azure Key Vault Environment Variables
The Problem
When attempting to create an Azure Key Vault environment variable in Power Platform, you get the following error message:
User is not authorized to read secrets from '/subscriptions/{<SubGuid>}/resourceGroups/<RGName>/providers/Microsoft.KeyVault/vaults/<KVName>/secrets/<SecretName>' resource.
I ran into this when configuring the CoE Starter Kit for a GCCH client and found the same issue in my own Commercial tenant.
The error code does not indicate what user is not authorized, and even with tracing enabled, it did not appear a trace log was generated for this error.
Per the Key Vault Setup Instructions you must first add the Microsoft.PowerPlatform service provider to the Azure Subscription. It also notes recent changes in Key Vaults to use RBAC based security instead of Access Policies and indicates the user configuring the Environment variable needs to be granted the Key Vault Secrets User role. Step 5, as currently written, indicates that this role must also be granted to the Dataverse service principal, but 1) indicates to add it as an access policy (this should read role assignment), and 2) identifies it by Application ID 00000007-0000-0000-c000-000000000000, which may not appear to be correct. It indicates if you have multiple service principals with the same name, to find the one that matches this ID and remove the others. You may find many service principals with similar related names but find yourself unable to locate one with this ID.
Unlike the previous Azure Policies user interface, the Role Assignment UI’s selector does not show the Application ID to aid in finding the correct one. Instead, the Review + Assign screen shows the Object ID, as shown below. Note the ID shown is the Object ID.
However, after adding them, you can open each hyperlinked Enterprise Application record to verify the Application Id. Interestingly, when opened in this way, the name does not match.
No mistake about it. On the Azure Key Vault Roles assignments, it shows as Dataverse, but when opened, the record shows as Common Data Service.
In the case of the GCCH tenant, it wasn’t called Dataverse. Instead, we found it listed as PowerApps Service - GCC L4, with Application ID 5e0cb1f6-2841-4956-9c76-868bfbc15a39. This probably varies with other regions / sovereign clouds, but I was not able to find these documented anywhere.
The Helpful Bit
When setting up Azure Key Vault environment variables, note the role assignment interface shows the Object ID, not the Application ID. Also, the service name may differ depending on the cloud.
References
MSFT Solution Troubleshooting: An active unmanaged layer is created after importing a managed solution – Power Apps | Microsoft Learn
MSFT – User Azure Key Vault Secrets: Use environment variables for Azure Key Vault secrets – Power Apps | Microsoft Learn
Thomasz Poszytek – How to Configure and Use Secret Environment Variable in Power Platform: Tomasz’s video shows this error, pointing out the guid mismatch, but the video is based on the old Access Policies approach, which shows the App Ids – SC VD 103 (youtube.com)
Yannick Reekmans – Power Platform Environment Variable Secrets: References the old ‘Dataverse’ service principal name. Power Platform environment variable secrets from Azure Key Vault: an improvement? – Yannick Reekmans – Building things on Microsoft 365, Dynamics 365, Power Platform and Azure