This project is a hands-on Microsoft Entra ID Identity and Access Management (IAM) security lab designed to demonstrate practical cloud identity administration, authentication security, Conditional Access, Role-Based Access Control (RBAC), monitoring, and troubleshooting.
The lab simulates common identity and security responsibilities performed by IT support, Microsoft 365, IAM, cloud support, and security administrators.
Rather than documenting configuration alone, the project focuses on the complete administrative workflow:
Configure → Test → Validate → Investigate → Document
Conditional Access controls were deployed using a safer staged approach:
Configure → Report-only → Simulate → Validate → Investigate → Audit
- Microsoft Entra ID user administration
- Security group administration
- Microsoft Authenticator
- Multifactor Authentication
- MFA number matching
- Conditional Access
- Named locations
- Legacy authentication protection
- Device platform restrictions
- Device code authentication restrictions
- Administrative portal protection
- Role-Based Access Control
- Least-privilege administration
- Sign-in log analysis
- Audit-log investigation
- Authentication troubleshooting
- Conditional Access troubleshooting
Microsoft Entra ID
|
+-----------------------+-----------------------+
| | |
Identities Authentication RBAC
| | |
Users / Groups MFA / Authenticator Admin Roles
| | |
+-----------------------+-----------------------+
|
Conditional Access
|
+----------------------+----------------------+
| | | |
MFA Locations Devices Auth Flows
| | | |
+----------------------+----------------------+
|
Access Decision
|
+---------------+---------------+
| |
Sign-In Logs Audit Logs
| |
Authentication Analysis Change Investigation
The project was completed in a dedicated Microsoft cloud lab environment using Microsoft Entra ID.
Administrative work was performed through the Microsoft Entra admin center.
The environment was structured around separate administrative and test identities so security controls could be evaluated without unnecessarily affecting the primary administrator.
| Component | Purpose |
|---|---|
| Microsoft Entra ID | Identity and access management |
| Microsoft Entra Admin Center | Identity/security administration |
| Microsoft Authenticator | MFA registration and authentication |
| Conditional Access | Context-aware access controls |
| Microsoft Entra RBAC | Administrative permission delegation |
| Sign-in Logs | Authentication investigation |
| Audit Logs | Administrative change tracking |
| What If | Conditional Access simulation |
Read the Environment Setup documentation
Dedicated security-lab identities were used for controlled testing.
Test identities simulated both standard users and privileged administrators.
A dedicated security group was created:
SG-CA-Test-Users
The group provided a scalable target for Conditional Access policies instead of requiring policies to be assigned individually to each test identity.
- Reviewed Microsoft Entra users
- Used dedicated security test identities
- Created security groups
- Added users to groups
- Verified group membership
- Used group-based Conditional Access targeting
- Separated standard and administrative testing
View all User and Group evidence
Read the User and Group documentation
Microsoft Authenticator was configured and tested as part of the lab's authentication-security implementation.
A test identity completed authentication registration and MFA validation.
Number matching was also tested to demonstrate stronger MFA verification.
- Reviewed authentication-method configuration
- Enabled Microsoft Authenticator
- Completed security-information registration
- Registered Microsoft Authenticator
- Tested MFA
- Tested number matching
- Verified successful registration
- Investigated authentication results
Read the MFA and Authentication documentation
Conditional Access was the primary security component of this project.
Multiple policies were created to demonstrate identity-based, role-based, location-based, device-based, application-based, and authentication-flow-based access controls.
Policies remained in Report-only mode during testing.
This provided a safer way to evaluate policy behavior without risking accidental administrative lockout.
| Policy | Security Objective | Mode |
|---|---|---|
| CA-Require-MFA-and-Compliant-Device | Require MFA/device security | |
| Report-only | ||
| CA001-Require-MFA-Test-Users | Require MFA for test users | Report-only |
| | CA002-Block-Legacy-Authentication | Block legacy authentication | Report-only | | CA003-Require-MFA-Admins | Require MFA for administrators | Report-only | | CA004-Block-Access-Outside-Trusted-Location | Restrict access by location | Report-only | | CA005-Block-Unsupported-Device-Platforms | Restrict unsupported platforms | Report-only | | CA006-Require-MFA-Admin-Portals | Protect administrative resources | Report-only | | CA007-Block-Device-Code-Authentication | Restrict device code authentication | Report-only |
This provides centralized evidence of the Conditional Access controls created during the lab.
Conditional Access was configured to require MFA for selected test identities.
The policy was evaluated in Report-only mode before potential enforcement.
Legacy authentication protocols can weaken modern identity-security controls.
A Conditional Access policy was configured to block legacy authentication clients.
This demonstrates how organizations can reduce exposure to authentication methods that do not fully support modern security controls.
Privileged identities represent high-value targets.
Conditional Access was configured to require MFA for selected Microsoft Entra administrative roles.
This adds an additional authentication layer around privileged administration.
A named location was created to represent a trusted corporate network.
The documentation-only TEST-NET range used for the lab was:
203.0.113.0/24
A Conditional Access policy was then configured to block access when authentication originated outside the trusted location.
The Microsoft Entra Conditional Access What If tool was used to simulate authentication scenarios before policy enforcement.
Policy behavior was evaluated using conditions such as:
- User
- Group
- Application
- Location
- Device platform
- Authentication flow
The simulation demonstrated that CA004 would apply when authentication originated outside the trusted location.
Testing from the simulated trusted network demonstrated that the location exclusion prevented CA004 from applying.
Testing both positive and negative conditions provided stronger validation than simply creating the policy.
Conditional Access was configured to evaluate device-platform conditions.
What If testing was used to validate expected behavior before enforcement.
Administrative portals provide access to sensitive cloud configuration.
CA006 was created to require MFA for Microsoft administrative resources.
This demonstrates additional protection around privileged cloud administration.
Device code authentication is useful for devices with limited input capabilities, but the authentication flow can present security risks if abused.
CA007 was created to block device code authentication for lab test identities.
The What If evaluation confirmed that CA007 matched the simulated device code authentication flow and produced the expected Block access result.
View all Conditional Access evidence
Read the complete Conditional Access documentation
Microsoft Entra directory roles were used to demonstrate least-privilege administration.
Rather than granting broad administrative access to every account, specialized roles were assigned and tested.
- Conditional Access Administrator
- Helpdesk Administrator
- Security Reader
This role was used for delegated Conditional Access administration.
This role represents limited IT support responsibilities without requiring broad tenant administration.
This role provides security visibility without configuration privileges.
Role assignment alone does not prove that least privilege is functioning.
The delegated Conditional Access administrator was tested to verify both allowed and restricted administrative functionality.
This demonstrated practical administrative separation rather than simply documenting role assignments.
Read the RBAC and Permissions documentation
Microsoft Entra sign-in logs were used to investigate authentication activity.
Sign-in analysis included reviewing:
- User identity
- Application
- Authentication status
- MFA requirements
- Conditional Access results
- Authentication interruptions
One successful authentication demonstrated that the MFA requirement had been satisfied by an MFA claim associated with the authentication session.
Conditional Access Report-only mode allowed policy behavior to be observed without actively enforcing the access decision.
This staged deployment approach reduces the risk of accidental user or administrator lockout.
Microsoft Entra audit logs were used to validate administrative changes.
The audit trail provided evidence that Conditional Access configuration changes were recorded.
This demonstrates how administrators can correlate configuration activity with Microsoft Entra audit records.
The controls implemented throughout this project form a layered identity-security model.
Identity
|
v
Strong Authentication
|
v
MFA / Microsoft Authenticator
|
v
Least-Privilege RBAC
|
v
Conditional Access
|
+---- Identity
+---- Application
+---- Location
+---- Device Platform
+---- Authentication Flow
|
v
Access Decision
|
v
Sign-In Monitoring
|
v
Audit & Investigation
The goal is not to rely on a single security mechanism.
Instead, identity protection is strengthened through multiple overlapping controls.
Read the Identity Security documentation
Troubleshooting was treated as a core component of the project rather than documenting only successful configurations.
The troubleshooting workflow was:
Identify → Reproduce → Investigate → Isolate → Correct → Validate → Document
- MFA registration session expiration
- Expired password sign-in interruption
- Conditional Access policy matching
- Conditional Access policy exclusions
- Group membership validation
- MFA claims
- RBAC permissions
- Sign-in results
- Audit events
- Licensing limitations
These scenarios demonstrate using Microsoft Entra evidence and diagnostic tools to determine the cause of identity and access issues rather than assuming the source of the problem.
Read the complete Troubleshooting documentation
Risk-based Conditional Access was investigated during the project.
The lab tenant did not expose the required Sign-in risk condition for the planned risk-based Conditional Access policy.
Instead of representing an unsupported feature as successfully configured, the limitation was documented and the project continued using supported Conditional Access scenarios.
This demonstrates an important real-world cloud administration skill:
Distinguishing configuration problems from licensing and feature-availability limitations.
Multiple security controls were combined rather than relying on passwords alone.
Administrative permissions were separated using specialized Microsoft Entra directory roles.
MFA and Microsoft Authenticator were configured and tested.
Conditional Access policies remained in Report-only mode while being evaluated.
Policies were tested under conditions where they should apply and conditions where they should not apply.
Sign-in logs were used to validate authentication behavior and investigate access events.
Audit logs were used to verify administrative changes and review policy activity.
Authentication and access issues were investigated using Microsoft Entra diagnostic information and controlled testing.
- Microsoft Entra ID
- User administration
- Security group administration
- Group membership management
- IAM administration
- Identity security
- Access management
- Multifactor Authentication
- Microsoft Authenticator
- MFA number matching
- Authentication methods
- Authentication registration
- Authentication troubleshooting
- User and group targeting
- Administrative-role targeting
- Application targeting
- Named locations
- Device platform conditions
- Authentication flow conditions
- Block access controls
- MFA grant controls
- Report-only deployment
- What If testing
- Policy validation
- Microsoft Entra RBAC
- Conditional Access Administrator
- Helpdesk Administrator
- Security Reader
- Least privilege
- Administrative separation
- Permission validation
- Sign-in log analysis
- Audit-log investigation
- Conditional Access troubleshooting
- MFA troubleshooting
- Password troubleshooting
- Group membership validation
- RBAC troubleshooting
- Licensing investigation
- Root-cause analysis
Detailed technical documentation is available for each major section of the project:
- Environment Setup
- Users & Groups
- MFA & Authentication
- Conditional Access
- RBAC & Permissions
- Identity Security
- Troubleshooting
Microsoft-Entra-ID-IAM-Security-Lab/
|
├── README.md
|
├── Documentation/
│ ├── 01-Environment-Setup.md
│ ├── 02-Users-Groups.md
│ ├── 03-MFA-Authentication.md
│ ├── 04-Conditional-Access.md
│ ├── 05-RBAC-Permissions.md
│ ├── 06-Identity-Security.md
│ └── 07-Troubleshooting.md
|
├── Screenshots/
│ ├── Authentication/
│ ├── Conditional-Access/
│ ├── Entra-ID/
│ ├── MFA/
│ ├── RBAC/
│ ├── Troubleshooting/
│ └── Users-Groups/
|
├── Help-Desk-Tickets/
|
└── Diagrams/
This project demonstrates that identity administration involves much more than creating users and resetting passwords.
A secure Microsoft Entra environment requires administrators to understand how identity, authentication, authorization, access policies, monitoring, and auditing work together.
Key lessons from the project include:
- MFA provides an important defense against password compromise.
- Conditional Access allows authentication context to influence access decisions.
- Report-only deployment reduces the risk associated with new access policies.
- What If testing provides a controlled way to validate policy logic.
- Named locations can support location-aware security decisions.
- Legacy authentication should be restricted where possible.
- Privileged administrative access should receive stronger protection.
- RBAC helps enforce least privilege.
- Sign-in logs provide critical authentication evidence.
- Audit logs provide accountability for administrative changes.
- Licensing can determine which identity-security capabilities are available.
- Effective troubleshooting requires validating the complete authentication path rather than assuming a single cause.
This repository was created as a practical demonstration of Microsoft cloud identity and security administration.
It is intended to demonstrate hands-on skills relevant to roles such as:
- IT Support Specialist
- Help Desk Technician
- Microsoft 365 Support Specialist
- Microsoft Entra ID Administrator
- Identity and Access Management Analyst
- Cloud Support Specialist
- Junior Systems Administrator
- Security Support Analyst
The project emphasizes not only configuration, but also testing, validation, troubleshooting, monitoring, security analysis, and technical documentation.
Complete
The lab includes configured identity-security controls, validation testing, screenshots, detailed documentation, and troubleshooting evidence.