Post

Azure Identity and Access: Azure AD, RBAC and Conditional Access

Azure Identity and Access: Azure AD, RBAC and Conditional Access

Why This Topic Matters

Identity and access are the foundation of cloud security. For AZ-900 candidates, understanding how Azure manages identities, access control, and multi-factor authentication is essential to designing safe and compliant solutions.

Good identity design affects:

  • Security posture and blast radius
  • Operational access and delegation
  • Compliance and auditability
  • End-user experience (SSO, MFA)

Knowing the difference between tenants, subscriptions, Azure Active Directory (Azure AD), and Role-Based Access Control (RBAC) helps you map business requirements to the right Azure controls.

Key Concepts

Tenant, Directory and Subscription

  • Azure AD tenant / directory: The identity boundary where users, groups, and applications live.
  • Subscription: Billing and resource boundary that trusts an Azure AD tenant for authentication and authorization.
  • A single tenant can be associated with multiple subscriptions; subscriptions cannot span tenants.

Azure AD Objects

  • Users: Human accounts (cloud or synchronized from on-premises) and service principals.
  • Groups: Logical collections to simplify permission assignment and application access.
  • Applications / Service principals: Identities used by apps and automation.

Authentication vs Authorization

  • Authentication: Verifying who the user (or service) is (Azure AD, MFA, SSO).
  • Authorization: Determining what an authenticated identity can do (RBAC, policies).

Role-Based Access Control (RBAC)

RBAC assigns built-in or custom roles at scopes: subscription, resource group, or resource.

  • Common built-in roles: Owner, Contributor, Reader, User Access Administrator.
  • Scope matters: Assign the least privilege at the narrowest practical scope.

Conditional Access and MFA

  • Multi-factor authentication (MFA): Stronger authentication factor (phone, app, hardware key).
  • Conditional Access: Policy-driven controls to require MFA, block risky sign-ins, or restrict access by location/device state.

Use Conditional Access to enforce MFA where risk is higher and to enable seamless SSO for trusted contexts.

Practical Guidance for AZ-900 Candidates

  1. Map identities to roles using RBAC, not by sharing accounts.
  2. Prefer group-based role assignments over granting permissions to individual users.
  3. Enable MFA for privileged accounts and configure Conditional Access for risk-based controls.
  4. Use service principals or managed identities for automation and avoid storing credentials in code.
  5. Apply the principle of least privilege and review role assignments periodically.

Simple Decision Checklist

  1. Which tenant owns your identity data?
  2. Which subscriptions will host the resources?
  3. What built-in roles satisfy the access need? If not, create a custom role.
  4. Which users require privileged access and need MFA/conditional policies?
  5. Are service principals and managed identities used for automation?

Common Mistakes to Avoid

  • Granting broad roles at subscription scope when resource-group scope suffices.
  • Using long-lived credentials for automation instead of managed identity.
  • Assuming on-premises AD controls automatically carry identical cloud protections.
  • Not enforcing MFA for privileged or external accounts.

References (Microsoft Learn)

Final Thoughts

Identity and access management is a high-impact AZ-900 area: small configuration choices (scopes, roles, MFA) translate directly into security posture. For exam and practice, focus on the boundaries between tenant, subscription, and RBAC scopes, and remember Conditional Access is the policy layer that ties identity to risk-aware access.

This post is licensed under CC BY-NC-ND 4.0 by the author.