Training module · Draft
Learning path: Non-Person Identity in Microsoft Entra ID
Twelve modules: one per chapter of the developer workbook, in the order of the implementation guide’s six gates, then the deployment runbook, then one service account migrated by hand, each with a lab on fixtures and a lab in your own test tenant or domain
Status — Draft
This page is still being written. Expect gaps and changes; it is not part of the workbook's production guidance. Last reviewed 2026-11-08.
A person leaves and HR tells you. A service account’s owner leaves and nothing tells you. This learning path teaches you to build the record that HR gives you for people: every non-person identity listed, owned, decided, credentialed, scoped and watched. You work through the six gates of Non-Person Identity: An Implementation Guide in order. In each module you run the tested code from the developer workbook Building Non-Person Identity on your laptop, then read what the same step takes in a test tenant.
Like a Microsoft Learn learning path, it is a short series of modules, each built on the one before. The modules don’t repeat the guide or the workbook. They tell you what to read, in what order, what to run, and what to check you understood.
Who this path is for
| Role | What you get from the path |
|---|---|
| Identity engineer | The order of work in the tenant for each gate, and the checks that prove it |
| Active Directory engineer | The service accounts, MSAs, gMSAs and dMSAs, and the Kerberos accounts that stay on an island |
| Developer | The code in examples/non-person-identity: what each script reads, the rules it applies, the plan it writes and the manifest it keeps |
| AI governance staff | Agent identities, blueprints and sponsors, and the checks that hold them to the program’s rule |
| ISSO reviewer | The federal requirements each gate supports, the KSI it lines up with, and the evidence you keep |
Level: intermediate. Products: Microsoft Entra ID, Microsoft Entra Workload ID, Microsoft Entra Agent ID, Azure Key Vault and Active Directory Domain Services. Scope: a civilian agency at FedRAMP Moderate, in Microsoft 365 GCC with commercial Azure, with an on-premises Active Directory, as the workbook assumes.
Prerequisites
- The guide’s track at a glance and path on one page: ten minutes, and every module refers back to them.
- Book 02, Chapter 09: service accounts and Book 04, Chapter 05, for the design. The modules link the sections they use.
- Microsoft Automation, Module 1: Graph and Azure Foundations: the clouds and endpoints, signing in as a workload, and permissions.
- PowerShell basics: you can run a script, import a module and read the objects it returns. Module 10 also runs Python.
What you’ll be able to do
When you finish the path, you’ll be able to:
- read every service account, MSA, gMSA, dMSA, app registration, service principal and managed identity into one register, with a risk and a candidate target;
- check each identity for two human owners and a sponsor, and plan the orphan rule as disable, never delete;
- turn Book 02’s migration path matrix into a decision for every identity, with HIGH-risk accounts in the first wave;
- hold the app management policy as reviewed JSON, and plan certificate rotation through Key Vault;
- sweep service principals for broad permissions and roles, and put Tier 1 service principals under Conditional Access for workload identities, report-only first;
- plan conversions to managed identities, federated credentials, gMSAs and dMSAs, with a parallel run and a way back;
- check AI agent identities and blueprints against the program’s sponsor and credential rules;
- find drift against an approved baseline and hand the ISSO an evidence package they can verify;
- deploy the kit to a live test environment, then production, with a preflight, a smoke test, an evidence record per requirement and a rehearsed rollback.
Modules
Work through them in order. They follow the guide’s gates, G1 to G6, with the guide’s AI agents section after the gates it builds on. So the workbook’s chapters come in a slightly different order: Chapters 07 and 08 (G4) come before Chapters 05 and 06 (G5). Module 11, the deployment runbook, comes after the gates: it runs every gate’s code in one safe order, and each of its steps names its gate. Module 12 is a companion to Module 8, for the service account guide: one account moved by hand, with Microsoft Learn’s commands, and the kit planning the same moves; take it after Module 8, or on its own. The workbook’s plan numbers its own gates, Gate 0 to Gate 7, and a module may say “Gate 2” or “Gate 7” for those; a plan gate isn’t always its G twin (the plan’s Gate 5 is G4), so check the gate table on the workbook’s index when the two numbers differ.
| # | Module | Gate | Workbook chapter | Time |
|---|---|---|---|---|
| 1 | Inventory every non-person identity | G1 Inventory | 01 | 55 min |
| 2 | Owners, sponsors and the orphan rule | G1 Inventory, G6 Lifecycle | 02 | 60 min |
| 3 | Decide each identity’s target | G2 Decision | 03 | 55 min |
| 4 | Set the credential rules | G3 Credential rules | 04 | 65 min |
| 5 | Cut the privilege of service principals | G4 Least privilege | 07 | 60 min |
| 6 | Conditional Access for workload identities | G4 Least privilege | 08 | 65 min |
| 7 | Convert to managed identities and federation | G5 Conversion | 05 | 60 min |
| 8 | Convert Kerberos accounts to gMSAs and dMSAs | G5 Conversion | 06 | 60 min |
| 9 | Govern AI agent identities | AI agents | 09 | 65 min |
| 10 | Find drift and file the evidence | G6 Lifecycle | 10 | 75 min |
| 11 | Deploy to test, then production | Every gate, through the stage steps | 11 | 60 min |
| 12 | Migrate a service account by hand | Companion to Module 8: the service account guide’s Migrations A to C | 06, 05 | 65 min |
Total time: about 12 hours 25 minutes, with each module’s Lab 1. Lab 2, in your own test tenant, isn’t counted: how long it takes depends on your tenant and your approvals.
Why twelve modules. The guide has six gates, but G1, G4 and G5 each need two workbook chapters, and every chapter’s Lab 1 is 7 to 11 steps. A module that ran two of those labs would take two hours. So each module teaches one chapter, and the gate column shows where it sits in the guide. Chapter 11, the runbook, serves every gate, so it’s a module of its own. Module 12 teaches a companion guide rather than a chapter: its lab reruns parts of Chapters 06 and 05. The guide’s SQL Server section has no chapter of its own: Module 1 shows its accounts handed to the Data Platform plan.
If you’re an ISSO reviewer, read each module’s introduction, its federal requirement table and its summary, and skip the labs. Modules 10 and 11 are yours in full. The workbook’s reading paths suggest an order for each role.
Each module follows the same units: an introduction with the federal requirements it supports, learning objectives, prerequisites, one to three concept units, Lab 1, Lab 2, a knowledge check and a summary.
What you need for the labs
Lab 1: a laptop, no tenant. Every module’s Lab 1 (except Module 10’s, which also uses examples/drift-pipeline in a POSIX shell) runs the code in examples/non-person-identity against the kit’s fictional fixtures, for the fictional tenant and the domain corp.contoso.example. You need:
- a copy of the repository, so you can work in
examples/non-person-identity; - PowerShell 7.1 or later with Pester 5;
- for Module 10, also Python 3.10 or later with pytest and PyYAML, and a shell with
sha256sum(Linux, macOS or Git Bash).
Run every command from examples/non-person-identity, in PowerShell 7, except Module 10’s steps 7 to 11, which run in examples/drift-pipeline in a POSIX shell and give that folder an out too. Each lab writes an out folder there and deletes it at the end. Nothing in Lab 1 signs in to anything or sends a request.
Lab 2: your own test tenant. Lab 2 needs a Microsoft Entra test tenant in the worldwide or GCC cloud for learning, never production, with fictional data (before a gate passes, rehearse once in your agency’s own cloud, as Book 16 describes). Some modules add a test Azure subscription, a Key Vault, a test Active Directory domain or Workload ID Premium. Each module says which. The workbook has no hosted sandbox: you bring the tenant. The authors didn’t run the Lab 2 steps. Each one ends with a way to back it out. Read the guide’s prerequisites for the roles and licenses before you start.
How this path fits with the other pieces
The guide is finished when it has four pieces: the guide, a narrated deck series, a developer workbook and a training path. This path is the training piece. Chapters 01 to 10 already have a narrated tour each, and each module links it; Chapter 11’s comes later. Each module also links its own narrated deck and video.
| Piece | Where |
|---|---|
| The design | Book 02, Chapters 09 and 10, Book 04, Chapters 05 and 06, Book 17 |
| The gates | Non-Person Identity: An Implementation Guide |
| The code and its labs | Building Non-Person Identity |
| The schedule | Non-Person Identity Modernization project |
| The federal sources | The guide’s Evidence table and the federal framework crosswalk |
Modules in this path
| Title | Description |
|---|---|
| Module 1: Inventory every non-person identity | Gate G1 and workbook Chapter 01: read every AD service account, MSA, gMSA, dMSA, app registration, service principal and managed identity into one register with a risk and a candidate target, see the reader refuse a call it doesn’t declare, and hand SQL Server accounts to the Data Platform plan. About 55 minutes, with a lab on fixtures and a test tenant lab. |
| Module 2: Owners, sponsors and the orphan rule | Gates G1 and G6 and workbook Chapter 02: check every identity in the register for two human owners and an active service record, build the orphan rule as a reviewed plan that disables and never deletes, and see the write path refuse a plan nobody approved. About 60 minutes, with a lab on fixtures and a test tenant lab. |
| Module 3: Decide each identity’s target | Gate G2 and workbook Chapter 03: turn Book 02’s migration path matrix into a proposed target for every identity, check each owner’s disposition against it, put HIGH-risk accounts in the first wave with a rollback, and scope Workload ID Premium. About 55 minutes, with a lab on fixtures and a test tenant lab. |
| Module 4: Set the credential rules | Gate G3 and workbook Chapter 04: hold the tenant’s app management policy as reviewed JSON (no new secrets, certificates capped at 180 days, the app instance property lock), compare it with the tenant into a plan that never loosens a restriction, and plan certificate rotation through Key Vault with an owner’s approval and an overlap. About 65 minutes, with a lab on fixtures and a test tenant lab. |
| Module 5: Cut the privilege of service principals | Gate G4 and workbook Chapter 07: sweep every service principal’s application permissions, delegated grants, directory roles and managed identities’ Azure roles, flag broad grants without a current exception, hand privileged service principals to the Privileged Access plan, build the quarterly owner review, and apply only the owners’ decisions through a plan whose SHA-256 a reviewer approved. About 60 minutes, with a lab on fixtures and a test tenant lab. |
| Module 6: Conditional Access for workload identities | Gate G4 and workbook Chapter 08: hold CA015 and CA037 as reviewed files, scoped to Tier 1 single-tenant service principals by object ID, ring by ring; check them before merge and against the tenant; create every policy report-only; summarize the service principal sign-ins; and enforce a ring only with D-NP5, -AllowEnforce and the reviewed summary’s hash. About 65 minutes, with a lab on fixtures and a test tenant lab. |
| Module 7: Convert to managed identities and federation | Gate G5 and workbook Chapter 05: convert legacy credentials in the plan’s order (a managed identity, then a federated credential, then a certificate), check each federated credential’s issuer, subject and audience against what the workload presents, test its token exchange against a fake, track the 30-day parallel run, and disable the legacy account only through a plan whose SHA-256 a reviewer approved. About 60 minutes, with a lab on fixtures and a test tenant lab. |
| Module 8: Convert Kerberos accounts to gMSAs and dMSAs | Gate G5 and workbook Chapter 06: give every Kerberos account a reviewed disposition, plan its move to a gMSA or a Windows Server 2025 dMSA, list what stays on the Kerberos island with an SPN owner and an end date, reconcile every gMSA and dMSA with the end state, and run the plan only by its approved hash. About 60 minutes, with a lab on fixtures and a test domain lab. |
| Module 9: Govern AI agent identities | The guide’s AI agents section and workbook Chapter 09: read agent identities and blueprints with their sponsors, owners and credentials, check them against the program’s rules (creation closed, a reviewed handshake, no secret on a production blueprint, no allAllowed inheritance, the ten-business-day sponsor rule, no shadow AI identity), run the same rules in a cloud without Agent ID, and plan report-only agent Conditional Access by its approved hash. About 65 minutes, with a lab on fixtures and a test tenant lab. |
| Module 10: Find drift and file the evidence | Gate G6 and workbook Chapter 10: run the register and the ownership check on a schedule, compare them with a baseline a reviewer approved by its SHA-256, find credentials added outside the pipeline from the audit log, read the review cycle, compare the AI use-case inventory vintages, and hand the ISSO hash-chained packages and a period summary they can check with sha256sum alone. About 75 minutes, with a lab on fixtures and a test tenant lab. |
| Module 11: Deploy to test, then production | Workbook Chapter 11, the deployment runbook, across every gate: one settings file per stage with no secret, a read-only preflight, a safe order from inventory to report-only Conditional Access, a smoke test on synthetic objects, an evidence record for every requirement row, a rollback approved by its SHA-256 and rehearsed in test, the go/no-go criteria, then production, enabling Conditional Access ring by ring. You dry-run four of the five deploy scripts on fixtures and see a fixture stage refused at the evidence check. About 60 minutes, with a lab on fixtures and a pointer to the live test and production stages; the chapter hasn’t been run against a live tenant. |
| Module 12: Migrate a service account, from a user account to a gMSA, a dMSA or Microsoft Entra | The companion guide Service Accounts, with the developer workbook’s Chapters 05 and 06: compare the kinds of service identity, choose a target with the decision path, follow Microsoft Learn’s steps for a user account to a gMSA, to a Windows Server 2025 dMSA and to a Microsoft Entra workload identity, and see the kit plan the same moves on fixtures, approved by hash, with a 30-day parallel run and never a delete. About 65 minutes, with a lab on fixtures and a test domain lab. |
Original content for project use. Every fact is carried by link from the guide and the workbook; the claims log is in the repository.