Cover of Workload Identities and App Registrations with Microsoft Entra ID
Microsoft Entra Field Guides

Workload Identities and App Registrations with Microsoft Entra ID

Service principals, managed identities, and federated credentials to retire client secrets

This is the companion page for Workload Identities and App Registrations with Microsoft Entra ID. If the book is in your hands, start with the placement quiz: it tells you whether to start at Chapter 1 or skip ahead. The chapter map and the hardest SC-300 questions answered in full are on this page too.

Get the book on Amazon See where you are The hard set

What this guide covers

The breach rarely starts with a misconfigured Conditional Access policy. It starts with a three-year-old client secret sitting in a public repo, attached to an app nobody remembers registering. Workload identities, the identities your software uses to authenticate, cannot perform MFA, usually have no lifecycle owner, and have to keep a credential somewhere. That is the whole problem, and it is why they have become one of the surfaces attackers reach for when they want quiet, durable access to a tenant.

Microsoft Learn documents every piece of the answer, but it scatters them across dozens of pages and never connects them. This book is the account I wanted the first time I had to explain, in a real tenant, why deleting an app registration also kills its service principal, which controls require Workload ID Premium (a standalone add-on license, separate from any Microsoft 365 or Microsoft Entra ID P2 plan you already own) and which the Free edition already covers, and why a one-character typo in a federated credential subject saves without an error and then surfaces only as an AADSTS70021 in a pipeline log. It walks application objects, service principals, and managed identities as one system, names the silent failure modes before you hit them, and draws the license line clearly so you know what you are paying for.

Every limit, license boundary, and portal path is grounded against current Microsoft Learn and validated in a live Microsoft 365 E5 lab. You do not need production Azure infrastructure to follow along; a trial tenant and a single test resource are enough.

Chapter map

  1. The Workload Identity Model: Concepts, Stack, and Exam Scope
  2. Licensing and Prerequisites: Free vs. Workload ID Premium
  3. Choosing a Workload Identity: Managed Identities, Service Principals, and Service Accounts
  4. Managed Identities in Practice: Enabling, Assigning, and Using Them
  5. Application Objects and Service Principals: The Registration Model
  6. App Authentication: Secrets, Certificates, and Federated Identity Credentials
  7. API Permissions: Delegated, Application, Admin Consent, and the Consent Framework
  8. App Roles: Defining, Assigning, and Consuming Authorization in Tokens
  9. Enterprise Applications: SSO Modes, User Assignment, and App Visibility
  10. User and Group Provisioning: SCIM, Automatic Provisioning, and Lifecycle Management
  11. On-Premises App Publishing with Application Proxy
  12. Conditional Access App Control and Defender for Cloud Apps Session Policies
  13. Securing Workload Identities: Conditional Access, ID Protection, Credential Governance, and the Production Checklist

Appendices: PowerShell and Graph Quick Reference; Build a Lab Tenant; Production Readiness Checklist.

Who it is for

This book is for the administrators and engineers who own app registrations, enterprise applications, and managed identities in a Microsoft Entra tenant, for developers whose applications have to authenticate against it, and for anyone preparing for SC-300 (Microsoft Identity and Access Administrator) who wants the workload-identity material at a depth the exam objectives only hint at.

See where you are

7 questions from this guide's territory (3 easy, 4 medium), with the explanation after each. Nothing is stored and nothing is sent anywhere.

The rest of the Microsoft Entra Field Guides

One product per book, a lab build in every one, and a companion page like this one for each. The last card is the collection: every volume of this series in one book, so check it against what you already own.

  • Cover of Authentication and Conditional Access with Microsoft Entra ID
    Field guide

    Authentication and Conditional Access with Microsoft Entra ID

    A disabled method can stay live in a legacy MFA or SSPR policy, and a policy that ships without emergency access exclusions can lock out recovery and administrators.

  • Cover of Microsoft Entra ID Fundamentals Field Guide
    Field guide

    Microsoft Entra ID Fundamentals Field Guide

    Group licensing quietly gives a user with no usage location the tenant's location, and dynamic groups and dynamic administrative units share one 15,000 ceiling.

  • Cover of Hybrid Identity and Global Secure Access with Microsoft Entra ID
    Field guide

    Hybrid Identity and Global Secure Access with Microsoft Entra ID

    An organizational-unit rename can silently delete synchronized objects.

  • Cover of Identity Governance with Microsoft Entra ID
    Field guide

    Identity Governance with Microsoft Entra ID

    Access reviews can miss post-snapshot provisioning, and PIM group permissions can take up to 24 hours to apply.

  • Cover of Microsoft Entra Field Guides: The Complete Collection
    The whole series in one volume

    Microsoft Entra Field Guides: The Complete Collection

    A Conditional Access policy can look stronger while never evaluating the user it was meant to protect. All five field guides in one volume.

    Kindle$29.99Get it on Amazon

Every Kindle book here has a sample on its Amazon page, about the first 10 percent of the book.

The hard set (2 questions)

The hardest SC-300 questions this guide publishes, none of them repeated from the placement quiz above: the answer first, why every other option is wrong, and the Microsoft Learn page behind it. The practice book holds the full bank.

You are documenting how apps obtain permissions in your tenant. One app is a single-page app that requests additional delegated scopes incrementally as the user opens new features; another is a daemon that uses application permissions. Which statement correctly describes the consent behavior and the resulting Microsoft Graph objects?

Correct answer: B. Delegated permissions support both static and dynamic consent and produce an oauth2PermissionGrant; application permissions are static-only and produce an appRoleAssignment.

Delegated permissions can be consented statically (a pre-configured list on the app registration) or dynamically (requested incrementally at sign-in) and, when granted, create an oauth2PermissionGrant. Application permissions can be consented only statically and only by an admin; granting them creates an appRoleAssignment.

Why the other options are wrong:

  • A. Only delegated permissions support dynamic/incremental consent; application permissions are static-only.
  • C. It is reversed: delegated permissions (scopes) surface in the scp claim, and application permissions (app roles) surface in the roles claim.
  • D. Permission classifications (low impact) apply only to delegated permissions eligible for user consent; application permissions always require admin consent.

Memory hook: Delegated = scopes/scp + oauth2PermissionGrant (static or dynamic); Application = roles + appRoleAssignment (static, admin-only).

Microsoft Learn: Permissions consent overview

An on-premises SharePoint site uses Integrated Windows Authentication (Kerberos). You publish it through application proxy and want seamless SSO so users already authenticated by Microsoft Entra ID are silently signed in to SharePoint. You select the Integrated Windows Authentication SSO mode with Kerberos Constrained Delegation (KCD). Which prerequisite must be true for the connector to obtain a Kerberos ticket on the user's behalf?

Correct answer: B. The server running the connector and the server running the app must be domain-joined to the same domain or trusting domains.

KCD-based SSO requires the connector host to be domain-joined (same domain as the app server or a trusting domain) so it can perform constrained delegation and request a Kerberos service ticket while impersonating the user. Valid SPNs must exist and the connector must be trusted for delegation to the app's SPN.

Why the other options are wrong:

  • A. IWA/Kerberos apps are precisely what KCD SSO is for; you do not convert them to SAML.
  • C. KCD delegation depends on Active Directory membership; a workgroup connector cannot request Kerberos tickets on a user's behalf.
  • D. SSO with KCD requires Microsoft Entra ID preauthentication, not Passthrough; choosing Passthrough removes the SSO options entirely.

Memory hook: KCD = Kerberos needs a domain. Connector must be domain-joined and trusted to delegate.

Microsoft Learn: Configure SSO with KCD

Exam prep? The SC-300 sampler scores you by topic and points you to the guide behind each miss.

Take the SC-300 sampler All 75 SC-300 sampler questions, with explanations