Il segnale di compliance in Conditional Access

Conditional Access (CA) in Microsoft Entra ID decide se concedere o bloccare l’accesso valutando segnali (utente, gruppo, applicazione, rischio, piattaforma, device) e applicando dei grant control. Tra questi, i due basati sullo stato del dispositivo sono centrali per MD-102:

  • Require device to be marked as compliant: richiede che il device sia registrato in Entra come conforme, in base a una compliance policy di Microsoft Intune.
  • Require Microsoft Entra hybrid joined device: richiede che il device sia hybrid joined, cioè aggregato sia al dominio Active Directory on-premises sia a Entra ID.

Quando in una policy con due grant control usi l’operatore OR (“Require one of the selected controls”), basta soddisfare una condizione; con AND (“Require all”) devono essere entrambe vere. Uno scenario tipico: ambienti misti in cui i client Windows aggregati sono hybrid joined ma i device mobili sono solo Entra joined/registered e gestiti da Intune. In quel caso “compliant OR hybrid joined” copre entrambi i parchi.

Dove nasce il segnale: MDM compliance e il device object

Il flag di compliance non vive nel token: è un attributo dell’oggetto device in Entra ID. Il flusso è:

  1. Intune valuta il dispositivo contro la compliance policy (versione OS, BitLocker/encryption, Defender attivo, jailbreak/root, ecc.).
  2. Intune scrive l’esito (compliant / noncompliant) sull’oggetto device in Entra.
  3. Al momento dell’autenticazione, CA legge quell’attributo. Sul client, il Primary Refresh Token (PRT) trasporta l’identità e lo stato del device che permette a CA la valutazione.

Per questo il device deve essere registrato in Entra: senza device identity, “require compliant device” fallisce a prescindere dalla postura reale della macchina.

Integrazione con il device risk di Defender

Con Microsoft Defender for Endpoint connesso a Intune (connector di Mobile Threat Defense / compliance), il machine risk level di Defender diventa un input della compliance policy. Configuri la regola “Require the device to be at or under machine risk score” (es. Medium): se Defender alza il rischio oltre la soglia, Intune marca il device noncompliant, e CA — trovando compliant = false — blocca l’accesso. È il pattern per una risposta condizionata alle minacce: la compliance fa da ponte tra il rischio di Defender e l’enforcement di CA.

Report-only mode ed esclusioni anti-lockout

Attivare “require compliant device” su All users / All cloud apps senza cautele è il modo più rapido per chiudersi fuori dal tenant. Due pratiche obbligatorie:

  • Report-only mode: la policy viene valutata e loggata (in Sign-in logs e nel What If) ma non applicata. Serve a misurare l’impatto prima dell’enforcement e a scoprire quanti device risulterebbero noncompliant.
  • Esclusioni: escludi almeno un break-glass / emergency access account (cloud-only, MFA robusta, escluso dalle policy device) e considera l’esclusione di account di servizio e device non gestibili. Senza break-glass, un errore di policy o un device admin noncompliant può bloccare ogni accesso amministrativo.

Trappole tipiche d’esame

  • Scenario: un tecnico rende conforme un device (aggiunge BitLocker) e prova subito ad accedere, ma CA continua a bloccarlo. → Risposta giusta: CA valuta lo stato registrato in Entra, non quello locale. Serve un nuovo sync di Intune e la ri-valutazione della compliance perché l’attributo device passi a compliant; l’accesso arriva dopo la propagazione, non istantaneamente.
  • Scenario: parco misto con Windows hybrid joined e iOS gestiti da Intune, si vuole una sola policy. → Grant control “Require compliant OR require hybrid joined device” con operatore OR.
  • Scenario: rollout di “require compliant device” senza impatto sugli utenti prima del go-live. → Distribuire la policy in report-only e analizzare i Sign-in logs / What If.
  • Scenario: bloccare l’accesso quando Defender rileva una minaccia elevata. → Non si mette il rischio direttamente in CA: si imposta la machine risk score nella compliance policy di Intune, e CA blocca via “require compliant device”.
  • Scenario: evitare il lockout amministrativo abilitando policy device tenant-wide. → Escludere l’account break-glass (cloud-only, escluso dai controlli device) dalla Conditional Access policy.