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