SC-300 study materials
SC-300 study resources

Litware: 6,800 Guests, a Silent Access Review, and 500 Governance Licenses

SC-300 · Put your knowledge to work in context.

All case studies

Litware: 6,800 Guests, a Silent Access Review, and 500 Governance Licenses

Litware has 4,200 employees and 6,800 guest accounts from 60 partner organizations. Business units grant access by sharing SharePoint sites directly with named individuals. No one can say which guests still work for their partner. HR sends a CSV of leavers to the helpdesk, which disables the account but leaves group membership intact; roughly 40 percent of leavers keep their group-based licenses for months. A quarterly access review of guests exists, but reviewers are the guests' internal sponsors' managers, and the review is configured to 'No change' when reviewers do not respond - 70 percent of reviewers never respond. Licensing: 4,200 Microsoft Entra ID P1 and 500 Microsoft Entra ID Governance.

1. Fix the leaver licensing leak given that only 500 users are covered by Entra ID Governance.

Read the worked answer

P1 does not include lifecycle workflows, access reviews, entitlement management, or PIM. With 4,200 employees and 500 Governance licenses, any design that depends on a Governance feature firing per leaver will fail for ~3,700 people. So split the solution by licence tier.

For everyone (works on P1): switch the licensing groups to be dynamic with a rule on accountEnabled -eq true. Group-based licensing removes the license when the user leaves the group, so disabling the account automatically drops the licence within the group-based-licensing processing window. Verify every affected user has a usageLocation - a missing value silently fails licence assignment.

For the 500 covered seats (Governance): use a lifecycle workflow on the employee-leave event to remove group memberships, revoke access packages, and delete or block the account. The prerequisite is the trap: the leave trigger needs employeeLeaveDateTime (and ideally the HR source of authority) populated in Entra ID. A CSV to the helpdesk provides none of that, so the first deliverable is a data path - HR inbound provisioning or a sync of the attribute from AD - not a workflow.

Guest leavers are different: they are only reachable through access packages with expiry, or through revocation driven by the partner organization. Do not assume the employee-leave workflow applies.

2. Redesign the guest access review so it actually produces decisions. Name every configuration defect you would change.

Read the worked answer

Four defects, four changes:

  1. Reviewer choice is wrong. The managers of internal sponsors have no visibility into whether a guest still works at their partner. For guest populations, reviewers should be the sponsors or group/site owners, with an explicit fallback reviewer configured for when the primary does not respond (a feature that exists precisely for this). Without a sponsor recorded on the guest object, the review has no legitimate decision-maker - that is a data problem to fix first.
  2. The non-response behaviour is wrong - but do not simply flip it to 'Remove access' on 6,800 objects. Run one cycle with recommendations enabled and auto-apply off to measure how many decisions are genuinely possible. Once sponsors are populated, move to 'Remove access' on a scoped population, then widen.
  3. The scope is wrong. Access reviews require P2 or Entra ID Governance for each user whose access is reviewed. 500 Governance licences against 6,800 guests means you cannot review everyone. Scope reviews to the guests with access to the highest-sensitivity sites and extend licensing only if the residual risk justifies it.
  4. The dependency on human response is wrong. Combine the review with access package expiry so guest access is time-bound by default and the review is a confirmation step rather than the only control. Auto-apply results, and set a review duration short enough that a stalled cycle is visible.

3. SharePoint direct sharing is bypassing your governance model. What do you do about it?

Read the worked answer

Recognise what the gap actually is. Entra sees the guest object, but a site-level permission granted through a sharing link is not derived from group membership or an access package. Revoking an Entra guest blocks sign-in, but the site permission artifact remains; re-inviting the same person can restore their access. So access reviews of Entra groups are not a complete control while direct sharing is allowed.

Reduce the bypass surface:

  • Set site-level external sharing limits: for sensitive sites, restrict sharing to people in your organization, and use a domain allowlist so guests can only be invited at partner corporate domains.
  • Restrict who can invite guests at the tenant level, and turn off 'anyone can invite' so invitations are attributable.
  • Move high-value collaboration into Teams or Microsoft 365 groups so the membership is an Entra object that access packages, expiry, and reviews can govern. For group-connected sites, run site membership reviews on the connected group.
  • For remaining non-group sites, generate a periodic SharePoint permission report and reconcile it against the guest inventory - this is detection, not control, and should be labelled as such.

Then re-scope the question: the goal is that every external identity has an Entra object with a sponsor and an expiry date. Direct sharing is acceptable only where the site itself has been classified as low sensitivity.