Active Directory: perché gli aggiornamenti Microsoft di aprile 2026 romperanno molti accessi Kerberos

L’aggiornamento cumulativo Microsoft in distribuzione nei prossimi giorni, a partire dal 14 aprile 2026, andrà a modificare il comportamento dei controller di dominio Active Directory. In particolare, cambierà il comportamento predefinito di Kerberos per tutti gli account Active Directory che non hanno valorizzato l’attributo msDS-SupportedEncryptionTypes. Si tratta di una novità attesa da tempo, ma che porta con sé effetti concreti e immediati sulle infrastrutture reali.

Per anni, molti ambienti aziendali hanno continuato a funzionare grazie a meccanismi impliciti di retrocompatibilità. Account di servizio dimenticati, appliance di rete, applicazioni legacy: tutti questi elementi spesso utilizzano sistemi di cifratura obsoleti senza che l’amministratore ne sia consapevole.

Il passaggio imposto da Microsoft rompe questo fragile equilibrio: da metà aprile 2026, gli account senza configurazione esplicita non useranno più l’algoritmo RC4 come fallback ma passeranno ad AES-SHA1; da luglio 2026, la modifica diventerà definitiva.

Kerberos, cifratura e attributi Active Directory: cosa cambia davvero

Kerberos è il protocollo di autenticazione predefinito nei domini Windows. Il meccanismo si basa su ticket crittografati generati dal KDC (Key Distribution Center), un servizio che opera sui controller di dominio. Ogni ticket viene cifrato utilizzando uno specifico algoritmo, selezionato in base ai metodi di cifratura supportati e dichiarati dall’account coinvolto.

Qui interviene l’attributo msDS-SupportedEncryptionTypes, un valore numerico che usa una bitmask (cioè una rappresentazione a singoli bit per indicare più opzioni contemporaneamente) per specificare quali algoritmi di cifratura sono supportati da un account. Quando questo valore non è configurato, il sistema adotta una logica implicita che permette comunque l’utilizzo di RC4, un algoritmo di cifratura più datato, anche in ambienti che dovrebbero utilizzare esclusivamente AES, considerato più sicuro.

La modifica introdotta da Microsoft elimina questo comportamento: l’assenza di valore non implica più compatibilità legacy. Il controller di dominio assume che l’account supporti AES e rifiuta RC4. Il risultato è netto: autenticazione negata se il servizio remoto non gestisce AES.

Perché il problema si presenta solo adesso

Molti ambienti Active Directory presentano una stratificazione di configurazioni accumulata negli anni. Account di servizio creati una decade fa, dispositivi NAS con stack Kerberos limitati, software verticali mai aggiornati: ogni elemento può avere requisiti diversi.

Finora, RC4 ha agito come una sorta di “collante” invisibile: anche quando non configurato esplicitamente, veniva utilizzato come soluzione di ripiego. La rimozione di questo fallback rende visibili tutte le incoerenze: servizi che funzionavano smettono improvvisamente di autenticarsi.

Il sintomo tipico è un’autenticazione fallita senza errori chiari lato applicativo. Nei log del controller di dominio compaiono eventi specifici, ma spesso sono ignorati o sottovalutati fino a quando non si ha un impatto diretto sul flusso di lavoro.

Come identificare gli account Active Directory ancora legati a RC4

Un controllo rapido passa dall’analisi dei log di sicurezza sui controller di dominio. Gli eventi 4768 e 4769 registrano rispettivamente la richiesta e l’emissione dei ticket Kerberos; il campo relativo al tipo di cifratura contiene un valore esadecimale che identifica l’algoritmo utilizzato (il codice 0x17) indica l’uso di RC4. Una semplice query PowerShell consente di filtrare questi eventi e individuare rapidamente gli account coinvolti:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4768,4769} -MaxEvents 20 | Where-Object { $_.Message -match '0x17' } | Format-List TimeCreated, Id, Message

Ogni risultato rappresenta un caso da analizzare. Non si tratta solo di verificare la configurazione dell’account, ma anche le capacità del sistema che richiede il ticket. Microsoft ha pubblicato anche strumenti dedicati come lo script che mostra le chiavi disponibili per ogni account o quello per individuare l’uso attivo di RC4.

Correzione pratica: configurare correttamente msDS-SupportedEncryptionTypes

L’intervento più diretto consiste nell’impostare esplicitamente msDS-SupportedEncryptionTypes sugli account coinvolti.

Il valore 24 (0x18) abilita AES128 e AES256, escludendo RC4. È la configurazione consigliata nella maggior parte dei casi.

Dopo la modifica, è necessario forzare la rigenerazione dei ticket: il comando klist purge elimina quelli presenti in cache e obbliga il sistema a richiederne di nuovi con le impostazioni aggiornate.

Un dettaglio spesso trascurato riguarda le password: se un account non ha mai aggiornato la password dopo l’introduzione di AES, potrebbe non disporre delle chiavi corrette. In questi casi, il reset della password è indispensabile.

Le policy di gruppo permettono di definire i tipi di cifratura consentiti lato client. L’impostazione chiave si trova in “Network security: Configure encryption types allowed for Kerberos“: è opportuno abilitare AES128, AES256, evitando di forzare RC4 a livello globale.

Se esistono sistemi che non supportano AES, la soluzione non è mantenere RC4 ovunque: conviene isolare questi casi in un’unità operativa separata, applicando una policy dedicata. In questo modo si limita l’esposizione senza compromettere l’intero dominio.

Kerberoasting: il rischio reale dietro RC4

La questione non riguarda solo la compatibilità ma la sicurezza. L’impiego dell’algoritmo RC4_HMAC_MD5, un metodo di cifratura ormai considerato debole, consente attacchi noti come Kerberoasting: un utente già autenticato nella rete può richiedere ticket di servizio associati a uno SPN (Service Principal Name, cioè l’identificativo di un servizio in ambiente Kerberos) e poi analizzarli offline per cercare di risalire alle password degli account.

Con RC4, il processo è rapido: strumenti come Hashcat possono decifrare password deboli in pochi minuti. Gli account di servizio rappresentano un bersaglio ideale, perché spesso hanno privilegi elevati e password statiche. Una singola credenziale compromessa può aprire la strada a un’escalation completa nel dominio: eliminare RC4 serve proprio a ridurre drasticamente la superficie di attacco. È proprio questa la motivazione che ha indotto Microsoft al “giro di vite”.

Gli aggiornamenti più recenti introducono anche indicatori specifici nei log dei controller di dominio. Gli eventi 201 e 202 nel registro System segnalano account che non saranno più compatibili con le nuove impostazioni. La presenza di questi eventi indica chiaramente che l’ambiente contiene configurazioni da correggere. Ignorarli significa rimandare un problema che si paleserà di certo con gli aggiornamenti di aprile e, in maniera definitiva, a luglio 2026.