SC-300 Identity & Access Administrator

Bulk user operations: create/update/delete users in bulk via CSV upload in Entra admin center, or via PowerShell (New-MgUser) and Microsoft Graph API (POST /users). Ideal for provisioning >50 users at once during organizational onboarding.

Dynamic groups: membership maintained automatically by attribute-based rules (e.g., user.department -eq "Finance" -and user.jobTitle -contains "Manager"). Two types: Security (for RBAC/CA) and Microsoft 365 (for Teams/SharePoint collaboration). Processing delay up to 24h after attribute change.

B2B Collaboration vs B2B Direct Connect: B2B Collaboration — external user exists as a Guest object in your tenant (manageable, can be CA-scoped, Access Review eligible). B2B Direct Connect — no guest object created; the external organization's users access specific Teams Shared Channels directly using their own IdP. Use B2B Connect for Teams-only cross-org collaboration without full guest provisioning overhead.

Guest lifecycle management: sponsor-based invitations, Access Reviews for regular revalidation, expiry policies for auto-cleanup of inactive guests. Use Entitlement Management Access Packages for structured external onboarding with automatic expiry.

Entra Connect vs Cloud Sync: Connect Sync (legacy agent on Windows Server — full feature set, supports complex topologies, custom attribute mapping, Exchange hybrid writeback). Cloud Sync (lightweight provisioning agent — no Windows Server management, auto-updates by Microsoft, better for multi-forest scenarios, but fewer advanced features).

Authentication methods: Password Hash Sync (PHS — hash of on-prem password synced to cloud; cloud authentication; supports leaked credential detection; fallback if on-prem is down — recommended for most orgs). Pass-through Authentication (PTA — credential validated against on-prem DC in real-time; no hash stored in cloud; requires always-on on-prem agent). Federation (AD FS — all authentication redirected to on-prem ADFS; most complex, highest cost, supports smartcard/third-party MFA; avoid unless mandatory).

Seamless SSO: Kerberos-based SSO for domain-joined Windows PCs. When user signs in to Windows via AD → Kerberos ticket obtained → Entra ID accepts ticket → no second prompt for M365 apps. Works with both PHS and PTA.

Writeback features: Password Writeback (user resets password in cloud/SSPR → synced back to on-prem AD — required for SSPR to work in hybrid). Device Writeback (Hybrid Entra Join registers device in both AD and Entra ID). Group Writeback (M365 groups synced to AD as Distribution Groups for on-prem Exchange).

Named Locations: define trusted IP ranges (office networks, VPN egress IPs) or countries as trusted locations. Use in CA policies: allow passwordless for trusted IPs, require stronger MFA from untrusted/unknown locations. Mark as "Compliant Network" to require Compliant Network Check in ZTNA scenarios.

Device-based CA: Require Hybrid Entra Joined device (domain-joined + Entra registered — corporate-managed, Group Policy applied). Require Intune-compliant device (must have encryption, min OS version, antivirus, password policy via Intune compliance policy). Require approved client app (Block unapproved IMAP/POP apps — enforce Outlook only for Exchange). App protection policy required (MAM — controls copy-paste, screenshots on BYOD).

Authentication Strengths: define a named set of accepted MFA methods for specific CA policies. Example: "Phishing-resistant MFA" strength = only FIDO2 + Windows Hello for Business + certificate-based auth → apply to all admin roles. Weaker methods (SMS) are then blocked for admins even if registered.

Continuous Access Evaluation (CAE): Entra ID pushes revocation events in near-real-time to CAE-capable apps (Teams, SharePoint, Exchange Online). If user is disabled or IP changes mid-session, session is killed within minutes (not at next token refresh which could be up to 1 hour). Critical for breach response.

Role settings per role: configure separately for each Entra role: max activation duration (e.g., Global Admin = 2h, Security Reader = 8h), require MFA on activation, require justification (mandatory text explaining why), require approval (manager or specific approver group must approve within 24h or request expires), require ticketing info (ServiceNow ticket number).

PIM for Groups: make group membership itself just-in-time, not just role assignments. User activates group membership → gets access to all resources tied to that group (RBAC, CA, app roles) → expires. More flexible than role-based PIM for complex access scenarios.

PIM Alerts: built-in alerts for dangerous patterns: "Roles don't require MFA for activation", "Too many Global Admins", "Roles are being activated too frequently", "Potential stale privileged identities". Review these regularly in PIM → Alerts section.

Access Reviews for PIM: periodic review of who has Eligible or Permanent assignments. If reviewer doesn't respond → auto-remove assignment. Schedule quarterly for high-impact roles (Global Admin, Privileged Role Admin). Removes forgotten permanent assignments that accumulate over time.

App Registration vs Enterprise App: App Registration = the identity of your custom-built app (defines redirect URIs, API permissions requested, client secrets/certificates). Enterprise App / Service Principal = the instance of an app in your tenant (your app OR a third-party SaaS like Salesforce, ServiceNow). Consent granted at the Enterprise App level.

OAuth 2.0 permission types: Delegated permissions (app acts on behalf of signed-in user — limited to what user can do; user or admin consents). Application permissions (app acts without user — daemon/background service; admin consent only). Principle: request only the scopes needed — never request full Mail.ReadWrite when Mail.Read suffices.

Consent framework: User consent (by default, users can consent to low-risk delegated scopes). Admin consent (required for high-risk or application permissions — admin consents on behalf of entire org). Restrict user consent via Entra admin center → Enterprise Apps → Consent settings → allow only verified publishers or disable user consent entirely → force admin consent workflow.

SAML SSO configuration: for legacy SaaS apps (Salesforce, SAP). Set Entity ID, Reply URL (ACS URL), attributes (NameID claim = user.mail or user.userprincipalname). Map additional attributes (department, employee ID) as SAML claims. Use Entra App Gallery for pre-configured SAML templates.

Catalogs and Access Packages: Catalog = container for resources (groups, apps, SharePoint sites, roles). Access Package = a bundle of resources within a catalog, with policies defining who can request, approval workflow, and expiry. Separate catalogs for different business units (HR, Finance, Engineering) with delegated catalog management to each team.

Access Package policies: Requestors (all members, specific groups, external users from specific orgs). Approval (single or multi-stage — manager first → team lead second). Expiry (fixed date, N days after assignment, never). Access Reviews (enable within package — periodic review of active assignments). Self-extension allowed (let users renew before expiry without going through full process).

Access Reviews — advanced scoping: scope to inactive users only (not logged in for 90+ days), or service principals with unused permissions, or Entra role assignments. Reviewer types: manager (dynamic — each user reviewed by their own manager), owner (resource owner), specific people (dedicated reviewers). Result options: auto-apply, require reviewer decision, or remove access if no response.

Lifecycle Workflows (Entra ID Governance): automate identity lifecycle: Joiner (send welcome email, enable account, generate temp TAP, add to groups on day 1 HR trigger). Mover (update groups when user changes department, update manager attribute). Leaver (disable account, revoke sessions, remove group memberships, block sign-in on last day, delete after 30 days).