Enterprise IAM implementation demonstrating identity lifecycle automation, least privilege, passwordless authentication, and Conditional Access.
This project demonstrates the design and implementation of a Microsoft Entra ID identity and access management environment based on Zero Trust principles.
The lab simulates a real-world enterprise IAM environment where identities are organized through dynamic group membership, administrative access is delegated using role-based access control (RBAC) and Administrative Units, strong authentication methods are deployed, and Conditional Access policies are used to protect organizational resources.
- Built a Microsoft Entra ID Zero Trust lab simulating workforce, contractor, helpdesk, and privileged identities
- Automated access using attribute-based dynamic security groups and validated Mover lifecycle behavior
- Implemented least-privilege administration using Administrative Units and scoped Entra role assignments
- Deployed Temporary Access Pass (TAP) and passkeys to demonstrate secure credential bootstrap and passwordless authentication
- Designed four Conditional Access policies covering MFA, privileged identities, legacy authentication, and phishing-resistant MFA
- Established a dedicated emergency access Global Administrator with targeted Conditional Access exclusion
- Tested Conditional Access using What If analysis, Report-only mode, interactive sign-ins, and Entra sign-in logs
- Validated successful phishing-resistant authentication against an Authentication Strength policy
- Microsoft Entra ID
- Conditional Access
- Role-Based Access Control (RBAC)
- Administrative Units
- Dynamic Security Groups
- Microsoft Authenticator
- Temporary Access Pass (TAP)
- Passkeys / Passwordless Authentication
- Authentication Strengths
- Phishing-Resistant MFA
- Microsoft Entra Sign-in Logs
- Conditional Access What If
This lab simulates an organization using Microsoft Entra ID as its cloud identity and access management platform. The environment contains multiple departments, geographic locations, contractors, standard workforce users, helpdesk administrators, and privileged administrators.
The objective was to implement a Zero Trust identity architecture that provides users with the access they require while reducing unnecessary administrative privilege and strengthening authentication for sensitive accounts.
| Component | Implementation |
|---|---|
| Identity Platform | Microsoft Entra ID |
| Identity Types | Workforce, contractors, helpdesk administrators, privileged administrators |
| Access Model | Dynamic groups + RBAC + Administrative Units |
| Administrative Model | Scoped Helpdesk Administrator and User Administrator roles |
| Authentication | Microsoft Authenticator, Temporary Access Pass, Passkeys |
| Privileged Authentication | Phishing-resistant authentication strength |
| Access Enforcement | Microsoft Entra Conditional Access |
| Recovery | Dedicated emergency access Global Administrator |
| Validation | What If analysis, Report-only evaluation, sign-in logs, authentication details |
The environment was designed around the following identity and access model:
- Workforce identities organized using user attributes and security groups
- Dynamic group membership to automate access based on identity attributes
- Administrative Units (AUs) to establish administrative boundaries
- Scoped administrative roles to limit helpdesk and user administration privileges
- Emergency access account for tenant recovery and administrative resiliency
- Temporary Access Pass (TAP) for secure authentication bootstrap
- Passkeys for phishing-resistant passwordless authentication
- Conditional Access to enforce identity-based security controls
- Sign-in logs and What If analysis to validate policy behavior before enforcement
The implementation applies core Zero Trust principles by explicitly verifying access requests, enforcing least-privilege access, and strengthening authentication for privileged identities.
Rather than relying only on passwords or broad administrative privileges, access decisions are based on identity, assigned role, authentication strength, resource access, and organizational scope.
The first phase established the identity foundation for the environment. User identities were created with organizational attributes such as department, location, and employment type so that access could be managed using identity data rather than relying entirely on manual group assignments.
Dynamic security groups were configured to automatically assign users to the appropriate access groups based on their Entra ID attributes.
Examples included:
- Finance users automatically assigned to the Finance security group
- Contractors dynamically grouped based on employment attributes
- Membership automatically recalculated when identity attributes changed
This creates a scalable identity model where access follows the user's organizational identity.
A simulated employee transfer was performed to validate dynamic access behavior.
When the user's department attribute changed:
- The user was removed from the previous department's dynamic group.
- The user was automatically added to the new department's dynamic group.
- Access tied to the previous dynamic membership was removed.
- Access tied to manually assigned groups remained intact.
This demonstrated the difference between attribute-driven access and explicitly assigned access, an important consideration when designing automated identity lifecycle processes.
The next phase focused on reducing administrative privilege by implementing delegated administration using Microsoft Entra Administrative Units and role-based access control (RBAC).
Rather than granting administrators tenant-wide permissions, administrative boundaries were created so delegated administrators could manage only the users within their assigned organizational scope.
Administrative Units were created to represent different organizational boundaries, including:
- Atlanta
- New York
- Contractors
Users were placed into the appropriate Administrative Units, creating defined scopes for delegated administration.
Administrative roles were then assigned at the Administrative Unit level.
Examples included:
- Atlanta Helpdesk Administrator – Helpdesk Administrator scoped to the Atlanta Administrative Unit
- New York Helpdesk Administrator – Helpdesk Administrator scoped to the New York Administrative Unit
- Contractor Administrator – User Administrator scoped to contractor identities
This design follows the principle of least privilege by limiting administrative authority to the identities an administrator is responsible for managing.
The delegated administration model was tested to verify that administrative permissions respected the configured boundaries.
An Atlanta-scoped administrator was able to interact with an identity located within the Atlanta Administrative Unit while an identity outside of that administrative scope remained outside the administrator's delegated authority.
This demonstrates how Administrative Units can reduce the blast radius associated with privileged accounts and prevent unnecessary tenant-wide administrative access.
The third phase strengthened authentication by moving beyond traditional password-based access and implementing modern authentication methods within Microsoft Entra ID.
Authentication methods were configured to support:
- Microsoft Authenticator
- Temporary Access Pass (TAP)
- Passkeys
- Passwordless authentication
- Phishing-resistant authentication
Temporary Access Pass was configured as a secure bootstrap mechanism for registering strong authentication credentials.
A TAP was generated for the test identity and used during the authentication registration process. This allowed the user to establish a strong authentication method without relying solely on an existing password.
Using the Temporary Access Pass bootstrap process, a passkey was successfully registered for the test identity.
The passkey provides phishing-resistant authentication using public-key cryptography rather than a reusable password or traditional MFA code.
The registered passkey was then used to perform a passwordless authentication test.
Successful authentication demonstrated that the identity could access Microsoft resources using a phishing-resistant credential without entering the account password.
The final implementation phase focused on protecting identities and cloud resources using Microsoft Entra Conditional Access.
Rather than immediately enforcing new controls, policies were deployed in Report-only mode first. This allowed policy behavior and potential user impact to be evaluated before enforcement, reducing the risk of accidental lockouts or business disruption.
Four Conditional Access policies were implemented:
| Policy | Purpose |
|---|---|
| CA01 – Require MFA for All Users | Establish a baseline MFA requirement for workforce identities |
| CA02 – Require MFA for Administrative Roles | Apply stronger access requirements to privileged identities |
| CA03 – Block Legacy Authentication | Prevent access using legacy authentication methods that cannot satisfy modern security controls |
| CA04 – Require Phishing-Resistant MFA for Administrative Roles | Require privileged identities to use phishing-resistant authentication |
CA04 was configured using an Authentication Strength requiring phishing-resistant MFA.
This provides stronger protection for privileged identities than traditional MFA methods by requiring authentication methods designed to resist credential phishing attacks.
An emergency access account was configured with the Global Administrator role and excluded from the phishing-resistant Conditional Access policy.
This provides a recovery path if normal administrative identities become inaccessible because of authentication or Conditional Access configuration issues.
The exclusion was deliberately limited to the designated emergency access identity rather than broadly bypassing privileged users.
Conditional Access behavior was validated using:
- Report-only deployment
- Conditional Access What If analysis
- Interactive test sign-ins
- Entra sign-in logs
- Authentication details
- Report-only policy results
Testing initially identified a role-scoping condition that prevented CA04 from applying to the intended test identity. After validating and correcting the administrative role assignment, the policy was evaluated again.
The final sign-in evaluation showed:
CA04 – Require Phishing-Resistant MFA for Administrative Roles → Report-only: Success
This confirmed that the privileged identity matched the policy and that its registered passkey satisfied the required phishing-resistant authentication strength.
This project demonstrates an identity-first Zero Trust architecture built around the principle of never trust, always verify.
The implemented controls produced the following security outcomes:
- Automated identity access using dynamic group membership
- Demonstrated automated Mover lifecycle behavior through identity attribute changes
- Reduced administrative blast radius through scoped role assignments
- Segmented administrative responsibility using Administrative Units
- Established modern authentication methods including Microsoft Authenticator and passkeys
- Implemented phishing-resistant authentication for privileged identities
- Reduced exposure to credential-based attacks by blocking legacy authentication
- Established an emergency access path with a dedicated Global Administrator account and targeted Conditional Access exclusion
- Evaluated Conditional Access policies in Report-only mode before enforcement
- Validated access decisions using What If analysis and Entra sign-in logs
Microsoft Entra ID
- Identity and user administration
- Group-based access management
- Dynamic membership rules
- Administrative Units
- Microsoft Entra roles
Authentication & Identity Security
- Microsoft Authenticator
- Temporary Access Pass (TAP)
- Passkeys
- Passwordless authentication
- Authentication strengths
- Phishing-resistant MFA
Conditional Access
- User and role targeting
- MFA enforcement
- Administrative role protection
- Legacy authentication blocking
- Emergency access exclusions
- Report-only deployments
- What If analysis
- Sign-in log validation
Zero Trust
- Identity-centric access control
- Least privilege
- Strong authentication
- Privileged identity protection
- Policy validation before enforcement
- Break-glass / emergency access design
This lab evolved from basic Microsoft Entra identity administration into a layered Zero Trust identity security implementation.
The environment demonstrates how identity lifecycle management, scoped administration, passwordless authentication, privileged access controls, and Conditional Access can work together to reduce identity-based risk.
Rather than treating configuration as the final step, each major control was tested and validated using Microsoft Entra reporting, authentication details, sign-in logs, and Conditional Access evaluation tools.
The result is a practical demonstration of skills directly applicable to Identity and Access Management (IAM), Microsoft Entra ID administration, Zero Trust security, and cloud identity engineering.






















