Dismissione di RC4 in Kerberos: prepararsi all’enforcement di luglio 2026

A partire dagli aggiornamenti cumulativi di gennaio 2026, Microsoft ha avviato un percorso di dismissione progressiva del cifrario RC4 (Rivest Cipher 4) all’interno del protocollo di autenticazione Kerberos. Il percorso si articola in tre fasi e culmina a luglio 2026, data in cui viene rimossa ogni possibilità di rollback e RC4 cessa di essere un cifrario implicitamente supportato dai Domain Controller. Alla base del cambiamento vi è la vulnerabilità CVE-2026-20833, che consente a un attaccante autenticato di sfruttare la debolezza crittografica di RC4 per condurre attacchi di tipo Kerberoasting e compromettere credenziali di service account.

L’impatto di questa transizione non è trascurabile. Ambienti Active Directory di lunga data contengono spesso account, servizi, appliance e dispositivi di terze parti che dipendono, in modo implicito o esplicito, dal cifrario RC4. Tra questi figurano in particolare le NAS joinate a dominio, i file server legacy, le stampanti di rete e le applicazioni industriali con stack Kerberos datati. In questo articolo analizziamo nel dettaglio gli scenari operativi che un amministratore deve valutare, con particolare attenzione al comportamento dei dispositivi non-Windows joinati a dominio, e descriviamo i workaround applicabili tramite Group Policy e configurazioni mirate.

Perché RC4 viene dismesso

Il cifrario RC4 è stato storicamente mantenuto in Kerberos per garantire compatibilità con sistemi legacy. Tuttavia, la sua debolezza crittografica lo rende vulnerabile ad attacchi offline di brute-force sui Ticket-Granting Service (TGS) emessi dal KDC. La tecnica di Kerberoasting sfrutta proprio questa debolezza: un attaccante autenticato richiede ticket di servizio cifrati con RC4 per account con Service Principal Name (SPN) e ne effettua il cracking offline, recuperando la password del service account.

Microsoft ha dichiarato ufficialmente, nella documentazione tecnica di Microsoft Learn, che il supporto a RC4 come tipo di cifratura assunto per i Domain Controller sarà disabilitato entro la fine del secondo trimestre 2026. L’alternativa, AES-SHA1 nelle varianti AES128 e AES256, è disponibile in tutte le versioni di Windows Server a partire da Windows Server 2008 e rappresenta oggi lo standard di riferimento.

Le tre fasi della dismissione

Il processo di dismissione si sviluppa su un arco temporale di sette mesi, strutturato in modo da consentire agli amministratori di individuare le dipendenze residue prima dell’enforcement definitivo. Le tre fasi sono le seguenti:

• Gennaio 2026 — Fase di Audit. L’installazione degli aggiornamenti cumulativi introduce nove nuovi event ID (da 201 a 209) nel System Event Log dei Domain Controller, oltre ad arricchire di informazioni gli eventi 4768 e 4769 del Security Log. In questa fase non viene bloccato alcun flusso di autenticazione: l’obiettivo è fornire visibilità sulle dipendenze RC4 presenti nell’ambiente. Viene inoltre introdotta la chiave di registro RC4DefaultDisablementPhase, che consente di anticipare manualmente l’enforcement impostando il valore a 2
• Aprile 2026 — Fase di Enforcement con rollback. Il valore DefaultDomainSupportedEncTypes (DDSET) utilizzato dal KDC cambia default, passando a 0x18 (AES128 + AES256). Gli account che non hanno un valore esplicito nell’attributo msDS-SupportedEncryptionTypes cesseranno di ricevere ticket RC4 in maniera implicita. Il rollback verso la modalità audit resta tecnicamente possibile tramite la chiave di registro
• Luglio 2026 — Fase di Enforcement definitivo. La chiave di registro RC4DefaultDisablementPhase viene ignorata dai Domain Controller aggiornati e la modalità audit non è più disponibile. RC4 continuerà a funzionare esclusivamente per gli account in cui è stato dichiarato esplicitamente nell’attributo msDS-SupportedEncryptionTypes. Dopo questa data non esiste più alcun meccanismo di fallback implicito

L’attributo msDS-SupportedEncryptionTypes e il bitmask Kerberos

Comprendere il funzionamento dell’attributo msDS-SupportedEncryptionTypes è la chiave per valutare l’esposizione del proprio ambiente. Si tratta di un bitmask che dichiara, per ciascun security principal (utente, computer, account di servizio, trust), quali tipi di cifratura Kerberos sono supportati dal corrispettivo sistema sottostante. Se l’attributo è nullo o pari a zero, il KDC applica il valore assunto definito dalla chiave DefaultDomainSupportedEncTypes — ed è proprio questo valore assunto che sta cambiando con gli aggiornamenti del 2026.

La tabella seguente riporta i valori più frequenti del bitmask e il loro significato operativo rispetto all’enforcement in corso:

Un aspetto spesso trascurato è che la presenza di un valore esplicito non equivale automaticamente alla compatibilità con l’enforcement. Un account configurato con 0x4 (solo RC4) è tecnicamente “popolato”, ma continuerà a fallire l’autenticazione dopo aprile 2026, perché non offre alcun cifrario AES negoziabile. L’attributo AD dichiara infatti ciò che il KDC assume supportato: se il sistema sottostante — sia esso una NAS, una stampante o un servizio custom — non implementa AES, l’attributo non può conferire una capacità che il dispositivo non possiede.

NAS joinate a dominio e dispositivi non-Windows: cinque scenari operativi

Le NAS joinate ad Active Directory rappresentano uno degli scenari più delicati dell’intera transizione. Si tratta di dispositivi che integrano uno stack Kerberos implementato dal vendor (Synology, QNAP, NetApp, Dell EMC, Buffalo e altri), con un livello di maturità e aggiornamento che varia sensibilmente da modello a modello e da versione firmware a versione firmware. La situazione non è binaria: esistono diversi scenari, ciascuno con un proprio profilo di rischio.

Scenario A — NAS con firmware recente e attributo msDS-SupportedEncryptionTypes esplicito

È lo scenario ideale. Durante il join al dominio — o successivamente, tramite uno script di re-registrazione — la NAS popola l’attributo msDS-SupportedEncryptionTypes del proprio computer account con un valore che include AES-SHA1 (tipicamente 0x18 o 0x1C). Il sistema operativo della NAS supporta nativamente AES128 e AES256, e il KDC emette ticket AES per le sessioni SMB, NFS Kerberos e per l’accesso amministrativo.

In questo caso l’enforcement di luglio 2026 non produce alcun impatto. L’attributo è esplicito, il valore include AES, e la NAS è in grado di elaborare correttamente i ticket ricevuti. Non è richiesta alcuna azione correttiva.

Scenario B — NAS con firmware recente ma attributo non valorizzato

Alcune NAS, in particolare quelle joinate a dominio diversi anni fa e mai sottoposte a rejoin, presentano un attributo msDS-SupportedEncryptionTypes non definito (valore null o zero). In questa condizione il KDC applica il valore di DefaultDomainSupportedEncTypes. Fino ad aprile 2026 questo default includeva RC4; a partire da quella data il default diventa AES-only (0x18).

Il comportamento post-enforcement dipende dalla reale capacità della NAS di negoziare AES:

• Se la NAS supporta AES nativamente, l’autenticazione continuerà a funzionare perché il client avviserà il KDC tramite il campo Advertized Etypes della propria capacità AES. Tuttavia, la configurazione resta fragile: eventi 4769 con errore KDC_ERR_ETYPE_NOTSUPP (0xE) potrebbero comparire in scenari di edge-case. È fortemente raccomandato popolare l’attributo con 0x18 per rendere esplicita la configurazione
• Se la NAS non supporta AES (firmware antico, stack Kerberos basato su librerie datate), l’autenticazione Kerberos fallirà completamente dopo aprile 2026. Gli utenti riceveranno errori di rete generici durante l’accesso alle condivisioni SMB; le connessioni WMI e PowerShell Remoting verso la NAS restituiranno l’errore 0x80090342. Nei log del Domain Controller comparirà l’evento 4769 con Failure Code: 0xE

Scenario C — NAS legacy con supporto solo RC4, attributo non valorizzato

Questo è il caso peggiore e, purtroppo, tutt’altro che raro in ambienti industriali o in realtà con ciclo di vita dell’hardware lungo. La NAS implementa uno stack Kerberos che supporta esclusivamente RC4, in alcuni casi ereditato da implementazioni Samba 3.x non aggiornate o da firmware proprietari mai portati allo standard AES. L’attributo msDS-SupportedEncryptionTypes non è valorizzato e il KDC, a partire da aprile 2026, tenterà di emettere ticket AES.

Il risultato è una rottura completa dell’autenticazione Kerberos verso la NAS. Il meccanismo è il seguente: il KDC, non ricevendo una dichiarazione esplicita nell’attributo e applicando il nuovo DDSET AES-only, emette un ticket cifrato con AES; la NAS, ricevendo un ticket che non è in grado di decifrare, rigetta la richiesta e la sessione SMB si interrompe. Dal punto di vista dell’utente, le condivisioni diventano irraggiungibili; dal punto di vista del Domain Controller, i log registrano richieste di ticket senza possibilità di negoziazione di un cifrario comune.

In assenza di un aggiornamento firmware che introduca il supporto AES (opzione da verificare come prima cosa con il vendor), l’unica mitigazione tecnica percorribile consiste nel dichiarare esplicitamente RC4 come cifrario supportato per quel singolo computer account, accettando il rischio di sicurezza residuo.

Scenario D — NAS con supporto solo RC4, attributo valorizzato con RC4

In questo scenario l’attributo msDS-SupportedEncryptionTypes del computer account è stato valorizzato a 0x4 (solo RC4) in fase di join, in modo coerente con le reali capacità della NAS. Contrariamente a quanto si potrebbe pensare, questa configurazione sopravvive all’enforcement di luglio 2026: come chiarito dalla documentazione ufficiale Microsoft, RC4 continuerà a funzionare per gli account che lo dichiarano esplicitamente.

Tuttavia, si tratta di una configurazione che rappresenta un debito tecnico e di sicurezza. Gli account con RC4 esplicitamente abilitato restano bersaglio privilegiato per gli attacchi di Kerberoasting, soprattutto se associati a SPN. Inoltre, dai Domain Controller basati su Windows Server 2025 non vengono più emessi Ticket-Granting Ticket (TGT) RC4: ciò significa che, pur continuando ad autenticarsi verso un dispositivo RC4-only, il dispositivo stesso non sarà in grado di autenticarsi ulteriormente verso altri servizi utilizzando Kerberos.

Scenario E — NAS che non supporta l’attributo msDS-SupportedEncryptionTypes

Esiste un ulteriore scenario, più sottile, in cui la NAS è tecnicamente joinata a dominio ma il suo processo di join non è mai stato in grado di scrivere o aggiornare l’attributo msDS-SupportedEncryptionTypes sul proprio computer account. Questo accade con implementazioni molto datate di Samba, con appliance che usano un bind LDAP limitato, o con dispositivi che trattano il join come pura autenticazione senza gestione degli attributi estesi del computer account.

Dal punto di vista di Active Directory, l’attributo risulta null e il comportamento segue quanto descritto nello Scenario B o C, a seconda delle reali capacità crittografiche del dispositivo. La differenza cruciale è che l’amministratore non può fare affidamento sulla NAS per mantenere l’attributo sincronizzato: occorre impostarlo manualmente da un Domain Controller tramite PowerShell o ADSI Edit, e verificare periodicamente che non venga sovrascritto a null al successivo reboot o rejoin del dispositivo.

Strategia di mitigazione: un approccio operativo a fasi

La strategia di mitigazione deve essere costruita in modo sequenziale, sfruttando la finestra di audit introdotta a gennaio 2026 per individuare le dipendenze e intervenire prima dell’enforcement. L’ordine operativo raccomandato è descritto nei paragrafi seguenti.

Fase 1 — Audit dell’ambiente

Il primo passo consiste nell’installare su tutti i Domain Controller il cumulative update di gennaio 2026 (o successivi). Questo aggiornamento abilita gli eventi di audit 201–209 e arricchisce di informazioni gli eventi 4768 e 4769 del Security Log. È importante sottolineare che l’installazione dell’update non introduce di per sé alcun blocco: serve esclusivamente a dare visibilità.

Microsoft mette a disposizione sul repository ufficiale microsoft/Kerberos-Crypto due script PowerShell fondamentali per la fase di audit:

• List-AccountKeys.ps1 — interroga il Security Event Log ed elenca le chiavi crittografiche disponibili per gli account rilevati. Consente di identificare gli account che possiedono solo chiavi RC4 e non dispongono di chiavi AES
• Get-KerbEncryptionUsage.ps1 — analizza l’effettivo utilizzo dei cifrari nelle richieste di ticket, con possibilità di filtrare per algoritmo specifico (ad esempio -Encryption RC4) per isolare i soli ticket emessi con il cifrario deprecato

Per ambienti di dimensioni maggiori è consigliabile centralizzare l’analisi tramite una soluzione SIEM (Microsoft Sentinel, Splunk, Elastic) o tramite Windows Event Forwarding verso un collector dedicato. Il periodo minimo di osservazione raccomandato è di due-tre settimane, così da intercettare anche i workload periodici quali backup notturni, job schedulati mensili e processi di riconciliazione.

Fase 2 — Censimento dei service account e dei computer account

Parallelamente all’audit dinamico, è necessario un censimento statico dell’attributo msDS-SupportedEncryptionTypes su tutti gli account di Active Directory. La query PowerShell seguente identifica i service account con SPN associato, che rappresentano il perimetro primario del rischio Kerberoasting:

Get-ADUser -Filter {ServicePrincipalName -like "*"} `
    -Properties msDS-SupportedEncryptionTypes, ServicePrincipalName |
  Select-Object SamAccountName, @{N="EncTypes";E={$_.'msDS-SupportedEncryptionTypes'}}

Una query analoga va eseguita su Get-ADComputer per identificare computer account — inclusi quelli delle NAS — privi di attributo valorizzato. Il valore decimale 28 corrisponde a 0x1C (RC4 + AES128 + AES256): questi account funzioneranno dopo luglio 2026, ma mantengono abilitato RC4 e andrebbero progressivamente portati a 0x18.

Fase 3 — Rimedi mirati

In funzione dei risultati dell’audit, si applicano i seguenti interventi correttivi, in ordine di priorità:

• Reset delle password dei service account sprovvisti di chiavi AES. Gli account creati prima dell’introduzione del supporto AES in Windows Server 2003, mai sottoposti a cambio password, non dispongono delle chiavi AES necessarie. Il semplice reset della password, eseguito su un Domain Controller moderno, genera automaticamente le chiavi AES128 e AES256
• Valorizzazione esplicita di msDS-SupportedEncryptionTypes. Per ciascun account identificato con attributo nullo e reale supporto AES, impostare il valore a 0x18. Per i computer account che rappresentano dispositivi con supporto misto (RC4 + AES), impostare a 0x1C come misura transitoria, pianificando la dismissione di RC4 al primo aggiornamento firmware utile
• Aggiornamento firmware dei dispositivi non-Windows. Contattare il vendor di NAS, stampanti e appliance per verificare la disponibilità di firmware che introducano il supporto AES-SHA1. Nella maggior parte dei casi i produttori principali (Synology DSM 6.2+, QNAP QTS 4.3+, NetApp ONTAP 9.x) dispongono di versioni compatibili
• Sostituzione dei dispositivi legacy non aggiornabili. Per hardware End-of-Life che non riceverà aggiornamenti, la sostituzione è l’unica strada sostenibile. Microsoft ha attivato un indirizzo dedicato, stillneedrc4@microsoft.com, per segnalare casi specifici di dispositivi di terze parti privi di supporto AES

Fase 4 — Transizione anticipata all’enforcement

Una volta completati i rimedi e verificata l’assenza di eventi di audit rilevanti per un periodo di almeno due settimane, è possibile anticipare manualmente l’enforcement senza attendere l’aprile 2026. L’operazione si effettua impostando la seguente chiave di registro su ciascun Domain Controller e riavviando la macchina:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters

Value: RC4DefaultDisablementPhase
Type:  REG_DWORD
Data:  2

Il vantaggio di questa strategia è poter osservare in modalità controllata le conseguenze dell’enforcement, mantenendo la possibilità di rollback impostando il valore a 1 (audit) e riavviando. Dopo luglio 2026 questa chiave viene ignorata e non fornisce più alcun meccanismo di mitigazione.

Workaround tramite Group Policy: Configure encryption types allowed for Kerberos

Quando l’intervento sul singolo attributo AD non è sufficiente — tipicamente in ambienti con parco macchine eterogeneo o quando si desidera applicare un profilo di cifratura uniforme a un’intera Unità Organizzativa — è possibile ricorrere a una Group Policy dedicata. La GPO agisce a livello di sistema operativo, influenzando sia i client che le richieste di ticket verso il KDC.

La policy di riferimento si trova nel seguente percorso della Group Policy Management Console:

Computer Configuration > Policies > Windows Settings > Security Settings >
Local Policies > Security Options >
Network security: Configure encryption types allowed for Kerberos

Le configurazioni tipiche sono due. Per un profilo AES-only, destinato a macchine e OU con tutti i componenti moderni, si selezionano esclusivamente AES128_HMAC_SHA1 e AES256_HMAC_SHA1. Per un profilo transitorio, che preserva la compatibilità con dispositivi legacy durante la fase di rimedio, si aggiunge RC4_HMAC_MD5 alle due opzioni AES.

Un aspetto cruciale è lo scoping della GPO. Applicare indiscriminatamente una policy AES-only all’intero dominio può produrre impatti a cascata difficili da diagnosticare. La raccomandazione è di:

• Segregare i computer account delle NAS e dei dispositivi legacy in una OU dedicata, applicandovi una GPO che mantenga RC4 tra i cifrari consentiti fino al completamento del piano di rimedio
• Applicare la GPO AES-only come policy di default sui server e sulle workstation moderne, verificandone prima l’efficacia su un pilota limitato
• Monitorare attivamente i log post-applicazione tramite gli script PowerShell già citati, per intercettare precocemente eventuali fallimenti di autenticazione

Workaround a livello di Domain Controller: DefaultDomainSupportedEncTypes

Quando l’eterogeneità dell’ambiente impedisce di configurare singolarmente tutti i computer account e la GPO rischia di essere troppo invasiva, è possibile agire sul valore assunto del KDC tramite la chiave di registro DefaultDomainSupportedEncTypes presente nel percorso HKLM\SYSTEM\CurrentControlSet\services\KDC di ciascun Domain Controller.

Impostando questa chiave con valore 0x1C (RC4 + AES128 + AES256) si forza il KDC ad assumere il supporto RC4 per tutti gli account privi di attributo esplicito, neutralizzando di fatto il cambio di default introdotto con l’aggiornamento di aprile 2026. Si tratta di una configurazione da utilizzare con estrema cautela, poiché reintroduce globalmente il rischio di Kerberoasting e va considerata esclusivamente come misura tampone per finestre di tempo limitate. Va inoltre sottolineato che, una volta installati gli aggiornamenti di luglio 2026, anche questa configurazione verrà progressivamente marginalizzata: l’evento 205 nel System Log continuerà a segnalare la configurazione come insicura, e futuri aggiornamenti potrebbero rimuoverne il riconoscimento.

Approccio selettivo: configurazione per singolo account

L’alternativa più chirurgica e di gran lunga preferibile consiste nel valorizzare esplicitamente l’attributo msDS-SupportedEncryptionTypes solo sugli account che ne hanno effettivamente bisogno. Per un computer account che rappresenta una NAS RC4-only, il comando è il seguente:

Set-ADComputer -Identity "NAS01" -Replace @{"msDS-SupportedEncryptionTypes"=28}

Questo approccio è preferibile perché isola il rischio al singolo dispositivo, mantiene la postura di sicurezza generale del dominio e consente una tracciabilità puntuale degli account per cui è stato concesso un trattamento speciale. È buona norma documentare ciascuna eccezione in un registro interno, con indicazione del dispositivo, della motivazione tecnica e della data prevista di dismissione dell’eccezione stessa.

Conclusioni

La dismissione di RC4 in Kerberos rappresenta un cambiamento strutturale del protocollo di autenticazione Active Directory. A differenza di altre hardening release, questa non si limita a modificare comportamenti di default: rimuove progressivamente la possibilità stessa di operare in modalità insicura, culminando a luglio 2026 con l’eliminazione dei meccanismi di rollback. L’azione preparatoria non è opzionale, e il costo dell’inazione si paga in termini di autenticazioni fallite in produzione, spesso su servizi e dispositivi di cui si era persa memoria progettuale.

La strategia vincente è quella di sfruttare appieno la finestra di audit aperta a gennaio 2026, identificare le dipendenze residue tramite gli strumenti ufficiali Microsoft, rimediare in ordine di priorità e anticipare l’enforcement nei segmenti dell’ambiente che lo consentono. Il caso delle NAS e dei dispositivi non-Windows joinati a dominio merita un’attenzione particolare: la combinazione tra supporto AES non garantito e attributi AD frequentemente non valorizzati può trasformare un aggiornamento ordinario in un incident di produzione. La valorizzazione esplicita dell’attributo msDS-SupportedEncryptionTypes, accompagnata da una GPO adeguatamente perimetrata, costituisce la combinazione operativa più robusta per attraversare la transizione senza interruzioni di servizio.