Entra ID Overview: The Identity Foundation
Master Microsoft's cloud identity service — the foundation for all Azure access control
🟢 Beginner
⏱ 15 Minutes
📘 AZ-104 · Module 01
Why This Matters
Before you can grant any Azure permission, you need identities to grant them to. Microsoft Entra ID is Azure's identity service — it's how you manage who your users are, organize them into groups, and control who gets licenses. Every single RBAC role assignment starts here. Without understanding Entra ID, you can't understand identity governance.
Before You Start
| Prerequisites | 00-Prerequisites: Identity & Access Fundamentals |
|---|
| Time to understand | 15 minutes |
|---|
| Difficulty | 🟢 Beginner (foundational, no identity experience needed) |
|---|
| What you'll learn | What Entra ID is, core identity objects, how groups work, administrative units |
|---|
The Simple Idea
What Is Entra ID?
Entra ID = Microsoft's cloud identity service where you manage:
- Who your users are
- What groups they belong to
- What licenses they have
- What roles can manage them
Think of it like HR records for cloud applications — it's the central registry of all identities in your organization.
Real-World Analogy: Company Directory
Entra ID is the single source of truth for identity in your Azure organization. Just like HR is the authoritative record of every employee, team, and permission level inside a company, Entra ID is the authoritative record of every user, group, and access level inside your tenant.
Company (Your Organization)
│
├── HR Department (Entra ID)
│ ├── Database: All employees (Users)
│ ├── Teams: Sales team, Dev team, Finance (Groups)
│ ├── Permissions: "Who reports to whom" (Administrative Units)
│ └── Licenses: "Who gets Office 365?" (Group-based licensing)
│
└── Finance Department (Azure Services)
└── Uses Entra ID to know "who is John?"
and "what permissions does he have?"
What's a Tenant?
A tenant is your organization's dedicated, isolated instance of Entra ID.
Each company is completely isolated. Users in TechCorp can't see AnotherCompany's data.
Microsoft Entra ID (the service)
├── TechCorp Tenant (company A)
│ ├── Users: sara@techcorp.com, mike@techcorp.com
│ └── Groups: Sales Team, Dev Team
├── AnotherCompany Tenant (company B)
│ ├── Users: john@anothercompany.com
│ └── Groups: Different teams
└── YetAnotherCompany Tenant (company C)
└── Completely isolated from A and B
Key Identity Objects
| Object | What It Is | Example | Why It Matters |
|---|
| User | Individual identity that can sign in | sara@company.com | RBAC role assigned to individuals |
| Group | Collection of users | grp-sales (50 people) | Assign permissions to many at once |
| Admin Unit | Scoped container for delegation | au-sales (Sales dept only) | Delegate admin over subset (not all users) |
| App Registration | Identity for applications/services | myapp-service | Apps authenticate to Azure securely |
| Tenant | Your org's isolated Entra instance | contoso.onmicrosoft.com | Isolation boundary |
How It Actually Works
The Critical Distinction: Groups Tell WHO, Admin Units Tell WHERE
This is the most commonly misunderstood part of Entra ID. Groups and Admin Units sound similar, but they serve completely different purposes.
Groups = "This is a manager key" ← Defines WHO someone is
- Sara is a member of grp-salesadmins (she's a sales admin)
- Groups identify identity and enable role assignment
- Groups do NOT limit scope
Admin Units = "But it only unlocks the Sales department door" ← Defines WHERE they can use their power
- John's admin role is scoped to au-sales (he can only manage Sales users)
- Admin Units limit the scope of delegated power
- Without an Admin Unit, power extends tenant-wide
Real Example: Why This Matters
WITHOUT Admin Unit
John is in grp-salesadmins
← (identifies him as sales admin)
John gets "User Administrator" role
← (gives him power)
Result: John can reset passwords
for ANYONE in the company ✗
Too dangerous
WITH Admin Unit
John is in grp-salesadmins
← (still identifies him as sales admin)
John gets "User Administrator" role
SCOPED to au-sales
← (gives power, but limited)
Result: John can reset passwords
ONLY for Sales users ✓
Safe and limited
Think of it like security badges at a building:
- Group = Which department you work for (identifies you)
- Admin Unit = Which floors your badge opens (limits your access)
Without an Admin Unit, John has a master key to ALL floors. With an Admin Unit, his key only opens the Sales floor.
Step 1: Create a User
Admin creates user: sara@company.com
↓
Entra ID now knows:
"Sara is a person in our organization"
Step 2: Add User to Groups
Sara joins groups:
├── grp-sales (all sales people)
├── grp-salesadmins (sales team leads)
└── grp-microsoft365 (Office 365 users)
Result: Sara inherits permissions
from each group
Step 3: Assign Licenses to Groups
License assignment:
Office 365 → grp-microsoft365
↓
Sara (member of grp-microsoft365)
automatically gets Office 365 ✓
Mike (also in the group)
automatically gets it ✓
Step 4: Create Admin Scope (Administrative Units)
Admin creates: au-sales
(Sales department scope)
│
├── Members: Everyone in Sales department
│
└── Purpose: "Sales team lead can reset
passwords, but ONLY for Sales dept"
Step 5: Delegate Admin Role (Scoped)
Assign role: User Administrator
To: John (Sales team lead)
Scoped to: au-sales (Sales dept only)
Result:
├── John can reset passwords → ONLY for Sales users ✓
├── John CANNOT reset passwords → for Finance users ✗
├── John CANNOT add users → to other departments ✗
└── Delegation achieved without tenant-wide admin access ✓
Mental Model: Entra ID as Organization Chart + HR System
CEO (Global Administrator — can do anything)
│
├─ VP Sales (User Administrator for Sales unit)
│ └─ Can manage Sales users only
│ └─ Cannot see Finance users
│
├─ VP Finance (User Administrator for Finance unit)
│ └─ Can manage Finance users only
│ └─ Cannot see Sales users
│
└─ VP IT (Global Admin)
└─ Can manage all users and settings
Each VP has power only in their area (scoped), yet all use the same Entra ID tenant.
Worked Example: Real Scenario
The Scenario
Contoso has 100 employees:
- Sales: 50 people
- Finance: 30 people
- IT: 20 people
Goal: Manage identities efficiently, delegate admin duties, assign licenses automatically.
Solution Using Groups + Admin Units
Step 1: Create Groups
Group: grp-sales
├── Members: All Sales employees (50 people)
└── Membership: Dynamic rule — "department eq Sales"
Group: grp-finance
├── Members: All Finance employees (30 people)
└── Membership: Dynamic rule — "department eq Finance"
Group: grp-allemployees-office365
├── Members: Everyone (100 people)
└── Membership: Dynamic rule — "user.accountEnabled eq true"
Step 2: Assign Licenses to Groups
Office 365 license → grp-allemployees-office365
└─ All 100 employees automatically
get Office 365 ✓
Teams license → grp-sales + grp-finance
└─ 80 employees automatically
get Teams ✓
Step 3: Create Administrative Units
Admin Unit: au-sales
├── Members: Everyone in Sales department
└── Purpose: Scope admin roles to Sales only
Admin Unit: au-finance
├── Members: Everyone in Finance department
└── Purpose: Scope admin roles to Finance only
Step 4: Delegate Admin Roles
Assignment 1:
Role: User Administrator
Person: Sarah (Sales team lead)
Scope: au-sales
Result: Sarah can reset passwords for Sales only ✓
Assignment 2:
Role: User Administrator
Person: Bob (Finance team lead)
Scope: au-finance
Result: Bob can reset passwords for Finance only ✓
Assignment 3:
Role: Global Administrator
Person: Alice (IT director)
Scope: Tenant-wide
Result: Alice can do anything, manage all departments ✓
Benefit
When new Sales employee joins:
└─ HR enters their info
└─ Dynamic group rule matches them to grp-sales
└─ Automatically added to grp-allemployees-office365
└─ Automatically gets Office 365 + Teams licenses
└─ Falls under Sarah's admin scope (au-sales)
└─ Sarah can manage their password without IT intervention
└─ ZERO manual steps! ✓
Common Mistakes (What NOT to Do)
❌ Mistake 1: Confusing Entra Roles with Azure RBAC
Wrong
Admin is Global Administrator in Entra ID
├─ Can create users, reset passwords, manage licenses
├─ Makes them THINK they can delete Azure resources
└─ They can't! (Completely different permission system) ✗
Fix
Understand they're separate:
├─ Global Administrator (Entra) ≠ Owner (Azure RBAC)
├─ User Administrator (Entra) ≠ Contributor (Azure RBAC)
└─ To manage both, you need roles in BOTH systems
Why it fails: Two separate permission systems — Entra Roles manage identities, while Azure RBAC manages Azure services/resources.
❌ Mistake 2: Using Assigned Groups for Dynamic Needs
Wrong
Create group: grp-salesreps
├─ Manually add 50 people
├─ When someone new joins Sales → admin must
│ manually add them
├─ When someone leaves → admin must
│ manually remove them
└─ Result: Manual overhead, human error ✗
Fix
Use dynamic groups:
└─ grp-salesreps
├─ Membership rule: "department eq Sales"
├─ When new Sales employee joins
│ → automatically added ✓
├─ When they leave Sales
│ → automatically removed ✓
└─ Zero manual work ✓
Why it fails: Doesn't scale. Manual processes are error-prone.
⚠️ Watch Out
Dynamic groups require Entra ID P1/P2 licensing!
❌ Mistake 3: Assigning Licenses Individually
Wrong
Admin assigns Office 365 license to:
├─ User 1 (manually)
├─ User 2 (manually)
├─ User 3 (manually)
└─ ... (50 more times, error-prone, tedious) ✗
Fix
Use group-based licensing:
└─ Create grp-office365-users (dynamic group)
└─ Assign Office 365 to the GROUP
└─ All members automatically get license ✓
└─ New members get it automatically ✓
Why it fails: Doesn't scale. Easy to forget someone.
How This Connects to Other Topics
Related to Module 01 (Identity & Governance)
- Entra ID = Create identities (users, groups)
- RBAC = Grant permissions TO those identities
- Management Groups & Policy = Enforce policies across subscriptions that Entra users access
Related to Module 02, 03, 04, 05
- All modules rely on Entra ID identities
- Every RBAC role assignment requires an Entra identity
- Every Azure access is authenticated through Entra ID
Key Takeaways
💡 Summary
- Entra ID = cloud identity system (who your users are)
- Tenant = isolated org instance (separate from other companies)
- Users are individual identities
- Groups are collections (use for permissions and licenses)
- Dynamic groups auto-add/remove members (requires P1/P2)
- Group-based licensing = auto-license thousands
- Admin Units scope admin roles (VP of Sales manages only Sales)
- Entra roles ≠ Azure RBAC (different systems, both needed)
- Delegation = admin scope (let managers handle their own people)