Key Vault data-plane access denied for all human users on RBAC vault in PME tenant

Question

Key Vault data-plane access denied for all human users on RBAC vault in PME tenant

Kensei Kawamura 100 Microsoft Employee

I am having trouble accessing secrets in my KV even when i have key vault administrator permissions, i am in the PME tenant so i am assuming it has some additional restrictions. but i have been able to access this in the past (6-8months ago) so im not sure if something has changed since then

0 comments

Answer accepted by question author

0 additional answers

Your answer

Answer 1

Allan Solomon Mejia 8,420

Hello @Kensei Kawamura

Having Key Vault Administrator on an RBAC-enabled vault should provide data-plane permissions for keys, secrets, and certificates, so if all human users are suddenly denied, I would first determine whether this is actually an RBAC failure or a network/security-policy restriction.

Please capture the exact 403 error from the portal or CLI. The error details are important, for example, ForbiddenByRbac points toward authorization, while messages mentioning public access, firewall, or private link indicate network enforcement.

Also check Key Vault → Networking. If Public Network Access has been disabled or the vault is restricted to a private endpoint, human users accessing through the Azure portal still need network connectivity to the Key Vault data-plane endpoint (<vault>.vault.azure.net). Having Key Vault Administrator doesn't bypass those network restrictions.

You can also verify the effective role assignment:

az role assignment list \
  --assignee <user-object-id> \
  --scope <key-vault-resource-id> \
  --include-inherited \
  -o table

If Key Vault Administrator is active and the network path is allowed but the request still returns 403, check whether there are conditional/ABAC role assignments or tenant-level controls affecting the request.

Since you mentioned this is the PME tenant and the behavior changed from what worked previously, if the same failure affects multiple human identities while workload/service identities continue working, this may require an internal Microsoft tenant/security-policy review rather than a Key Vault configuration change.

If you can share the sanitized 403 error including its innererror.code (without tenant, subscription, vault, or user identifiers), that should tell us which layer is denying the request.

Please "Accept the Answer" if this information helped you. This will help us and others in the community as well.

Kensei Kawamura 100 Microsoft Employee

Hi Allan, thanks for the quick reply. I have verified that keyvault networking is set to allow all public network. I have also asked someone else on my team to elevate permission via JIT and they also ran into the same issue. Here is the error without any sensitive info:

(Forbidden) Caller is not authorized to perform action on resource.
If role assignments, deny assignments or role definitions were changed recently,
please observe propagation time.
Caller: appid=<CLIENT_APP_ID>;oid=<USER_OBJECT_ID>;iss=https://sts.windows.net/<TENANT_ID>/
Action: 'Microsoft.KeyVault/vaults/secrets/getSecret/action'
Resource: '/subscriptions/<SUB_ID>/resourcegroups/<RG>/providers/microsoft.keyvault/vaults/<VAULT>/secrets/<SECRET_NAME>'
Assignment: (not found)
DenyAssignmentId: null
DecisionReason: null
Vault: <VAULT>;location=westus2

Inner error: {
    "code": "ForbiddenByRbac"
}

Allan Solomon Mejia 8,420 Reputation points

2026-08-12T21:10:47.4033333+00:00
Hi @Kensei Kawamura

Thanks, the inner_error.code: "ForbiddenByRbac" is very helpful. This confirms the request is reaching Key Vault successfully and is being rejected by the Azure RBAC data-plane authorization layer, so I don't think networking is the issue.

Key Vault Administrator normally includes all Key Vault data-plane operations, including Microsoft.KeyVault/vaults/secrets/getSecret/action.

I would now verify the effective role assignment and its exact scope, rather than adding another role:

az role assignment list \ --assignee <USER_OBJECT_ID> \ --scope <KEY_VAULT_RESOURCE_ID> \ --include-inherited \ --include-groups \ -o table

Check that Key Vault Administrator is actually active, applies to this vault through the vault/RG/subscription hierarchy, and isn't only an eligible PIM assignment that hasn't been activated. Microsoft supports eligible/JIT Azure RBAC assignments through PIM, so an eligible role isn't equivalent to an active assignment.

I would also inspect the role assignment for an ABAC condition. Key Vault now supports conditions on secret data actions, and a condition can result in ForbiddenByRbac even though the user appears to have the correct role.

Since you mentioned that multiple users are seeing the same issue, if their assignments are active, correctly scoped, and have no unexpected conditions, I'd next check whether those users receive their Key Vault permissions through the same group/PIM configuration.

If direct and group-based assignments are both confirmed correct but getSecret continues returning ForbiddenByRbac, especially if this started simultaneously for multiple users, I think this is sufficiently isolated for Microsoft to investigate the tenant's effective RBAC evaluation.

Please don't forget "Accept the Answer" if this information helped you. This will help us and others in the community as well.
Kensei Kawamura 100 Reputation points Microsoft Employee

2026-08-12T21:19:06.44+00:00

i don't know what happened, maybe there was some outage but now i can view the keyvault, thank you for the help!