AZ-104 Labs
Curriculum Mapping
This project combines and extends the concepts from the official Microsoft Learning labs. It transforms the isolated tasks into a cohesive, production-ready solution.
Lab 01: Manage Entra ID Identities
Lab 02a: Subscriptions & RBAC
---
## 🏢 The Business Scenario
**Client:** FinCore Systems (FinTech)
**The Problem:** The "Help Desk" team has too much power. They currently have **Contributor** access, which allows them to delete production databases.
**The Requirement:** We need a custom security role that allows them to:
- ✅ **Restart Virtual Machines** (to fix issues).
- ✅ **Open Support Tickets** (to get help).
- ❌ **Strictly Block** them from creating new resources or registering expensive service providers (Shadow IT).
---
## 🏗️ The Architecture
Instead of assigning permissions to individuals (which is unscalable), we will build a hierarchy:
1. **Identity:** Users are assigned to an Entra ID Group (`grp-fincore-support`).
2. **Scope:** We create a Management Group (`mg-fincore-corp`) to govern all subscriptions.
3. **Permissions:** We attach a Custom RBAC Role to the Management Group, which trickles down to everything below it.
Never trust, always verify. Permissions are explicitly granted, never assumed. Every action requires validation.
---
## 🚀 Step-by-Step Implementation
### Phase 1: Identity Management (Entra ID)
First, we need to create the "Who." We **never** assign roles to users directly; we assign them to groups.
#### 1. Create the Security Group
I started by creating a dedicated security group for the support team. This ensures that if we hire 50 new engineers, we just add them to this group, and they inherit the permissions automatically.
- **Group Name:** `grp-fincore-support`
- **Type:** Security
Management Groups allow you to apply governance at scale. Instead of assigning a role to 50 individual subscriptions, you assign it once at the Management Group level, and it automatically cascades down to all child subscriptions and resources.
---
### Phase 3: The "Least Privilege" Custom Role
This is the core of the project. The built-in **"Support Request Contributor"** role was too weak (can't restart VMs), but **"Virtual Machine Contributor"** was too dangerous (can delete VMs).
I created a **Custom Role** by cloning the Support role and modifying it.
#### 1. Adding Permissions (The "Allow" List)
We need to create a role that specifically allows VM restart but denies everything else initially.
I explicitly added `Microsoft.Compute/virtualMachines/restart/action`. This gives Alex the power to reboot a frozen server without giving him the power to delete it.
#### 2. Blocking Shadow IT (The "NotAction" List)
To prevent the Help Desk from accidentally enabling expensive services (like AI or Blockchain), I added `Microsoft.Support/register/action` to the **NotActions** list. This effectively "denies" the ability to register new resource providers.
{
"properties": {
"roleName": "FinCore Support Specialist",
"description": "Can open tickets and restart VMs. Cannot register new providers.",
"assignableScopes": [
"/providers/Microsoft.Management/managementGroups/mg-fincore-corp"
],
"permissions": [
{
"actions": [
"Microsoft.Authorization/*/read",
"Microsoft.Resources/subscriptions/resourceGroups/read",
"Microsoft.Support/*",
"Microsoft.Compute/virtualMachines/restart/action"
],
"notActions": [
"Microsoft.Support/register/action"
],
"dataActions": [],
"notDataActions": []
}
]
}
}
There are three critical components to this configuration:
1. **AssignableScopes**: The role is scoped to `/mg-fincore-corp`. This means it *cannot* be assigned at the Root Management Group (too broad) or a single Subscription (too narrow). It exists exactly where FinCore operates.
2. **Actions**: We explicitly grant `Microsoft.Support/*` for ticketing and the *specific* `restart/action` for VMs. This avoids the dangerous `write` or `delete` permissions found in standard Contributor roles.
3. **NotActions**: This acts as a safety filter. Even if another policy or role tries to grant "Support" access, this role explicitly carves out the ability to `register` new resource providers, preventing accidental cost spikes from "Shadow IT" service headers.
---
### Phase 4: Assigning the Role
With the role created, we now assign it to our security group at the Management Group scope. This ensures that the permissions trickle down to all subscriptions and resources within our organization.
---
### Phase 5: The "Hacker" Verification
A security architecture is only good if it works. I logged in as **Alex** (using an Incognito window) to test the boundaries.
#### Test 1: VM Operations (The "Least Privilege" Test)
First, I attempted to **Restart** a Virtual Machine. Since this action was explicitly allowed in our custom role, it should work.
**Success!** The command executed without issues.
Next, I attempted to **Delete** the same VM. Since this action was NOT in our custom role (and `Delete` is a destructive action), it should be blocked.
**Blocked!** Azure's ARM layer correctly prevented the action.
#### Test 2: Support Operations
I attempted to open a **Support Ticket**. The custom role successfully allowed access to the support blade.
