Conditional Access Blocks Service Principal
Tailspin has a multitenant app registration used by a partner. A Conditional Access policy requires multifactor authentication for all users accessing the Azure portal and applies to 'All cloud apps'. A second policy blocks legacy authentication. An automation runbook uses a service principal with a client secret to call the Microsoft Graph API and fails with 'AADSTS50076: The user is required to use multi-factor authentication.' The service principal is not in any excluded group. Separately, a guest user from the partner tenant can sign in to the portal but cannot access a subscription where they are assigned the Reader role at the subscription scope.
1. Why does the service principal receive an MFA challenge, and how should the policy be corrected?
Read the worked answer
Conditional Access targets users and workload identities differently. A policy scoped to 'All cloud apps' with an MFA grant control applies to user sign-ins; service principals authenticate with client credentials and cannot perform interactive MFA. The AADSTS50076 error indicates the token request is being evaluated under a policy that requires MFA, which typically happens when the policy's user assignment includes 'All users' and the workload identity is treated as a member, or when a separate workload identity policy targets it.
Correction:
- Inspect the policy's Users assignment - service principals should not be in a user-scoped policy. Use the workload identities Conditional Access surface for non-human identities.
- Exclude the automation service principal explicitly if it must remain under user policy scope, and document the compensating control (network restriction, certificate credential, short secret lifetime).
- Prefer certificate credentials or federated credentials over client secrets.
- Verify with sign-in logs filtered to the service principal to see which policy applied.
2. Diagnose the guest user's subscription access failure.
Read the worked answer
The guest can authenticate (portal sign-in works) but authorization fails. Possible causes:
- Role assignment scope mismatch: the Reader assignment may be on a management group or a different subscription than the one being accessed. Verify the assignment's scope in the subscription's Access control (IAM).
- Guest restrictions in the resource tenant: external collaboration settings or a Conditional Access policy may restrict guest access to specific apps, but this would usually block portal sign-in too, so it is less likely.
- Directory role vs Azure RBAC: being a guest with directory permissions does not grant subscription access; only Azure RBAC assignments do.
- Just-in-time or PIM: if the assignment is eligible rather than active, the guest must activate it.
Check the sign-in log for the resource tenant and the IAM blade for the exact principal ID and scope before changing policy.