Microsoft AZ-104: Azure Active Directory e Gestione delle identità — Guida allo studio

By Laurynas Brazys · 6 August 2026 · #microsoft #az-104 #certification #exam-prep #study-guide

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

Panoramica

Azure Active Directory (Azure AD) è il piano di controllo delle identità per i servizi cloud di Microsoft. Un tenant è una directory di identità dedicata e attendibile che contiene utenti, gruppi, applicazioni, dispositivi e policy. Una sottoscrizione è un contenitore di fatturazione per le risorse di Azure ed è associata a un solo tenant Azure AD per l’identità e l’accesso; un singolo tenant può contenere più sottoscrizioni. Le assegnazioni di ruolo per le risorse di Azure (Azure RBAC) provengono dal tenant associato alla sottoscrizione. Gli utenti si autenticano rispetto al loro tenant di origine e possono ottenere l’accesso a risorse in qualsiasi sottoscrizione che considera attendibile quel tenant. Le policy di governance delle identità e di sicurezza (ad esempio, Conditional Access) si applicano a livello di tenant e determinano come le identità utilizzano i servizi tra le varie sottoscrizioni.

Identità, Gruppi e Licenze

Gli account utente di Azure AD rientrano in tre categorie che influenzano il ciclo di vita, l’autenticazione e l’amministrazione:

Gli utenti solo cloud sono creati e gestiti in Azure AD. Le loro credenziali risiedono solo nel tenant e il ripristino della password è gestito da Azure AD (SSPR).
Gli utenti sincronizzati provengono da un Active Directory on-premise e sono sincronizzati tramite Azure AD Connect. Il loro ciclo di vita dell’identità è gestito on-premise. Con la Password Hash Synchronization (PHS), Azure AD memorizza un hash dell’hash della password on-premise; con la Pass-through Authentication (PTA) o la federazione, la convalida della password avviene on-premise. Con il writeback delle password abilitato (Azure AD Premium + Azure AD Connect), SSPR e il “Cambio password” nel cloud possono aggiornare l’AD on-premise.
Gli utenti guest (collaborazione B2B) sono identità esterne rappresentate come userType=Guest. Si autenticano con il loro provider di identità di origine (un altro Azure AD, un account Microsoft o un codice di accesso monouso) e viene concesso loro l’accesso tramite gruppi, assegnazioni di app o RBAC. L’invito dà luogo a un processo di riscatto (redemption) che il guest completa prima di accedere alle risorse.

I gruppi forniscono autorizzazione e licenze scalabili. L’appartenenza assegnata (Assigned) è gestita esplicitamente. L’appartenenza dinamica (Dynamic) (Azure AD Premium P1) valuta delle regole basate sugli attributi dell’utente o del dispositivo e mantiene automaticamente l’appartenenza quasi in tempo reale, ideale per scenari basati sul tipo di dipendente, sul dipartimento o sulla conformità del dispositivo. La gestione delle licenze basata su gruppi (Group-based licensing) assegna SKU di prodotto (ad esempio, Microsoft 365 E5, Azure AD Premium) a gruppi di sicurezza; Azure AD calcola l’assegnazione effettiva delle licenze, rispetta le disattivazioni dei piani di servizio ed evidenzia i conflitti. I gruppi dinamici si abbinano bene alla gestione delle licenze basata su gruppi per assegnare automaticamente le licenze a gruppi di utenti in base ai loro attributi.

Identità Ibrida con Azure AD Connect

Azure AD Connect stabilisce i modelli di sincronizzazione delle identità e di accesso per gli ambienti ibridi:

Password Hash Synchronization (PHS): Sincronizza un hash crittografico dell’hash delle password on-premise in Azure AD. Azure AD esegue l’autenticazione, abilitando un’alta disponibilità senza connettività in ingresso verso la rete aziendale, e supporta il Seamless SSO. PHS è l’opzione più semplice e resiliente ed è raccomandata per la maggior parte delle organizzazioni.
Pass-through Authentication (PTA): Agenti leggeri convalidano le password rispetto all’AD on-premise in tempo reale su una connessione TLS 443 in uscita. Supporta il Seamless SSO e mantiene le dipendenze dalle policy di accesso on-premise senza implementare una federazione. Distribuire più agenti per l’alta disponibilità.
Federazione (es. AD FS): L’autenticazione avviene presso un STS gestito dal cliente con l’emissione di claim e vincoli opzionali per smartcard/Kerberos. Aggiunge complessità e costi operativi ed è ora riservata a requisiti di claim e di accesso di nicchia. Molte organizzazioni migrano dalla federazione a PHS/PTA.

La sincronizzazione viene eseguita da uno scheduler (ciclo predefinito di 30 minuti). Usare

undefined

per applicare immediatamente le modifiche recenti come nuovi utenti, appartenenze a gruppi e aggiornamenti di attributi. Eseguire

undefined

solo per la prima volta o per modifiche alla topologia/schema (esegue un’importazione, sincronizzazione ed esportazione complete ed è più lento). Forzare la replica di AD, riavviare NetLogon o manipolare il Global Catalog non attiva un’esportazione di Azure AD Connect; il metodo supportato è il ciclo di sincronizzazione PowerShell o le operazioni tramite Synchronization Service Manager. Limitare l’ambito della sincronizzazione con il filtraggio per OU e attributi. Per l’integrazione del writeback delle password e di SSPR con l’ambiente on-premise, abilitare la funzionalità di writeback in Azure AD Connect e concedere le autorizzazioni on-premise necessarie.

Decisioni di Accesso: Accesso Condizionale, MFA, SSPR e Identity Protection

L’Accesso Condizionale (Conditional Access) (Azure AD Premium P1/P2) valuta i segnali e applica controlli in tempo reale al momento dell’accesso e dell’emissione dei token. Una policy si applica a utenti, gruppi o ruoli di directory; ad app cloud o azioni utente; e a condizioni come il rischio di accesso, la piattaforma del dispositivo, le app client (legacy o moderne) e le posizioni. Le posizioni attendibili (Named locations) contrassegnano intervalli IP o paesi/regioni fidati e consentono una logica esplicita di inclusione/esclusione. I controlli di concessione (Grant controls) impongono requisiti come:

Richiedi l’autenticazione a più fattori (MFA)
Richiedi che il dispositivo sia contrassegnato come conforme (compliant) (Intune)
Richiedi un dispositivo aggiunto ad Hybrid Azure AD (Hybrid Azure AD joined)
Richiedi una policy di protezione delle app, app client approvate o Termini di utilizzo I controlli di sessione (Session controls) gestiscono la frequenza di accesso, le sessioni persistenti del browser o le restrizioni applicate dalle app. Quando il requisito è “Gli Amministratori Globali devono usare l’MFA e un dispositivo attendibile da posizioni non attendibili”, si deve puntare al ruolo di directory Global Administrator, usare una condizione per le posizioni che escluda le reti attendibili nominate e configurare i controlli di concessione per richiedere l’MFA più un dispositivo conforme o uno aggiunto ad Hybrid Azure AD. Questo problema non si risolve attivando l’MFA per utente o modificando solo i controlli di sessione.

L’autenticazione a più fattori può essere imposta tramite:

MFA per utente (Per-user MFA): Uno stato legacy e granulare di abilitazione/disabilitazione a livello dell’oggetto utente. Manca di fattori contestuali ed è generalmente superato dai requisiti di Conditional Access.
MFA tramite Conditional Access: L’approccio moderno e raccomandato. Richiede l’MFA solo in condizioni specifiche (ad esempio, accessi ad alto rischio, reti non attendibili, ruoli con privilegi).
Self-Service Password Reset (SSPR): Metodi di autenticazione e registrazione configurabili, con writeback opzionale della password in locale (on-premises). La registrazione combinata unifica la configurazione di MFA e SSPR. Definisci le policy di registrazione, i metodi (ad esempio, Microsoft Authenticator, FIDO2, SMS/voce, se consentiti) e le impostazioni di blocco/notifica. I modelli di consumo legacy di Azure MFA (Per Authentication vs Per Enabled User, che usano i provider MFA classici) non possono essere cambiati direttamente; è necessario distribuire un nuovo provider e riassegnare gli utenti: la semplice “modifica del modello” tramite portale o CLI non è supportata.

Azure AD Identity Protection (Azure AD Premium P2) rileva e risponde ai rischi utilizzando dati di telemetria come credenziali trapelate, spostamenti atipici, IP collegati a malware e proprietà di accesso non familiari:

Il rischio utente (User risk) stima la probabilità che un’identità sia compromessa nel tempo, attivando policy come “Richiedi cambio password per rischio medio e superiore”.
Il rischio di accesso (Sign-in risk) stima la probabilità che un accesso specifico sia dannoso, abilitando controlli come “Richiedi MFA per rischio medio e superiore”. Le policy di rischio possono risolvere automaticamente il problema (auto-remediate) o bloccare l’accesso. Si integra con Conditional Access sfruttando il rischio come condizione e dando priorità a metodi MFA resilienti.

Ruoli amministrativi e governance B2B

I ruoli amministrativi definiscono l’ambito del controllo all’interno di Azure AD e dovrebbero seguire il principio del privilegio minimo:

Il ruolo Global Administrator ha piena autorità su identità, sicurezza e licenze. Utilizzarlo con parsimonia, proteggerlo con l’Accesso Condizionale (Conditional Access) e l’MFA, e considerare Privileged Identity Management (PIM) per l’elevazione dei privilegi just-in-time e le verifiche di accesso.
Il ruolo User Administrator può creare e gestire utenti e gruppi, reimpostare le password non amministrative e gestire alcuni attributi della directory. Delimitare ulteriormente l’ambito utilizzando le Unità amministrative (Administrative Units) per limitare il raggio d’impatto (blast radius) a dipartimenti o aree geografiche specifiche.
I ruoli personalizzati (Azure AD Premium) consentono di definire set di autorizzazioni granulari per gli oggetti della directory; possono essere assegnati a utenti o gruppi, opzionalmente con un ambito limitato alle Unità amministrative.

La collaborazione B2B consente agli utenti esterni di accedere ad app e risorse senza duplicare le identità. Il processo include:

Invito: Un utente interno o un’automazione invita tramite e-mail o un URL di riscatto diretto, richiedendo opzionalmente l’accettazione delle Condizioni per l’utilizzo (Terms of Use).
Riscatto: L’utente guest si autentica con la propria identità di origine. Se non disponibile, può essere utilizzato un passcode monouso. Il riscatto andato a buon fine crea o conferma l’oggetto guest nel tenant della risorsa.
Autorizzazione: Concedere l’accesso tramite gruppi di Azure AD, assegnazioni di app o Azure RBAC su sottoscrizioni/gruppi di risorse. Utilizzare le licenze basate su gruppo se l’utente guest necessita di servizi con licenza.
Governance: Utilizzare le Verifiche di accesso (Access Reviews) (Azure AD Premium P2) per attestare periodicamente la necessità continua dell’accesso guest, rimuovere automaticamente gli utenti guest obsoleti e verificare le decisioni. Configurare le impostazioni di collaborazione esterna e i criteri di accesso tra tenant per bilanciare collaborazione e rischio. Applicare l’Accesso Condizionale agli utenti guest, utilizzando posizioni attendibili (named locations) e requisiti MFA appropriati al rischio esterno.

Scenario pratico

Contoso Ltd. ha un’implementazione di identità ibrida e deve ridurre il rischio per l’accesso con privilegi durante l’onboarding degli utenti di un partner a specifiche applicazioni. L’amministratore di Azure ha il compito di imporre l’MFA e l’affidabilità del dispositivo (device trust) per gli Amministratori globali provenienti da reti non attendibili, accelerare la sincronizzazione degli utenti dall’ambiente on-premise al cloud durante una fusione e governare l’accesso guest dei partner a un sito SharePoint Online e a un’app line-of-business interna.

Approccio passo-passo:

Modellare le identità e l’affidabilità (trust)

Associare tutte le sottoscrizioni di Azure al tenant di Contoso per centralizzare la governance delle identità. Creare un gruppo di risorse dedicato e gruppi di sicurezza di Azure AD per l’accesso alle app. Ciò garantisce un unico piano di policy e semplifica il targeting dell’Accesso Condizionale.

Ottimizzare l’accesso ibrido e la sincronizzazione

Configurare Azure AD Connect con la Sincronizzazione dell’hash delle password (Password Hash Synchronization) e il Single Sign-On facile (Seamless SSO) per semplicità e resilienza. Distribuire gli agenti PTA solo se i controlli normativi richiedono la convalida della password on-premise. Utilizzare il filtro per OU per definire l’ambito dei contenitori di utenti della fusione. Per una disponibilità utente urgente, eseguire

undefined

. La PHS offre una disponibilità gestita da Microsoft e riduce la dipendenza dall’ambiente on-premise; il ciclo delta garantisce un’esportazione tempestiva senza una pesante sincronizzazione completa.

Applicare i controlli per l’accesso con privilegi

Creare una policy di Accesso Condizionale che abbia come target il ruolo di Global Administrator. Condizioni: includere tutte le posizioni, escludere gli intervalli IP aziendali attendibili (named trusted corporate IP ranges). Controlli di concessione: richiedere l’autenticazione a più fattori e richiedere che il dispositivo sia contrassegnato come conforme (o richiedere un dispositivo aggiunto ad Azure AD ibrido). Questo soddisfa esattamente al momento dell’accesso il requisito “MFA + dispositivo attendibile da posizioni non attendibili”. Utilizzare PIM per rendere le assegnazioni di Global Administrator just-in-time e richiedere approvazione più MFA, riducendo i privilegi permanenti.

Standardizzare MFA e SSPR

Disabilitare gli stati MFA per utente legacy e affidarsi all’Accesso Condizionale per imporre l’MFA in modo contestuale. Abilitare la registrazione combinata e l’SSPR con il writeback delle password in modo che gli utenti sincronizzati possano reimpostare sia le password del cloud sia quelle on-premise. Ciò migliora l’esperienza utente e garantisce la conformità. Evitare di tentare di cambiare i modelli di consumo MFA legacy esistenti, poiché non è un’operazione supportata.

Eseguire l’onboarding degli utenti partner con B2B e governare l’accesso

Invitare le identità dei partner come guest nel tenant di Contoso e assegnarle a un gruppo di sicurezza mappato al sito SharePoint e all’app. Applicare una Verifica di accesso (Access Review) al gruppo guest con una ricorrenza di 90 giorni e la rimozione automatica per chi non risponde. Applicare una policy di Accesso Condizionale agli utenti guest che richieda l’MFA al di fuori degli intervalli IP dei partner designati (named partner IP ranges). La collaborazione B2B evita la duplicazione degli account, sfrutta l’autenticazione del partner e le Verifiche di accesso forniscono una governance del ciclo di vita con risultati verificabili.

Perché questi servizi:

Azure AD Connect con PHS offre il minor carico operativo con una sicurezza elevata; la sincronizzazione delta garantisce un provisioning rapido.
I controlli di concessione dell’Accesso Condizionale impongono direttamente l’MFA e l’affidabilità del dispositivo, cosa che i controlli di sessione e l’MFA per utente non possono garantire.
L’SSPR con writeback chiude il cerchio per le identità sincronizzate, riducendo il carico di lavoro dell’helpdesk e allineandosi alla conformità.
La collaborazione B2B unita alle Verifiche di accesso bilancia la collaborazione esterna con il principio del privilegio minimo e l’attestazione periodica, minimizzando il rischio e mantenendo l’agilità.

Tutti i domini · Sottoscrizioni di Azure →

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