Azure Active Directory: Cloud Identity and Access Management

Azure Active Directory (Azure AD), now rebranded as Microsoft Entra ID, is Microsoft's cloud-based identity and access management (IAM) service. Every Azure subscription is backed by an Azure AD tenant. It handles authentication for Azure resources, Microsoft 365, and any third-party or custom application you choose to integrate. Getting Azure AD right is the single most important security investment you can make in your Azure environment.

Azure AD vs On-Premises Active Directory

Despite the shared name, Azure AD and on-premises Active Directory Domain Services (AD DS) are different products designed for different environments:

• On-Premises AD DS: LDAP, Kerberos, Group Policy. Manages computers and users on a corporate network.
• Azure AD: REST APIs, OAuth 2.0, SAML, OpenID Connect. Manages cloud identities and app access over the internet.

Organizations with on-premises AD can sync identities to Azure AD using Azure AD Connect, giving users a single identity across both environments (hybrid identity).

Users and Groups

In the Azure Portal, navigate to Microsoft Entra ID > Users to create and manage user accounts. There are two account types:

• Member users: Internal accounts belonging to your tenant (employees, service accounts).
• Guest users (B2B): External users invited from other Azure AD tenants or with personal Microsoft accounts.

Use Groups to manage access at scale. Assign permissions to a group rather than to individual users — when someone joins or leaves a team, update group membership instead of hunting down individual resource assignments.

# Create a new user with the Azure CLI
az ad user create 
  --display-name "Jane Smith" 
  --user-principal-name jane.smith@yourdomain.onmicrosoft.com 
  --password "TempP@ssw0rd!" 
  --force-change-password-next-sign-in true

# Create a security group
az ad group create 
  --display-name "Dev Team" 
  --mail-nickname "devteam"

# Add the user to the group
az ad group member add 
  --group "Dev Team" 
  --member-id $(az ad user show --id jane.smith@yourdomain.onmicrosoft.com --query id -o tsv)

Role-Based Access Control (RBAC)

Azure RBAC controls what users can do with Azure resources. Roles are assigned at a scope — management group, subscription, resource group, or individual resource. The three most important built-in roles:

• Owner: Full access including the ability to delegate access to others.
• Contributor: Create and manage resources but cannot grant access to others.
• Reader: View resources only — no changes permitted.

Follow the principle of least privilege: assign the most restrictive role that still allows the user to do their job.

# Assign the Contributor role to a user on a specific resource group
az role assignment create 
  --assignee jane.smith@yourdomain.onmicrosoft.com 
  --role "Contributor" 
  --resource-group rg-myapp-dev

Multi-Factor Authentication (MFA)

Enable MFA for all users — it is the single most effective control against account compromise. In the Portal, go to Microsoft Entra ID > Users > Per-user MFA to enable it for specific accounts, or use Security Defaults (Entra ID > Properties > Manage Security Defaults) to enable MFA for all users in the tenant automatically. Security Defaults is free and recommended for tenants without Azure AD Premium.

Conditional Access Policies

Available with Azure AD Premium P1 or P2, Conditional Access lets you enforce access policies based on signals like user location, device compliance, and risk level. Example policies:

• Require MFA when signing in from outside the corporate network.
• Block access from countries your organization doesn't operate in.
• Require a compliant (Intune-managed) device to access sensitive applications.

Create policies at Microsoft Entra ID > Security > Conditional Access. Always test new policies in Report-only mode before enforcing them to avoid locking out legitimate users.

App Registrations and Service Principals

When your application or automation script needs to authenticate to Azure AD, you create an App Registration. This generates a Service Principal — a non-human identity with its own credentials and permissions.

# Create an app registration and service principal
az ad sp create-for-rbac 
  --name "myapp-service-principal" 
  --role "Contributor" 
  --scopes /subscriptions/<SUBSCRIPTION_ID>/resourceGroups/rg-myapp-dev

# Output includes appId, password (client secret), and tenant — store these securely

Store the client secret in Azure Key Vault, never in source code or environment variables checked into version control.

Key Takeaways

Azure AD is the security backbone of your entire Azure environment. Start by enforcing MFA and least-privilege RBAC, then layer in Conditional Access policies as your security posture matures. Every privileged action — creating resources, changing network rules, accessing secrets — should be tied to a specific, audited identity whether human or automated.