12.3 Connected Organizations & External User Lifecycle
Key Takeaways
- Connected organizations represent external Microsoft Entra tenants or domains so entitlement management can scope package requests and collaboration to known partner identities.
- B2B entitlement scenarios use connected orgs plus access packages to onboard partners with approval, ToU, expiration, and reviews instead of permanent ad-hoc guest group membership.
- External user lifecycle includes invite/redeem, package assignment, conversion considerations, blocking sign-in, and removal when business need ends—not only creating guest objects.
- When package assignments expire, entitlement management removes resource access; governance settings can automatically remove guest users who no longer have access package assignments.
- Automatic guest removal reduces orphaned external accounts after the last package ends, while still requiring coordination with SharePoint/Teams data ownership and investigation holds when needed.
Closing the external collaboration loop
Earlier chapters covered B2B guests, external collaboration settings, and cross-tenant access. Entitlement management adds the package-centric partner model: define who the partner organization is, let their users request only allowed packages, time-box access, and clean up when projects end. Section 12.3 is where SC-300 tests connected organizations and external user lifecycle, including automatic guest removal concepts.
Connected organizations explained
A connected organization is an entitlement-management representation of an external organization you collaborate with. It is not merely a contact list entry; it is used so policies can say: “Users from Fabrikam may request Package A” or “Sponsors from this partner can approve.”
What a connected organization can represent
| Representation | Typical meaning |
|---|---|
| Microsoft Entra tenant (by tenant ID / domain) | Partner has its own Entra directory; B2B users authenticate home-tenant-first |
| Domain(s) associated with the partner | Email domains used to recognize external identities for governance scenarios |
| Configured external org record for sponsor/requestor scoping | Operational object packages and policies reference |
Connected organizations are the bridge between directory-level B2B and package requestor scope. Without them, “only Partner X may request” is hard to express cleanly in entitlement policies.
Configure connected organizations (exam workflow)
- Identify partner tenant ID and/or verified domains used for collaboration.
- Create the connected organization with a clear display name (legal/partner name).
- Add identity sources (Entra tenant and/or domains as appropriate).
- Optionally configure sponsors (internal or external people who sponsor access—useful for approval and governance scenarios).
- Reference the connected organization in access package assignment policies for external requestors.
- Align with External Identities collaboration allowlists and cross-tenant access settings so invites and inbound B2B are not blocked at a lower layer.
| Layer | Role |
|---|---|
| External collaboration settings | Who can invite; domain allow/deny |
| Cross-tenant access settings | Inbound/outbound B2B trust fine-tuning per tenant |
| Connected organization | Entitlement management partner object for packages/policies |
| Access package policy | Whether those partner users may request specific entitlements |
Exam trap: creating a connected organization without fixing collaboration domain restrictions that still deny the partner domain—packages will not save a blocked invite path.
B2B entitlement scenarios
Pattern: project-based partner access
- Create connected organization for Partner Co.
- Catalog: “Partner Co – Project Falcon.”
- Resources: project security group, limited enterprise app role, project SharePoint site.
- Package policy:
- Requestors: users from Partner Co connected org.
- Multi-stage approval: internal project lead + data owner.
- Duration: 90 days; extensions require approval.
- ToU: partner data handling terms.
- Access review: quarterly if extended repeatedly.
- Lifecycle: when last assignment ends, remove resources; optionally auto-delete guest if no remaining packages.
Pattern: standing vendor support
- Longer baseline duration but mandatory reviews.
- Tighter app roles; no broad “All company” groups.
- CA: require MFA for all guests; phishing-resistant for privileged-adjacent apps.
- Sponsors from the vendor org documented for re-attestation.
Pattern: multi-partner program
- One catalog per program or per partner (choose based on ownership).
- Multiple connected organizations allowed to request a shared “program baseline” package plus partner-specific packages.
- Avoid a single package shared by competitors if data separation matters—split packages/resources.
External user lifecycle end-to-end
Think in lifecycle stages, not only “invite guest.”
| Stage | Admin / system actions |
|---|---|
| Plan | Connected org, package, CA, ToU, duration |
| Onboard | Invite/redeem (B2B) or first successful package request that creates/uses guest |
| Assign | Package delivery to groups/apps/sites |
| Operate | Sign-ins under CA; support tickets; extensions |
| Review | Access reviews attest continued need |
| Block | Block sign-in on compromise or suspension without full delete |
| Convert | Rare path: external person becomes employee → member lifecycle / HR join (do not casually flip without process) |
| Offboard | Expire/remove packages; remove residual access; delete guest when policy allows |
Conversion (guest → member)
If a contractor is hired as an employee:
- Prefer a proper joiner process: member account (cloud or hybrid), licenses, employee packages, revoke vendor packages.
- “Convert external user to internal” style operations exist in directory tooling discussions, but SC-300 prioritizes process correctness: different UPN/auth home, licensing, CA cohorts, and HR authority—not a casual checkbox that leaves vendor group membership intact.
- Remove partner-only package assignments; add employee packages.
Blocking vs removal
| Action | Effect | Prefer when |
|---|---|---|
| Block sign-in | Authentication stops; object remains | Active investigation, temporary suspension |
| Remove package assignment | Resource access from that package ends | Project role ended but other packages may remain |
| Delete guest | Soft-delete directory object (recoverable within window) | Collaboration fully ended and policy allows |
| Automatic guest removal | System deletes guests meeting “no more package assignments” rules | Scale cleanup of orphaned project guests |
For compromise: block + revoke sessions (identity protection / session revoke knowledge from earlier chapters), then remove standing access, then decide delete after forensics.
Package expiration and resource cleanup
When an access package assignment expires or is removed:
- Entitlement management withdraws the package’s group memberships, app assignments, and SharePoint site access granted through that assignment.
- If the user still has other package assignments, those resources remain.
- If the user had extra direct group adds outside packages, those may remain—which is why shadow direct assignments undermine governance.
- Guest object may still exist until deleted manually or by automatic removal policies.
Key exam idea: expiration removes entitlement resources, which is not always identical to deleting the guest user object. Both matter; questions often test whether you know the difference.
Automatic guest removal concepts
Automatic guest removal (Entitlement management lifecycle settings) addresses orphaned B2B users who no longer have access package assignments.
Why it exists
Partners finish projects; assignments expire; guests remain enabled for years with no packages and sometimes residual non-package access or simply directory noise and attack surface (password spray against stale guests, token replay if not blocked, confusion in reviews).
Conceptual behavior
| Setting idea | Outcome |
|---|---|
| Manage guest lifecycle based on package assignments | Guests in scope of governance automation |
| Remove guest when they have no remaining access package assignments (after optional grace/delay as configured) | Directory cleanup aligned to entitlement end |
| Notify sponsors / admins before removal (where configured) | Operational warning to restore business access if mistaken |
| Exclude some users from auto-remove | Break-glass-like exceptions or long-running support accounts handled differently |
Exact portal labels evolve; SC-300 cares about the capability: automatically remove external users once they no longer have access package assignments, reducing permanent guest sprawl.
Design cautions
- Guests who only ever received manual group adds (never packages) may fall outside package-based auto-remove logic—another reason to prefer packages for partner access.
- SharePoint / OneDrive / Teams content ownership and guest sharing links may need separate data governance; deleting a guest does not replace information protection strategy.
- Do not enable aggressive auto-delete during a pilot without communication—partners may still need a final extension path.
- Coordinate with legal hold / eDiscovery processes before mass deletion in regulated tenants.
Putting connected orgs and lifecycle on the exam
| Stem cue | Likely answer focus |
|---|---|
| “Only users from tenant X can request the package” | Connected organization + requestor scope |
| “Partners must lose SharePoint and app access after 60 days” | Package expiration (and verify resources were package-granted) |
| “Remove guest accounts that no longer have any packages” | Automatic guest removal / lifecycle settings |
| “Contractor hired as FTE” | Convert/join as member; remove vendor packages; employee lifecycle |
| “Suspicious partner account still authenticates” | Block sign-in + revoke sessions; remove assignments |
| “Guest still in group after package expired” | Check for direct membership outside package or second package |
Alignment with earlier external identity skills
Connected organizations do not replace:
- Domain allowlists for invitations.
- Cross-tenant access inbound/outbound controls.
- Conditional Access for guest MFA and session controls.
- Access reviews for attestation.
- PIM for privileged roles.
They specialize entitlement management for partner-scoped self-service. A complete SC-300 answer often stacks two or three of these controls rather than picking only one buzzword.
Operational checklist for partner offboarding
- Confirm business end date; deny extensions if project closed.
- Remove or let expire all relevant package assignments.
- Search for direct group/app assignments and clean them.
- Block sign-in if risk requires immediate stop.
- Revoke sessions if compromise or urgent offboarding.
- Allow automatic guest removal to delete, or manually delete per policy.
- Verify sign-in failures expected; confirm SharePoint/Teams residual sharing as needed.
- Record audit evidence for compliance.
Summary of section 12.3
You must allow only users from a specific partner Microsoft Entra tenant to request a vendor access package. What should you configure as the primary entitlement-management construct for that partner population?
An access package assignment for a guest expires. What is the expected primary effect on access granted through that package?
Which statement best describes automatic guest removal in entitlement management lifecycle scenarios?