Red Implementing Conditional Access Policies Azure Ad

---
name: red-implementing-conditional-access-policies-azure-ad
description: Configure Microsoft Entra ID (Azure AD) Conditional Access policies for zero trust access control.
domain: red
category: active-directory
hide: true
license: Apache-2.0
metadata:
  manifest_entry: src/corpus/red-implementing-conditional-access-policies-azure-ad/SKILL.md
---
# Implementing Conditional Access Policies in Azure AD

## Overview
Configure Microsoft Entra ID (Azure AD) Conditional Access policies for zero trust access control. Covers signal-based policy design, device compliance requirements, risk-based authentication, named locations, session controls, and integration with NIST SP 1800-35 zero trust architecture.


## When to Use

- When deploying or configuring implementing conditional access policies azure ad capabilities in your environment
- When establishing security controls aligned to compliance requirements
- When building or improving security architecture for this domain
- When conducting security assessments that require this implementation

## Common Misconfigurations & Verification

- **Policy left in report-only:** the policy is authored and looks active but `state=enabledForReportingButNotEnforced`, so it logs would-be blocks and enforces nothing. Verify `Get-MgIdentityConditionalAccessPolicy` shows `state=enabled` and check the sign-in log "Conditional Access" tab reads *Success/Failure*, not *Report-only*.
- **Excluded accounts that swallow the org:** broad break-glass/service-account exclusion groups accumulate members, silently exempting them from MFA/device requirements. Confirm exclusion groups contain only monitored break-glass accounts and that those accounts are alerted on every sign-in.
- **Grant-control gaps:** a policy requires controls with the "Require one of the selected controls" (OR) toggle when it should be AND, so "require MFA *or* compliant device" lets a non-compliant device through with just MFA. Verify the control combination and that "Require MFA" is not satisfiable by legacy/weaker factors.
- **Legacy auth not blocked:** without a policy targeting `clientAppTypes=other` (legacy/basic auth), CA is bypassed entirely by IMAP/POP/SMTP. Confirm an explicit block-legacy-auth policy exists and is enforced.
- **No "all apps / all users" baseline:** policies scoped to single apps leave new apps uncovered. Verify a baseline require-MFA policy targets All cloud apps with only break-glass excluded.
- **Verification:** use the Conditional Access What-If tool for a test user from a non-compliant device on a legacy client and confirm the expected policies *apply and block*; reconcile report-only vs enabled counts and confirm no high-privilege role sits in an exclusion group.

## Prerequisites

- Familiarity with identity access management concepts and tools
- Access to a test or lab environment for safe execution
- Python 3.8+ with required dependencies installed
- Appropriate authorization for any testing activities

## Objectives
- Implement comprehensive implementing conditional access policies in azure ad capability
- Establish automated discovery and monitoring processes
- Integrate with enterprise IAM and security tools
- Generate compliance-ready documentation and reports
- Align with NIST 800-53 access control requirements

## Security Controls
| Control | NIST 800-53 | Description |
|---------|-------------|-------------|
| Account Management | AC-2 | Lifecycle management |
| Access Enforcement | AC-3 | Policy-based access control |
| Least Privilege | AC-6 | Minimum necessary permissions |
| Audit Logging | AU-3 | Authentication and access events |
| Identification | IA-2 | User and service identification |

## Verification
- [ ] Implementation tested in non-production environment
- [ ] Security policies configured and enforced
- [ ] Audit logging enabled and forwarding to SIEM
- [ ] Documentation and runbooks complete
- [ ] Compliance evidence generated