Lab 12 — Microsoft 365 Applications as Entra ID Identity Objects

Understanding Resource-Based Conditional Access and Sign-In Logs

---

Lab Purpose

This lab establishes a foundational and exam-critical understanding of how Microsoft 365 applications actually interact with Microsoft Entra ID.

The goal is not to configure new controls, but to observe and correctly interpret:

• How Microsoft 365 workloads appear as enterprise applications
• How a single user sign-in produces multiple Entra ID sign-in events
• How Conditional Access (CA) is evaluated per resource, not per “login”
• Why sign-in logs look confusing unless this model is understood

This lab exists to eliminate one of the most common conceptual failures on the SC-300 exam.

---

What We Did (High-Level)

1. Identified Microsoft 365 workloads as Enterprise Applications (Service Principals)
2. Signed in as a user and accessed Microsoft 365 resources (Office portal / SharePoint)
3. Examined Entra ID sign-in logs generated by that single user action
4. Traced how multiple resources were evaluated independently by Entra ID
5. Interpreted log results correctly without mislabeling success/failure

---

Core Technical Findings

1. Microsoft 365 Is Not a Single Application

“Microsoft 365” is not one app from Entra ID’s perspective.

It is a collection of independent enterprise applications, including (but not limited to):

• Microsoft Graph
• Office Home
• My Apps (App Catalog)
• SharePoint Online
• Exchange-related services
• Teams-related services

Each of these exists as a distinct service principal in the tenant.

---

2. One User Action Creates Multiple Sign-In Events

A single human action such as:

• Signing into office.com
• Opening SharePoint
• Launching apps from My Apps

results in multiple Entra ID sign-in events, because:

• Each downstream resource requests its own token
• Each token request triggers its own Conditional Access evaluation

There is no such thing as a single “Microsoft 365 login” internally.

---

3. Conditional Access Is Evaluated Per Resource

Conditional Access policies are evaluated:

• Per sign-in event
• Per resource (enterprise application)

Not per user session. Not per browser window. Not per “login attempt.”

This explains why one user sign-in can show:

• One event marked Interrupted
• Followed by multiple Success events
• Each tied to a different resource

This is expected behavior.

---

4. Why Sign-In Logs Look “Strange” at First

During the lab, we observed a sequence similar to:

• Resource: Microsoft Graph → Status: Interrupted
• Resource: Office Home → Status: Success
• Resource: My Apps → Status: Success

This does not indicate an error.

It reflects the authentication flow:

• Microsoft Graph is used early for identity and directory access
• Office Home represents the Microsoft 365 landing workload
• My Apps represents the application catalog experience

Each step is logged separately because each is a separate authorization decision.

---

5. “Success” and “Failure” Mean User Outcome, Not Policy Quality

In Entra ID sign-in logs:

• Success = the user obtained access
• Failure = the user did not obtain access

These labels do not mean:

• “The policy worked”
• “The policy failed”
• “The configuration is wrong”

A Conditional Access policy can work perfectly and still produce a Failure if the policy is designed to block access.

This distinction is critical for both labs and the SC-300 exam.

---

Exam-Critical Takeaways (SC-300)

• “All cloud apps” ≠ “Microsoft 365”
• Microsoft 365 is a bundle, not a single enforcement target
• Conditional Access is always resource-scoped
• Sign-in logs reflect authorization outcomes, not intent
• Multiple log entries for one user action are normal