Practical deployment of Azure AD Conditional Access and Identity Protection for hybrid infrastructures

In this article I show how to practically introduce Azure AD Conditional Access and Identity Protection in a hybrid infrastructure. Hybrid in this context means: on-premises Active Directory (AD) synchronized to Azure AD (Azure Active Directory) via Azure AD Connect (AAD Connect), mixed clients (Windows, macOS, mobile devices) as well as on-premises applications and cloud services. The goal is a phased, secure operation with measurable verification and fallback mechanisms.

Why Conditional Access and Identity Protection belong together

Conditional Access (CA) is the policy engine in Azure AD that controls access to applications based on conditions — e.g. user role, device state, location or risk signals. Identity Protection (IP) provides these risk signals: Sign-in-Risk (risk at sign-in), User-Risk (suspicious behavior at the account level) and other events such as “Leaked credentials”. Together, CA rules permit an automated decision logic: for example, allow sign-in but require MFA or block when a risk is high.

Prerequisites and architecture overview

Before you create policies, review and document the basics:

• Azure AD licensing: Conditional Access generally requires Azure AD Premium P1, Identity Protection requires Azure AD Premium P2. License compliance is a prerequisite for certain features.
• AAD Connect: Synchronization must run reliably; check “password hash sync” or Federation/Pass-through Authentication (PTA) depending on the authentication model. AAD Connect is the tool linking on-prem AD and Azure AD.
• Hybrid Join / Device Registration: Devices must appear correctly as Azure AD Hybrid Joined or Azure AD Registered in order to use Device Compliance (Gerätekonformität) as a condition.
• MFA rollout: Multi-Factor Authentication should be available, including the enrollment process and helpdesk procedures for users who, for example, need to be issued a replacement device.
• Emergency access: At least two break-glass accounts with RESTricted use and separate MFA mechanisms to RESTore admin access if Conditional Access becomes too RESTrictive.

Architecture components briefly explained

Active Directory (AD): traditional on-premises directory service; Azure AD: cloud-based identity directory; Azure AD Connect: synchronization service; Device Compliance: result of an MDM/EMM check (e.g. Intune) to detect managed devices; MFA: additional authentication factors such as a phone app or hardware token.

Step 1: Analysis of the current environment and risk assessment

Start with a baseline analysis. The aim is to avoid unintended lockouts and to enable later fine-tuning of policies.

• Analyze sign-in logs: Which clients use legacy authentication (older protocols such as SMTP, IMAP, POP, older Outlook clients)? Legacy protocols often bypass modern authentication and MFA.
• Device inventory: Which devices are managed (MDM), which are not? Hybrid Join and Intune compliance are prerequisites for device-based CA conditions.
• Privileged accounts: identify service and application accounts (e.g. synchronization accounts, backup accounts). Many service accounts cannot easily perform MFA.

Audit script: basic sign-in log retrieval

With Microsoft Graph PowerShell you can list sign-ins and CA policies. Establish a connection and examine current sign-in events.

# Connect with required permissions (AuditLog.Read.All recommended)
Connect-MgGraph -Scopes "AuditLog.Read.All","Policy.Read.All","Directory.Read.All"
# Recent sign-in events (example, top 100 latest sign-ins)
Get-MgAuditLogSignIn -Top 100 | Select-Object UserDisplayName, UserPrincipalName, ApplicationDisplayName, Status, CreatedDateTime | Format-Table -AutoSize

Why this helps: You can spot recurring errors, failed MFA attempts or clients using legacy protocols — typical indicators of pitfalls when deploying CA.

Step 2: Policy strategy and phased plan

A successful rollout works in phases: Report-Only / Monitoring → Pilot → Partial enforcement → Full enforcement. Use „Report-Only“ or „What If“ functions to simulate impact.

Recommended phases

1. Monitoring & Reporting: Define policies but do not enforce them. Log who would be affected.
2. Pilot group: Security team, IT, selected business units. Enforce policies, collect feedback.
3. Growth phase: Group-based rollout by risk/department.
4. Enforce: Full enforcement with accompanying measures for helpdesk and support.

Policy design principles

• Think least privilege: Require only necessary conditions, e.g., MFA for access from untrusted locations.
• Define fallback rules: Never block all administrative paths — establish Break-Glass accounts or Administrative Units with exception policies.
• Exclude service accounts: Service or legacy accounts must be clearly identified and, if necessary, operated within secure perimeters (e.g., via VPN, RESTricted IP ranges).

Conditional Access: Typical policies and pitfalls

Common CA rules that have proven effective:

• Require MFA: Enforce MFA for all administrators and privileged roles.
• Block Legacy Authentication: Prevents insecure protocols; be cautious with service clients and SMTP-relay scenarios.
• Conditional Access based on device compliance: Allow only managed, compliant devices.
• Geolocation & IP ranges: Block logins from unknown countries or require additional checks.

Typical pitfalls

• Undiscovered service accounts: Often overlooked and then locked out by a strict CA policy.
• Legacy auth for apps: Email relays or legacy applications can be blocked; plan SMTP relay alternatives or authentication via Modern Auth.
• Incorrect device claims: MDM integration is missing or devices are not correctly shown as Hybrid Joined, causing device conditions to fail.
• MFA enrollments: Missing helpdesk processes for lost devices can lead to high support effort.

Identity Protection: Automating risk responses

Identity Protection classifies sign-ins and user risks into levels (low, medium, high). A common use is to automatically elevate requirements via CA: for high sign-in risk, e.g., block or enforce MFA.

When Identity Protection can fail

IP uses heuristic and ML-based signals. It is effective when sufficient telemetry is available (many sign-ins, diverse devices). In very small tenants or when telemetry is fragmented (many proxy sign-ins, rewrites), misclassifications can occur. Therefore: always test RESTrictive measures first in Report-Only.

Practical checks and tests

Perform structured tests, document results and have a clear rollback plan.

Checklist for tests

• Report-Only evaluation for 14–30 days.
• Pilot with 10–50 users, incl. admins and service accounts.
• Test cases: new device, managed device, external Wi‑Fi, SMB/legacy client, Exchange Online with Outlook Desktop, mobile mail, service-account actions.
• Monitor: Sign-in Logs, Conditional Access insights, Identity Protection Alerts, helpdesk tickets.

Important PowerShell check: Hybrid Join status on clients

For a quick check of a client use the dsregcmd tool locally on a Windows client.

# Run on the Windows-client (as admin console)
& 'C:WindowsSystem32dsregcmd.exe' /status

The tool shows whether a device is Hybrid Joined and which Azure AD claims are present. If devices do not appear correctly here, device-based CA conditions will not work.

Monitoring, logging and troubleshooting

For stable operation you need observability methods:

• Azure AD sign-in logs and Conditional Access insights: evaluate regularly (error rates, blocked access attempts).
• Alerts: forward Identity Protection Alerts to your ticketing system or SIEM (e.g. via Azure Monitor, Event Hubs or Graph API).
• Reporting: weekly reports on blocked logins, MFA adoption, device status.

Sign-in log example via Graph PowerShell

# Last sign-in attempts of a specific user
Connect-MgGraph -Scopes "AuditLog.Read.All"
Get-MgAuditLogSignIn -Filter "userPrincipalName eq 'max.mustermann@contoso.com'" -Top 50 | Format-Table CreatedDateTime,Status,AppDisplayName,ClientAppUsed,ConditionalAccessStatus -AutoSize

# Export all sign-ins with legacy-client indicator to CSV
Get-MgAuditLogSignIn -Top 1000 | Where-Object { $_.ClientAppUsed -like '*Other*' } | Select-Object UserPrincipalName, CreatedDateTime, ClientAppUsed, AppDisplayName | Export-Csv -Path .legacy-auth-signins.csv -NoTypeInformation

This gives you a reliable list of which users or applications use legacy clients. The goal is to prioritize these workloads and plan alternatives.

Azure AD Conditional Access and Identity Protection in live operation

In live operation it’s less about individual policies and more about processes: inventory maintenance, change management, monitoring runs and escalation paths. Automate reporting and define SLAs for resolving false positives.

SIEM and dashboarding: fields you should forward

For correlated alerts and forensics you should export at least the following fields to your SIEM: userPrincipalName, ipAddress, deviceDetail (if available), clientAppUsed, conditionalAccessStatus, riskLevelAggregated, riskDetail, authenticationMethods, location. These fields allow quick filtering by affected accounts, locations or devices.

// Example Kusto query for Log Analytics / Sentinel
SigninLogs
| where TimeGenerated > ago(7d)
| project TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName, ClientAppUsed, ConditionalAccessStatus, RiskLevelAggregated, DeviceDetail
| summarize count() by UserPrincipalName, ConditionalAccessStatus, bin(TimeGenerated, 1d) | sort by TimeGenerated desc

These queries serve as the basis for dashboards that, for example, detect spikes in blocking events or unusual aggregations of risk level.

Change Control and Versioning of Policies

Treat Conditional Access policies like infrastructure code: document purpose, scope, exceptions, author and date. Store configuration snapshots in a version repository or as exported JSONs. This enables a reproducible policy rollback.

Rollback and Emergency Strategy (concrete runbook steps)

A clear runbook reduces downtime. Example steps for an emergency response to a widespread lockout:

1. Notify: Inform the incident owner and IT management; activate channels (phone/SMS).
2. Identify: Use sign‑in logs to narrow down the scope of the block (e.g., all admins or an entire department).
3. Quick fix: Temporarily enable a predefined exception group or switch a specific policy to Report‑Only/Disabled.
4. Use break‑glass: If all else fails, use root/break‑glass accounts to perform administrative tasks.
5. Fix & Review: Remediate the cause (e.g., device‑claim fix, adjust exception list), document it, and implement the remediation permanently after 24/48 hours.

Important: Test the runbook in scheduled exercises at least once annually and after major policy changes.

WordPress‑Special: Azure AD‑protected admin access

Many organizations run WordPress as a publishing platform or portal frontend. If WordPress is integrated with Azure AD (SAML/OIDC), you can enforce Conditional Access there as well. Consider the following:

• SSO configuration: WordPress must be set up as an Enterprise App in Azure AD; session and cookie lifetimes should be aligned with CA session controls.
• REST API & App‑Tokens: Automated services that operate via REST API must not rely on user passwords. Use app registrations with limited permissions and Conditional Access exceptions where necessary.
• Caching & Load Balancer: CA‑based MFA prompts can be affected by caching/reverse proxies; test auth flows via the production frontend.
• Fallback mechanism: Create separate local admin accounts (for emergency control only) with strong access protection that are not part of the regular SSO chain.

Best Practices for hybrid operation

• Automate inventory and reporting for devices. Only then will you know which devices are covered by CA.
• Manage service accounts centrally and migrate such accounts to modern authentication where possible.
• Train helpdesk and end users: MFA enrollment, Self‑Service Password Reset (SSPR) and procedures for suspicious sign‑ins.
• Use Conditional Access Named Locations (IP‑Ranges) for corporate sites, but do not rely on them exclusively — IPs can change.
• Documentation: Store all policies, exceptions and rollback procedures under version control (e.g., in Git or an internal wiki).

Practical example: Minimal policy for getting started

A conservative start: Enforce MFA for all administrators, block legacy authentication, set Identity Protection to Report‑Only, and create a device compliance policy for access to sensitive apps. Test for 14–30 days before proceeding.

Conclusion and final remarks

The introduction of Azure AD Conditional Access and Identity Protection in hybrid environments is an iterative process. Crucial are a thorough inventory, staged rollouts, monitoring and a solid fallback strategy. Avoid “Big Bang” activations without a pilot and automated alerts; errors in the detection of service accounts or device claims are the most common causes of operational disruptions.

If you use this guide as a checklist — analysis, pilot, staged rollout, monitoring, contingency plan — you will sustainably reduce risk and operational effort. The combination of Conditional Access rules and Identity Protection signals enables adaptive access control that offers the greatest protection in hybrid architectures at a controllable level of effort.

Further audit and control checklist (summary)

• License check (P1/P2) completed?
• Is AAD Connect stable and synchronized?
• Device compliance and Hybrid Join verified?
• Break‑Glass accounts and runbook in place?
• Pilot group defined and report‑only phase started?
• Monitoring + SIEM integration operational?

FAQ

See the FAQ block at the end of this post for common questions and short answers.

Hybrid infrastructure is also important for this topic. The article places these aspects in context and shows what matters in daily operations.