4.1 External Collaboration & Guest Lifecycle
Key Takeaways
- Microsoft Entra B2B collaboration invites external users into your tenant as guest objects so they can access apps and resources while authenticating with their home identity provider when possible.
- External collaboration settings control who can invite guests, what guest users can see in the directory, and whether collaboration is restricted to allowlisted domains or blocked domains.
- Guest invitations can be sent individually or in bulk; redemption creates or links the guest user so they can sign in and receive assigned access.
- User type Guest is the primary directory signal for external collaborators; governance, Conditional Access, dynamic groups, and access packages commonly target guest userType.
- Lifecycle management for guests includes invite, redeem, assign access, review, block sign-in, and delete or convert based on policy—not treating guests identically to members.
Why external identities matter on SC-300
Domain 1 of the Microsoft Identity and Access Administrator Associate exam (SC-300) expects you to manage external identities and external collaboration. Real organizations rarely keep every collaborator as a full member account in their tenant. Partners, vendors, contractors, and multi-company project staff usually authenticate with their home identity and receive limited access in your tenant through Microsoft Entra External Identities — primarily B2B collaboration.
This section covers guest lifecycle and tenant collaboration settings. Cross-tenant access defaults, B2B direct connect, cross-tenant sync, and external identity providers appear in the following sections of this chapter.
B2B collaboration in plain language
B2B collaboration invites an external user into your Microsoft Entra tenant as a guest user. After the invitation is redeemed, the guest can be assigned to groups, enterprise applications, SharePoint sites, Teams, and access packages — subject to your policies.
Key ideas:
- The guest is an object in your directory (
userType= Guest in typical B2B scenarios). - Authentication preferably uses the user’s home identity (their organization’s Entra tenant, a social identity where allowed, or another supported IdP path).
- You still control authorization in your tenant: apps, groups, Conditional Access, and governance.
- Guests are not a back door around Zero Trust; they should receive least privilege, MFA/Conditional Access where appropriate, and time-bound access when governance features are used.
| Concept | What it means for SC-300 |
|---|---|
| Resource tenant | Your tenant that hosts apps/data and issues the invitation |
| Home tenant / home IdP | Where the external user primarily authenticates |
| Guest user object | Representation of the external user in the resource tenant |
| Invitation | Email/link that starts the B2B onboarding flow |
| Redemption | Completing invite so the guest can sign in and use assigned access |
| B2B collaboration | Classic invite-and-collaborate model (Teams, apps, SharePoint, etc.) |
Do not confuse B2B guests with creating a full member account for every contractor. Member accounts imply internal workforce identity, different default permissions, and often different licensing and governance patterns.
External collaboration settings
In the Microsoft Entra admin center, External Identities → External collaboration settings (wording can vary slightly by portal version) define tenant-wide defaults for inviting and using guests.
Guest user access restrictions
These settings limit what guests can see and do in the directory, not merely whether they exist:
| Level (conceptual) | Typical intent |
|---|---|
| Most inclusive | Guests have similar directory read capabilities to members for many objects (rarely recommended for Zero Trust) |
| Limited / most restrictive guest access | Guests see limited profile and membership data; reduces enumeration and reconnaissance |
| Blocked guest access to directory (where available as a restriction model) | Guests cannot read directory objects beyond what apps explicitly need |
Exam framing: if a scenario says partners should collaborate in Teams/SharePoint but must not browse the full directory, choose more restrictive guest user access, not “make them Global Readers.”
Guest invite settings
Control who can invite:
- Anyone in the organization can invite (broad; convenient; higher risk of shadow IT invites).
- Member users and users with specific admin roles can invite.
- Only users with admin roles that permit inviting (tightest common control).
- No one can invite (collaboration effectively frozen until settings change or alternate flows are used).
Also consider whether guest users themselves may invite other guests. Many security baselines deny guest-to-guest inviting to prevent uncontrolled sprawl.
Collaboration restrictions (domains)
Domain allow/deny lists reduce accidental or malicious collaboration outside approved partners:
| Mode | Behavior |
|---|---|
| Allow invitations to any domain | Default open collaboration (subject to other settings) |
| Deny invitations to specified domains | Block known risky or unwanted domains; allow everything else |
| Allow invitations only to specified domains | Allowlist model — strongest partner boundary for regulated industries |
Exam rule: when the business says “only collaborate with contoso.com and fabrikam.com,” choose allow only specific domains, not a long deny list of the entire internet.
These collaboration settings work together with cross-tenant access settings (next section). Collaboration settings are the classic guest/invite surface; cross-tenant access settings refine inbound/outbound trust per partner tenant for B2B collaboration and direct connect.
Guest user type and identity properties
A redeemed B2B collaborator typically appears with:
- User type:
Guest - Identities / source: external (shows federation or invitation source indicators)
- UPN pattern: often
#EXT#style cloud UPNs for guests (for example,user_contoso.com#EXT#@yourtenant.onmicrosoft.com), while the user still signs in with their email/home identity experience - Object ID: still the unique key for Graph, restore, and assignment troubleshooting
Dynamic membership and Conditional Access commonly use rules or assignments based on userType -eq Guest. Access packages and entitlement management also treat external users as a first-class lifecycle population.
Member vs Guest comparison for exams:
| Aspect | Member | Guest (B2B) |
|---|---|---|
| Typical origin | Workforce hire / sync / cloud create | Invitation or self-service B2B flow |
| Default directory permissions | Broader internal defaults | Restricted by guest access settings |
| Auth home | Usually your tenant or hybrid | Usually external home IdP |
| Governance focus | Joiner-mover-leaver HR path | Invite, review, expire, remove |
| Licensing | Full workforce SKUs common | Often unlicensed or limited feature licensing |
Inviting guests: individual and bulk
Individual invite
Administrators (or authorized inviters) can invite a guest by email address, optionally adding a personal message, CC, and group/app assignment at invite time. The system sends an invitation that the external user redeems.
You can also create guest-oriented flows via Microsoft Graph (invitation resource) for automation — SC-300 cares that Graph/PowerShell invite is a valid admin path, not only portal clicks.
Bulk invite
Large partner onboarding uses bulk invite CSV templates in the Entra admin center (or scripted Graph loops). Columns typically include email/UPN to invite, display name, and optionally redirect URL or invitation message patterns depending on template version.
Bulk success depends on:
- Collaboration settings allowing the inviter and the target domain
- Valid email addresses and not colliding with existing objects incorrectly
- Capacity/process to assign access after invite (groups, apps, packages)
- Communication so partners complete redemption
Inviting without an access plan produces orphan guests who redeem and still cannot reach business apps — a common operational failure, not a directory bug.
Redemption lifecycle
Redemption is when the invited user accepts the invitation and establishes the authentication relationship needed to use resource-tenant access.
Conceptual stages:
- Invite created — guest object may exist in invited state; invitation email/link issued.
- User opens redeem experience — may consent to permissions, complete MFA if required by resource or home policies, and select identity.
- Redeemed — guest can sign in to assigned resources under resource-tenant policies.
- Ongoing use — Conditional Access, continuous access evaluation, and app permissions apply like other users, with guest-specific nuances.
If redemption never happens, the user cannot use the access. Admins can resend invitations when emails are lost or expire from a process perspective. Some pending guests should be cleaned up if the project is canceled.
Email one-time passcode (OTP) and other External Identities options can help when the guest does not have a workable home IdP redemption path. Know that External Identities supports multiple redemption methods so collaboration is not limited to only Entra-to-Entra partners.
Managing external user accounts
Day-2 operations for guests mirror internal lifecycle, with extra governance emphasis:
| Operation | When to use |
|---|---|
| Assign groups / app roles / access packages | Grant least-privilege resource access after or during invite |
| Block sign-in | Immediate stop of authentication without deleting history |
| Delete (soft-delete) | Collaboration ended; follow retention and data ownership process |
| Restore | Accidental delete within soft-delete window |
| Access reviews | Periodic attestation that the guest still needs access |
| Entitlement management expiration | Time-box partner access automatically |
| Convert guest to member (rare, process-driven) | External person becomes an employee; follow HR onboarding, do not casually flip types without process |
Offboarding guests should revoke app assignments, group memberships, and Teams/SharePoint access pathways, then block or delete per policy. Leaving former vendors as enabled guests with residual group membership is a frequent audit finding.
Guest accounts still appear in sign-in logs and audit logs. Use those for investigating failed redemptions, unexpected partner access, and Conditional Access failures.
Guest access restrictions in applications and Microsoft 365
Directory guest settings are only one layer. Application owners and Microsoft 365 admins also control:
- Whether specific enterprise applications allow guest assignment
- SharePoint / OneDrive external sharing levels (organization-wide and site-level)
- Teams guest access and external access (Teams “external access” for federation chat is related but not identical to Entra B2B guest objects — exam items may distinguish guest access in Teams vs external access federation)
- Sensitivity labels and DLP that constrain what guests can download or share
SC-300 identity admins must coordinate with M365 sharing settings: Entra may allow invites while SharePoint is locked to existing guests only — or the reverse. For exam scenarios, read carefully which control plane the question targets.
Practical design patterns
- Default deny for invites from standard users; allow a partner-onboarding group or helpdesk role to invite.
- Allowlist partner domains for regulated collaboration.
- Restrict guest directory visibility to the most practical restrictive setting the business can tolerate.
- Prefer access packages (later domain) for multi-resource partner projects over ad-hoc permanent group adds.
- Target Conditional Access to all guests or high-risk guest cohorts (require MFA, block legacy auth, session controls).
- Schedule access reviews on guest-containing groups.
Exam traps
- Treating guests as members for default permissions and broad directory read.
- Opening anyone can invite in a high-security scenario.
- Using deny list when the requirement is only specific partners (need allowlist).
- Inviting hundreds of guests without group/app/package assignment and calling the job done.
- Forgetting redemption when troubleshooting “invited user cannot access Teams.”
- Deleting instead of blocking during an active investigation of guest compromise.
An organization must allow B2B collaboration only with two partner email domains and block invitations to every other domain. Which external collaboration approach best matches that requirement?
A partner was invited yesterday but cannot open the assigned enterprise application. Sign-in logs show no successful authentications for that guest. What lifecycle step is most likely incomplete?
Security wants external collaborators in the tenant but does not want guests browsing broad directory information. Which control plane should an identity administrator tighten first for that directory-visibility goal?
Which statement correctly contrasts a B2B guest with a cloud-only member contractor account?