2.1 Microsoft Entra ID Security, Users, and Groups

2.1 Microsoft Entra ID Security, Users, and Groups

Microsoft Entra ID (formerly Azure Active Directory) is Microsoft's cloud-based identity and access management service. In a modern cloud environment, identity forms the primary security perimeter under the Zero Trust model ("Never Trust, Always Verify"). Unlike legacy Active Directory Domain Services (AD DS), which relies on Kerberos, NTLM, and LDAP over hierarchical Organizational Units (OUs), Microsoft Entra ID is built on RESTful APIs and modern cloud standards including OpenID Connect (OIDC), OAuth 2.0, and SAML 2.0.

Entra ID Fundamentals & Tenant Isolation

An Entra ID tenant represents a dedicated, isolated instance of the directory service created when an organization provisions a Microsoft cloud service (such as Microsoft Azure or Microsoft 365). Tenant boundaries enforce strict identity isolation:

• Directory Objects: User Principals, Security Groups, Service Principals, Managed Identities, and Registered Devices exist exclusively within their home tenant scope.
• Authentication Boundary: Tokens issued by a tenant are valid only for resources that trust that specific directory instance, unless explicit B2B (Business-to-Business) cross-tenant collaboration or multi-tenant app registration is configured.
• Flat Structure: Entra ID lacks traditional AD DS forest/domain trusts and OU trees. Administrative hierarchy must be implemented using Administrative Units, custom Azure RBAC roles, and scoping policies.

---

Administrative Units (AUs) for Scoped Management

In large enterprise environments, granting tenant-wide directory roles (such as User Administrator or Helpdesk Administrator) violates the principle of least privilege. If a regional helpdesk technician possesses the tenant-wide User Administrator role, they can reset passwords for executive officers or global administrators.

Administrative Units (AUs) solve this operational challenge by creating scoped administrative boundaries inside a single Entra ID tenant. An AU is a directory container that holds specific users, groups, or devices.

+-------------------------------------------------------------------------+
|                        Microsoft Entra ID Tenant                        |
|                                                                         |
|  +-----------------------------------+  +----------------------------+  |
|  |   European Operations AU          |  |  US Sales AU               |  |
|  |                                   |  |                            |  |
|  | - EU User Accounts                |  | - US User Accounts         |  |
|  | - EU Shared Workstations          |  | - US Sales Devices         |  |
|  +-----------------------------------+  +----------------------------+  |
|                    ^                                                    |
|                    | (Scoped Role Assignment)                           |
|        [EU Helpdesk Admin User]                                         |
+-------------------------------------------------------------------------+

AU Membership & Scoping Rules

1. Scoped Role Assignment: Administrators assign directory roles scoped to an AU rather than the entire tenant. A user assigned Helpdesk Administrator on the "European Operations AU" can reset passwords and modify attributes only for objects inside that AU.
2. Static vs. Dynamic Membership: Objects can be added to an AU manually (static) or automatically using dynamic membership rules based on user/device attributes (e.g., user.country -eq "Germany").
3. Key Architectural Constraints (AZ-500 Exam Notes):
   • AUs cannot be nested; an AU cannot contain another AU.
   • Assigning a role to an AU grants permissions only over direct member objects within that AU. It does not grant permissions over the AU container object itself unless container roles are explicitly assigned.
   • Dynamic AUs use the exact same OData evaluation engine as Dynamic Groups.

---

Security Groups vs. Microsoft 365 Groups

Entra ID supports two main group types designed for distinct operational security controls:

---

Dynamic User and Device Groups (Syntax Rules)

Dynamic groups automatically manage group membership by evaluating object attributes against defined rules. When a user's department changes from "Sales" to "Engineering", Entra ID automatically removes the user from the Sales group and adds them to the Engineering group without manual IT intervention.

OData Rule Expression Structure

A dynamic membership rule consists of three parts: Property, Operator, and Value.

Syntax: (object.property -operator "Value")

Supported Operators

• Binary Operators: -eq (equals), -ne (not equals), -contains (substring match), -notContains, -startsWith, -notStartsWith, -match (regex match), -notMatch.
• Set Operators: -in (matches any element in an array set), -notIn.
• Logical Operators: -and, -or, -not.

Dynamic Group Membership Rules Breakdown

Syntax Rules & Pitfalls for AZ-500 Engineers

1. Quotes: String values must be enclosed in double quotes "..." (e.g., user.department -eq "Finance").
2. Case Sensitivity: Operator syntax (e.g., -eq, -and) is case-insensitive, but object property names (e.g., user.department) are strict.
3. No Group Nesting: Dynamic rules evaluate individual user or device attributes only. A dynamic group cannot evaluate membership based on another group's membership.
4. Null Keywords: The null keyword is unquoted. Writing -ne "null" checks for the literal string "null" rather than missing data.

---

License Assignment and Compliance

Directly assigning licenses to individual user accounts introduces compliance drift and manual overhead. Group-Based Licensing resolves this by attaching license SKUs (such as Microsoft Entra ID P2 or Enterprise Mobility + Security E5) directly to a Security Group.

• Automated Lifecycle: Adding a user to the group automatically provisions all selected license plan options. Removing the user revokes the license.
• License Processing Errors: If a tenant runs out of available license seats or experiences conflicting service plans (e.g., duplicate Exchange Online plans), the user enters a License Error state. Engineers must resolve errors in the Entra Admin Center by expanding license seat counts or resolving plan conflicts.
• Feature Requirements: Features such as Entra ID Protection, PIM, and Risk-Based Conditional Access require Microsoft Entra ID P2 licenses. Standard Conditional Access and SSPR with Password Writeback require Microsoft Entra ID P1.

---

Password Protection & Smart Lockout

Traditional complexity requirements (uppercase, lowercase, digits, special characters) fail to stop modern credential attacks because users choose predictable patterns (e.g., Spring2026!). Microsoft Entra Password Protection enforces defense against weak passwords across cloud and hybrid environments.

[ User Enters New Password ]
          |
          v
[ Global Banned Password List ] ----(Match?)----> [ REJECT: Common Password ]
          |
       (No Match)
          v
[ Custom Banned Password List ] ----(Match?)----> [ REJECT: Org Terms / Leetspeak ]
          |
       (No Match)
          v
[ Password Accepted & Hashed ]

Global and Custom Banned Password Lists

• Global Banned Password List: Maintained automatically by Microsoft threat intelligence, dynamically blocking millions of known weak passwords and variations.
• Custom Banned Password List: Allows administrators to specify up to 10,000 organization-specific terms (e.g., company names, local landmarks, product lines). The engine applies fuzzy matching—automatically normalizing leetspeak substitutions (@ for a, 0 for o, $ for s), casing, and substrings. Adding Contoso automatically blocks C0nt0s02026!.

Smart Lockout Thresholds

Traditional Active Directory lockouts lock account access globally across all IP addresses after N failed attempts, creating an easy vector for malicious denial-of-service (DoS) attacks. Smart Lockout separates legitimate user authentications from attacker attempts:

• It tracks failed sign-in attempts by combining IP address context and authentication signatures.
• When threshold limits are breached (default: 10 failed attempts), Smart Lockout locks out only the attacker's originating IP address, allowing the legitimate user to continue signing in from their familiar location.
• Azure AD Password Protection Agent: Installs on on-premises Domain Controllers to evaluate password changes against cloud global and custom banned lists before writing to Active Directory.

---

Entra ID Protection Risk Detection Policies

Microsoft Entra ID Protection analyzes trillions of signals daily using machine learning to detect identity compromise. Risk detections are separated into two distinct risk classifications:

Risk Policy Enforcement Levels

Policies can be set to trigger on Low and above, Medium and above, or High risk levels. Setting a User Risk Policy to High requiring a secure password reset automatically revokes existing refresh tokens, forcing the user to verify via MFA and create a new password to clear the risk state.