Microsoft MD-102: Identità, accesso e accesso condizionale — Guida allo studio

By Laurynas Brazys · 5 August 2026 · #microsoft #md-102 #certification #exam-prep #study-guide

Fa parte della Microsoft Endpoint Administrator Associate MD-102 — Guida allo studio. Esercitati con risposte verificate nel centro esami Microsoft, oppure fai test cronometrati su ExamRoll.io.

Panoramica

La gestione di identità, accessi e accesso condizionale in Microsoft 365 stabilisce come utenti, dispositivi e app vengono autenticati e autorizzati ad accedere alle risorse aziendali. Azure AD Conditional Access (CA) valuta segnali come lo stato dell’utente e del dispositivo, la posizione e il rischio per applicare controlli quali MFA, conformità del dispositivo, protezione delle app e restrizioni di sessione. Le policy basate sul rischio di Azure AD Identity Protection automatizzano la correzione per gli utenti compromessi e gli accessi a rischio. I Primary Refresh Tokens (PRT) offrono un single sign-on trasparente sui dispositivi aggiunti ad Azure AD (Azure AD joined), mentre Enterprise State Roaming preserva un’esperienza utente produttiva su più dispositivi. Privileged Identity Management applica l’elevazione dei privilegi just-in-time per gli amministratori. Infine, una strategia ben strutturata per i gruppi di Azure AD è fondamentale per definire con precisione i destinatari (targeting) sia in Intune che in Conditional Access.

Accesso Condizionale: condizioni, controlli di concessione, località denominate e strategia MFA

L’Accesso Condizionale valuta le condizioni e applica i controlli di concessione/sessione per produrre una decisione sì/no al momento dell’emissione del token. Le policy di CA vengono valutate dopo l’autenticazione primaria e prima che venga emesso un token di accesso.

Condizioni chiave da padroneggiare:

• Utente e gruppo: Definiscono l’ambito dei destinatari della policy. Utilizzare la logica di inclusione/esclusione per i test pilota e per escludere gli account di emergenza (break-glass).
• App cloud o azioni: Selezionare app specifiche (es. Exchange Online, SharePoint Online, app aziendali personalizzate) o azioni utente (registrare le informazioni di sicurezza).
• Piattaforma e stato del dispositivo: Filtrare per sistema operativo e richiedere la conformità del dispositivo o l’hybrid Azure AD join per soddisfare i requisiti Zero Trust per i dispositivi. La conformità del dispositivo è segnalata da Intune e richiede che il dispositivo sia valutato e contrassegnato come conforme.
• Posizioni: Utilizzare le località denominate (named locations) per includere/escludere per paese/regione o intervalli IP. Contrassegnare l’uscita dalla rete aziendale come “attendibile” per allentare i controlli quando appropriato.
• App client: Distinguere i client di autenticazione moderna (browser, client Office moderni) dai protocolli legacy (IMAP/POP/SMTP/ActiveSync basic). Per bloccare solo l’autenticazione legacy consentendo quella moderna, utilizzare la condizione App client insieme a un controllo di concessione di tipo Blocco (Block) per i client legacy.
• Rischio di accesso e rischio utente: Acquisiscono i segnali di rischio da Identity Protection per attivare decisioni di step-up o di blocco al momento dell’accesso o in base alla compromissione dell’account.

I controlli di concessione definiscono cosa deve essere soddisfatto per l’accesso:

• Richiedi autenticazione a più fattori
• Richiedi che il dispositivo sia contrassegnato come conforme
• Richiedi dispositivo hybrid Azure AD joined
• Richiedi modifica password (correzione del rischio)
• Richiedi condizioni d’uso
• Richiedi app client approvata e/o policy di protezione delle app (per MAM senza registrazione del dispositivo)

I controlli di sessione modellano il comportamento post-autenticazione:

• Frequenza di accesso e sessione del browser persistente
• Conditional Access App Control (tramite Microsoft Defender for Cloud Apps) per l’ispezione della sessione in tempo reale
• Disabilita le impostazioni predefinite di resilienza dove è richiesta un’elevata affidabilità

Best practice per il ciclo di vita delle policy:

• Iniziare con la modalità di sola segnalazione (report-only) per convalidare l’impatto
• Utilizzare i modelli di policy per scenari comuni (es. bloccare l’autenticazione legacy, proteggere i ruoli di amministratore)
• Includere sempre account di accesso di emergenza che bypassano l’Accesso Condizionale (CA)
• Combinare “richiedi conformità del dispositivo” con le policy di conformità di Intune per imporre controlli su sistema operativo, crittografia, antivirus e jailbreak/root

Località denominate e intervalli IP attendibili:

• Le località denominate (named locations) possono essere paesi/regioni (basate sulla geolocalizzazione IP) o intervalli CIDR IPv4/IPv6 specifici. Contrassegnare una località denominata come attendibile ne consente l’uso come esclusione o per allentare i controlli (es. bypassare l’MFA negli uffici considerati attendibili). Solo gli IP pubblici di uscita (egress) sono efficaci; gli IP privati sottoposti a NAT non sono visibili esternamente.
• Identity Protection può considerare le località denominate attendibili come a rischio inferiore per il rilevamento di accessi non familiari. Mantenere un elenco autorevole degli IP di uscita aziendali e tenerlo aggiornato per evitare falsi positivi.

Strategia MFA: MFA per utente vs MFA tramite Conditional Access:

• L’MFA per utente (legacy) impone l’MFA in modo statico a livello dell’oggetto utente e supporta il “salto dell’MFA per IP attendibili” solo tramite le sue impostazioni classiche. Manca di una valutazione contestuale e di un targeting granulare, e va in conflitto con le richieste di CA.
• L’MFA tramite Conditional Access è l’approccio consigliato. Applica l’MFA in base a condizioni quali la sensibilità dell’app, lo stato del dispositivo e il rischio. Si integra con Identity Protection per richieste basate sul rischio e supporta i client di autenticazione moderna.
• Guida alla migrazione: Impostare lo stato “Disabilitato” (Disabled) per l’MFA per utente, implementare policy di MFA basate su CA e affidarsi alla policy centralizzata dei Metodi di Autenticazione per la registrazione e l’applicazione dei metodi (es. Authenticator, FIDO2, SMS). Utilizzare l’MFA preferita dal sistema e la corrispondenza numerica (number matching) per rafforzare la sicurezza delle approvazioni push.

Protezione dell’identità, rischio utente e di accesso e ruolo del PRT nel SSO seamless

Azure AD Identity Protection (AIP) calcola il rischio probabilistico tramite machine learning e la threat intelligence di Microsoft:

• Il rischio di accesso valuta ogni autenticazione in tempo reale (es. proprietà di accesso non familiari, spostamento atipico, IP collegato a malware, IP anonimo).
• Il rischio utente riflette la probabilità che un’identità sia compromessa (es. credenziali trapelate, accessi anomali ripetuti).

Criteri:

• Criterio di rischio di accesso: Per un rischio di accesso medio/alto, imporre “Richiedi MFA” o “Blocca accesso”. Questo è ideale per un’autenticazione “step-up” al momento di accessi rischiosi.
• Criterio di rischio utente: Per un rischio utente medio/alto, imporre “Richiedi cambio password” o “Blocca accesso”. Questo risolve le identità compromesse forzando un reset sicuro della password tramite SSPR/MFA.
• Integrazioni: Configurare i criteri di CA con le condizioni “Rischio di accesso” o “Rischio utente” per un controllo preciso per ogni app. Escludere gli account di emergenza (break-glass). Utilizzare le posizioni attendibili nominate per ridurre i falsi positivi.
• Licenze e audit: Identity Protection richiede Azure AD Premium P2. Utilizzare il flusso di lavoro di rilevamento e indagine dei rischi per confermare, ignorare o risolvere i rischi ed esportare i log in un SIEM.

Primary Refresh Token (PRT) e SSO seamless su dispositivi Azure AD joined:

• Il PRT è un refresh token associato al dispositivo e all’utente (user-scoped), emesso durante l’accesso al dispositivo (Azure AD joined o hybrid Azure AD joined). Risiede nello stack di credenziali del sistema operativo ed è protetto dal TPM, se disponibile.
• Il PRT abilita il SSO alle app integrate con Azure AD tramite il Web Account Manager (WAM) e MSAL, eliminando richieste di autenticazione ripetute. Quando l’accesso iniziale ha soddisfatto i requisiti MFA, il PRT trasporta un claim MFA che può soddisfare la richiesta “Richiedi MFA” di un criterio di CA senza una nuova richiesta di autenticazione, fino alla scadenza della frequenza di accesso o alla modifica del criterio.
• Rinnovo e sicurezza: il PRT viene rinnovato periodicamente e può essere sottoposto a una sfida con nonce per verificare la presenza del dispositivo. La revoca della registrazione del dispositivo o la disabilitazione dell’utente invalida l’emissione di token successivi.
• Relazione con il Seamless SSO: Azure AD Seamless SSO (basato su Kerberos tramite Azure AD Connect) avvantaggia principalmente i computer aggiunti a un dominio nella rete aziendale che utilizzano PHS/PTA. I dispositivi Azure AD joined si affidano al PRT per il SSO; non è necessario il Seamless SSO per i dispositivi AADJ per ottenere il SSO alle risorse cloud.

Enterprise State Roaming, PIM e strategia dei gruppi per una destinazione precisa

Enterprise State Roaming (ESR):

• ESR sincronizza le impostazioni di Windows supportate e alcune impostazioni delle app per gli utenti di Azure AD su tutti i dispositivi Azure AD joined e hybrid Azure AD joined. Gli esempi includono la personalizzazione, la lingua e alcune impostazioni delle app di Windows; non include documenti o file arbitrari.
• Abilitare ESR nelle impostazioni del tenant di Azure AD e definirne l’ambito per tutti gli utenti o per utenti selezionati. I dati sono crittografati in transito e a riposo (at rest) in Azure; le chiavi hanno un ambito a livello di tenant. ESR riduce i tempi di riconfigurazione durante la sostituzione di un dispositivo o il provisioning con Autopilot e integra, ma non sostituisce, le soluzioni di gestione dei profili.

Privileged Identity Management (PIM) per l’accesso amministrativo just-in-time:

• PIM (Azure AD P2) rende gli utenti idonei (eligible) anziché assegnati in modo permanente a ruoli con privilegi (es. Global Administrator, Intune Administrator, Security Administrator) o a gruppi di accesso con privilegi (PAG).
• L’attivazione può richiedere MFA, una giustificazione, numeri di ticket e approvazione, e può essere limitata nel tempo con un inizio e una fine prestabiliti. Genera record di audit immutabili e avvisi in caso di attivazione eccessiva.
• Utilizzare PIM per ridurre i privilegi permanenti (standing privilege), limitare il raggio d’impatto (blast radius) e soddisfare i requisiti di conformità. Per Intune, rendere gli amministratori idonei per il ruolo di Intune Administrator o per un PAG a cui è concesso un ruolo RBAC di Intune con ambito definito. Richiedere l’approvazione per i ruoli ad alto impatto e limitare l’attivazione all’orario di lavoro.

Gruppi di Azure AD per il targeting in Intune e CA:

• Gruppi assegnati: Appartenenza statica, ideale per progetti pilota e quando gli attributi non sono sufficienti. Amministrativamente semplici e deterministici.
• Gruppi di utenti dinamici: L’appartenenza è calcolata dagli attributi dell’utente (es. department, usageLocation, jobTitle). Ideali per criteri basati sull’utente, assegnazioni di app e governance delle licenze. Richiede Azure AD Premium P1.
• Gruppi di dispositivi dinamici: L’appartenenza si basa sugli attributi del dispositivo (es. deviceOSType, deviceOwnership, enrollmentProfileName, deviceCategory). Ideali per criteri basati sul dispositivo e distribuzioni di app.
• Linee guida per il targeting in Intune:
  • Utilizzare i gruppi di utenti per i criteri basati sull’utente (es. criteri di protezione delle app, assegnazioni di app di Office) e i gruppi di dispositivi per i profili basati sul dispositivo (es. configurazione, conformità).
  • Preferire i filtri per dispositivi di Intune per un ambito di alta precisione sulle assegnazioni a “Tutti i dispositivi”, al fine di ridurre la proliferazione di gruppi (group sprawl) e i ritardi di valutazione.
  • Per il Conditional Access, definire l’ambito dei criteri per utenti e identità di carico di lavoro; utilizzare i filtri per dispositivi all’interno di CA quando è necessario restringere l’applicazione in base alle proprietà del dispositivo e richiedere lo stato “dispositivo conforme” o “hybrid joined” per imporre la postura del dispositivo.
• Buone pratiche (Hygiene): Evitare l’uso di gruppi annidati che causano ritardi imprevedibili nella valutazione dinamica. Monitorare l’elaborazione dell’appartenenza ai gruppi e progettare esclusioni di fallback per gli account di emergenza (break-glass) o di servizio.

Unire i pezzi: pattern di accesso moderni e sicuri

Un pattern robusto per endpoint cloud-first:

• Bloccare l’autenticazione legacy utilizzando una policy di accesso condizionale (CA) con la condizione App client limitata ai protocolli legacy e un controllo di concessione Blocca.
• Imporre la MFA basata su CA con un ambito della policy definito in base alla sensibilità (ad es., richiedere la MFA per Exchange/SharePoint e tutti i portali di amministrazione). Eliminare la MFA per utente per prevenire conflitti.
• Richiedere la conformità del dispositivo per le piattaforme desktop con controlli di sessione per la frequenza di accesso. Per il BYOD mobile, richiedere app client approvate e policy di protezione delle app senza registrazione (enrollment).
• Sfruttare Identity Protection: richiedere la MFA per rischi di accesso di livello medio, bloccare i rischi di accesso di livello alto e richiedere il cambio password per rischi utente di livello medio/alto.
• Utilizzare le località attendibili (named locations) per ridurre l’attrito per l’utente sulle reti aziendali fidate, pur continuando a imporre la conformità del dispositivo e i controlli di sessione secondo necessità.
• Assicurarsi che i dispositivi aggiunti (joined) ad Azure AD ottengano un PRT per un SSO trasparente, supportato dai segnali di conformità di Intune e di Defender for Endpoint, ove applicabile.
• Governare l’accesso amministrativo con PIM ed eseguire revisioni periodiche degli accessi.

Scenario pratico

Fabrikam, Inc. sta distribuendo laptop Windows 11 aggiunti (joined) ad Azure AD e gestiti con Intune a una forza lavoro globale. I requisiti di sicurezza includono il blocco dell’autenticazione legacy, l’imposizione della MFA basata sul rischio, l’obbligo di dispositivi conformi per l’accesso a Microsoft 365, l’abilitazione dell’SSO e la minimizzazione dell’attrito per l’utente causato da richieste di autenticazione frequenti. Gli amministratori devono elevare i propri privilegi solo quando necessario. Gli utenti devono poter mantenere la personalizzazione del desktop sui nuovi dispositivi.

1. Implementare una baseline di accesso condizionale

• Creare una policy CA “Blocca autenticazione legacy”: come destinatari (target) tutti gli utenti, escludere due account di emergenza (break-glass), includere tutte le app cloud, impostare App client sui protocolli legacy e concedere Blocca. Perché: Questo blocca in modo preciso solo i protocolli legacy, preservando l’accesso tramite autenticazione moderna.

2. Richiedere MFA e conformità del dispositivo per Microsoft 365

• Creare una policy CA “L’accesso a M365 richiede un dispositivo conforme o MAM”: come destinatari tutti gli utenti, includere Exchange Online e SharePoint Online, richiedere che il dispositivo sia contrassegnato come conforme per Windows/macOS; per iOS/Android, richiedere un’app client approvata e una policy di protezione delle app. Impostare la frequenza di accesso nel controllo di sessione a 14 giorni. Perché: Bilancia sicurezza e usabilità, imponendo un approccio Zero Trust sugli endpoint gestiti e il MAM per il BYOD senza registrazione (enrollment).

3. Abilitare la protezione basata sul rischio con Identity Protection

• Configurare la policy per il rischio di accesso (Sign-in risk): per livello medio e superiore, richiedere la MFA; per livello alto, bloccare l’accesso.
• Configurare la policy per il rischio utente (User risk): per livello medio e superiore, richiedere il cambio password tramite SSPR+MFA. Perché: Automatizza la remediation in tempo reale e in caso di compromissione dell’account per ridurre i tempi di risposta agli incidenti.

4. Stabilire località attendibili (named locations)

• Definire intervalli di IP per i datacenter e gli uffici regionali di Fabrikam e contrassegnarli come attendibili. Perché: Riduce le richieste di MFA non necessarie provenienti da punti di uscita (egress) noti e migliora l’accuratezza dei segnali di rischio.

5. Garantire un SSO trasparente tramite PRT su dispositivi aggiunti (joined) ad Azure AD

• Registrare i dispositivi con Windows Autopilot (Azure AD join) e Intune. Verificare l’emissione del PRT usando dsregcmd /status e assicurarsi che la sincronizzazione dell’ora e il TPM siano integri. Perché: Il PRT fornisce un SSO legato al dispositivo, soddisfa le attestazioni (claim) MFA dell’accesso condizionale quando applicabile ed elimina le richieste di autenticazione ripetute.

6. Configurare la conformità e il targeting di Intune con i gruppi di Azure AD

• Creare gruppi di dispositivi dinamici per piattaforma e proprietà e applicare le policy di conformità (crittografia, sistema operativo minimo, stato di Defender). Usare i filtri per dispositivi di Intune per raffinare le assegnazioni a “Tutti i dispositivi” per i profili di configurazione e le app Win32. Perché: Assicura che solo i dispositivi conformi ricevano l’accesso, minimizzando al contempo la proliferazione di gruppi (group sprawl) e la latenza di valutazione.

7. Governare l’accesso privilegiato con PIM

• Rendere l’Helpdesk idoneo per i ruoli Intune Help Desk Operator ed Endpoint Security Manager; rendere il Cloud Ops idoneo per il ruolo Intune Administrator. Richiedere MFA, giustificazione e finestre di attivazione di 4 ore con approvazione per i ruoli più elevati. Perché: Riduce i privilegi permanenti (standing privilege), impone il principio del privilegio minimo (least privilege) e fornisce attivazioni tracciabili e verificabili (auditable).

8. Abilitare Enterprise State Roaming (ESR)

• Attivare ESR per tutti gli utenti di Azure AD. Comunicare quali impostazioni vengono sincronizzate (roam) e validare la sincronizzazione sui dispositivi pilota. Perché: Conserva la personalizzazione dell’utente tra le sostituzioni dei dispositivi, migliorando la produttività durante gli eventi del ciclo di vita del dispositivo.

Questo design utilizza l’accesso condizionale per l’applicazione contestuale delle policy, Identity Protection per la remediation automatizzata del rischio, il PRT per un SSO trasparente su dispositivi aggiunti (joined) ad Azure AD, Intune e i gruppi dinamici per un targeting preciso delle policy, PIM per l’amministrazione just-in-time e ESR per un’esperienza utente coerente — il tutto allineato con i principi Zero Trust e l’efficienza operativa.

← Sicurezza degli endpoint e Microsoft Defender · Tutti i domini · Co-gestione e ambienti ibridi →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →

Sfoglia Microsoft →