Troubleshooting Lab: Manage External Users
Diagnostic Scenarios
Scenario 1 — Root Cause
The IT team of a company received a complaint from carlos.lima@fornecedor.com, a guest user who has been active in the tenant for three months. Carlos states that after trying to access a corporate application integrated with Microsoft Entra ID, he receives the following message:
AADSTS50020: User account 'carlos.lima@fornecedor.com' from identity provider
'fornecedor.com' does not exist in tenant 'contoso.com' and cannot access the
application '8e3f4b2a-...' in that tenant. The account needs to be added as an
external user in the tenant first. Sign out and sign in again with a different
Azure Active Directory user account.
The administrator verifies in the portal and confirms that Carlos's account exists in the directory as Guest type with Active status. The application is registered in the tenant and has assigned users. Carlos states that he could access normally until last week and that there was no change on his side. The fornecedor.com domain is not listed as a blocked domain in the external collaboration settings.
The administrator also notes that on the same day the problem started, a tenant license migration was performed, unrelated to external users.
What is the root cause of the problem?
A) The fornecedor.com domain was added to the external collaboration restrictions list after the complaint.
B) Carlos's account was removed from the application's user assignment in Microsoft Entra ID.
C) Carlos's invitation expired and the session token was automatically invalidated.
D) Microsoft Entra Conditional Access settings block external users' access to the application.
Scenario 2 — Action Decision
The cause of the problem has been identified: during an access group reorganization in the tenant, the Guest account of carlos.lima@fornecedor.com was removed from the direct application assignment and the group he belonged to also had its application assignment revoked. Carlos needs to regain access urgently, as there is a critical delivery in progress.
The administrator has the following restrictions:
- Does not have permission to reassign groups to the application (this action requires security team approval, with a 48-hour SLA)
- Has permission to manage direct user assignments in applications
- Must not create new groups or alter the existing group structure
- Access needs to be restored in less than 30 minutes
What is the correct action to take at this moment?
A) Open a ticket to the security team requesting group reassignment to the application with maximum priority.
B) Create a new temporary group, add Carlos and assign this group to the application.
C) Add Carlos directly to the list of users assigned to the application in Microsoft Entra ID.
D) Resend the external collaboration invitation to Carlos, forcing Guest account recreation.
Scenario 3 — Root Cause
An administrator receives a complaint from three different external users, from distinct domains, all reporting that their collaboration invitations were received by email but when clicking the link, the page returns the following error:
Sorry, but we're having trouble signing you in.
AADSTS65005: The application has requested permissions to access a resource that
does not match what is configured in the Consent Framework.
Investigating the recent history, the administrator identifies the following actions performed in the last two days:
- TLS certificate update for an internal application (unrelated to the invitation flow)
- Redirect URL change in the application registration used in the invitation redemption flow
- Addition of a new verified domain to the tenant
- Key rotation for a monitoring application
All invitations were sent within the same period and the three users attempted to redeem the invitation on the same day. Internal tenant users report no access problems.
What is the root cause of the problem?
A) Adding the new verified domain to the tenant invalidated pending invitations generated before the change.
B) The redirect URL in the redemption flow application registration was changed to an incompatible value.
C) The monitoring application key rotation generated conflict with the guest authentication process.
D) The updated TLS certificate is not recognized by the external users' identity provider.
Scenario 4 — Diagnostic Sequence
An administrator receives the following report: external users from a specific partner can accept the invitation and access the tenant, but are blocked when trying to open a set of files in SharePoint Online shared with them. Internal users access the same files without any problems.
The administrator needs to diagnose the problem. The available investigation steps are:
- Step P: Verify if the external user is assigned or is a member of the group with access to the SharePoint library
- Step Q: Check the external user's sign-in logs in Microsoft Entra ID to identify if there's a Microsoft Entra Conditional Access block
- Step R: Confirm that the invitation was accepted and that the Guest account has
Activestatus in the directory - Step S: Verify external sharing settings at the SharePoint site level and organization level in the tenant
- Step T: Open a ticket with Microsoft support reporting incompatibility between SharePoint and Microsoft Entra External ID
What is the correct diagnostic sequence?
A) R, Q, S, P, T
B) Q, R, P, S, T
C) R, S, Q, P, T
D) S, R, Q, P, T
Answer Key and Explanations
Answer Key — Scenario 1
Answer: B
The decisive clue in the statement is that Carlos existed in the directory with Active status and accessed normally until the previous week. The AADSTS50020 error may seem to indicate that the account doesn't exist, but the message is generic and also appears when the user exists in the directory but doesn't have assignment to the specific application. The statement itself confirms that the application "has assigned users," signaling that assignment is necessary.
The information about license migration is deliberately irrelevant and serves to divert diagnosis. Tenant licenses don't affect application assignments for external users.
Alternative A is incorrect because the non-blocked domain is explicitly confirmed. Alternative C confuses invitation expiration with active session; an expired invitation would prevent initial redemption, not access for a user who has been active for three months. Alternative D is plausible, but Conditional Access would block with a different error code (AADSTS53003 or similar) and would affect other external users as well.
Acting based on alternative D would be the most dangerous mistake: changing Conditional Access policies without precise diagnosis can affect all external users in the tenant.
Answer Key — Scenario 2
Answer: C
Given the set of restrictions, the only action that restores access within the 30-minute timeframe, without violating the administrator's permissions and without altering the group structure, is to add Carlos directly to the application's user assignment list.
Alternative A respects the process, but the 48-hour SLA makes the critical delivery unfeasible and ignores that the administrator has an alternative within their permissions. Alternative B explicitly violates the restriction of not creating new groups. Alternative D is technically incorrect: resending an invitation doesn't restore application assignments; the invitation controls directory access, not permissions on specific resources.
The central point of this scenario is to distinguish between what is technically possible, what is within available permissions, and what meets time constraints.
Answer Key — Scenario 3
Answer: B
The AADSTS65005 error indicates an incompatibility between the permissions requested during the authentication flow and what is configured in the application registration. The Microsoft Entra External ID invitation redemption flow depends on an application registration with valid and consistent redirect URIs. A change in this URL breaks the flow for all invitations that go through this application, regardless of the guest's domain of origin.
The confirmatory clue is that the three users are from distinct domains and all failed in the same period, right after the redirect URL change. If the problem was domain-specific or invitation-specific, it would affect only one of the users.
The information about the TLS certificate and monitoring application key rotation is purposefully irrelevant. Adding a verified domain (alternative A) doesn't invalidate pending invitations; invitations are tied to email address, not the tenant domain.
The most dangerous distractor is alternative D, as it leads the administrator to investigate the external provider side, wasting time on something outside their control.
Answer Key — Scenario 4
Answer: A
The correct sequence is: R, Q, S, P, T
The diagnostic reasoning should follow a progression from most comprehensive to most specific, eliminating hypotheses from outside to inside:
- R — Confirm that the user accepted the invitation and is active. If the account is not active, no other step is necessary.
- Q — Check sign-in logs to identify Conditional Access blocks. A block at this layer would prevent any access, not just to SharePoint.
- S — Verify tenant and site external sharing settings. SharePoint has its own external sharing controls that are independent of Microsoft Entra ID and can block access even for active guests.
- P — Verify assignment to the specific group or library. This step is more granular and only makes sense after confirming that previous layers are correct.
- T — Opening a support ticket is always the last resort, after exhausting internal diagnostics.
Alternative B starts with Conditional Access before confirming the account is active, which inverts the logic. Alternative C skips Conditional Access before SharePoint, which can lead to incomplete diagnosis. Alternative D starts with SharePoint settings without validating the basic account state, which is the prerequisite for everything.
Troubleshooting Tree: Manage External Users
Color Legend:
| Color | Node Type |
|---|---|
| Dark Blue | Initial symptom (entry point) |
| Blue | Diagnostic question (binary or state decision) |
| Red | Identified cause |
| Green | Recommended action or resolution |
| Orange | Validation or intermediate verification |
To use this tree when facing a real problem, start with the root node describing the general symptom. From each diagnostic question, answer based on what is directly observable in the portal or logs, without presuming the cause. Follow the path that corresponds to the actual observed state until reaching an identified cause node. Only then execute the corresponding recommended action and validate the result in the sign-in logs before closing the ticket.