02 Microsoft Entra ID Security

Identity is one of the most important security boundaries in modern cloud environments. A compromised identity can bypass many otherwise strong technical controls.

Welcome to the Microsoft Entra ID Security Lab.

In the previous lab, you focused on Azure RBAC and learned:

• who can manage Azure resources

• which roles apply

• how scope works

• how inherited permissions affect access

• how least privilege should be implemented

Now you will move deeper into the identity layer.

This lab focuses on:

• authentication

• MFA

• Conditional Access

• privileged roles

• PIM

• guest identities

• application identities

• service principals

• managed identities

• sign-in investigation

• identity governance

You will move from:

I understand Microsoft Entra ID

to:

I can assess, secure, investigate, and improve identity security.

🎯 Mission Information

Item	Details
Lab	Microsoft Entra ID Security
Difficulty	Beginner → Intermediate
Estimated Time	2–3 hours
Primary Focus	Identity Security & Access Governance
Target Roles	Identity Security Engineer, IAM Engineer, Azure Security Engineer, SOC Analyst
Certification Alignment	SC-300, AZ-500, SC-100
Career Skill	Identity Security Assessment & Investigation
Environment	Personal Microsoft Entra / Azure lab tenant
Cost Awareness	Some advanced features may require licensing

⚠️ Licensing Note

Some Microsoft Entra security capabilities may depend on the licensing available in your lab environment.

Examples may include:

• Conditional Access

• Privileged Identity Management

• Identity Protection

• access reviews

If a feature is unavailable, do not skip the concept.

Instead:

1. review the configuration flow

2. document the intended design

3. explain the security purpose

4. create a simulated finding or architecture

The goal of this lab is to build security understanding, not merely click through features.

🏢 Mission Scenario

You have joined an organization as a junior Identity Security Engineer.

The company uses Microsoft Entra ID for:

• employees

• administrators

• contractors

• Azure access

• enterprise applications

• automation

Security leadership has raised several concerns:

• some users may not have appropriate MFA coverage

• administrators may hold permanent privileged roles

• Conditional Access may be inconsistent

• old guest accounts may remain active

• service principals may have long-lived secrets

• application permissions may be excessive

• identity lifecycle controls may be weak

• suspicious sign-ins may not be investigated consistently

Your mission is to assess the identity environment and recommend stronger controls.

🎯 Mission Objectives

By the end of this lab, you should be able to:

• review Entra users and groups

• distinguish authentication from authorization

• review MFA coverage

• understand Conditional Access design

• review privileged directory roles

• understand PIM

• assess emergency-access accounts

• review guest identities

• review service principals

• understand managed identities

• identify risky application credentials

• understand access reviews

• assess joiner-mover-leaver controls

• investigate suspicious sign-in activity

• create identity-security findings

• recommend remediation

📚 Prerequisites

Before beginning, you should understand:

• Microsoft Entra ID basics

• users

• groups

• authentication

• authorization

• Azure RBAC basics

• least privilege

• MFA

Recommended previous work:

• SC-900

• SC-300

• AZ-500

• Azure RBAC Lab

🧠 Identity Security Mental Model

Think:

Identity
   ↓
Authentication
   ↓
Context
   ↓
Access Policy
   ↓
Authorization
   ↓
Resource / Application
   ↓
Monitoring
   ↓
Governance

For every identity, ask:

Who?

Who or what is the identity?

How?

How does it authenticate?

What?

What does it have access to?

Why?

Why does it have that access?

How Long?

Is access permanent or temporary?

Monitoring?

Would suspicious activity be detected?

Lifecycle?

What happens when the identity no longer needs access?

🧪 Task 1 — Review the Entra Tenant

Navigate to:

Microsoft Entra admin center

Review:

• tenant name

• tenant ID

• domains

• user count

• group count

• guest identities

• enterprise applications

Do not publish tenant IDs in screenshots or portfolio material.

🧪 Task 2 — Inventory Users

Navigate to:

Microsoft Entra ID → Users

Create a simple inventory.

User	Type	Enabled	Privileged?	MFA Review	Owner

Classify users such as:

• employees

• administrators

• contractors

• guests

• test accounts

🧠 Security Question

Ask:

Why does this account exist?

An account with no owner or business purpose should be reviewed.

🧪 Task 3 — Review Disabled and Inactive Accounts

Look for:

• disabled users

• old test accounts

• former contractors

• old administrator accounts

• accounts with unclear ownership

🚨 Common Finding

Finding:
Inactive Identity Remains Enabled

Risk:
Unused accounts increase attack surface and may remain unnoticed if compromised.

Recommendation:
Validate ownership and remove or disable access where no longer required.

🧪 Task 4 — Review User Types

Understand the difference between:

• member users

• guest users

Guest access deserves special attention because the identity may belong to:

• partners

• suppliers

• contractors

• external collaborators

🧪 Task 5 — Review Groups

Navigate:

Microsoft Entra ID → Groups

Review:

• security groups

• role-assignable groups where present

• group ownership

• membership

Create:

Group	Purpose	Privileged?	Owner	Membership Review

🧠 Group Security Question

Ask:

Who can add users to this group?

If a group provides sensitive access, membership management is itself a privileged action.

🧪 Task 6 — Create a Test Security Group

Create:

ghc-security-lab-users

Add one or two controlled test users.

Use this group for later policy design.

🧪 Task 7 — Review Authentication Methods

Navigate to the relevant authentication-method configuration.

Review the available methods in your environment.

Examples may include:

• password

• authenticator-based methods

• security keys

• other approved methods

🧠 Security Question

Ask:

Which authentication methods should privileged users be allowed to use?

Not every authentication method provides the same level of assurance.

🧪 Task 8 — Review MFA Coverage

Determine whether human users, especially privileged users, have MFA coverage.

Create:

User	Privileged?	MFA / Strong Auth Coverage	Risk

🚨 Example Finding

Finding ID:
ENTRA-001

Title:
Privileged User Lacks Strong MFA Coverage

Severity:
High

Risk:
Compromise of a single credential may enable privileged access.

Recommendation:
Require strong MFA for privileged identities using approved authentication methods and policy controls.

🧠 MFA Principle

Do not ask only:

Is MFA enabled?

Ask:

Is MFA consistently enforced under the right conditions?

🧪 Task 9 — Understand Authentication vs Authorization

Create this simple scenario.

User
 ↓
Successfully Authenticates
 ↓
Attempts Application Access
 ↓
Authorization Denied

Explain:

Authentication

Identity was verified.

Authorization

The requested access was not permitted.

This distinction is essential during troubleshooting.

🧪 Task 10 — Explore Conditional Access

If available, navigate to:

Microsoft Entra → Protection / Conditional Access

Review existing policies.

For every policy document:

• target users/groups

• target applications

• conditions

• grant controls

• exclusions

• policy state

📋 Conditional Access Review

Policy	Target	Condition	Control	Exclusions	Risk Addressed

🧠 Conditional Access Mental Model

Use:

Identity
  +
Application
  +
Device
  +
Location
  +
Risk
      ↓
Policy
      ↓
Allow / Block / Require Controls

🧪 Task 11 — Design a Privileged-User Conditional Access Policy

Create a design for:

Privileged administrators must use stronger authentication.

Document:

Target:
Privileged administrator group

Application:
Administrative/cloud applications as appropriate

Grant:
Require approved strong authentication

Exclusions:
Emergency-access identities only where justified

Deployment:
Report-only/test before enforcement

⚠️ Do Not Lock Yourself Out

Before enforcing Conditional Access:

• identify emergency-access accounts

• test policies

• use report-only modes where available

• exclude only what is necessary

• validate administrative access

🧪 Task 12 — Create an Emergency-Access Design

Document two controlled emergency-access identities conceptually.

They should be:

• highly protected

• rarely used

• monitored

• not used for normal administration

🧠 Security Principle

Emergency access should exist for resilience.

But:

emergency access must not become an unmonitored security backdoor.

🧪 Task 13 — Review Directory Roles

Navigate to:

Roles and administrators

Review high-impact roles.

Examples may include roles involving:

• global administration

• security administration

• privileged role management

• user administration

• application administration

📋 Privileged Role Review

Identity	Role	Permanent?	Business Need	Last Review

🧠 Important

Entra directory roles and Azure RBAC roles are different.

Remember:

Entra Role
→ Identity / Directory Administration

Azure RBAC
→ Azure Resource Administration

🧪 Task 14 — Identify Permanent Privilege

Look for users who permanently hold powerful roles.

Ask:

Does this person really need continuous administrator authority?

🚨 Example Finding

Finding ID:
ENTRA-002

Title:
Permanent Privileged Role Assignment

Severity:
High

Observation:
A human administrator permanently holds a high-impact directory role.

Risk:
Credential compromise provides immediate privileged authority.

Recommendation:
Evaluate just-in-time privileged access using PIM where available.

🧪 Task 15 — Explore PIM

If your environment supports Privileged Identity Management, review:

• eligible assignments

• active assignments

• activation requirements

• approval

• duration

• MFA requirements

If unavailable, design the workflow.

Administrator
     ↓
Eligible Role
     ↓
Activation Request
     ↓
Strong Authentication
     ↓
Approval / Justification
     ↓
Temporary Access
     ↓
Expiration

🧠 Security Benefit

PIM reduces:

standing privilege.

🧪 Task 16 — Compare Permanent vs Eligible Access

Document:

Model	Exposure
Permanent Administrator	Privilege always available
Eligible Administrator	Privilege available only after activation

Then identify where temporary privilege would reduce risk.

🧪 Task 17 — Review Guest Identities

Navigate to users and filter for guest accounts.

For each guest ask:

• who invited them?

• which company?

• which application/resource?

• when last used?

• is access still required?

🚨 Guest Access Risk

A contractor finishing a project does not automatically lose access unless lifecycle controls remove it.

🧪 Task 18 — Create a Guest Access Review

Build:

Guest	Sponsor	Purpose	Last Activity	Still Needed?	Action

🧠 Professional Question

Ask:

Who owns the decision to retain external access?

Security should not guess.

There should be a business owner.

🧪 Task 19 — Review Enterprise Applications

Navigate to:

Enterprise applications

Review application identities and access.

For each application ask:

• business purpose

• owner

• assigned users/groups

• permissions

• credentials

• last use where available

🧪 Task 20 — Review App Registrations

Navigate to:

App registrations

Review:

• owners

• API permissions

• credentials

• certificates

• secrets

🚨 Security Red Flags

Look for:

• no owner

• broad application permissions

• old secrets

• long-lived secrets

• unknown applications

• excessive administrator consent

🧪 Task 21 — Review Service Principals

Understand the relationship conceptually:

Application Registration
        ↓
Application Identity
        ↓
Service Principal
        ↓
Tenant Access

🧠 Security Question

Ask:

What can this application identity do if compromised?

Treat non-human identities as part of the attack surface.

🧪 Task 22 — Review Client Secrets

For each application secret record:

• expiration

• age

• owner

• purpose

🚨 Example Finding

Finding ID:
ENTRA-003

Title:
Long-Lived Application Secret

Severity:
High / Medium depending on privilege

Risk:
Compromise of the secret could provide persistent application access.

Recommendation:
Reduce credential lifetime and evaluate certificate-based or managed identity alternatives where appropriate.

🧪 Task 23 — Understand Managed Identities

For Azure-hosted workloads, understand the preferred pattern:

Azure Workload
      ↓
Managed Identity
      ↓
Azure Resource

rather than:

Azure Workload
      ↓
Stored Client Secret
      ↓
Azure Resource

🧠 Why Managed Identities Matter

They can reduce:

• secret storage

• manual secret rotation

• accidental credential exposure

🧪 Task 24 — Design a Managed Identity Scenario

Scenario:

An Azure application needs access to Key Vault.

Design:

Application
   ↓
Managed Identity
   ↓
Least-Privilege Permission
   ↓
Key Vault

Document why this is preferable to hardcoding a secret.

🧪 Task 25 — Review Application Permissions

For important applications, inspect requested permissions.

Ask:

• delegated or application-style access?

• how broad is the permission?

• does it match the business requirement?

• was administrator consent appropriate?

🚨 Example Risk

Application Needs:
Read limited business data

Application Has:
Broad organization-wide access

This deserves review.

🧪 Task 26 — Review Administrative Consent

Identify applications with broad permissions requiring administrator approval.

Ask:

Who approved this?

Why?

Is it still required?

🧠 Consent Is a Security Decision

Do not treat admin consent as:

click Accept.

It can create significant access.

🧪 Task 27 — Review Identity Lifecycle

Choose several test identities and classify them as:

• joiner

• mover

• leaver

🧠 Joiner

Should receive appropriate initial access.

🧠 Mover

Should lose old access and receive new access.

🧠 Leaver

Should lose access promptly.

🧪 Task 28 — Simulate a Mover Risk

Scenario:

Employee
 ↓
Finance Team
 ↓
Finance Access
 ↓
Moves to HR
 ↓
Receives HR Access
 ↓
Retains Finance Access

Identify the risk:

privilege accumulation.

🧪 Task 29 — Review Access Reviews

If available, review or design access reviews for:

• privileged groups

• guest users

• sensitive applications

📋 Access Review Decision

Identity	Access	Business Need	Decision
			Retain / Remove / Investigate

🧠 Governance Principle

Access should not last forever simply because:

nobody removed it.

🧪 Task 30 — Design an Access Review Schedule

Example:

Privileged Roles
→ Monthly / Quarterly

Guest Access
→ Quarterly

Sensitive Applications
→ Quarterly / Periodic

General Access
→ Risk-Based

Use actual organizational requirements rather than blindly following a fixed cadence.

🧪 Task 31 — Review Sign-In Logs

Navigate to Entra sign-in logs.

Review test or available events.

For each event record:

• user

• time

• IP

• location

• application

• authentication result

• device

• Conditional Access result

🧠 Sign-In Investigation Question

A successful sign-in tells you:

authentication succeeded.

It does not tell you:

the activity was legitimate.

🧪 Task 32 — Review Audit Logs

Review identity administrative activity such as:

• user creation

• group membership changes

• role assignment

• application changes

• Conditional Access changes

🧠 Security Operations Connection

Identity attacks often involve:

Credential Access
      ↓
Sign-In
      ↓
Privilege Change
      ↓
Persistence
      ↓
Resource Access

Sign-in and audit telemetry should be correlated.

🧪 Task 33 — Investigate a Suspicious Sign-In Scenario

Scenario:

A privileged administrator signs in from an unusual location.

Do not automatically declare compromise.

Investigate:

Identity
 ↓
Sign-In Time
 ↓
Source IP / Location
 ↓
Device
 ↓
Authentication Method
 ↓
MFA
 ↓
Conditional Access
 ↓
Subsequent Activity

🔍 Questions

Ask:

• was travel expected?

• was VPN in use?

• was MFA successful?

• which application was accessed?

• what happened next?

• were roles modified?

🧪 Task 34 — Correlate Sign-In and Audit Activity

After the suspicious sign-in, check for:

• privileged-role changes

• new applications

• secret creation

• group membership changes

• Conditional Access modifications

🚨 High-Risk Sequence

Suspicious Sign-In
      ↓
Privilege Assignment
      ↓
New Application Secret
      ↓
Persistent Access

This may represent an identity attack path.

🧪 Task 35 — Simulate an Identity Incident Timeline

Create:

Time	Event	Identity	Risk
09:10	Suspicious sign-in	Admin	High
09:14	Role assigned	Admin	High
09:18	App secret created	App	High
09:25	Security team detects	SOC	—

🧠 Investigation Goal

You should be able to tell:

what happened first, what followed, and what the attacker may have achieved.

🧪 Task 36 — Determine Identity Incident Scope

Ask:

Users

Which human identities were involved?

Roles

Which privileges were affected?

Applications

Were app identities created or modified?

Sessions

Could active sessions remain?

Azure Resources

What could the identity access?

🧪 Task 37 — Create an Identity Finding Register

ID	Finding	Severity	Identity	Recommendation
ENTRA-001
ENTRA-002

🧪 Task 38 — Create a Conditional Access Finding

Example:

Finding ID:
ENTRA-004

Title:
Privileged Administrators Not Covered by Strong Conditional Access

Severity:
High

Observation:
High-impact administrators are not consistently subject to stronger authentication policy.

Risk:
Credential compromise may provide privileged access without sufficient contextual controls.

Recommendation:
Implement a tested Conditional Access strategy for privileged identities with appropriate emergency-access safeguards.

🧪 Task 39 — Create a Guest Access Finding

Finding ID:
ENTRA-005

Title:
Stale Guest Identities Retain Access

Severity:
Medium

Observation:
External identities associated with completed projects remain enabled.

Risk:
Former third parties may retain unnecessary access.

Recommendation:
Establish ownership, periodic guest access reviews, and expiration/removal processes.

🧪 Task 40 — Create an Application Identity Finding

Finding ID:
ENTRA-006

Title:
Application Has Excessive Permissions

Severity:
High

Observation:
An application identity holds organization-wide permissions beyond its documented business requirement.

Risk:
Compromise of the application credential could provide broad unauthorized access.

Recommendation:
Reduce permissions to least privilege, confirm ownership, and review credential design.

📊 Risk Rating Model

Use:

Privilege
+
Credential Strength
+
Scope
+
Exposure
+
Persistence
+
Business Impact
=
Risk

🔴 Critical

Potential major tenant or enterprise compromise.

🟠 High

Privileged identity weakness, excessive application authority, or serious authentication gap.

🟡 Medium

Meaningful lifecycle or governance weakness.

🔵 Low

Cleanup, documentation, or minor hardening issue.

🧪 Task 41 — Build an Entra Security Assessment Checklist

Control	Status	Risk	Recommendation
Privileged MFA coverage
Conditional Access
Emergency access
Permanent privileged roles
PIM usage
Guest access
Service principals
Application secrets
Admin consent
Access reviews
Joiner/Mover/Leaver
Sign-in monitoring

🎤 Microsoft Entra ID Security Interview Questions

Practise without notes.

Fundamentals

1. What is Microsoft Entra ID?

2. What is a tenant?

3. Member vs guest user?

4. Authentication vs authorization?

Authentication

5. What is MFA?

6. Why is password-only authentication risky?

7. What is passwordless authentication?

8. Why do privileged users need stronger authentication controls?

Conditional Access

9. What is Conditional Access?

10. What types of signals can Conditional Access use?

11. How would you deploy a Conditional Access policy safely?

12. Why are emergency-access identities important?

Privileged Access

13. What is PIM?

14. Eligible vs permanent privilege?

15. Why is standing privilege risky?

16. How would you secure highly privileged administrators?

Applications

17. What is a service principal?

18. What is an application registration?

19. Service principal vs managed identity?

20. Why are long-lived client secrets risky?

21. What is admin consent?

Governance

22. What is an access review?

23. Why should guest access be reviewed?

24. What is joiner-mover-leaver?

25. What security risk exists during employee role changes?

Investigation

26. How would you investigate a suspicious sign-in?

27. Which identity changes would you consider high risk?

28. What would you review after an unexpected privileged-role assignment?

🚨 Scenario Interview Question 1 — Suspicious Administrator Sign-In

A privileged administrator signs in from an unusual country and then creates a new application credential.

A strong answer should include:

Validate Sign-In
      ↓
Authentication Context
      ↓
Role / Privilege
      ↓
Audit Activity
      ↓
Application Credential
      ↓
Scope
      ↓
Containment

🚨 Scenario Interview Question 2 — Permanent Global Privilege

Several administrators permanently hold powerful directory roles but only require them occasionally.

Discuss:

• business need

• PIM

• eligible assignments

• activation controls

• MFA

• monitoring

🚨 Scenario Interview Question 3 — Stale Contractor

A contractor left six months ago but still exists as an active guest.

Discuss:

• sponsor

• access review

• disable/remove

• lifecycle process

• governance

🚨 Scenario Interview Question 4 — Production App Secret

A critical application uses a long-lived client secret stored in configuration.

Discuss:

• credential exposure

• permission scope

• secure storage

• certificate or managed identity alternatives

• rotation

🚨 Scenario Interview Question 5 — User Locked Out

A valid employee suddenly cannot access a business application after a Conditional Access change.

Use:

Identity
 ↓
Authentication
 ↓
Conditional Access Result
 ↓
Device / Location
 ↓
Application Assignment
 ↓
Authorization
 ↓
Logs

Do not simply disable the security policy.

🧠 Identity Interview Framework

Use:

Identity
   ↓
Authentication
   ↓
Context
   ↓
Policy
   ↓
Authorization
   ↓
Privilege
   ↓
Governance
   ↓
Telemetry

💬 Interview Tip

Avoid:

“Enable MFA and Conditional Access.”

A stronger answer is:

“I would first identify the identity population and risk, establish strong authentication for privileged users, apply Conditional Access based on relevant context, reduce standing privilege through PIM, govern external and application identities, and monitor sign-in and administrative activity.”

That sounds like an Identity Security Engineer.

📁 Portfolio Evidence

After completing this lab, create a sanitized portfolio package.

Include:

Identity Architecture

Show:

User / Application
       ↓
Microsoft Entra
       ↓
Authentication
       ↓
Conditional Access
       ↓
Authorization
       ↓
Application / Resource

Privileged Access Review

Document:

• privileged identities

• permanent vs eligible access

• recommendations

Guest Access Review

Show lifecycle decisions.

Application Identity Review

Document:

• permissions

• credentials

• ownership

• recommendations

Suspicious Sign-In Investigation

Create:

• evidence

• timeline

• conclusion

• remediation

📝 Resume Examples

Instead of:

Knowledge of Microsoft Entra ID.

Use:

Performed a Microsoft Entra ID security review in a lab environment covering MFA, Conditional Access, privileged roles, guest identities, service principals, application credentials, and identity-governance controls.

Or:

Investigated simulated suspicious identity activity using Entra sign-in and audit telemetry and documented scope, privilege changes, persistence indicators, and remediation recommendations.

⭐ Job-Readiness Check

After this lab, you should be able to:

• explain Microsoft Entra ID

• review users and groups

• distinguish authentication and authorization

• explain MFA

• explain Conditional Access

• understand emergency access

• review privileged roles

• explain PIM

• assess guest identities

• review service principals

• explain managed identities

• identify risky application secrets

• understand admin consent

• explain access reviews

• understand joiner-mover-leaver

• investigate suspicious sign-ins

• create professional identity findings

If your identity-security strategy still means only:

enable MFA,

repeat the lab.

The goal is:

secure the complete identity lifecycle — authentication, privilege, application identity, governance, monitoring, and removal of unnecessary access.

🧹 Lab Clean-Up

After the lab:

• remove temporary test users

• remove unnecessary test groups

• undo temporary privileged assignments

• remove test application secrets

• remove temporary app registrations where appropriate

• remove lab Conditional Access policies if no longer needed

• ensure emergency-access testing did not leave unsafe exclusions

• confirm no unnecessary guest accounts remain

🏆 Mission Complete

You have now practised:

Identity Inventory
      ↓
Authentication Security
      ↓
Conditional Access
      ↓
Privileged Access
      ↓
Application Identity
      ↓
Guest Governance
      ↓
Identity Lifecycle
      ↓
Investigation
      ↓
Security Findings

These are core skills for:

• Identity Security Engineers

• IAM Engineers

• Azure Security Engineers

• SOC Analysts

• Security Consultants

• Cloud Security Architects

🚀 What’s Next?

You now understand who the identity is, how it authenticates, and how privilege should be governed.

The next step is to secure the network paths that those identities and workloads use inside Azure.

➡️ Next: Azure Network Security Lab

In the next lab, you will work with:

• Azure VNets

• subnets

• NSGs

• routing

• public exposure

• Azure Firewall concepts

• Private Endpoints

• service access

• VNet peering

• network monitoring

• traffic troubleshooting

• network-security findings

• remediation

• Azure network interview scenarios