Lab 01 — Microsoft Entra ID Assessment

Mission Information

Field	Details
Career Path	Cloud Penetration Tester
Module	Azure Cloud Penetration Testing
Difficulty	Intermediate
Estimated Time	90–120 Minutes
Lab Type	Identity Security Assessment
Environment	Authorised Azure Lab Tenant
Primary Tools	Azure CLI, Microsoft Graph, Azure Portal
Output	Entra ID Assessment Report
Cost	Azure Free Tier or Existing Lab Tenant

Mission Brief

You are working as a Cloud Penetration Tester for CloudNova Technologies.

The organisation has been engaged to assess the Microsoft Entra ID environment of a fictional customer named Northstar Digital Services.

Northstar uses Microsoft Entra ID for:

Employee authentication
Azure Portal access
Microsoft 365 services
Enterprise applications
Guest collaboration
Service principals
Managed identities
Administrative access

The customer is concerned that rapid cloud adoption may have created excessive privileges, outdated identities, insecure applications, and poorly governed access relationships.

Your task is to perform a structured, read-only Microsoft Entra ID assessment and identify identity risks that could contribute to Azure attack paths.

You must not create users, reset passwords, add application credentials, modify group membership, grant consent, or change administrative roles.

Mission Objectives

By completing this lab, you will:

Confirm the authorised tenant and identity context.
Enumerate visible users and guest accounts.
Review Microsoft Entra groups and group ownership.
Identify privileged directory roles.
Review application registrations.
Review enterprise applications and service principals.
Identify application ownership relationships.
Review application credential metadata.
Assess available authentication and Conditional Access information.
Identify risky identity relationships.
Create an identity attack-path diagram.
Produce an enterprise-style assessment report.

Business Outcomes

This assessment helps the organisation answer:

Which identities exist in the tenant?
Which users and groups hold privileged access?
Are guest identities appropriately governed?
Which applications and service principals have access?
Who controls privileged applications?
Are old or long-lived credentials present?
Could a low-privileged user influence a privileged identity?
Are identity changes visible to the security team?
Which controls should be improved first?

Prerequisites

Before starting, confirm that you have completed:

Lesson 01 — Azure Offensive Security Foundations
Lesson 02 — Microsoft Entra ID Attacks
Lesson 03 — Azure RBAC Exploitation

You should also understand:

Microsoft Entra users and groups
Administrative roles
Application registrations
Enterprise applications
Service principals
Managed identities
Azure RBAC
Authentication and Conditional Access
Rules of Engagement

Required Access

Use a dedicated lab identity with read-only permissions wherever possible.

Recommended access includes:

Directory Readers
Global Reader
Security Reader
Reader access to the authorised Azure subscription

The exact information visible will depend on your tenant permissions and licensing.

Do not attempt to bypass missing permissions.

Rules of Engagement

You are authorised to:

View permitted directory objects.
Enumerate users and groups visible to your identity.
Review administrative-role assignments.
Review application and service-principal metadata.
Review application owners.
Review credential metadata without retrieving secret values.
Review Azure role assignments associated with identities.
Document identity relationships.
Create a sanitised assessment report.

You are not authorised to:

Create or delete users.
Invite guest users.
Reset passwords.
Add authentication methods.
Add or remove group members.
Activate privileged roles.
Add application secrets or certificates.
Export private keys.
Grant application consent.
Modify Conditional Access.
Create Azure role assignments.
Retrieve production secrets.
Perform password attacks.
Perform phishing.
Attempt authentication bypass.
Disable logging.

Stop immediately if you discover unexpected access to sensitive information.

Lab Architecture

Authorised Test Identity
          │
          ▼
Microsoft Entra ID Tenant
          │
          ├── Users
          ├── Guest Users
          ├── Groups
          ├── Administrative Roles
          ├── Application Registrations
          ├── Enterprise Applications
          ├── Service Principals
          └── Managed Identities
                   │
                   ▼
            Azure Role Assignments
                   │
                   ▼
              Azure Resources

Expected Deliverables

At the end of the lab, create:

Microsoft Entra ID Assessment
│
├── 01 Engagement Context
├── 02 Tenant Overview
├── 03 User Inventory
├── 04 Guest User Review
├── 05 Group and Ownership Review
├── 06 Administrative Role Review
├── 07 Application Review
├── 08 Service Principal Review
├── 09 Credential Metadata Review
├── 10 Azure Role Mapping
├── 11 Identity Attack Paths
├── 12 Findings
├── 13 Recommendations
└── 14 Evidence

Part 1 — Prepare the Assessment Environment

Task 1.1 — Verify Azure CLI

Open PowerShell, Windows Terminal, or your approved Linux terminal.

Check the Azure CLI version:

az version

If the command is unavailable, install the Azure CLI using the approved method for your workstation.

Record:

Azure CLI version:
Operating system:
Assessment date:
Tester:

Task 1.2 — Authenticate

az login

Where device-code authentication is required:

az login --use-device-code

Do not authenticate using personal administrator accounts unless explicitly approved.

Task 1.3 — Confirm the Current Context

Run:

az account show --output table

Record:

Account name
Tenant ID
Subscription ID
Subscription name
Current state

Store the active tenant ID:

TENANT_ID=$(az account show --query tenantId -o tsv)

Store the active subscription ID:

SUBSCRIPTION_ID=$(az account show --query id -o tsv)

Display the values:

echo "Tenant ID: $TENANT_ID"
echo "Subscription ID: $SUBSCRIPTION_ID"

Confirm that both identifiers are included in the authorised scope.

Validation Checkpoint

You should be able to confirm:

The correct test identity is authenticated.
The correct tenant is active.
The authorised subscription is selected.
No production tenant outside scope is being queried.

Part 2 — Establish the Current Identity

Task 2.1 — Display the Signed-In User

Run:

az ad signed-in-user show

For a concise view:

az ad signed-in-user show \
  --query "{DisplayName:displayName,UserPrincipalName:userPrincipalName,ObjectId:id,UserType:userType}" \
  --output table

Record:

Display name
User principal name
Object ID
User type

Store the object ID:

CURRENT_USER_ID=$(az ad signed-in-user show --query id -o tsv)

Task 2.2 — Review the Current User’s Azure Roles

Run:

az role assignment list \
  --assignee "$CURRENT_USER_ID" \
  --all \
  --output table

Record:

Role name
Scope
Direct or inherited assignment
Subscription or resource affected

Do not assume that a user without an Azure role has no Microsoft Entra privilege.

These are separate authorisation systems.

Part 3 — Review Tenant and Domain Information

Task 3.1 — Review Tenant Information

Run:

az account tenant list --output table

Record:

Tenant ID
Default domain
Tenant type, where visible
Additional accessible tenants

Task 3.2 — Review Verified Domains

Depending on your approved permissions and tooling, use Microsoft Graph or the Azure Portal to review:

Initial tenant domain
Custom verified domains
Federated domains
Default domain

Document only domain names relevant to the authorised tenant.

Assessment Questions

Does the organisation use multiple domains?
Are any legacy domains still present?
Is hybrid identity likely?
Are external identity providers involved?
Do domain names reveal mergers or business units?

Part 4 — User Inventory

Task 4.1 — List Visible Users

Run:

az ad user list \
  --query "[].{DisplayName:displayName,UserPrincipalName:userPrincipalName,UserType:userType,AccountEnabled:accountEnabled,ObjectId:id}" \
  --output table

Where the tenant contains many objects, export the authorised result:

az ad user list \
  --output json > entra-users.json

Protect the exported file because it contains identity information.

Task 4.2 — Classify Users

Create an inventory with the following columns:

Display Name	UPN	User Type	Enabled	Privileged	Business Owner	Observation

Classify accounts as:

Standard employee
Administrator
Contractor
Guest
Shared account
Service-style user account
Unknown
Disabled
Dormant, where activity data is available

Task 4.3 — Identify Naming and Governance Issues

Look for:

Generic names
Shared accounts
Test accounts
Old project accounts
Accounts without clear ownership
Disabled identities with active assignments
Unexpected personal domains
Accounts using inconsistent naming standards

Do not classify an account as malicious based only on its name.

Validate business ownership first.

Part 5 — Guest User Assessment

Task 5.1 — List Guest Users

Run:

az ad user list \
  --filter "userType eq 'Guest'" \
  --query "[].{DisplayName:displayName,UserPrincipalName:userPrincipalName,AccountEnabled:accountEnabled,ObjectId:id}" \
  --output table

Task 5.2 — Create a Guest Access Review Table

Guest User	External Domain	Enabled	Group Membership	Azure Role	Sponsor	Review Required

Task 5.3 — Review Guest Risk

Identify guests who:

Have Azure role assignments
Belong to sensitive groups
Appear to be associated with completed projects
Use personal email domains
Have no documented sponsor
Have no expiration or review process
Are disabled but retain access assignments

Assessment Questions

Is guest access justified?
Is sponsorship documented?
Are access reviews performed?
Are guests protected by Conditional Access?
Are guest accounts removed when no longer required?
Can guests enumerate more directory information than necessary?

Part 6 — Group and Membership Assessment

Task 6.1 — List Groups

Run:

az ad group list \
  --query "[].{DisplayName:displayName,MailEnabled:mailEnabled,SecurityEnabled:securityEnabled,ObjectId:id}" \
  --output table

Export where needed:

az ad group list --output json > entra-groups.json

Task 6.2 — Review Group Members

For an authorised group:

az ad group member list \
  --group "<authorised-group-id-or-name>" \
  --query "[].{DisplayName:displayName,ObjectType:'@odata.type',ObjectId:id}" \
  --output table

Task 6.3 — Review Group Owners

Run:

az ad group owner list \
  --group "<authorised-group-id-or-name>" \
  --output table

Task 6.4 — Identify Sensitive Groups

Prioritise groups associated with:

Azure administrators
Security operations
Application owners
Production access
Key Vault access
Storage access
CI/CD
Automation
Emergency access
Privileged Identity Management

Group Risk Questions

For each sensitive group, ask:

Who owns the group?
Who can modify membership?
Are guest users included?
Is membership reviewed?
Does the group hold Azure roles?
Does the group grant application access?
Is the group dynamic?
Is the business purpose documented?

Potential Attack Path

User controls group membership
        ↓
Group holds privileged role
        ↓
User adds controlled identity
        ↓
Privileged access inherited

Do not modify membership to validate this path.

Configuration evidence is sufficient.

Part 7 — Administrative Role Assessment

Task 7.1 — Review Microsoft Entra Administrative Roles

Use the Microsoft Entra admin centre or authorised Microsoft Graph tooling to identify:

Active role assignments
Eligible role assignments
Permanently active administrators
Group-based assignments
Privileged guest users
Role scope
Privileged Identity Management controls

Focus on roles such as:

Global Administrator
Privileged Role Administrator
Application Administrator
Cloud Application Administrator
Authentication Administrator
Privileged Authentication Administrator
User Administrator
Groups Administrator
Conditional Access Administrator
Security Administrator
Global Reader

Administrative Role Matrix

Identity	Identity Type	Role	Active/Eligible	Assignment Type	MFA/PIM	Scope	Observation

Task 7.2 — Review Permanent Privilege

Identify:

Roles permanently active
Roles assigned directly to users
Roles assigned to guest accounts
Roles without Privileged Identity Management
Emergency accounts without clear governance
Roles with no documented business owner

Assessment Questions

Could eligible access replace permanent access?
Is MFA required for activation?
Is approval required?
Are activation periods reasonable?
Are role activations monitored?
Are access reviews performed?

Part 8 — Application Registration Assessment

Task 8.1 — List Application Registrations

Run:

az ad app list \
  --query "[].{DisplayName:displayName,AppId:appId,ObjectId:id,CreatedDateTime:createdDateTime}" \
  --output table

Export the authorised list:

az ad app list --output json > entra-applications.json

Task 8.2 — Review a Specific Application

Run:

az ad app show \
  --id "<authorised-application-id>"

Review:

Display name
Application ID
Object ID
Sign-in audience
Redirect URIs
Identifier URIs
Required resource access
Tags
Business ownership

Task 8.3 — Review Application Owners

Run:

az ad app owner list \
  --id "<authorised-application-id>" \
  --query "[].{DisplayName:displayName,UserPrincipalName:userPrincipalName,ObjectId:id}" \
  --output table

Application Ownership Assessment

Identify applications that:

Have no owners
Have only one owner
Have former employees as owners
Have development users owning production applications
Have guest users as owners
Have too many owners
Use broad Microsoft Graph permissions
Have privileged Azure role assignments through their service principal

Potential Attack Path

Application owner
        ↓
Can manage application credentials
        ↓
Authenticate as service principal
        ↓
Use application permissions

Do not add a credential to validate the relationship.

Part 9 — Credential Metadata Assessment

Task 9.1 — Review Application Credential Metadata

For an authorised application:

az ad app credential list \
  --id "<authorised-application-id>" \
  --output table

Record metadata only:

Credential type
Key ID
Start date
End date
Display name
Usage

Do not attempt to retrieve secret values.

Credential Review Table

Application	Credential Type	Key ID	Start Date	Expiry Date	Lifetime	Owner	Observation

Task 9.2 — Identify Credential Risks

Look for:

Long-lived credentials
Expired credentials
Multiple active credentials
Credentials without descriptive names
Certificates valid for excessive periods
Credentials associated with abandoned applications
Applications with no sign-in activity
Production and development sharing the same identity

Assessment Questions

Are credentials rotated?
Are expired credentials removed?
Is workload identity federation available?
Are certificates governed?
Is application sign-in activity monitored?
Are credentials linked to a documented owner?

Part 10 — Service Principal Assessment

Task 10.1 — List Service Principals

Run:

az ad sp list \
  --query "[].{DisplayName:displayName,AppId:appId,ObjectId:id,ServicePrincipalType:servicePrincipalType}" \
  --output table

Large tenants may return many Microsoft-managed objects.

Focus on customer-owned and authorised enterprise applications.

Task 10.2 — Review a Specific Service Principal

Run:

az ad sp show \
  --id "<authorised-service-principal-id>"

Review:

Display name
Application ID
Object ID
Service principal type
Account enabled state
Tags
Application ownership relationship

Task 10.3 — Review Azure Roles

Store the service principal object ID:

SP_OBJECT_ID="<authorised-service-principal-object-id>"

List role assignments:

az role assignment list \
  --assignee "$SP_OBJECT_ID" \
  --all \
  --output table

Record:

Role name
Scope
Subscription
Resource group
Resource
Direct or inherited access

Service Principal Risk Questions

Does the identity have Owner or Contributor access?
Is the scope broader than necessary?
Does it access multiple subscriptions?
Is it used by development and production?
Are credentials long-lived?
Are owners documented?
Does it have both Graph and Azure permissions?
Is sign-in activity monitored?

Part 11 — Managed Identity Review

Managed identities are represented as service principals in Microsoft Entra ID.

Task 11.1 — List User-Assigned Managed Identities

Run:

az identity list \
  --query "[].{Name:name,ResourceGroup:resourceGroup,ClientId:clientId,PrincipalId:principalId,Location:location}" \
  --output table

Task 11.2 — Review Managed Identity Roles

For an authorised principal ID:

az role assignment list \
  --assignee "<managed-identity-principal-id>" \
  --all \
  --output table

Task 11.3 — Identify Connected Resources

Review which workloads use the managed identity.

Potential workloads include:

Virtual Machines
Function Apps
App Services
Logic Apps
Automation Accounts
Kubernetes workloads

Managed Identity Matrix

Identity	Type	Attached Resource	Azure Role	Scope	Environment	Risk

Potential Attack Path

Low-trust workload
        ↓
User-assigned managed identity
        ↓
Production Key Vault role
        ↓
Production secret access

Do not attach or detach identities during this lab.

Part 12 — Azure Role Mapping

Task 12.1 — List Role Assignments

Run:

az role assignment list \
  --all \
  --query "[].{PrincipalName:principalName,PrincipalType:principalType,Role:roleDefinitionName,Scope:scope}" \
  --output table

Task 12.2 — Identify High-Impact Assignments

Look for:

Owner
User Access Administrator
Contributor
Key Vault Administrator
Key Vault Secrets User
Storage Blob Data Owner
Storage Blob Data Contributor
Virtual Machine Contributor
Managed Identity Operator
Custom roles

Task 12.3 — Identify Broad Scope

Classify scope as:

Management group
Subscription
Resource group
Resource

Broad scope increases potential impact.

Role Assignment Matrix

Principal	Type	Role	Scope	Direct/Inherited	Business Purpose	Observation

Part 13 — Authentication and Conditional Access Review

This section may require Microsoft Entra administrative access and appropriate licensing.

Use the Azure Portal or approved Microsoft Graph tooling.

Task 13.1 — Review Authentication Controls

Assess:

MFA coverage
Privileged account protection
Passwordless authentication
Legacy authentication
Authentication-strength policies
Emergency-access accounts
Registration and recovery governance

Task 13.2 — Review Conditional Access

Record:

Policy name
State
Included users or groups
Excluded users or groups
Target applications
Conditions
Grant controls
Session controls

Conditional Access Matrix

Policy	State	Users	Exclusions	Applications	Requirement	Observation

Assessment Questions

Are privileged users covered?
Are guest users covered?
Is legacy authentication blocked?
Are risky sign-ins addressed?
Are unmanaged devices restricted?
Are exclusions documented?
Are emergency accounts monitored?
Are policies in report-only mode?

Do not enable, disable, or modify policies.

Part 14 — Logging and Detection Review

Task 14.1 — Review Identity Logs

Where authorised, review:

User sign-in logs
Service-principal sign-ins
Managed-identity sign-ins
Non-interactive sign-ins
Microsoft Entra audit logs
Privileged Identity Management activity

Task 14.2 — Identify Expected Detection Events

The organisation should be able to monitor:

New users
Guest invitations
Group membership changes
Administrative-role assignments
Application creation
Application credential additions
Application-owner changes
Consent grants
Service-principal sign-ins
Managed-identity use
Conditional Access changes
Authentication-method changes

Detection Coverage Table

Activity	Expected Log	Collected	Alerted	SOC Owner	Gap

Part 15 — Build Identity Attack Paths

Create at least three safe, evidence-supported attack paths.

Do not perform the final escalation action.

Attack Path 1 — Application Ownership

Development user
        ↓
Owns production application
        ↓
Can manage application credentials
        ↓
Service principal has Azure role
        ↓
Potential production access

Attack Path 2 — Group Ownership

User owns privileged group
        ↓
Can influence group membership
        ↓
Group holds Azure role
        ↓
Potential inherited access

Attack Path 3 — Managed Identity

Low-trust workload
        ↓
Uses shared managed identity
        ↓
Identity has production Key Vault access
        ↓
Potential production secret access

Attack Path Evidence Table

Step	Object	Permission or Relationship	Evidence	Expected Detection

Every step must be supported by:

Object ID
Role assignment
Ownership record
Scope
Resource relationship
Configuration evidence

Part 16 — Create Findings

Create findings only where evidence supports the risk.

Finding Template

Finding Title

Use a clear and business-relevant title.

Severity

Use the approved risk methodology.

Affected Objects

Document:

Tenant
Identity
Group
Application
Service principal
Role
Scope

Observation

Explain what was identified.

Evidence

Include:

Sanitised command output
Role assignment
Ownership record
Credential metadata
Relevant screenshot

Attack Path

Starting identity
        ↓
Identity weakness
        ↓
Intermediate privilege
        ↓
Target resource
        ↓
Business impact

Business Impact

Explain the effect on:

Confidentiality
Integrity
Availability
Compliance
Production access
Customer information

Recommendation

Provide:

Immediate action
Near-term improvement
Strategic control
Validation requirement

Example Finding 1

Finding Title

Development User Owns a Production-Privileged Application Registration

Observation

A development user is listed as an owner of an application registration whose service principal has Contributor access to a production resource group.

Application ownership may allow the user to manage application credentials.

Potential Attack Path

Development identity compromised
        ↓
Application credential added
        ↓
Authentication as service principal
        ↓
Contributor access to production resources

Business Impact

Compromise of the development identity could provide indirect access to production Azure resources and break environment separation.

Recommendation

Remove unnecessary application ownership.
Separate production and development applications.
Review all application credentials.
Reduce the service principal’s Azure role.
Prefer workload identity federation.
Monitor application credential changes.
Review service-principal sign-ins.

Example Finding 2

Finding Title

Guest User Retains Access Through a Privileged Azure Group

Observation

A guest user associated with a completed external project remains a member of a group assigned a privileged Azure role.

Business Impact

Compromise of the external identity could provide unauthorised access to Azure resources after the business relationship has ended.

Recommendation

Remove the guest from the privileged group.
Review all guest access.
Assign sponsors and expiration.
Implement periodic access reviews.
Apply Conditional Access to guests.
Monitor guest sign-ins.

Example Finding 3

Finding Title

Shared Managed Identity Connects Development and Production Environments

Observation

A user-assigned managed identity is attached to a development workload and holds access to a production Key Vault.

Potential Attack Path

Development workload compromised
        ↓
Shared managed identity
        ↓
Production Key Vault
        ↓
Production credential exposure

Recommendation

Use separate identities for each environment.
Remove production access from the development identity.
Restrict who can attach the identity.
Apply object-level or vault-level least privilege.
Monitor managed-identity and Key Vault activity.

Part 17 — Create the Final Assessment Report

Your report should contain the following sections.

1. Executive Summary

Explain:

Overall identity-risk posture
Most significant identity weakness
Potential business impact
Immediate remediation priorities

2. Scope

Document:

Tenant
Subscription
Included identities
Included applications
Exclusions
Assessment date

3. Methodology

Describe:

Read-only enumeration
Identity inventory
Role review
Application review
Credential metadata review
Attack-path analysis
Detection review

4. Tenant Overview

Document:

Tenant ID
Primary domain
Identity model
Hybrid identity status, where known
Number of visible users
Number of guests
Number of groups
Number of applications

5. Identity Findings

Include:

Users
Guests
Groups
Administrative roles
Applications
Service principals
Managed identities
Azure roles
Authentication controls

6. Attack Paths

Include at least three diagrams.

7. Detection Coverage

Explain which identity events are logged and alerted.

8. Recommendations

Organise recommendations into:

Immediate — 0 to 7 Days

Remove unnecessary privileged access.
Remove obsolete guest access.
Revoke unknown credentials.
Review privileged application owners.
Address critical cross-environment identities.

Near Term — 8 to 30 Days

Implement Privileged Identity Management.
Strengthen Conditional Access.
Introduce application credential governance.
Separate production and development identities.
Implement guest access reviews.

Strategic — 31 to 90 Days

Establish identity governance.
Automate access reviews.
Implement workload identity federation.
Build continuous identity attack-path monitoring.
Standardise non-human identity ownership.

Validation Checklist

Before completing the lab, confirm:

Troubleshooting

Azure CLI Returns Insufficient Privileges

Cause:

The test identity lacks directory read permissions.

Action:

Confirm the assigned role.
Request approved read-only access.
Do not attempt to bypass the control.
Document the assessment limitation.

User or Group Lists Are Incomplete

Cause:

Directory permissions, filtering, or paging limitations.

Action:

Confirm permissions.
Use the authorised Microsoft Graph interface.
Export results carefully.
Document any visibility limitation.

Application Credential Values Are Not Visible

This is expected.

Existing client secret values cannot normally be retrieved after creation.

Review only metadata such as:

Key ID
Credential type
Start date
Expiration date

Role Assignments Appear Empty

Cause:

Wrong subscription
Insufficient Azure permissions
Role assigned through a group
Assignment exists at another scope

Action:

az account list --output table

Select the authorised subscription:

az account set --subscription "<authorised-subscription-id>"

Then repeat the role-assignment query.

Microsoft Entra Role Information Is Unavailable

Cause:

Insufficient directory permissions
Missing licensing
Restricted Graph access

Action:

Use the approved Entra admin portal with authorised access.
Request Global Reader or Directory Reader where appropriate.
Document the limitation.

Cleanup

This lab is designed to be read-only.

Cleanup activities include:

Sign out of Azure CLI:

az logout

Remove exported files containing identity information when no longer required.
Store assessment evidence in the approved encrypted location.
Redact tenant IDs, object IDs, email addresses, and internal names from portfolio copies.
Confirm that no accounts, credentials, roles, or permissions were changed.

Portfolio Evidence

Create a sanitised portfolio entry containing:

Lab objective
Assessment methodology
Identity inventory template
Privileged-role matrix
Application ownership review
Managed-identity mapping
Three sanitised attack-path diagrams
Example finding
Remediation roadmap
Lessons learned

Do not publish:

Real tenant IDs
Real user principal names
Object IDs
Internal application names
Production role assignments
Customer domains
Credential metadata linked to real systems

Learning Outcomes

After completing this lab, you should be able to:

Perform a structured Microsoft Entra ID assessment.
Identify users, guests, groups, and privileged roles.
Assess application and service-principal ownership.
Review credential metadata safely.
Map managed identities to Azure resources.
Connect Microsoft Entra relationships to Azure RBAC.
Build realistic identity attack paths.
Evaluate identity logging and detection coverage.
Produce an enterprise-quality identity assessment report.

Knowledge Review

Why are Microsoft Entra and Azure RBAC permissions reviewed separately?
How can group ownership create indirect privilege?
Why is application ownership security-sensitive?
What is the difference between an application registration and a service principal?
Why should credential metadata be reviewed?
How can a managed identity connect development and production?
Why must guest access be reviewed regularly?
What is the value of Privileged Identity Management?
Why is read-only evidence often sufficient?
Which identity events should be monitored by the SOC?

Mission Complete

You have completed the Microsoft Entra ID Assessment.

You have:

Established the authorised identity context
Reviewed users and guests
Assessed groups and administrative roles
Reviewed applications and service principals
Examined credential metadata
Mapped managed identities
Connected identity relationships to Azure roles
Built identity attack paths
Produced an enterprise assessment structure

Next Lab

➡️ Lab 02 — Azure Storage Assessment

In the next lab, you will perform a structured Azure Storage security assessment covering Storage Accounts, containers, Azure Files, public access, Azure RBAC, Shared Access Signatures, network controls, data protection, monitoring, and storage-related attack paths.