• Guide, Sicurezza, Sistemi Operativi
• 24 Aprile 2026

Un Domain Controller non è un server come gli altri. Può avere lo stesso sistema operativo, lo stesso ciclo di patching e magari la stessa finestra di manutenzione degli altri server Windows. Ma il suo impatto è diverso: se smette di funzionare, non si ferma solo una macchina. Si interrompe una parte dell’identità aziendale.

Il caso KB5082063, emerso con gli aggiornamenti Microsoft di aprile 2026, è un buon promemoria tecnico: il patch management dei Domain Controller deve essere trattato come un processo separato, controllato e verificabile.

Gli aggiornamenti di sicurezza sono necessari. Su questo non si discute. Il problema è che, in ambienti enterprise, “necessario” non significa automaticamente “innocuo”.

Il caso degli aggiornamenti Microsoft di aprile 2026 lo dimostra bene: una patch pensata per migliorare sicurezza e affidabilità ha introdotto, in alcuni scenari Active Directory, un comportamento potenzialmente molto critico sui Domain Controller. Non parliamo del classico aggiornamento che richiede un riavvio in più o di una console che mostra un messaggio poco chiaro. Parliamo di Domain Controller che possono entrare in un ciclo continuo di riavvio a causa di crash del processo LSASS.

E quando LSASS va giù su un Domain Controller, Active Directory non la prende con filosofia. Diciamo che non prepara una tisana.

Il problema: LSASS, Domain Controller e reboot loop

Microsoft ha documentato un problema legato all’aggiornamento di sicurezza di aprile 2026 KB5082063 per Windows Server 2025. Dopo l’installazione e il successivo riavvio, alcuni Domain Controller in foreste multidominio che utilizzano Privileged Access Management, o PAM, possono sperimentare crash di LSASS durante la fase di startup. Il risultato è un riavvio ripetuto del Domain Controller, con possibile indisponibilità dei servizi di autenticazione e directory.

Figura 1 – KB5082063

LSASS, Local Security Authority Subsystem Service, è uno dei componenti più delicati di Windows. Gestisce autenticazione, sicurezza locale, token di accesso e interazioni fondamentali con Active Directory. Su un Domain Controller, il suo ruolo è ancora più critico perché impatta direttamente la capacità del dominio di autenticare utenti, computer, servizi e applicazioni.

Il problema non riguarda indistintamente ogni server Windows. Secondo Microsoft, lo scenario interessa ambienti Windows Server gestiti, in particolare Domain Controller presenti in foreste con più domini e configurazioni PAM. Non riguarda i PC consumer o dispositivi personali non gestiti da un reparto IT.

Perché un reboot loop su un Domain Controller è un incidente serio

Un Domain Controller che si riavvia continuamente non è semplicemente “un server non disponibile”.

È un problema di identità.

Se il Domain Controller non riesce a completare l’avvio, non può fornire correttamente autenticazione Kerberos, NTLM, LDAP, replica, policy e tutti quei servizi che spesso diamo per scontati fino al momento in cui smettono di funzionare.

In ambienti piccoli, il rischio è evidente: se i Domain Controller sono pochi, la perdita anche temporanea di uno di essi può creare disservizi importanti. In ambienti grandi, il rischio è più subdolo: il problema può non colpire tutti i DC, ma può impattare ruoli specifici, siti remoti, servizi legacy, applicazioni che puntano a Domain Controller determinati o processi di autenticazione particolarmente sensibili.

Il punto non è solo “la patch ha un bug”. Il punto è che Active Directory resta ancora oggi il cuore dell’identità aziendale in moltissimi ambienti. Quando qualcosa impatta i DC, l’effetto non rimane confinato al sistema operativo: arriva agli utenti, alle applicazioni, ai file server, ai servizi cloud ibridi, agli accessi amministrativi e, in generale, alla continuità operativa.

Gli aggiornamenti out-of-band rilasciati da Microsoft

Microsoft ha risolto il problema tramite aggiornamenti out-of-band rilasciati il 19 aprile 2026. Per Windows Server 2025 la correzione standard è KB5091157, mentre per i sistemi Windows Server 2025 iscritti a hotpatching Microsoft indica l’utilizzo dell’aggiornamento hotpatch OOB KB5091470, distribuito tramite Windows Update e senza necessità di riavvio.

Figura 2 – Elenco problemi risolti

Il Windows Message Center riporta anche gli aggiornamenti out-of-band per le altre versioni supportate di Windows Server: Windows Server 2025, Windows Server 23H2, Windows Server 2022, Windows Server 2019 e Windows Server 2016. Per Windows Server 2025, KB5091157 risolve sia il problema del reboot loop sia un problema di installazione dell’aggiornamento di aprile; per le versioni precedenti, gli OOB sono focalizzati sul problema dei Domain Controller.

Questo dettaglio è importante: non basta sapere che “è uscita una patch di emergenza”. Bisogna verificare quale versione di Windows Server è in uso, quale KB è applicabile e quale canale di aggiornamento viene utilizzato.

Non solo Domain Controller: BitLocker e installazioni fallite

Nelle note di KB5082063 Microsoft documenta anche altri problemi noti.

Il primo riguarda alcuni sistemi con una configurazione BitLocker non raccomandata via Group Policy. In presenza di determinate condizioni, dopo il primo riavvio successivo all’installazione dell’aggiornamento, il dispositivo può richiedere l’inserimento della BitLocker Recovery Key. Microsoft specifica che lo scenario riguarda una combinazione precisa di condizioni, tra cui BitLocker attivo sull’unità di sistema, una configurazione esplicita del profilo di validazione TPM con PCR7 incluso, PCR7 Binding indicato come “Not Possible” in msinfo32 e presenza del certificato Windows UEFI CA 2023 nel Secure Boot Signature Database.

Il secondo problema riguarda un numero limitato di dispositivi Windows Server 2025 sui quali l’installazione dell’aggiornamento può fallire con errori come 0x800F0983 o 0x80073712. Anche questo problema viene risolto dall’aggiornamento out-of-band KB5091157.

Sono effetti collaterali diversi, ma con un elemento comune: confermano che il patching non è solo “installare gli aggiornamenti”. È gestione del rischio operativo.

Cosa dovrebbero fare gli amministratori

La prima cosa da fare è verificare se nell’ambiente sono presenti Domain Controller Windows Server interessati dagli aggiornamenti di aprile 2026 e se esistono scenari compatibili con quelli descritti da Microsoft: foreste multidominio, utilizzo di PAM, Domain Controller non ancora aggiornati con gli OOB, oppure sistemi che hanno manifestato crash LSASS o riavvii ripetuti. Microsoft indica il problema come risolto dagli aggiornamenti out-of-band del 19 aprile 2026.

La seconda cosa è evitare la tentazione del “patchiamo tutto subito ovunque”. La sicurezza richiede velocità, ma l’infrastruttura richiede metodo. In particolare, sui Domain Controller è opportuno avere sempre un processo di distribuzione progressivo: prima un numero limitato di DC non critici, poi validazione dei log, controllo della replica, verifica dell’autenticazione e solo dopo estensione al resto dell’ambiente.

La terza cosa è controllare BitLocker prima di aggiornare i sistemi potenzialmente interessati. Microsoft raccomanda di verificare le Group Policy BitLocker, in particolare la configurazione del profilo TPM per firmware UEFI nativo e l’eventuale inclusione esplicita di PCR7, oltre allo stato PCR7 Binding da msinfo32.

Figura 3 – msinfo

Microsoft segnala come non raccomandate alcune configurazioni BitLocker via Group Policy che includono esplicitamente PCR7 nel profilo di validazione TPM.

Figura 4 – GPO

Figura 5 – GPO

La quarta cosa è distinguere tra server generici e Domain Controller. Un file server, un application server e un DC non hanno lo stesso impatto in caso di rollback, reboot loop o errore di installazione. Il Domain Controller va trattato come componente identitario critico, non come “un Windows Server qualsiasi con un ruolo in più”.

Una possibile checklist operativa

Prima della distribuzione degli aggiornamenti:

• verificare versioni e build dei Domain Controller;
• controllare se l’ambiente usa PAM o foreste multidominio;
• confermare lo stato di replica Active Directory;
• verificare backup e procedure di restore dei Domain Controller;
• controllare la disponibilità di almeno un DC funzionante per dominio e sito critico;
• validare configurazioni BitLocker e Secure Boot sui server interessati;
• testare gli aggiornamenti su un sottoinsieme limitato di sistemi.

Dopo l’installazione:

• controllare Event Viewer per errori LSASS, Kerberos, Netlogon, Directory Service e System;
• verificare autenticazione utente e computer;
• controllare replica AD con repadmin;
• verificare SYSVOL e Group Policy;
• controllare eventuali richieste anomale di BitLocker Recovery Key;
• documentare build, KB installate e comportamento osservato.

Figura 6 – Flusso logico

Il vero insegnamento

Questo episodio non significa che non bisogna installare gli aggiornamenti Microsoft. Sarebbe una conclusione sbagliata e pericolosa.

Significa invece che il patch management, soprattutto sui sistemi di identità, deve essere trattato come un processo di change management vero. Active Directory non è un componente accessorio dell’infrastruttura: è spesso la radice da cui dipendono autenticazione, autorizzazione, accesso alle risorse, gestione degli endpoint e integrazione con ambienti cloud e ibridi.

Per questo motivo i Domain Controller dovrebbero avere una procedura di aggiornamento dedicata, con finestre controllate, monitoraggio, rollback plan, verifica dei prerequisiti e comunicazione interna. Non basta sapere che una patch è “security”. Bisogna sapere cosa cambia, dove viene installata, su quali ruoli, con quale sequenza e con quale piano di emergenza.

Conclusioni

Gli aggiornamenti di aprile 2026 hanno ricordato una cosa che gli amministratori di infrastrutture Microsoft conoscono bene: la sicurezza non vive nel vuoto.

Una patch può chiudere vulnerabilità importanti, ma può anche introdurre problemi operativi significativi se distribuita senza controllo nei punti più sensibili dell’ambiente. E pochi punti sono sensibili quanto i Domain Controller.

La risposta corretta non è rimandare indefinitamente gli aggiornamenti. La risposta corretta è patchare meglio.

Con più test. Con più consapevolezza. Con più attenzione ai ruoli critici. E, soprattutto, con la certezza che Active Directory non è solo “vecchia infrastruttura”: è ancora il sistema nervoso di moltissime aziende.

Quando il sistema nervoso tossisce, tutta l’azienda se ne accorge.

Stay tuned!