• Guide, Sicurezza, Sistemi Operativi
• 13 Aprile 2026

Nell’articolo Quando Kerberos smette di essere indulgente. L’addio a RC4 – ICT Power avevamo lasciato Kerberos in una fase quasi psicologica: meno indulgente, più esplicito, meno disposto a coprire silenziosamente incoerenze che per anni sono rimaste in produzione senza fare troppo rumore. Gennaio 2026 aveva introdotto più visibilità. Aprile 2026, invece, è il momento in cui quella visibilità si trasforma in comportamento concreto. Non è più solo una questione di “osservare RC4”: è il punto in cui il fallback implicito smette di essere una stampella affidabile.

Il cambiamento da capire è semplice solo in apparenza: quando l’attributo msDS-SupportedEncryptionTypes non è valorizzato, i Domain Controller non devono più comportarsi come se RC4 fosse una scelta naturale “per compatibilità”. Con l’hardening collegato a CVE-2026-20833, la traiettoria indicata da Microsoft è chiara: da gennaio 2026 si osserva e si fa audit; da aprile 2026 entra in gioco l’enforcement di default; fino a luglio 2026 resta possibile un rollback manuale, poi anche quella rete di sicurezza viene rimossa.

Detto in modo brutale: non si rompe “Kerberos”. Si rompe la dipendenza da un comportamento implicito che in molti ambienti mascherava password troppo vecchie, account di servizio lasciati immutati da anni, appliance che parlano ancora un Kerberos da museo, trust configurati con inerzia più che con intenzione.

RC4 non scompare ma smette di essere il paracadute automatico

Il rischio è raccontarla male e dire che “Microsoft disabilita RC4”. La realtà è più sottile, e quindi più pericolosa. RC4 non evapora: smette di essere il comportamento implicito quando la directory non è stata configurata in modo chiaro. È per questo che gli ambienti più esposti non sono necessariamente quelli “vecchi”, ma quelli rimasti a metà: abbastanza moderni da dare per scontato AES, ma abbastanza trascurati da non aver mai verificato davvero chiavi disponibili, bitmask, SPN e reset password.

Se msDS-SupportedEncryptionTypes è nullo, il default si sposta verso AES128 + AES256; le richieste che continuano a vivere di RC4 o di negoziazioni legacy smettono di essere assecondate automaticamente. È il momento in cui l’assenza di una scelta diventa essa stessa una scelta, e pure sbagliata.

KB di aprile 2026 e build coinvolte

Al 13 aprile 2026 (Italia), gli aggiornamenti cumulativi di aprile (Patch Tuesday del 14 aprile 2026) non risultano ancora pubblicati nelle tabelle ufficiali di release history. Di conseguenza, i KB esatti di aprile 2026 dipendono dalla versione e verranno riportati nelle rispettive pagine “update history” dopo il rilascio.

Perché gli ambienti si rompono davvero

Qui entra in gioco la differenza che in molti lab è invisibile, ma in produzione fa male: supportare AES non significa avere davvero le chiavi AES disponibili. Un account può dichiarare un certo set di encryption types e continuare comunque a fallire, perché le chiavi AES non sono mai state generate. E le chiavi AES si generano quando la password viene impostata o reimpostata in un contesto compatibile, non per pura forza di volontà dell’amministratore o per telepatia del Domain Controller.

È qui che iniziano i problemi più fastidiosi:

• Servizi con SPN su account storici;
  
• NAS o appliance non Windows con keytab vecchi o supporto Kerberos parziale;
  
• Trust inter-forest rimasti con configurazioni legacy;
  
• Infrastrutture SMB o scenari come FSLogix che si appoggiano a una negoziazione rimasta permissiva troppo a lungo.
  

Microsoft ha anche esplicitato che l’assenza di eventi d’audit non basta a certificare la compatibilità di sistemi non Windows. Tradotto: non vedere errori non significa essere al sicuro; significa solo che potresti non aver ancora guardato nel posto giusto.

Timeline

Gennaio 2026: compare la telemetria utile. I Domain Controller iniziano a dare segnali più chiari, soprattutto tramite gli eventi KDCSVC 201-209, che aiutano a capire dove RC4 viene ancora usato o presunto.

14 aprile 2026: scatta il cambio di default annunciato. Non è più solo “guarda meglio”: è “comportati diversamente”. Gli oggetti con encryption types non espliciti vengono trattati in ottica AES, non più con indulgenza legacy.

Luglio 2026: finisce il periodo in cui si può ancora usare la chiave di rollback come stampella. Dopo quel punto, la finestra di tolleranza si chiude davvero.

Questo è il momento in cui Microsoft smette di avvertire e comincia a pretendere coerenza. Un po’ come un sysadmin paziente che per mesi ti manda alert gentili e poi un giorno cambia la policy. E, guarda caso, aveva ragione lui.

Dove guardare prima di aggiornare

Il primo consiglio pratico non è “disabilitare RC4 dappertutto”. Quello è il modo più rapido per trasformare un martedì di patching in una rievocazione storica dell’apocalisse. Il primo consiglio è: inventario, osservabilità, correlazione.

1. Eventi KDCSVC nel log System

Dopo gli update di gennaio 2026, Microsoft raccomanda di controllare il System log sui DC cercando gli eventi KDCSVC 201-209. Sono il primo punto da cui partire per capire quali servizi o account stanno ancora vivendo di presupposti RC4 o di configurazioni incomplete.

2. Eventi 4768 e 4769 nel log Security

Il secondo livello è il Security log, soprattutto l’evento 4769, per capire quali ticket di servizio stanno ancora usando RC4 e quali account o servizi sono coinvolti. Microsoft ha arricchito questi eventi proprio per rendere più facile distinguere tra ciò che l’account dichiara e ciò che il KDC ha realmente disponibile.

Nel contesto di Kerberos, 0x17 corrisponde a RC4-HMAC. È un controllo semplice, grezzo, ma molto efficace per iniziare a capire chi sta ancora nuotando nel passato.

Figura 1 – Esempio di ticket

Figura 2 – Esempio di log

3. Controllo dell’attributo msDS-SupportedEncryptionTypes

Molti account problematici emergeranno da un audit LDAP o direttamente da ADUC con Advanced Features abilitate, andando su Attribute Editor e verificando msDS-SupportedEncryptionTypes. Se l’attributo è nullo, non significa automaticamente “problema”, ma significa certamente “da verificare con priorità”.

Figura 3 – Attributo forzato

4. Verifica delle chiavi effettivamente disponibili

Questo è il punto che separa l’hardening dal folklore. Se un account di servizio è stato creato secoli fa e la password non è mai stata ruotata, potresti trovarti con un oggetto che sembra pronto per AES ma che in realtà non possiede le chiavi necessarie. In questi casi la remediation più concreta resta spesso il reset password controllato, coordinato con il team applicativo.

Gli scenari che faranno più male

Account di servizio con SPN

Sono il caso classico. IIS, SQL Server, servizi custom, middleware, connettori LDAP, applicazioni Java dimenticate in una VM che nessuno osa spegnere: se usano account di servizio vecchi e password statiche, sono i candidati naturali a diventare rumorosi dopo aprile. Non a caso sono anche i candidati preferiti nelle catene di Kerberoasting; quindi, mettere mano qui non è solo compatibilità: è riduzione reale della superficie d’attacco.

NAS, appliance e sistemi non Windows

Qui il pericolo è doppio: da un lato il supporto AES può essere incompleto o mal configurato; dall’altro i team Windows spesso non hanno visibilità sufficiente sul lato dispositivo. Keytab esportati anni fa, firmware vecchi, stack Samba non aggiornati: tutto questo entra improvvisamente nel radar.

Trust inter-forest

I trust legacy sono piccoli monumenti all'”abbiamo sempre fatto così”. Microsoft documenta chiaramente che in caso di mismatch sugli encryption types possono comparire errori come KDC_ERR_ETYPE_NOTSUPP, e che la correzione passa dalla riallineazione del trust per supportare AES.

FSLogix e profili su SMB

Il blog Microsoft dedicato a FSLogix è prezioso perché mostra un caso enterprise molto concreto: quando il backend SMB e l’integrazione AD dipendono ancora da RC4 o da attributi non impostati, l’impatto può toccare direttamente il montaggio dei profili e quindi l’operatività utente. È una di quelle situazioni in cui il problema sembra “di autenticazione”, ma il ticket arriva alla service desk come “non si apre il desktop”. Classico. Elegantissimo. Tossico.

Cosa fare davvero: playbook operativo

La strategia migliore, oggi, non è binaria. È progressiva.

Fase 1: aggiornare e osservare

Aggiorna i DC con gli update disponibili da gennaio 2026 in poi, raccogli eventi KDCSVC 201-209, analizza i 4768/4769, e crea una lista di account, servizi e sistemi che mostrano ancora dipendenze RC4 o configurazioni ambigue.

Fase 2: correggere i casi reali

Qui il lavoro è molto più utile:

• ruotare le password degli account di servizio storici;
  
• verificare e, dove serve, impostare in modo esplicito msDS-SupportedEncryptionTypes;
  
• aggiornare keytab e appliance;
  
• testare i trust cross-forest con AES.
  

Fase 3: governare il default

Una volta ridotto il rumore, puoi lavorare sulle policy di dominio o sui settaggi specifici per restringere davvero RC4. Ad esempio la GPO:

Network security: Configure encryption types allowed for Kerberos

Figura 4 – GPO

Fase 4: usare il rollback solo come airbag, non come stile di vita

Microsoft documenta la chiave di registro RC4DefaultDisablementPhase come meccanismo temporaneo di gating/rollback fino a luglio 2026. È utile per gestire emergenze e change window andate male, ma non dovrebbe diventare la scusa per rimandare la remediation vera. Mettere un cerotto sopra una dipendenza legacy non la rende meno legacy. Solo meno silenziosa.

Un esempio:

Cosa cambia nel flusso di autenticazione

Figura 5 – Nuovo flusso

La figura non rappresenta il flusso tecnico del protocollo Kerberos nel dettaglio, ma sintetizza l’evoluzione del comportamento del KDC nel percorso di hardening che culmina con l’enforcement di aprile 2026. Il punto chiave è il passaggio evidenziato in aprile, in cui, a parità di attributo msDS-SupportedEncryptionTypes nullo, il default smette di seguire una logica legacy e si sposta verso AES.

Nella parte iniziale del flusso non cambia nulla: il client invia una AS-REQ al KDC per richiedere un TGT, e il Domain Controller risponde con una AS-REP contenente il ticket iniziale e la chiave di sessione.

La differenza emerge nel passaggio successivo, quando il client usa il TGT per inviare una TGS-REQ e ottenere un service ticket verso uno specifico servizio. È proprio in questa fase che il KDC deve decidere quale tipo di cifratura usare per il ticket destinato allo SPN richiesto.

Nel diagramma sono rappresentati due comportamenti alternativi. Nel ramo superiore, relativo allo scenario pre-aprile 2026, il KDC applica il comportamento legacy: se l’attributo msDS-SupportedEncryptionTypes dell’account di servizio è nullo, il controller di dominio assume implicitamente un set di tipi di cifratura compatibili con ambienti storici, arrivando in alcuni casi a emettere ancora un ticket RC4. Questo è il motivo per cui, in molti ambienti, RC4 ha continuato a sopravvivere anche senza una configurazione esplicita.

Nel ramo inferiore, che rappresenta il comportamento da aprile 2026 in poi, la logica cambia. Se msDS-SupportedEncryptionTypes è nullo, il KDC non ricade più automaticamente su RC4, ma tratta la situazione con un default orientato ad AES. Il risultato è che il Domain Controller emette un ticket AES se il servizio è compatibile, oppure restituisce un errore come KDC_ERR_ETYPE_NOTSUPP se il servizio o l’account non sono in grado di supportare i tipi di cifratura richiesti.

La parte finale del flusso resta invariata: il client presenta il ticket al servizio tramite AP-REQ e, se tutto è coerente, ottiene accesso con la relativa AP-REP. In altre parole, il diagramma evidenzia che il vero cambiamento non riguarda l’intero protocollo Kerberos, ma il criterio con cui il KDC sceglie il tipo di cifratura del service ticket quando la configurazione dell’account non è esplicita.

Conclusioni

Il vero messaggio da portarsi a casa non è che RC4 sia improvvisamente diventato un problema nel 2026. Il problema c’era già. Solo che per anni Active Directory ha continuato a fare quello che molti sistemi legacy fanno benissimo: tenere insieme il presente e il passato con una quantità impressionante di pazienza. Ad aprile 2026 quella pazienza inizia a finire. E quando un’infrastruttura smette di essere indulgente, non sta diventando cattiva: sta solo smettendo di mentire.

Chi arriverà preparato vedrà questo aggiornamento come un passaggio necessario verso una postura Kerberos più sana. Chi arriverà impreparato lo vivrà come l’ennesimo patch Tuesday “che ha rotto tutto”. La differenza, come spesso accade, non la fa la patch. La fa ciò che abbiamo ignorato prima che la patch ci costringesse a guardarlo.

Stay tuned!