MSA1.14 Module Summary

Module 1 Summary — Entra ID Identity Architecture

Module 1 assessed the organization's identity architecture across 11 content subsections. Each sub produced specific findings, queries, and deliverables that feed into the architecture package and drive the work in MSA2–MSA14. Here's what you built, what you found, the specific queries that produced each finding, and what each finding means for the rest of the course.

MSA1.1 — Tenant Architecture

You queried the tenant boundary using Get-MgOrganization and the verified domain configuration to confirm NE operates a single Entra ID tenant with yourtenant.onmicrosoft.com as the default domain. The single-tenant decision (ADR-MSA1-001) establishes the identity perimeter for every subsequent module — all 1,006 identities, all CA policies, all governance processes operate within one boundary. The alternatives (multi-tenant for data sovereignty, B2B platform for external collaboration, B2C for customer-facing) were rejected with specific constraint-based reasoning documented in the ADR. This decision is the first one in the architecture package because everything else inherits from it.

MSA1.2 — Identity Types

You produced the identity census using Graph API queries across five categories: 87 cloud-only members, 723 synced members, 147 guests, 34 app registrations (with 12 corresponding service principals), and 3 managed identities — 1,006 total. Each identity object was examined with annotated Graph API output explaining every architecturally significant field: OnPremisesSyncEnabled distinguishing cloud-only from synced, ExternalUserState categorizing guests as Accepted/PendingAcceptance/blank, PasswordCredentials and KeyCredentials revealing application credential age and expiration status. The census is the input for every design decision in MSA2–MSA14 because you can't design controls for identity types you haven't inventoried.

MSA1.3 — Attack Surfaces

You mapped each identity type to its specific threat model with real sign-in log evidence. Cloud-only users face password spray (errorCode 50126 from anomalous IPs), AiTM phishing (pre-satisfied MFA claim + empty deviceId + anomalousToken risk event), and token theft (replayed sessions from unregistered devices). Synced users inherit on-premises AD vulnerabilities through the PHS pipeline (DCSync extracts the same hashes that Entra ID stores). Guests create cross-tenant trust exploitable via CVE-2025-55241 (Actor Token impersonation enabling exponential tenant-to-tenant lateral movement). Workload identities bypass all user-targeted CA policies through the client credentials flow. This per-type threat model drives authentication method selection (MSA2), CA policy scope (MSA3), privileged access design (MSA4), and detection rule targeting (MSA9).

MSA1.4 — Hybrid Architecture

You queried the sync configuration using the onPremisesSynchronization Graph API endpoint and annotated every feature flag in the output. NE uses Cloud Sync with PHS (passwordSyncEnabled: True), password writeback (passwordWritebackEnabled: True), and hard-match protection (blockCloudObjectTakeoverThroughHardMatchEnabled: True). ADR-MSA1-002 documents the decision with four alternatives rejected: revert to legacy Entra Connect (Microsoft's stated direction is Cloud Sync), PTA (adds on-premises dependency and reduces Identity Protection without regulatory justification), federation/AD FS (maximum complexity, no benefit), and disable writeback (retained for SSPR with MFA as compensating control). The PHS decision is architecturally decisive for MSA2–MSA3 because it enables full Identity Protection risk evaluation for all 723 synced users.

MSA1.5 — Legacy Cleanup

You identified 6 legacy component categories, produced 3 HIGH-priority risk register entries, and documented the 9-step decommission sequence for the legacy Entra Connect server. The AZUREADSSOACC computer account has a 410-day-old Kerberos key (MSA1-RISK-001) enabling Silver Ticket-based SSO forgery. The legacy Entra Connect service account retains Directory Synchronization Accounts role permissions (MSA1-RISK-002). The powered-off server contains SQL LocalDB identity data (MSA1-RISK-003). The Golden SAML attack analysis taught why AD FS decommission is critical when migrating away from federation. The Authentication Methods Policy review revealed SMS is still enabled — a finding MSA2 addresses when designing the authentication strength architecture.

MSA1.6 — Administrative Units

You designed the organization's AU structure: 6 site AUs (Manchester, Newcastle, Birmingham, Leeds, Bristol, Edinburgh), 2 function AUs (Finance, Executive), and 1 restricted management AU (Privileged — protecting break-glass accounts). The Datadog Security Labs AU persistence attack taught why monitoring AU creation events matters (an attacker creates a restricted AU to protect their own backdoor account from remediation). You learned the critical distinction: AUs scope admin roles while groups scope resource access — they're complementary, not interchangeable. CA policies can't target AUs. The coordination requirement between AU membership and group membership is a design constraint that MSA1.10 addresses.

MSA1.7 — Identity Lifecycle

You documented the JML lifecycle gap by querying employeeHireDate (0% coverage) and employeeLeaveDateTime (0% coverage), confirming that time-based Lifecycle Workflow triggers can't fire. You designed joiner and leaver workflow JSON with annotated execution conditions and task sequences (enable account with enableOnPremisesAccount, assign license by SKU ID, add to explicit group by ID, generate TAP, send welcome email). The mover problem was illustrated through SOC Analyst 2's history: 7 groups at joining, +3 from a project assignment, +1 from a role change, 0 removed — resulting in 11 memberships (8 stale). The HR data pipeline is the foundational blocker: without connecting the HR system to Entra ID via one of three provisioning methods (SuccessFactors connector, Workday connector, API-driven inbound provisioning), lifecycle automation is impossible.

MSA1.8 — Stale Identities

You measured stale identity prevalence using signInActivity queries across all identity categories and found 151 stale identities out of 1,006 (15%). The breakdown: 21 stale members (90-day threshold, break-glass excluded), 98 stale guests (67% of all guests — 34 PendingAcceptance, 52 accepted-but-inactive, 12 blank-state), 4 abandoned app registrations (expired credentials, never authenticated), 4 expired-active apps (expired credentials but previous sign-in activity — HR Data Sync is unexplained), and 27 disabled accounts with residual group memberships (Robert Finch: 14 groups). Five risk register entries (MSA1-RISK-004 through 008) with specific remediation commands including Remove-MgGroupMemberByRef for group cleanup. The five architectural controls that prevent future accumulation each map to a subsequent module.

MSA1.9 — Naming Conventions

You assessed naming compliance across all object types: 41% of groups follow a prefix convention (59% don't), 0% of CA policies follow any convention, 0% of app registrations follow any convention. The naming taxonomy establishes {Type}-{Scope}-{Purpose} for groups, CA-{Persona}-{Action}-{Scope} for CA policies, and App-{Environment}-{Purpose}-{Owner} for app registrations. You configured the group naming policy (PrefixSuffixNamingRequirement with [GroupName]-[Department] suffix, CustomBlockedWordsList with 10 blocked words), learned the critical enforcement gap (naming policy applies to M365 groups only, not admin-created security groups), and wrote the weekly compliance audit script as the compensating control. ADR-MSA1-003 documents the standard. The naming convention is referenced by every subsequent module that creates objects in Entra ID.

MSA1.10 — Group Architecture

You classified all 214 groups by type using Graph API properties (groupTypes, securityEnabled, mailEnabled) and diagnosed sprawl: 31 empty groups (14%), 14 single-member groups, 67 ownerless groups (31%), 142 without descriptions (66%). The target architecture consolidates to 74 groups with defined types, defined purposes, and defined ownership. You documented the group-to-AU coordination requirement (AU membership and group membership must match for populations that need both admin delegation and CA targeting). Group-based licensing (currently zero license groups) and role-assignable groups (currently zero) are identified as prerequisites for MSA4's PIM design and MSA12's governance architecture.

MSA1.11 — NE Identity Assessment

You assembled the complete assessment: census summary, 8 risk register entries (4 HIGH, 4 MEDIUM), 3 ADRs, 8 additional findings with downstream impact analysis, and a 4-tier remediation roadmap. The roadmap maps dependencies (naming convention before group consolidation, HR provisioning before lifecycle automation, group owners before access reviews) and estimates effort per tier. The CISO presentation structure distills the assessment into a 2-minute executive delivery: three numbers (1,006 identities, 151 stale, 214 groups), three risks (legacy server, stale guests, unexplained app authentication), and the ask (immediate fixes cost nothing, medium-term needs project planning, long-term requires HR partnership).

What you have in the architecture package

01-identity/
├── identity-census.md                    Census: 1,006 identities across 5 types
│                                          with annotated Graph API output per type.
│                                          Referenced by: MSA3, MSA4, MSA9, MSA12.
│
├── identity-threat-model.md              Per-type threat model: attack techniques,
│                                          sign-in log evidence, architectural controls.
│                                          Referenced by: MSA2, MSA3, MSA4, MSA9.
│
├── adrs/
│   ├── ADR-MSA1-001-tenant.md            Single-tenant decision + 3 alternatives.
│   ├── ADR-MSA1-002-hybrid.md            Cloud Sync + PHS + 4 alternatives.
│   └── ADR-MSA1-003-naming.md            Naming convention standard.
│
├── legacy-inventory.md                   6 legacy categories, decommission sequences.
│                                          Drives immediate remediation actions.
│
├── au-design.md                          9 AUs: 6 site, 2 function, 1 restricted.
│                                          Referenced by: MSA4 (PIM), MSA12 (reviews).
│
├── lifecycle-gap-assessment.md           JML gap: 0% HR coverage, no workflows.
│                                          Drives MSA12 governance architecture.
│
├── stale-identity-report.md              151/1,006 stale (15%). Per-category
│                                          remediation scripts.
│
├── naming-convention-standard.md         Taxonomy for groups, CA, apps, AUs.
│                                          Referenced by: every module MSA2–MSA14.
│
├── group-architecture.md                 Current: 214 → Target: 74. Sprawl metrics.
│                                          Referenced by: MSA3, MSA4, MSA12.
│
├── ne-identity-assessment.md             Complete assessment: 8 risks, 3 ADRs,
│                                          4-tier roadmap, CISO presentation.
│
├── risk-register/
│   └── msa1-risk-register.md             MSA1-RISK-001 through 008 with finding,
│                                          evidence, impact, remediation.
│
└── scripts/
    └── naming-compliance-audit.ps1       Weekly audit script detecting violations.

What Module 2 requires from Module 1

Module 2 (Authentication Architecture) designs the authentication methods for every identity type. It consumes six specific outputs from Module 1:

The identity census (MSA1.2) — authentication method selection requires knowing which identity types exist. Cloud-only users and synced users authenticate differently from guests (who authenticate in their home tenant) and workload identities (which authenticate via client credentials). MSA2 designs authentication per type.

The per-type threat model (MSA1.3) — the authentication method must defend against the specific threats each type faces. Phishing-resistant MFA defends against AiTM for human users. Certificate-based authentication or federated credentials defend against credential leaks for workload identities. MSA2 selects methods based on threat, not on generic "best practice."

The PHS decision (ADR-MSA1-002) — PHS means Identity Protection has full signal coverage for synced users, which means risk-based authentication policies can function. If NE had chosen PTA, MSA2's risk-based design would need compensating controls for the reduced Identity Protection coverage.

The SMS finding (MSA1.5) — the Authentication Methods Policy shows SMS is enabled. MSA2 evaluates whether SMS should remain as an allowed method, be restricted to specific populations, or be disabled entirely — based on the threat model analysis from MSA1.3 (SIM swapping, SS7 interception).

The group architecture (MSA1.10) — authentication method targeting uses groups. The SG-CA-Exclude-BreakGlass group from MSA1.10 is the exclusion mechanism for break-glass accounts. Authentication strength policies (MSA2's primary output) are enforced through CA policies (MSA3) that target groups. The naming convention means MSA2's groups follow the SG- pattern from day one.

The break-glass accounts (MSA1.12 lab) — MSA2 designs the break-glass authentication exception: these accounts bypass MFA by design, must use passwords (not passkeys, not FIDO2 — they must work when all other authentication infrastructure fails), and must have dedicated sign-in monitoring. The restricted management AU (MSA1.6) protects them from administrative modification.

If the identity layer has gaps — inaccurate census, uncharacterised threats, undocumented hybrid architecture, unstructured groups — the authentication architecture inherits those gaps. That's why Module 1 exists: to establish the foundation that every subsequent module builds on. The quality of the identity layer determines the quality of everything above it.