Microsoft Azure — Microsoft Entra ID (Azure AD)

Azure is Microsoft's cloud computing platform offering over 200 services. This article covers microsoft entra id (azure ad) with production-ready configurations, best practices, and hands-on examples.

What Is Microsoft Entra ID and Why It Matters

Microsoft Entra ID, formerly Azure Active Directory, is Microsoft's cloud-based identity and access management service. It provides authentication and authorization for users, applications, and resources both in the cloud and on-premises. Unlike traditional on-premises Active Directory, Entra ID is a multi-tenant, cloud-native directory service that supports modern protocols like OAuth 2.0, OpenID Connect, and SAML. For DevOps teams, Entra ID is the backbone of access control for Azure resources, enabling single sign-on (SSO), multi-factor authentication (MFA), and conditional access policies. Understanding Entra ID is critical because misconfigurations are a leading cause of security breaches in cloud environments. In production, you'll use it to manage identities for your CI/CD pipelines, application users, and service principals.

az account show --query tenantId -o tsv

Setting Up Your First Entra ID Tenant

Every Azure subscription is associated with an Entra ID tenant. If you don't have one, create it via the Azure portal or using the Azure CLI. The tenant is automatically created when you sign up for Azure, but you can also create a standalone tenant for development. Key objects in a tenant include users, groups, applications, and service principals. For DevOps, you'll often create service principals for automated tools like Terraform, Jenkins, or GitHub Actions. When creating a tenant, pay attention to the initial domain name (e.g., contoso.onmicrosoft.com) and consider adding a custom domain for production. A common mistake is using the default domain for user emails, which can cause confusion. Always configure at least one Global Administrator and enable security defaults for basic protection.

az account create --name "DevTenant" --offer-type MS-AZR-0017P --subscription-name "DevSubscription"

Users, Groups, and Administrative Units

Users are the core identity objects in Entra ID. You can create cloud-only users or synchronize from on-premises Active Directory using Azure AD Connect. Groups simplify access management by assigning permissions to a collection of users. Use security groups for permissions and Microsoft 365 groups for collaboration. For fine-grained administrative control, use Administrative Units to delegate management of specific users or groups without granting global admin rights. In production, follow the principle of least privilege: assign users only the roles they need. Avoid using Global Administrator for daily tasks; instead, use role-specific administrators like User Administrator or Application Administrator. Regularly review guest users and remove stale accounts to reduce attack surface.

Connect-MgGraph -Scopes "User.ReadWrite.All"
New-MgUser -DisplayName "Jane Doe" -UserPrincipalName "jane@contoso.com" -MailNickname "jane" -PasswordProfile @{Password="TempPass123!"; ForceChangePasswordNextSignIn=$true} -AccountEnabled $true

Service Principals and Managed Identities

Service principals are the identity for applications and automation tools. When you register an application in Entra ID, a service principal is created in your tenant. You can assign roles to service principals to grant access to Azure resources. However, managing secrets for service principals is error-prone. Managed identities are a safer alternative: they are automatically managed by Azure and eliminate the need to store credentials. There are two types: system-assigned (tied to a specific resource) and user-assigned (standalone identity that can be assigned to multiple resources). For DevOps pipelines, prefer managed identities over service principals. For example, a VM running a CI/CD agent can use a managed identity to access Azure Key Vault without any secrets.

az identity create --name "MyPipelineIdentity" --resource-group "rg-devops"
az vm identity assign --identities "MyPipelineIdentity" --resource-group "rg-devops" --name "MyVM"

Conditional Access Policies for DevOps

Conditional Access is the policy engine that enforces access controls based on signals like user location, device state, and risk level. For DevOps, you can create policies that require MFA for accessing the Azure portal, block access from untrusted IP ranges, or require compliant devices for CI/CD pipeline access. Policies are evaluated at sign-in and can grant, block, or require additional verification. A common production pattern is to require MFA for all administrative actions but allow service principals to bypass MFA via exclusion. Be careful with policy ordering: if you block all access accidentally, you can lock yourself out. Always create a break-glass account excluded from all policies.

Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess"
$params = @{
    displayName = "Require MFA for Azure Portal"
    state = "enabled"
    conditions = @{
        applications = @{ includeApplications = @("797f4846-ba77-4d27-9c6c-0c2b1b9c8b8b") }
        users = @{ includeUsers = @("All") }
    }
    grantControls = @{
        builtInControls = @("mfa")
        operator = "OR"
    }
}
New-MgIdentityConditionalAccessPolicy -BodyParameter $params

Application Registration and Permissions

To integrate an application with Entra ID, you register it in the App Registrations blade. This creates an application object that defines the app's authentication settings, redirect URIs, and required API permissions. Permissions can be delegated (on behalf of a user) or application (app-only). For DevOps tools like Terraform or GitHub Actions, you typically use application permissions with client credentials flow. When granting permissions, be precise: request only the minimum scopes needed. Over-permissioning is a common security issue. Also, configure redirect URIs carefully to avoid open redirect vulnerabilities. In production, use certificate-based authentication instead of client secrets for higher security.

az ad app create --display-name "MyDevOpsApp" --sign-in-audience AzureADMyOrg --web-redirect-uris "https://myapp.com/callback"
az ad app permission add --id <app-id> --api 00000003-0000-0000-c000-000000000000 --api-permissions e1fe6dd8-ba31-4d61-89e7-88639da4923d=Role

Integrating Entra ID with Azure DevOps

Azure DevOps can use Entra ID for authentication and access control. When you connect your Azure DevOps organization to an Entra ID tenant, you enforce corporate credentials and can use Conditional Access policies. This integration also enables group-based licensing and automatic user provisioning. To connect, go to Azure DevOps Organization Settings > Microsoft Entra ID. Once connected, all users must sign in with their Entra ID credentials. For service connections, use managed identities or service principals with appropriate permissions. A common pitfall is disconnecting the tenant without migrating users, which can lock everyone out. Always plan the migration carefully and communicate with your team.

az devops admin user update --organization https://dev.azure.com/myorg --origin-id <user-object-id> --license-type express

Monitoring and Auditing with Entra ID Logs

Entra ID provides three types of logs: sign-in logs, audit logs, and provisioning logs. Sign-in logs show who signed in, from where, and whether it succeeded. Audit logs track changes to directory objects like user creation or role assignment. Provisioning logs detail synchronization from HR systems or other directories. For DevOps, these logs are essential for security investigations and compliance. You can stream logs to Azure Monitor, Log Analytics, or a SIEM like Sentinel. Set up alerts for suspicious activities like multiple failed sign-ins or role assignments to privileged roles. In production, retain logs for at least one year for compliance and use diagnostic settings to export them to a storage account or event hub.

Connect-MgGraph -Scopes "AuditLog.Read.All"
Get-MgAuditLogSignIn -Filter "createdDateTime ge 2026-01-01" -Top 10 | Select-Object UserPrincipalName, AppDisplayName, Status, CreatedDateTime

Common Pitfalls and How to Avoid Them

Misconfigurations in Entra ID can lead to security breaches or service outages. Common pitfalls include: (1) Using the default domain for user sign-ins, which makes phishing easier. (2) Over-permissioning service principals with Contributor instead of a custom role. (3) Not enabling MFA for all users, especially admins. (4) Leaving legacy authentication protocols enabled, which bypass MFA. (5) Forgetting to review guest users, leading to stale access. (6) Not using break-glass accounts for emergency access. To avoid these, implement a least-privilege model, enable security defaults, and regularly audit permissions. Use tools like Microsoft Secure Score to track your security posture.

az rest --method get --uri "https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy/authenticationMethodConfigurations" --query "value[?id=='email'].state" -o tsv

Identity Protection and Risk-Based Policies

Microsoft Entra ID Protection is a P2 feature that detects identity risks: leaked credentials, anonymous IP access, atypical travel, malware-linked IPs, and unfamiliar sign-in properties. Risk signals are categorized as user risk (probability the identity is compromised) and sign-in risk (probability the authentication request is not legitimate). Configure risk-based Conditional Access policies: automatically require MFA for medium+ sign-in risk, force password change for high user risk, or block access for critical accounts. Use the Identity Protection dashboard to investigate risky users and sign-ins, with a remediation workflow. For production, enable risk policies gradually: start in report-only mode, investigate findings, then enforce. Integrate with Microsoft Sentinel for advanced threat hunting. Also configure alerts for when risky users are detected to trigger immediate investigation.

Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess"

# Create sign-in risk policy
$params = @{
    displayName = "Require MFA for Medium+ Sign-In Risk"
    state = "enabled"
    conditions = @{
        signInRiskLevels = @("medium", "high")
        users = @{ includeUsers = @("All") }
        applications = @{ includeApplications = @("All") }
    }
    grantControls = @{
        builtInControls = @("mfa")
        operator = "OR"
    }
}
New-MgIdentityConditionalAccessPolicy -BodyParameter $params

Hybrid Identity: Synchronizing On-Premises with Entra ID

Most enterprises have on-premises Active Directory and need to extend identities to the cloud. Azure AD Connect (for complex topologies) and Microsoft Entra Cloud Sync (for simple, filtered sync) synchronize users, groups, and passwords. Azure AD Connect supports password hash sync (PHS), pass-through authentication (PTA), and federation with AD FS. For production, use PHS as a baseline — it's the simplest and enables Identity Protection's leaked credential detection. Enable Seamless SSO for domain-joined machines. For high availability, deploy Azure AD Connect in staging mode on a second server. Always use filtered sync (OU-based or attribute-based) to avoid syncing service accounts and disabled users. Implement password writeback to allow self-service password reset (SSPR) from the cloud. Monitor sync health via the Azure AD Connect Health dashboard.

Import-Module ADSync
Get-ADSyncScheduler | Format-List SyncCycleEnabled, CustomizedSyncCycleInterval, NextSyncCyclePolicyType
Get-ADSyncConnectorRunStatus -ErrorAction SilentlyContinue | Format-Table Name, RunStepName, StepResult, EndTime

Entra ID Governance: Access Reviews, PIM, and Entitlement Management

Entra ID Governance ensures the right people have the right access for the right duration. Privileged Identity Management (PIM) provides just-in-time (JIT) activation for Azure AD roles and Azure RBAC roles with approval workflows, time-bound activation (1-8 hours default), and audit logging. Access Reviews automate periodic review of group memberships, application assignments, and role activations — reviewers get emailed and stale access is auto-removed. Entitlement Management creates access packages (bundles of roles, groups, and apps) that users can request via the My Access portal with approval flows and expiration policies. In production, use PIM for all privileged roles (never assign permanent Global Admin), run quarterly access reviews for all privileged groups, and create access packages for common role combinations (e.g., 'DevOps Engineer' gets Contributor on dev subscription + Reader on prod).

Connect-MgGraph -Scopes "PrivilegedAccess.ReadWrite.AzureAD"

# Configure PIM settings for Global Admin role
$params = @{
    approvalStages = @(
        @{
            approvalStageTimeOutInDays = 1
            isApproverRequired = $true
            escalationApprovers = @()
            primaryApprovers = @(
                @{ id = "admin@contoso.com"; isBackup = $false }
            )
        }
    )
    maximumGrantPeriodInMinutes = 480
    requireJustification = $true
    requireMfa = $true
}

Set-MgPolicyRoleManagementPolicy -UnifiedRoleManagementPolicyId "GlobalAdmin" -BodyParameter $params