Microsoft AZ-801: Gestione delle Identità e degli Accessi per Ambienti Ibridi — Guida allo studio

By Laurynas Brazys · 7 August 2026 · #microsoft #az-801 #certification #exam-prep #study-guide

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

Panoramica

La gestione delle identità e degli accessi in ambienti ibridi si basa su un piano di controllo coerente tra Active Directory Domain Services (AD DS) on-premise e Microsoft Entra ID. I componenti fondamentali sono la sincronizzazione delle directory e il monitoraggio dello stato di integrità, l’identità dei dispositivi e il single sign-on, la federazione sicura o la pubblicazione tramite reverse proxy per le app legacy, e la governance just-in-time per i ruoli con privilegi e gli utenti esterni. Le progettazioni efficaci includono Azure AD Connect (ora Microsoft Entra Connect sync), Azure AD Connect Health, Hybrid Azure AD Join con una rigorosa disciplina di troubleshooting, Seamless SSO, AD FS quando è richiesta la federazione, Azure AD Application Proxy con Kerberos Constrained Delegation per le app on-premise, policy di accesso condizionale (Conditional Access) robuste, Azure AD Password Protection sui domain controller e Microsoft Entra ID Governance, che comprende PIM e la gestione dei diritti (entitlement management).

Azure AD Connect e Health nell’Identità Ibrida

Azure AD Connect è il motore di sincronizzazione autorevole tra AD DS e Microsoft Entra ID. Definire correttamente l’ambito, trasformare e scrivere gli attributi è di fondamentale importanza.

Il writeback delle password estende la reimpostazione self-service della password (SSPR) e la modifica della password dal cloud all’AD on-premise. Richiede Microsoft Entra ID P1/P2, l’abilitazione di SSPR nel tenant, traffico HTTPS in uscita dal server di sincronizzazione e che l’account di servizio di Azure AD Connect sync disponga delle autorizzazioni di reimpostazione appropriate in AD. Quando abilitato, per gli utenti che reimpostano la password in Entra, la modifica viene applicata immediatamente in AD DS, rispettando le policy sulle password di AD.

Il writeback dei dispositivi crea oggetti msDS-Device in AD DS per i dispositivi registrati in Entra. Questo supporta l’accesso condizionale on-premise in AD FS e alcuni scenari di trust dei certificati di Windows Hello for Business. I requisiti includono uno schema di Windows Server 2012 R2 o successivo, i diritti di Enterprise Admin per creare il container RegisteredDevices e una configurazione di Azure AD Connect che punti alla foresta e all’OU corrette. L’account di servizio di sincronizzazione riceve diritti delegati su quel container.

Il writeback dei gruppi sincronizza i gruppi di Microsoft 365 in AD DS come gruppi abilitati alla posta elettronica (mail-enabled) per le liste di indirizzi e le ACL on-premise. Il group writeback v2 permette di definire l’ambito a una specifica OU e preserva l’appartenenza ai gruppi con maggiore fedeltà. Per le funzionalità di posta, si raccomanda Exchange hybrid. Gli amministratori non dovrebbero modificare on-premise gli attributi dei gruppi originati dal cloud; il writeback da Entra deve essere considerato autorevole.

Le regole di sincronizzazione determinano l’ambito degli oggetti, le operazioni di join e i flussi di attributi. Utilizzare il Synchronization Rules Editor per creare regole personalizzate in ingresso (inbound) o in uscita (outbound) con una precedenza più alta (valore numerico più basso) anziché modificare quelle predefinite. Definire filtri di ambito (ad esempio, sincronizzare solo gli utenti con un attributo specifico), regole di join (come correlare gli oggetti cloud e on-premise — la coerenza di immutableId/sourceAnchor è fondamentale) e trasformazioni (normalizzare gli UPN, mappare gli attributi di estensione). Limitare la sincronizzazione utilizzando il filtraggio per dominio/OU o basato su attributi per minimizzare l’esposizione dei dati e ridurre la superficie di errore.

Azure AD Connect Health fornisce un monitoraggio continuo per AD DS, AD FS e AAD Connect. Installare gli agenti Health sui domain controller, sui server AD FS/WAP e sul server di sincronizzazione. Il portale espone:

Errori e avvisi di sincronizzazione: errori di esportazione (ConstraintViolation, ObjectTypeMismatch), eventi di resilienza per attributi duplicati, fallimenti nella sincronizzazione degli hash delle password, problemi di sincronizzazione delta e stato di integrità dello scheduler.
Analisi di AD FS: errori di emissione dei token, scadenza dei certificati, aggiornamento dei metadati di trust, latenza verso le relying party e anomalie come un numero elevato di blocchi extranet.
Analisi di AD DS: backlog di replica, stato di integrità dei ruoli FSMO, fallimenti del canale sicuro e insight sulla deprecazione di NTLM. Indagare con costanza gli errori nella fase in cui si verificano (importazione, sincronizzazione, esportazione) utilizzando il Synchronization Service Manager e correlandoli con gli avvisi di Connect Health. Utilizzare le analisi di utilizzo (usage analytics) per dimensionare correttamente l’infrastruttura e rilevare pattern anomali di accesso o di emissione di token.

Identità del Dispositivo e Single Sign-On

L’Hybrid Azure AD Join (HAADJ) associa i dispositivi aggiunti al dominio a Entra, abilitando l’SSO basato su PRT e l’Accesso Condizionale basato sul dispositivo. I requisiti includono domini personalizzati verificati in Entra, configurazione dell’SCP in AD (Azure AD Connect può configurarlo per ogni foresta), registrazione dei dispositivi abilitata in Entra e accesso in uscita agli endpoint di registrazione dei dispositivi. Windows 10/11 e Windows Server 2016+ supportano l’hybrid join automatico quando hanno visibilità diretta di un controller di dominio o un’adeguata raggiungibilità di rete. I dispositivi di versioni precedenti richiedevano storicamente AD FS/Workplace Join, ma le implementazioni moderne standardizzano sulle versioni dei sistemi operativi client supportate.

Il processo di join si basa sull’individuazione del tenant da parte del dispositivo tramite l’SCP nella partizione di Configurazione, contattando gli endpoint enterpriseregistration, autenticandosi con l’account del computer e registrando un oggetto dispositivo in Entra. Una registrazione riuscita si traduce in un Primary Refresh Token (PRT) che abilita l’SSO verso le applicazioni moderne. Eseguire la risoluzione dei problemi con dsregcmd:

dsregcmd /status conferma che AzureAdJoined = YES e DomainJoined = YES, e mostra lo stato del PRT, il TenantId e i codici di errore.
Esaminare il registro eventi User Device Registration (Applications and Services Logs) per errori di DRS e di autenticazione.
Verificare la sincronizzazione dell’ora, le esclusioni del proxy per gli endpoint di registrazione dei dispositivi, la correttezza dell’SCP e che il writeback dei dispositivi (se utilizzato) abbia creato il contenitore AD con le autorizzazioni appropriate. Se necessario, dsregcmd /leave cancella la registrazione per consentire un nuovo tentativo di join pulito.

Azure AD Seamless SSO fornisce l’autenticazione integrata di Windows a Entra senza AD FS. L’abilitazione dell’SSO in Azure AD Connect crea l’account computer AZUREADSSOACC in AD e imposta gli SPN (HTTP/autologon.microsoftazuread-sso.com). I controller di dominio emettono un ticket di servizio Kerberos per questo SPN quando i browser accedono all’endpoint di autologon; Entra convalida il ticket utilizzando la chiave condivisa archiviata in modo sicuro nel tenant. I client supportati includono Microsoft Edge e Internet Explorer con gli endpoint di Entra nella zona Intranet locale, Google Chrome tramite la policy di Windows Integrated Authentication e Firefox con la configurazione negotiate. I dispositivi devono essere aggiunti al dominio e trovarsi sulla rete aziendale (o connessi tramite VPN) per presentare i ticket Kerberos; le modalità di navigazione privata possono disabilitare la WIA. Le chiavi su AZUREADSSOACC vengono ruotate automaticamente; non reimpostarle manualmente. Il Seamless SSO funziona sia con Password Hash Sync che con Pass-through Authentication.

Federazione, Pubblicazione di Applicazioni e Accesso Sicuro

Active Directory Federation Services rimane rilevante laddove le organizzazioni necessitino di arricchimento delle attestazioni (claim), autenticazione con smart card o certificato, o contratti di federazione preesistenti. In AD FS, un ‘claims provider trust’ rappresenta una fonte di identità in ingresso (tipicamente Active Directory o un IdP partner). Un ‘relying party trust’ rappresenta un’applicazione che si affida ai token di AD FS (ad esempio, Microsoft 365 in modalità federata o un’app SAML). Le regole di emissione delle attestazioni (claim) trasformano gli attributi in ingresso nei token attesi dal relying party; utilizzare il linguaggio delle regole di attestazione o i modelli di regola per creare policy con il principio del privilegio minimo. Mantenere integri i certificati di firma e decrittografia dei token e automatizzare il rollover ove possibile. Web Application Proxy (WAP) pubblica AD FS esternamente, convalida il trust del proxy di AD FS e termina la connessione TLS sul perimetro (edge); monitorare lo stato di WAP e assicurarsi che le whitelist degli endpoint e il rinnovo dei certificati siano automatizzati.

Per modernizzare l’accesso alle applicazioni web on-premise, Azure AD Application Proxy fornisce la pre-autenticazione cloud e si integra con l’Accesso Condizionale. Distribuire i connettori su host Windows Server aggiunti al dominio con traffico HTTPS solo in uscita verso il servizio. Utilizzare i gruppi di connettori per segmentare le app per zona di rete, latenza o residenza dei dati, e per fornire isolamento per le app ad alto rischio. Scegliere la pre-autenticazione con Azure AD per imporre MFA, conformità del dispositivo, rischio di accesso e appartenenza a gruppi prima che il traffico raggiunga il datacenter; la pre-autenticazione pass-through dovrebbe essere riservata a scenari in cui l’app gestisce l’autenticazione e l’Accesso Condizionale non è richiesto. Per l’SSO verso applicazioni con Integrated Windows Authentication, configurare la Kerberos Constrained Delegation (KCD) sull’account computer del connettore verso l’SPN di destinazione (HTTP/app-server). Il connettore ottiene un ticket Kerberos per conto dell’utente e lo presenta all’applicazione, abilitando un SSO trasparente da internet pur mantenendo la delega con il privilegio minimo. Convalidare gli SPN, assicurarsi che il connettore possa raggiungere i KDC e l’app di backend, e limitare la delega solo ai servizi richiesti.

L’Accesso Condizionale applica policy consapevoli del rischio e della postura su tutte le app cloud e on-premise pubblicate. Combinare segnali come lo stato del dispositivo (Richiedi che il dispositivo sia contrassegnato come conforme) e lo stato della directory (Richiedi dispositivo aggiunto a Hybrid Azure AD) per controllare l’accesso per gli endpoint gestiti. Sfruttare il rischio di accesso da Identity Protection per bloccare o richiedere l’MFA per accessi anomali. Applicare la policy alle app pubblicate con Azure AD Application Proxy con pre-autenticazione Azure AD; per le app federate con AD FS, replicare l’intento tramite le regole di attestazione di AD FS o migrare alla pre-autenticazione cloud. Escludere gli account di emergenza (break-glass) e le entità servizio (service principal), e testare la policy in modalità di solo report prima di applicarla.

Accesso con privilegi, protezione delle password e governance

Azure AD Password Protection elimina le credenziali deboli combinando l’elenco globale di password vietate di Microsoft con un elenco personalizzato dell’organizzazione. Distribuire il servizio proxy di Azure AD Password Protection su uno o più server membri per mediare la connettività dei DC verso il cloud, e installare l’agente DC su ogni domain controller scrivibile per applicare la policy al momento dell’impostazione/modifica della password. Gli agenti recuperano la policy corrente tramite HTTPS e l’applicazione può essere eseguita in modalità di audit prima di passare alla modalità di imposizione (enforce). L’algoritmo valuta varianti e sostituzioni comuni; monitorare i registri eventi dedicati per i rifiuti e l’auditing. Questa funzionalità si integra con il writeback delle password di SSPR, in modo che le stesse regole vengano applicate ovunque.

Privileged Identity Management (PIM) rende operativo il principio del privilegio minimo (least privilege) attraverso assegnazioni idonee e attivazione just-in-time (JIT). Assegnare ruoli ad alto impatto (Global Administrator, Privileged Role Administrator, Security Administrator) come idonei, non permanenti. Configurare i requisiti di attivazione come MFA, ticket o giustificazione, flusso di lavoro di approvazione con approvatori designati, attivazione a tempo limitato e, facoltativamente, Azure AD Conditional Access all’attivazione. PIM per i gruppi estende l’accesso JIT all’appartenenza/proprietà dei gruppi di accesso con privilegi, che a loro volta possono essere assegnati a ruoli Azure AD o Azure RBAC. Utilizzare le verifiche di accesso (access review) per ricertificare l’appartenenza a ruoli e gruppi a cadenza regolare, richiedendo ai proprietari delle risorse di attestare o revocare l’accesso automaticamente quando gli utenti sono inattivi o cambiano reparto. Gli avvisi identificano gli account con privilegi permanenti (standing) e i registri di audit catturano ogni attivazione e approvazione ai fini della conformità.

La gestione dei diritti di Microsoft Entra ID Governance cura i pacchetti di accesso (access package) che raggruppano risorse (gruppi, siti SharePoint e applicazioni) con policy di ciclo di vita e approvazione. Definire chi può richiedere l’accesso (utenti interni, reparti specifici o utenti esterni da organizzazioni connesse), impostare approvazioni a più fasi, richiedere una giustificazione aziendale e imporre la scadenza con verifiche di accesso a fine vita. Le organizzazioni connesse (connected organization) modellano i domini e gli identity provider dei partner per semplificare l’onboarding B2B con termini d’uso appropriati e automazione del ciclo di vita. Gli utenti richiedono l’accesso tramite il portale My Access e, alla scadenza, le risorse vengono rimosse automaticamente per ridurre al minimo l’accesso permanente.

Scenario pratico

Siemens AG sta migrando applicazioni web legacy on-premise verso un accesso moderno, mantenendo AD DS e introducendo il principio del privilegio minimo. Gli utenti si lamentano delle continue richieste di credenziali per Microsoft 365 e le app interne, e gli auditor richiedono un accesso amministrativo a tempo limitato e una solida igiene delle password.

Stabilire l’identità ibrida e il SSO

Distribuire Microsoft Entra Connect sync con Password Hash Sync, abilitare il Seamless SSO. Questo riduce le richieste di credenziali consentendo un SSO basato su Kerberos tramite l’account AZUREADSSOACC senza richiedere AD FS. Configurare il filtraggio per OU e regole di sincronizzazione personalizzate per limitare l’ambito ai soli oggetti necessari e normalizzare gli UPN.

Abilitare la fiducia nel dispositivo (device trust) e il Conditional Access

Configurare l’Hybrid Azure AD Join tramite Azure AD Connect per registrare i client Windows aggiunti al dominio. Questo fornisce segnali basati sul dispositivo per il Conditional Access. Convalidare la registrazione con

undefined

e risolvere le errate configurazioni di SCP o proxy emerse nel registro User Device Registration.

Pubblicare le app on-premise in modo sicuro

Distribuire i connettori di Azure AD Application Proxy in due datacenter e inserire le app in gruppi di connettori per località. Utilizzare la pre-autenticazione di Azure AD in modo che il Conditional Access imponga l’hybrid-join o la conformità e l’MFA sul perimetro (edge). Configurare KCD sugli account macchina dei connettori per le app IWA, limitando la delega a SPN specifici per ottenere un SSO via internet con il privilegio minimo.

Rafforzare le password end-to-end

Installare il servizio proxy di Azure AD Password Protection su server membri ridondati e l’agente DC su tutti i domain controller scrivibili. Abilitare la modalità di imposizione (enforce) con un elenco personalizzato di password vietate che rifletta termini specifici di Siemens. Questo garantisce il rifiuto coerente delle password deboli sia on-premise sia tramite SSPR con password writeback.

Modernizzare l’accesso con privilegi

Implementare PIM con assegnazioni idonee per i ruoli Global Administrator, Privileged Role Administrator e ruoli critici di Azure RBAC. Richiedere MFA, giustificazione e approvazione a un’unica fase, con finestre di attivazione di 4 ore. Configurare verifiche di accesso trimestrali per tutti i ruoli con privilegi e i gruppi di accesso con privilegi, rimuovendo automaticamente le assegnazioni inattive o non approvate.

Monitorare e operare

Installare gli agenti di Azure AD Connect Health sul server di sincronizzazione, su AD FS/WAP (se ancora utilizzati per partner specifici) e sui domain controller. Utilizzare gli avvisi di integrità (health alert) per tracciare errori di sincronizzazione, stato della sincronizzazione degli hash delle password, integrità della replica di AD DS e anomalie nell’emissione di token AD FS. Sfruttare le analisi di utilizzo per dimensionare correttamente la capacità dei connettori e rilevare picchi anomali.

Questo approccio elimina la federazione non necessaria, centralizza le policy con il Conditional Access e utilizza KCD per modernizzare l’accesso alle app legacy. Il Seamless SSO e l’HAADJ eliminano le richieste di password, Password Protection impone credenziali robuste all’origine, e PIM, insieme alle verifiche di accesso, fornisce un accesso amministrativo just-in-time e verificabile, in linea con il principio del privilegio minimo.

← Disaster Recovery e Continuità Operativa · Tutti i domini

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