Lab — Azure CLI Identity Foundations (Application + Service Principal + Permissions)

Purpose (Why This Lab Exists)

This lab establishes the core identity mechanics behind Microsoft Entra ID that are repeatedly tested on the SC-300 exam.

The real objective was not to build a usable app. The objective was to force clarity around:

• Application object vs Service Principal (Enterprise Application)
• Where permissions are defined, requested, and granted
• How Azure CLI maps to Entra ID concepts
• Why assignments affect sign-in but not permissions
• Why exam questions hinge on which object is being modified

This lab creates the foundation that all later CLI-based questions depend on.

---

Step 1 — Application Object (Global Definition)

What we did

Using Azure CLI, we created an Application object:

az ad app create --display-name "Lab-CLI-App-Foundation"

What this object is

• A global definition
• Tenant-agnostic in concept
• Describes what the app wants
• Stores:
  • App (client) ID
  • App configuration
  • Requested permissions

What it is NOT

• It does not authenticate
• It does not receive tokens
• It does not enforce access

Exam language mapping

• Application object
• App registration
• Client definition

These all refer to the same thing.

---

Step 2 — Service Principal (Enterprise Application)

What we did

We created a Service Principal for the application:

az ad sp create --id <AppId>

What this object is

• A tenant-local identity
• The runtime presence of the app
• The thing Entra ID issues tokens about
• The thing permissions are actually granted to

What it is NOT

• It is not global
• It is not reusable across tenants
• It does not define permissions — it receives them

Exam language mapping

• Service Principal
• Enterprise Application
• App identity

These refer to the same object.

---

Step 3 — Permission Definition vs Request vs Grant (Critical Distinction)

A. Permission Definitions (Live on the Resource)

Example:

• Microsoft Graph defines User.Read

These permissions:

• Do not live in your tenant
• Are owned by the resource API
• Are immutable by you

---

B. Permission Requests (Application Object)

We added a permission request:

az ad app permission add

This modifies:

• The Application object
• Saying: “I would like this permission”

Important:

• This does nothing by itself
• No access is enabled yet

---

C. Permission Grants (Service Principal / Tenant State)

We then granted the permission:

az ad app permission grant

This:

• Writes tenant-state consent
• Binds the permission to the Service Principal
• Makes the permission operational

This is where access actually becomes possible.

---

Step 4 — Consent and Who It Applies To

The grant resulted in:

• consentType = AllPrincipals
• Meaning: admin consent

This answers a key exam question:

“Where is consent stored?”

Answer:

• As tenant state
• Bound to the service principal
• Not the application object

---

Step 5 — User Assignment Semantics (Very Common Exam Trap)

Default behavior

• Assignment required = No
• Any user may attempt delegated sign-in

This does not mean:

• The user is authorized
• The user bypasses Conditional Access
• The app can act without consent

It only means:

• Users do not need explicit assignment

If Assignment Required = Yes

• Only assigned users/groups may sign in
• Permissions can exist but be unreachable

Key rule

Assignment controls who may sign in — not what the app can do.

---

Step 6 — Delegated vs Application Permissions (Boundary Lock)

Delegated permissions

• Act as a signed-in user
• Require:
  • user sign-in
  • consent
  • CA evaluation
• Assignment may block sign-in

Application permissions

• Act as the app itself
• No user involved
• Assignment is irrelevant
• Admin consent is mandatory

This lab configured delegated User.Read only.

---

What We Did NOT Do (Intentionally)

We did not:

• Create a client secret or certificate
• Acquire tokens
• Call Microsoft Graph
• Assign users explicitly
• Add application permissions

Those are next-lab topics, not missing steps.

---

Exam-Critical Takeaways

1. Application object = definition
2. Service Principal = identity
3. Permissions are:
   • defined on the resource
   • requested on the app
   • granted to the service principal
4. Consent modifies tenant state
5. Assignment affects sign-in, not permissions
6. CLI commands map cleanly to UI concepts

---

Extensions (Future Labs)

Possible next steps building on this foundation:

• Add application permissions
• Create client secrets
• Acquire app-only tokens
• Compare delegated vs app-only sign-ins
• Analyze sign-in logs for app vs user tokens
• Practice exam-style CLI command selection

---

Final Lock-In Statement

Nothing can access anything until a service principal exists and consent is granted — no matter how many permissions appear configured.