Mastering Security in Microsoft Entra ID (MFA, Conditional Access, Identity Protection)

Microsoft Entra ID (formerly Azure Active Directory) is the cornerstone of secure identity management in Microsoft 365 and Azure environments. It delivers comprehensive protection through Multi-Factor Authentication (MFA), Conditional Access (CA) policies, and Identity Protection (IP). This article provides an in-depth technical perspective suitable for scientific and enterprise-grade IAM implementations.

✅ Multi-Factor Authentication (MFA)

What is MFA?

Multi-Factor Authentication adds a second layer of verification in addition to a password. The goal is to mitigate risks associated with credential theft.

Supported Authentication Methods:

Method Protocols / Standards Comment
Microsoft Authenticator OATH-TOTP / Push via REST Recommended for mobile-first environments
SMS / Voice Call PSTN Susceptible to interception
FIDO2 Security Key WebAuthn / CTAP2 Best for passwordless & phishing-resistant login
Windows Hello TPM-backed biometric certs Strong device-bound authentication
TOTP (Google/Authy) RFC 6238 (TOTP) Compatible with RFC-compliant apps

Setup Guidelines:

  • Admin Center: Azure Portal → Entra ID → Security → MFA
  • Enforce via Conditional Access rather than legacy per-user settings.
  • Secure registration using registration campaigns or Identity Protection triggers.

Backend Protocol Support:

  • MFA challenge integrates with WS-Federation, SAML 2.0, OAuth2, and OpenID Connect.
  • Session tokens contain MFA claim (amr: ["mfa"]) for downstream app validation.

🧠 Conditional Access Policies

Conditional Access (CA) enforces access control in real-time based on signals like user identity, device health, network location, and session risk.

Policy Evaluation Engine

graph TD;
  A[Sign-in Request] --> B{Evaluate Conditions};
  B --> C{Risk Level?};
  B --> D{Device Compliance?};
  B --> E{Geo-Location Allowed?};
  C --> F[Grant: Require MFA];
  D --> G[Grant: Require Compliant Device];
  E --> H[Block Access];
  F --> I[Token Issued];
  G --> I;
  H --> J[Access Denied];

Detailed Condition Types:

  • User context: ID, group, directory role, licensing
  • Client app: Browser, legacy, mobile, modern
  • Platform: Windows, macOS, iOS, Android
  • Locations: Named locations, IP ranges
  • Sign-in risk: Low/Medium/High from Identity Protection
  • Device state: Azure AD registered/hybrid joined, Intune compliance

Best Practices:

  • Use reportOnly mode for dry-runs
  • Always define exclude rules for break-glass accounts (e.g., cloud-only emergency admin)
  • Avoid overlapping policies to minimize evaluation complexity

🚨 Identity Protection (IP)

Overview:

Identity Protection is a risk-based detection engine powered by machine learning algorithms across Microsoft’s global threat intelligence graph.

Risk Signals:

Risk Source Detection Logic
Atypical Travel Impossible travel time from previous IP
Anonymous IP Address Use of TOR, VPNs, or anonymizers
Malware-linked IP IPs involved in known botnets or credential stuffing
Unfamiliar Sign-in Props Deviations in browser fingerprint, locale, etc.

Policies:

  • User Risk Policy: Enforces action on users marked high-risk (e.g., reset password)
  • Sign-in Risk Policy: Applies actions on specific risky login attempts (e.g., require MFA)

Technical Requirements:

  • Entra ID P2 License
  • Sign-in telemetry must be ingested (Log Analytics / Sentinel recommended)
  • Integration with Security Operations Center (SOC) pipelines via Microsoft Graph API or Sentinel connectors

🔄 Authorization Flow (MFA + CA + IP)

graph TD;
  A[User Sign-in] --> B[Azure AD Authentication];
  B --> C[CA Policy Evaluation];
  C --> D[MFA Prompt if required];
  D --> E{MFA Success?};
  E -->|Yes| F[Risk Analysis - Identity Protection];
  E -->|No| X[Block Access];
  F --> G{Sign-in Risk Acceptable?};
  G -->|Yes| H[Token Issued];
  G -->|No| X;

🧱 Terraform Template (Conditional Access)

resource "azurerm_conditional_access_policy" "require_mfa" {
  name     = "Require MFA for all users"
  state    = "enabled"
  scope {
    include_users = ["All"]
  }
  conditions {
    sign_in_risk_levels = ["medium", "high"]
    client_app_types    = ["all"]
  }
  grant_controls {
    built_in_controls = ["mfa"]
    operator          = "OR"
  }
}

Notes:

  • Use azurerm_role_assignment to scope policy to specific admins.
  • This template requires Terraform v1.5+ and azurerm >= 3.0

📤 JSON Policy Export

PowerShell Export

Connect-AzureAD
$policy = Get-AzureADMSConditionalAccessPolicy -PolicyId "<GUID>"
$policy | ConvertTo-Json -Depth 10 > policy.json

JSON Schema Fragment:

{
  "displayName": "Require MFA for Admins",
  "state": "enabled",
  "conditions": {
    "users": {
      "includeRoles": ["62e90394-69f5-4237-9190-012177145e10"]
    }
  },
  "grantControls": {
    "operator": "OR",
    "builtInControls": ["mfa"]
  }
}

🧩 Graph API Automation

Get all policies

GET https://graph.microsoft.com/beta/identity/conditionalAccess/policies
Authorization: Bearer <token>

Create policy via Graph

POST https://graph.microsoft.com/beta/identity/conditionalAccess/policies
Content-Type: application/json
Authorization: Bearer <token>

{
  "displayName": "Require MFA",
  "state": "enabled",
  "conditions": {
    "users": {
      "includeGroups": ["<group-id>"]
    }
  },
  "grantControls": {
    "operator": "OR",
    "builtInControls": ["mfa"]
  }
}

📊 Monitoring with KQL (Azure Monitor / Sentinel)

SigninLogs
| where ConditionalAccessStatus == "failure"
| summarize Total=count() by ConditionalAccessPolicyResult
IdentityProtectionRiskEvents
| summarize Events = count() by RiskLevel, RiskEventType

Suggested Dashboards:

  • MFA registration completeness
  • Sign-in attempts by country & risk level
  • Policy evaluation breakdown by result

For citation or inclusion in a scientific paper, all data sources and Microsoft documentation links can be appended in a formal references section.