entra1-6 Exercise 1: Which Gate Is It? ========================================================= Source: Microsoft Learn pages on permissions and consent, user and admin consent, assigning users and groups, Conditional Access (including workload identities) and the AADSTS error-code reference. Re-check before relying on any detail; Microsoft renames pages and settings. (a) Only newly hired Fabrikam staff can't sign in; older staff can Gate: 1, permissions and consent (user consent). Likely cause: The tenant's user-consent setting was tightened (for example to "Disable user consent"). Existing users already have recorded consent; new users need to consent for the first time and are not allowed to, so they are not even prompted. First page: the tenant's user-consent setting (Enterprise apps > Consent and permissions; menu names vary, so search the portal), then the enterprise application's Permissions page. Fix options: an administrator grants tenant-wide consent, or the consent workflow is enabled with a reviewer. Rule out: Assignment (if "Assignment required" is Yes, are the new staff in the assigned group?), which gives the same pattern. (b) After version 4.2, every Contoso user is told approval is required Gate: 1, consent. The "Approval required" window is the admin consent workflow. Likely cause: The release added a permission that Contoso's administrator never granted. Microsoft notes users can be prompted again even after admin consent if the app requests another permission. First page: Enterprise apps > > Permissions, compared with the registration's API permissions (in the tenant that owns it). The fix is a new admin consent for the updated list; your product team should also be able to say exactly what changed in 4.2. Lesson: Release notes should list any new permission. (c) 40 Sales users fail; Support Staff works; Sales nested in All Staff Gate: 2, assignment. Likely cause: Assignment doesn't cascade to nested groups, and nested group membership isn't currently supported. The Sales users aren't assigned even though "All Staff" is. First page: Enterprise apps > > Users and groups. Fix: assign the Sales group directly (or add the users to an assigned group). Group assignment needs Entra ID P1 or P2. Evidence: A failed user's sign-in often shows AADSTS50105 (user isn't assigned to a role for the app). (d) Nightly token request failing since Tuesday; service-principal sign-in says "Access has been blocked due to Conditional Access policies." Gate: 3, conditions (Conditional Access for workload identities). Likely cause: A policy targeting this service principal blocks token requests from outside allowed IP ranges (or on risk). Maybe your server's IP address changed, or a new policy was created. First page: Sign-in logs > Service principal sign-ins > the event > Conditional Access tab, then Entra ID > Conditional Access > Policies. Fix: the client's security team adds your fixed IP address as an allowed location (or otherwise adjusts the policy); do not ask for the policy to be disabled. Note: This feature covers single-tenant service principals in the client's tenant, not multitenant apps, so it also tells you the client created their own registration (arrangement B or C). (e) Your support engineer, signed in as a guest, sees AADSTS50020 Gate: 3, guests/cross-tenant (the account question). Likely cause: Microsoft: the account doesn't exist in the tenant and must be added as an external user. The guest was never invited, or invitation wasn't redeemed, or they are signing in with the wrong account. First page: Entra ID > Users in the client's tenant (does the guest exist?). If the guest exists, check the cross-tenant access inbound settings and external collaboration settings. WHY THIS WORKS AS AN ANSWER --- The pattern of who is affected, and when it began, points at a gate before any log is opened. Each answer names one cause, one page and one fix owned by the client, and never involves a secret or turning security off.