Problem
CurrentPrincipalId (in current_principal_id_provider.go) resolves the current user's object ID by:
- Calling
LookupTenant(subscriptionId) → returns UserAccessTenantId (the user's home tenant)
- Calling Graph
/me against that tenant → returns the home-tenant oid
For B2B/guest users, the home-tenant oid is different from the guest oid in the resource tenant. All callers that use this principal ID to interact with the resource tenant's ARM APIs receive the wrong identity.
Impact
All callers of CurrentPrincipalId are affected:
| Caller |
File |
Impact |
| Preflight role check |
bicep_provider.go:2220 |
assignedTo() filter uses wrong oid → false positive warning |
loadParameters |
bicep_provider.go:1800 |
AZURE_PRINCIPAL_ID in ARM params → role assignments target wrong principal |
| bicepparam compile |
bicep_provider.go:1980 |
Same as above |
| Terraform provider |
terraform_provider.go:722 |
Principal ID in tfvars → wrong identity |
| Key Vault RBAC |
cmd/env.go:612 |
Role assignment on Key Vault targets wrong principal |
Root Cause
LookupTenant returns sub.UserAccessTenantId (correct for credential creation) but callers also use the same tenant for identity resolution via Graph /me. For guest users:
- Home tenant → Graph
/me returns home-oid (e.g. 4070b897-...)
- Resource tenant → Graph
/me returns guest-oid (different value)
The UserAccessTenantId vs TenantId distinction (account.Subscription model) is documented as:
UserAccessTenantId: tenant under which the user authenticates (home tenant)TenantId: tenant that owns the subscription (resource tenant)
Proposed Fix
CurrentPrincipalId (or GetCurrentPrincipalId) should resolve the oid in the resource tenant context when the principal ID will be used for ARM operations in that tenant. This may require:
- Calling Graph
/me against sub.TenantId instead of sub.UserAccessTenantId, or
- Extracting the oid from an ARM token scoped to the resource tenant, or
- Providing both oids and letting callers choose
Care must be taken not to break credential creation flows, which correctly use UserAccessTenantId.
Related
Problem
CurrentPrincipalId(incurrent_principal_id_provider.go) resolves the current user's object ID by:LookupTenant(subscriptionId)→ returnsUserAccessTenantId(the user's home tenant)/meagainst that tenant → returns the home-tenant oidFor B2B/guest users, the home-tenant oid is different from the guest oid in the resource tenant. All callers that use this principal ID to interact with the resource tenant's ARM APIs receive the wrong identity.
Impact
All callers of
CurrentPrincipalIdare affected:bicep_provider.go:2220assignedTo()filter uses wrong oid → false positive warningloadParametersbicep_provider.go:1800AZURE_PRINCIPAL_IDin ARM params → role assignments target wrong principalbicep_provider.go:1980terraform_provider.go:722cmd/env.go:612Root Cause
LookupTenantreturnssub.UserAccessTenantId(correct for credential creation) but callers also use the same tenant for identity resolution via Graph/me. For guest users:/mereturnshome-oid(e.g.4070b897-...)/mereturnsguest-oid(different value)The
UserAccessTenantIdvsTenantIddistinction (account.Subscriptionmodel) is documented as:UserAccessTenantId: tenant under which the user authenticates (home tenant)TenantId: tenant that owns the subscription (resource tenant)Proposed Fix
CurrentPrincipalId(orGetCurrentPrincipalId) should resolve the oid in the resource tenant context when the principal ID will be used for ARM operations in that tenant. This may require:/meagainstsub.TenantIdinstead ofsub.UserAccessTenantId, orCare must be taken not to break credential creation flows, which correctly use
UserAccessTenantId.Related