# AZ-104 Project 1: Azure Identity & Access Management (RBAC + MFA)

This project is part of my hands-on preparation for the Microsoft AZ-104 (Azure Administrator) certification. The objective was to design, implement, and validate a secure Azure identity and access model using Microsoft Entra ID, Azure RBAC, and multi-factor authentication (MFA).

## Overview

Identity is the foundation of security in Azure. Before deploying workloads, organizations must define who can access resources, what actions they are allowed to perform, and how access is protected.

In this project, I implemented a secure identity and access model using Microsoft Entra ID and Azure Role-Based Access Control (RBAC). The focus was on **least-privilege access**, **role separation**, and **MFA enforcement** — core responsibilities of an Azure Administrator in real production environments.

This project aligns directly with **AZ-104 exam objectives** and reflects real-world Azure administration practices.

## Business Problem

Organizations must answer three critical questions before creating any resources in Azure:

1. Who should be able to access Azure resources?
    
2. What level of access does each role require?
    
3. How is access protected if credentials are compromised?
    

Without proper role separation and MFA enforcement, cloud environments are exposed to misconfiguration, unauthorized changes, and security incidents.

## Architecture Overview

This project uses Microsoft Entra ID for identity management and Azure RBAC for authorization.

**Access model:**

* Azure administrators manage resources
    
* Helpdesk users have read-only visibility
    
* MFA is required before Azure access is granted
    

**Core components:**

* Microsoft Entra ID users and security groups
    
* Azure RBAC at subscription and resource group scopes
    
* Microsoft Entra Security Defaults for MFA enforcement
    
* Audit and sign-in logs for validation
    

**The diagram below illustrates the identity authentication and authorization flow implemented in this project.**

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1766788027726/8e6ec265-21d8-4bec-86a4-e904ceb08608.png align="center")

## Identity & RBAC Design

### Users and Groups

The following users were created for validation:

* **cloudadmin.lab** – Azure administrator account
    
* **helpdesk.lab** – Helpdesk / support user
    
* **breakglass.lab** – Emergency access account
    

Access was assigned using **security groups** instead of individual users to reflect enterprise best practices:

* **Azure-Admins**
    
* **Helpdesk-Ops**
    

Group-based RBAC simplifies permission management and scales effectively as environments grow.

### Role Assignments

Azure RBAC roles were assigned as follows:

| Group | Role | Scope |
| --- | --- | --- |
| Azure-Admins | Contributor | Subscription |
| Helpdesk-Ops | Reader | Resource Group |

**Why Contributor instead of Owner?**  
Contributor enables full resource management without allowing role assignment changes, reducing the risk of privilege escalation.

**Why Reader for Helpdesk?**  
Helpdesk users can view resources and assist with troubleshooting while being prevented from making configuration changes.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1766788240498/a8a1ab33-5abb-4056-9cb8-cfb20839474f.png align="center")

## MFA Enforcement

Custom Conditional Access policies require Microsoft Entra ID Premium licensing. Since this tenant did not include that license, **Microsoft Entra Security Defaults** were enabled instead.

Security Defaults enforce:

* Mandatory MFA for users and administrators
    
* Blocking of legacy authentication protocols
    
* Microsoft-managed Conditional Access policies
    

MFA enforcement was validated when **helpdesk.lab** was required to register an MFA method before accessing the Azure portal.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1766788309126/4d148719-d01d-4956-98fd-7fd9ad0e5631.png align="center")

## Validation & Testing

### RBAC Validation

To confirm least-privilege access enforcement:

* The **helpdesk.lab** account attempted to create an Azure resource
    
* Azure denied the action due to insufficient permissions
    

This validated that the Reader role was correctly enforced at the resource group scope.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1766788470922/c4fd4b3d-0b70-45d8-a9dc-991d6e2778e3.png align="center")

## Logging & Auditability

Audit logs confirmed:

* Group membership changes
    
* RBAC role assignments
    
* Security configuration updates
    

Sign-in logs may experience brief propagation delays in smaller tenants; however, MFA enforcement was verified through mandatory MFA registration and successful authenticated access.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1766792520416/c59d1e6a-7d38-47cb-96d8-bc9ccf229bb3.png align="center")

## Key Takeaways

* Identity is the primary security perimeter in Azure
    
* Group-based RBAC enables scalable access control
    
* Least-privilege access reduces security and operational risk
    
* MFA enforcement is essential, even in small environments
    
* Azure identity controls behave consistently across lab and production environments
    

## Skills Demonstrated

* Microsoft Entra ID administration
    
* Azure RBAC design and validation
    
* Least-privilege access modeling
    
* MFA enforcement using Security Defaults
    
* Azure identity and access troubleshooting
    

## Final Thoughts

This project demonstrates how Azure identity and access controls are designed, implemented, and validated in real environments. The focus on security, governance, and verification reflects the expectations of an Azure Administrator role rather than a theoretical exercise.