Azure Identity and Entra ID: Users, Groups, RBAC, and Conditional Access for AZ-104

Introduction

Microsoft Entra ID (formerly Azure Active Directory) is the cornerstone of identity management in Azure. For the AZ-104 exam, you must understand how Entra ID handles authentication, authorization, and access control. This post covers the core concepts: users and groups, role-based access control (RBAC), and Conditional Access policies. We'll focus on practical examples and exam-relevant details.

Users and Groups in Entra ID

Entra ID supports two types of identities: users (representing people or service principals) and groups (for managing multiple users). Groups can be security groups (for permissions) or Microsoft 365 groups (for collaboration). When assigning permissions, it's best practice to add users to groups and assign RBAC roles to those groups.

Creating Users and Groups

• Users: Created via the Azure portal, Microsoft 365 admin center, or PowerShell. Each user has a User Principal Name (UPN) like user@domain.onmicrosoft.com.
• Groups: Can be assigned (static membership) or dynamic (membership based on rules, e.g., department = "IT"). Dynamic groups require an Azure AD Premium P1 license.

Exam Tip: Know that dynamic groups are evaluated periodically, not in real time. Changes to user attributes may take up to 24 hours to reflect.

Authentication vs. Authorization

• Authentication (AuthN): Proves identity. Entra ID supports protocols like OAuth 2.0, OpenID Connect, SAML, and WS-Federation. For example, when a user signs in to the Azure portal, Entra ID validates their credentials.
• Authorization (AuthZ): Determines what an authenticated user can do. In Azure, authorization is handled by RBAC (role-based access control) and Azure Policy.

Example: A user authenticates via OAuth 2.0 (AuthN), then RBAC checks if they have the Contributor role on a resource group (AuthZ).

Role-Based Access Control (RBAC)

RBAC is an authorization system built on Azure Resource Manager. It uses roles (collections of permissions) assigned to security principals (users, groups, service principals, managed identities) at a scope (management group, subscription, resource group, or resource).

Key RBAC Roles for AZ-104

• Owner: Full access, can delegate access to others.
• Contributor: Full access except for delegating access (cannot assign RBAC roles).
• Reader: Read-only access.
• User Access Administrator: Can manage user access to Azure resources (assign RBAC roles).

Built-in vs. Custom Roles: Built-in roles cover common scenarios. Custom roles allow fine-grained permissions, e.g., "Can restart VMs but not delete them." Custom roles are defined using a JSON file with Actions, NotActions, DataActions, and AssignableScopes.

RBAC Inheritance

Permissions are inherited from higher scopes. For example, assigning the Contributor role at the subscription scope grants contributor access to all resource groups and resources within that subscription. However, deny assignments (from Azure Blueprints or managed applications) can block access even if a role assignment allows it.

Exam Tip: Understand that RBAC is not the same as Azure Policy. RBAC controls who can do what, while Azure Policy controls what resources can be created or configured.

Conditional Access Policies

Conditional Access is an Entra ID Premium feature that enforces access controls based on signals like user, device, location, and risk. Policies are if-then statements: if a condition is met, then enforce a control (e.g., require MFA, block access, require compliant device).

Components of a Conditional Access Policy

• Assignments: Users/groups, cloud apps (e.g., Azure Management, Office 365), conditions (device platform, location, client app, sign-in risk, user risk).
• Access controls: Grant (require MFA, require device to be marked as compliant, require approved client app, require password change) or Session (use app-enforced restrictions, use Conditional Access App Control).

Example Policy

Scenario: Require multi-factor authentication for all administrators accessing the Azure portal.

1. Name: Require MFA for Azure Portal Admins
2. Assignments:
   • Users and groups: Select a group containing admin users.
   • Cloud apps: Microsoft Azure Management.
   • Conditions: (none, or specify locations if needed).
3. Access controls: Grant – Require multi-factor authentication.
4. Enable policy: On.

Exam Tip: Conditional Access policies apply to first-factor authentication (password) and then enforce second-factor (MFA) or other controls. Also, policies can be set to Report-only mode to test impact without enforcement.

What to Watch for on the Exam

• Difference between Azure AD and Entra ID: They are the same service; Microsoft rebranded Azure AD to Microsoft Entra ID. The exam uses both terms.
• RBAC vs. Azure AD roles: RBAC controls Azure resource access; Azure AD roles (like Global Administrator) control access to Entra ID itself and Microsoft 365.
• Service principals: Used for automated tools (e.g., Azure CLI, PowerShell, apps). They are like user identities for applications.
• Managed identities: Automatically managed service principals for Azure resources (e.g., a VM can get a managed identity to access Key Vault).
• Conditional Access licensing: Requires Azure AD Premium P1 or P2. P2 adds risk-based policies (Identity Protection).
• Default protection: Since August 2021, MFA is required for all users accessing Azure portal, billing, and support by default (if you have enough licenses).

Conclusion

Mastering Entra ID, RBAC, and Conditional Access is essential for the AZ-104 exam. Focus on understanding the hierarchy of scopes, the difference between authentication and authorization, and how policies enforce security. Practice creating users, assigning roles at different scopes, and configuring a Conditional Access policy in the Azure portal.

To solidify your knowledge, try answering practice questions on these topics. Check out the official Microsoft Learn modules and sample questions to test your readiness.