Migrazione da RC4 ad AD: individua gli scenari di rottura nascosti nel tuo dominio di origine

Prova a immaginarlo.

Durante una normale migrazione di Active Directory, tutto sembra procedere per il meglio. Un account di servizio viene trasferito senza intoppi dal dominio di origine a quello di destinazione. Le autorizzazioni sembrano corrette. Le appartenenze ai gruppi sono intatte. La cronologia dei SID viene conservata.

Poi, una settimana dopo, l'applicazione associata a quell'account inizia a presentare malfunzionamenti intermittenti. Quando finalmente qualcuno collega i malfunzionamenti alla migrazione, l'help desk ha già 40 ticket aperti. E nessuno riesce a spiegarne il motivo.

Cosa è cambiato? L'account aveva chiavi Kerberos basate esclusivamente su RC4 nel sistema di origine. Gli strumenti di migrazione standard hanno copiato l'hash NTLM. Il dominio di destinazione — appena creato, aggiornato con le patch e con le impostazioni predefinite AES — non dispone di chiavi AES per quell'account.

E dopo il 14 aprile 2026, i DC aggiornati non ricorreranno più implicitamente alla crittografia RC4 per gli account privi di una configurazione RC4 esplicita. L'autenticazione semplicemente non funzionerà più.

Se state portando avanti un progetto di migrazione, consolidamento o gestione delle identità basata su rapporti di fiducia in Active Directory che si protrarrà oltre la scadenza del 4 luglio 2026 per l'applicazione delle nuove norme, questo rischio potrebbe già essere presente nel vostro ambiente.

Nel blog Come verificare la presenza della crittografia RC4 nel proprio ambiente, i miei colleghi Guido Grillenmeier e Rich Peckham forniscono query di esempio che puoi utilizzare come modelli per verificare il tuo ambiente e individuare gli account che dipendono da RC4.

Ciò di cui hai bisogno ora è un piano d'azione che ti aiuti a prevenire eventuali problemi con l'account.

Cosa imparerai in questo articolo

• Dove è più probabile che si verifichino errori di migrazione legati a RC4
• I tipi di guasti che possono verificarsi e a cosa prestare attenzione
• Come valutare sistematicamente il proprio ambiente e individuare gli account a rischio di interruzione del servizio
• Quali strumenti gratuiti possono aiutarti nella tua ricerca
• Misure da adottare subito per prepararsi al passaggio al sistema AES

Perché i progetti di migrazione sono particolarmente esposti alle modifiche apportate a RC4?

Il calendario di dismissione di RC4 è ben documentato.

• Gennaio 2026: Microsoft ha introdotto la funzione di controllo e la RC4DefaultDisablementPhase chiave di registro.
• Aprile 2026: Microsoft ha modificato l'impostazione predefinita del KDC, limitandola al solo AES, per gli account che non dispongono del msDS-SupportedEncryptionTypes attributo impostato esplicitamente.
• Luglio 2026: Microsoft elimina la modalità di controllo e smette di applicare il RC4DefaultDisablementPhase ripristinare completamente la chiave di registro, lasciando che solo gli account con eccezioni RC4 esplicite possano ancora ricevere ticket RC4.

Il post di Semperis dedicato alla procedura di verifica illustra in dettaglio il processo di rilevamento in condizioni di stabilità. Ciò che tale procedura non tratta è lo scenario di migrazione, in cui il rischio si manifesta in tre modi specifici:

• Le migrazioni comportano il trasferimento degli account oltre i confini di sicurezza. Un account che oggi viene autenticato correttamente nell'ambiente di origine potrebbe non superare l'autenticazione nel momento in cui viene trasferito in un ambiente di destinazione con criteri di sicurezza più rigorosi, anche se i criteri dell'ambiente di origine sono permissivi.
  
• Gli strumenti di migrazione gestiscono le credenziali in modo asimmetrico. Gli strumenti di migrazione standard copiano l'hash NTLM ma non le chiavi AES. La serie "AD Hardening" di Microsoft, parte 4, lo spiega chiaramente: se il dominio di destinazione non supporta RC4, sarà necessario reimpostare la password dell'account nel dominio di destinazione affinché Kerberos funzioni. Ciò vale per ogni account le cui chiavi sul lato di origine siano esclusivamente RC4.
  
• Gli errori sono silenziosi. Le dipendenze RC4 in stato stazionario si manifestano come eventi KDCSVC 201–209. Gli errori causati dalla migrazione spesso non lo fanno. Al contrario, si presentano come errori dell'applicazione senza alcun collegamento evidente al tipo di crittografia. La causa principale deve essere dedotta, non osservata.

Nel loro insieme, questi fattori rendono insufficiente una singola query PowerShell. I team di migrazione necessitano di un processo di analisi strutturato.

Quali account sono a rischio di errori di migrazione legati a RC4?

Prima di proseguire, una precisazione. Gli aggiornamenti di aprile 2026 sono stati implementati senza causare i problemi diffusi che alcuni media del settore avevano previsto, almeno in base a quanto abbiamo osservato sul campo. Nella maggior parte degli ambienti dei clienti, la crittografia Kerberos configurata è rimasta intatta e l'autenticazione procede normalmente.

Questo post non vuole allarmare.
Ciò che sostiene è che persiste una modalità di guasto specifica e identificabile — e che i passaggi alla nuova piattaforma sono proprio gli eventi più suscettibili di metterla in luce.

Tre condizioni che mettono a rischio un conto

Gli errori di migrazione silenziosi relativi a RC4 si verificano solitamente quando si verificano tutte e tre le seguenti condizioni:

• AES indicato ma non fornito. L'account msDS-SupportedEncryptionTypes L'attributo viene popolato con i bit AES oppure risulta nullo se l'impostazione predefinita del dominio è AES. Il KDC interpreta questo come "AES supportato" e tenta di emettere ticket AES per l'account.
  
• Nessun materiale relativo alle chiavi AES nel sistema di destinazione. Le chiavi AES vengono generate solo quando viene impostata una password in un ambiente DFL 2008 o versioni successive. Gli account a più alto rischio sono quelli vecchi, mai reimpostati, e quelli migrati in cui le credenziali sono state copiate senza rigenerare le chiavi AES. L'attributo indica AES; le chiavi indicano solo RC4.
  
• L'account sta effettuando l'autenticazione tramite Kerberos. L'errore si manifesta solo quando l'account richiede un ticket Kerberos. In quel momento, il KDC tenta l'autenticazione AES (come da condizione 1), non trova alcuna chiave AES (come da condizione 2) e l'autenticazione fallisce. Gli account inattivi e quelli che si autenticano solo tramite NTLM rimangono invisibili perché lo stato di errore non viene mai attivato.

Quali sono i tipi di conto più a rischio?

Nella maggior parte delle aziende, l'insieme degli account a rischio non è casuale. Tende infatti a concentrarsi in cinque tipologie di account: categorie che vale la pena approfondire in qualsiasi discussione preliminare alla migrazione.

• Account di servizio ereditati dalla prima implementazione di Active Directory, creati tra il 2000 e il 2010 e mai sottoposti a rotazione delle password. Questi rappresentano la categoria più frequente all’interno della popolazione a rischio.
• Conti con PASSWD_CANT_CHANGE o DONT_EXPIRE_PASSWORD Flag UAC impostati. Questi flag sono strettamente correlati alle password impostate una sola volta al momento della configurazione iniziale e mai modificate.
• Sistemi non Windows con credenziali Kerberos memorizzate localmente: host Linux con file keytab, server di applicazioni Java con credenziali hardcoded krb5.conf, dispositivi NAS aggiunti al dominio, dispositivi di rete con credenziali memorizzate nella cache.
• Account di servizio intestati ad amministratori che hanno lasciato l'incarico, per i quali esistono le credenziali ma si è persa la conoscenza istituzionale di ciò che dipende da tali account.
• Account di computer in cui la rotazione automatica delle password non funziona correttamente: computer rimasti a lungo offline, account abbandonati, account con PasswordNeverExpires impostato in modo errato.

In media, quanti account potrebbero essere interessati dal problema RC4 durante la migrazione ad Active Directory?

Sulla base dell'esperienza sul campo maturata nel corso di diversi progetti di migrazione, la percentuale di account a rischio in un determinato ambiente rientra solitamente in questi intervalli.

Tipo di ambiente	Popolazione media a rischio
Ambienti Greenfield realizzati dopo il 2010 con una solida governance delle identità	0–10 conti
Tipica impresa di medie-grandi dimensioni con almeno un decennio di esperienza con Active Directory	20–200 conti
Ambienti creati tramite fusioni e acquisizioni senza un successivo consolidamento dell'identità	Da alcune centinaia a poche migliaia
Ambienti acquisiti in cui l'organizzazione acquirente non ha ancora completato la razionalizzazione delle identità	Molto variabile, a volte superiore alla fascia delle fusioni e acquisizioni

NOTA: Questi sono spunti di partenza per definire l'ambito delle discussioni, non dati quantitativi. Il numero effettivo di utenti potrà essere confermato solo attraverso il lavoro di analisi che svolgeremo insieme.

Perché il passaggio al nuovo sistema AD concentra i rischi

Questi account basati su RC4 possono rimanere attivi in produzione per anni senza presentare problemi. La loro autenticazione Kerberos si basa su ticket memorizzati nella cache e su una ri-autenticazione sporadica, il che fa sì che le chiavi AES mancanti rimangano invisibili durante il normale funzionamento.

Il passaggio alla nuova piattaforma cambia questa situazione. Invalida simultaneamente le credenziali memorizzate nella cache per l'intera popolazione, impone l'invio di nuove richieste AS-REQ e TGS-REQ in un breve lasso di tempo e fa emergere la modalità di errore proprio nel momento in cui le conoscenze del responsabile sono ormai obsolete e l'analisi delle cause alla radice risulta più complessa.

Le due modalità di guasto che stai cercando

Prima di addentrarci nella metodologia di analisi, è utile definire le due categorie distinte di rischio di rottura che si sta cercando di individuare.

• Deriva latente della configurazione. Account che oggi sembrano a posto ma che non supereranno i controlli di conformità: la popolazione a rischio definita in precedenza. Gli attributi di AD indicano una cosa, mentre il materiale crittografico effettivo ne indica un'altra. Questo non è possibile rilevarlo interrogando solo gli attributi di AD.
  
• Rischio legato al meccanismo di migrazione. Errori che derivano specificamente dal modo in cui la migrazione trasferisce i dati relativi all'identità. Questi non compaiono nei dati di telemetria in condizioni di stabilità su nessuna delle due parti e includono:
  • Dipendenze storiche del SID
  • Scenari a doppio accesso in cui la stessa identità logica effettua l'autenticazione da entrambi i domini
  • Valore DFL inferiore a quello del 2008 (si innesca silenziosamente ad ogni reimpostazione della password successiva alla migrazione)
  • Discordanze negli attributi di fiducia.

Entrambe le categorie richiedono prove concrete. Nessuna delle due viene individuata in modo affidabile dagli strumenti che analizzano una sola fonte di dati.

Come prepararsi al passaggio da RC4 ad AES: una metodologia di analisi della migrazione in sei fasi

Comprendere il contesto in cui operano gli account che utilizzano l'algoritmo RC4 — nonché i potenziali tipi di errore che potresti incontrare — ti fornisce un quadro di riferimento su cui basarti mentre procedi con l'individuazione di tali account e la loro configurazione per l'AES.

Questa è la sequenza collaudata sul campo che utilizziamo con i clienti nei progetti di migrazione. Ogni fase fornisce dati che vanno ad alimentare la matrice finale degli scenari di interruzione.

Fase 0: Definire le regole del gioco

Prima di individuare eventuali problemi, è opportuno documentare sia l'ambiente di origine che quello di destinazione. L'asimmetria tra i due costituisce di per sé un'area di rischio primaria.

Per ogni dominio, registrare:

• Livello funzionale delle foreste e dei domini
• Versione del sistema operativo di ogni DC
• Ultimo aggiornamento cumulativo
• Il valore di RC4DefaultDisablementPhase su ogni controller di dominio (DC)

È possibile che alcuni centri di distribuzione non dispongano di RC4DefaultDisablementPhase o DefaultDomainSupportedEncTypes non è stata impostata affatto. Ciò significa solitamente che l'impostazione non è stata configurata in modo esplicito e che il DC sta seguendo il comportamento predefinito corrente per il proprio sistema operativo e livello di patch.

Ciò che conta ora è se tale comportamento efficace sia coerente all'interno dell'ambito e tra la lingua di partenza e quella di arrivo.

      $path = 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\' +
    'Policies\System\Kerberos\Parameters'
Invoke-Command -ComputerName (Get-ADDomainController -Filter *).HostName -ScriptBlock {
    Get-ItemProperty -Path $using:path -ErrorAction SilentlyContinue |
        Select-Object PSComputerName, RC4DefaultDisablementPhase,
                               DefaultDomainSupportedEncTypes
}

Verificare la presenza di asimmetrie: se un dominio di origine con DFL 2003 e fase non impostata viene associato a un dominio di destinazione con DFL 2016 già in fase 2, tutti gli account migrati privi di chiavi AES smetteranno di funzionare al momento del passaggio.

Nota per tutti i server DC con Server 2012 o 2012 R2 con ESU scadute: questi non riceveranno le patch di luglio 2026 e sono fonti RC4 non modificabili.

Se le chiavi di registro mancano: verificare la versione del sistema operativo del DC, il livello delle patch e se altri DC dello stesso dominio presentano valori espliciti. Il campanello d'allarme non è l'assenza della chiave in sé, ma una situazione eterogenea in cui alcuni DC si trovano effettivamente in uno stato di comportamento e altri in un altro.

Considerare la discrepanza tra sorgente e destinazione come un segnale di rischio: la mancanza di chiavi nella sorgente unita a impostazioni di fase esplicite nella destinazione, oppure valori predefiniti nulli da un lato ed eccezioni RC4 esplicite dall'altro, sono proprio le combinazioni che nascondono scenari di interruzione della migrazione fino al momento del passaggio.

Documentare il trust di migrazione: Un trust con msDS-SupportedEncryptionTypes l'impostazione a 0x4 (solo RC4) garantisce che il punto di rottura si verifichi nel luglio 2026. Un trust con l'attributo impostato su null segue il più recente comportamento predefinito di AES ed è molto meno probabile che raggiunga il punto di rottura rispetto a un trust esplicitamente fissato su RC4.

Fase 1: Verificare che entrambi i domini siano in grado di rilevare il traffico RC4

Non puoi trovare ciò che non registri. Verifica l'auditing Kerberos su ogni DC in entrambi i domini:

      auditpol /get /subcategory:"Servizio di autenticazione Kerberos"
auditpol /get /subcategory:"Operazioni sui ticket di servizio Kerberos"

Entrambi dovrebbero segnalare sia i successi che gli errori. Se ciò non avviene, applicare l'oggetto Criteri di gruppo (GPO) standard per il controllo di Kerberos all'unità organizzativa (OU) del controller di dominio prima di procedere.

Sui server DC aggiornati con patch fino a gennaio 2026 o successive, il registro di sistema dovrebbe registrare anche gli eventi KDCSVC del provider compresi tra 201 e 209. La totale assenza di tali eventi in un ambiente con applicazioni legacy note indica solitamente una lacuna nella registrazione piuttosto che un ambiente pulito; pertanto, è necessario verificare l'applicazione delle patch e la raccolta dei dati prima di dare per scontato che non vi sia alcuna vulnerabilità RC4.

Prestare attenzione anche alla visibilità parziale: attività di auditing attivate su alcuni DC ma non su altri, eventi inoltrati solo da una parte dell'infrastruttura o finestre di conservazione troppo brevi per rilevare gli account di servizio a bassa frequenza.

Fase 2: Individuazione del livello di configurazione

Questa fase individua gli scenari di interruzione rilevabili esclusivamente dagli attributi di AD. La soluzione più rapida è quella open source RC4-ADAssessment Modulo PowerShell, da eseguire su entrambi i domini:

      Install-Module -Name RC4-ADAssessment
Import-Module RC4-ADAssessment

Invoke-RC4Assessment -Domain source.contoso.com -ExportResults
Invoke-RC4Assessment -Domain target.contoso.com -ExportResults

Questo modulo rileva:

• Configurazione della crittografia DC
• Crittografia basata sulla fiducia
• Durata della password KRBTGT
• Tutti gli account di servizio contrassegnati come "solo RC4" o "con DES abilitato"
• Conti presso il USE_DES_KEY_ONLY Flag UAC
• Account con eccezioni RC4 esplicite
• Account con password non aggiornate

Ogni risultato viene esportato con comandi di correzione pronti per essere copiati e incollati. Considera l'output come un elenco di candidati in ordine di priorità piuttosto che come una prova definitiva. La Fase 2 indica dove approfondire, ma sono i dati degli eventi e il contesto dell'applicazione a confermare l'effettivo verificarsi di un problema di migrazione.

Presta particolare attenzione agli account di servizio i cui PasswordLastSet è antecedente all'aggiornamento del dominio di origine alla versione DFL 2008. Si tratta di candidati ad alta priorità appartenenti alla popolazione a rischio sopra definita, i quali dovrebbero essere verificati sulla base dei dati relativi agli eventi e alla storia migratoria.

Fase 3: Analisi comportamentale

La configurazione indica ciò che è consentito. Gli eventi indicano ciò che sta realmente accadendo. Spesso non coincidono.

Esegui la valutazione con l'analisi del registro eventi abilitata oppure esegui una query direttamente su Sentinel o Splunk:

      Invoke-RC4Assessment -Domain source.contoso.com `
-AnalyzeEventLogs -EventLogHours 168 -ExportResults

Il risultato più significativo è la discrepanza tra la configurazione AES e l'utilizzo effettivo di RC4: account per i quali AD indica "Supporto AES", ma i registri degli eventi mostrano l'emissione di ticket RC4. Questa discrepanza rappresenta proprio il tipo di errore che emergerà durante la migrazione.

Per quanto riguarda in particolare i progetti di migrazione, esegui anche le richieste TGS tra domini. Tra 4769 eventi, cerca i ticket di assistenza in cui ServiceName si trova nell'altro regno e TicketEncryptionType è 0x17. Il traffico RC4 tra domini diversi funge da indicatore di allarme per i fallimenti del percorso di fiducia durante la migrazione in fase di applicazione delle misure; pertanto, anche i casi rilevati in numero limitato meritano un'indagine approfondita, poiché l'applicazione interessata potrebbe essere fondamentale per l'attività aziendale.

Presta attenzione anche agli account di servizio che effettuano l'autenticazione solo durante le finestre di elaborazione batch, le operazioni di fine mese o i processi pianificati; è facile trascurarli nelle finestre di raccolta brevi e spesso sono proprio questi a causare le sorprese più spiacevoli durante il passaggio al nuovo sistema.

Fase 4: Individuazione a livello di applicazione

È proprio qui che la maggior parte delle migrazioni fallisce, e dove gli strumenti compatibili con Active Directory offrono la minore visibilità.

Eseguire uno scan su ogni host Linux, Java e dispositivo di rete che utilizza Kerberos basato su AD.

Elenco dei file keytab; qualsiasi cosa che contenga solo arcfour-hmac Le voci sono protette con RC4. È probabile che esistano ancora alcuni sistemi non Windows che utilizzano keytab generati anni fa.

Controlla /etc/krb5.conf per valori fissi default_tkt_enctypes o permitted_enctypes indicando solo RC4. Entrambe smetteranno di funzionare dopo luglio 2026, indipendentemente da ciò che farà AD; inoltre, per aggiornare il keytab in base al dominio di destinazione è necessario che l'account migrato disponga di chiavi AES, il che ci riporta ai risultati della Fase 2.

Per ogni applicazione che utilizza l'autenticazione Kerberos, guidare il proprietario attraverso:

• L'account di servizio attualmente in uso e il suo msDS-SupportedEncryptionTypes valore
• Dove è ospitata l'applicazione
• Se è in uso un keytab e quando è stato generato
• Se la documentazione del fornitore specifica i tipi di crittografia Kerberos richiesti
• Se l'autenticazione preliminare utilizza RC4 con pin

È probabile che vi siano lacune nella documentazione. Molti proprietari non sapranno quando è stato generato il keytab né se il fornitore supporti correttamente l'AES, e questa incertezza costituisce di per sé un utile indicatore di rischio.

Verificare inoltre la presenza di configurazioni di crittografia hardcoded in punti in cui il rilevamento degli attributi AD non raggiunge la sicurezza di rete:

• Il Network security: Configure encryption types allowed for Kerberos Impostazione GPO
• Server collegati di SQL Server
• Identità dei pool di applicazioni IIS con password non aggiornate
• App Java con -Dsun.security.krb5.permitted_enctypes Opzioni della JVM

Fase 5: Rischi specifici della migrazione

Gli scenari di interruzione che analizzeremo in questa fase si verificano esclusivamente durante il passaggio alla migrazione. Si tratta di caratteristiche del meccanismo di migrazione piuttosto che dei singoli domini in condizioni di stabilità.

Analizza la gestione delle password del tuo strumento di migrazione. Se lo strumento copia le password, copia tutte le credenziali presenti. Un account che nella fonte utilizza solo chiavi RC4 arriverà nella destinazione con solo chiavi RC4. La misura di mitigazione standard — il ripristino forzato della password dopo la migrazione — può compromettere il funzionamento dei servizi correlati se l'applicazione è in esecuzione.

Ogni account di servizio deve disporre di un piano documentato per il ripristino post-migrazione che preveda una finestra di manutenzione.

Valutate con obiettività le diverse strategie di sincronizzazione delle password. Alcuni strumenti di migrazione offrono filtri di sincronizzazione delle password che rilevano le modifiche sui DC di origine e le riproducono su quelli di destinazione. Questi strumenti risolvono effettivamente il problema della generazione delle chiavi AES sul sistema di destinazione, ma:

• Installare un percorso di codice privilegiato sui DC di origine
• Esporre temporaneamente il testo in chiaro nella memoria
• Attivare solo in caso di modifica della password (escludendo completamente gli account inattivi e gli account di servizio senza rotazione delle password)
• Si corre il rischio operativo qualora il filtro non segnali il malfunzionamento

L'uso di tali strumenti è legittimo in contesti di coesistenza circoscritti, in cui i compromessi sono documentati e accettati, ma non può sostituire il lavoro di analisi di cui sopra.

Elencare gli scenari di funzionamento duale. Durante la finestra di migrazione, gli utenti e i servizi potrebbero essere presenti sia nell'ambiente di origine che in quello di destinazione. Identificare i casi in cui la stessa identità logica effettua l'autenticazione da entrambe le parti, in genere nell'ambito di rapporti di fiducia tra domini, federazioni o tenant Entra ID sincronizzati.

Ognuno di essi rappresenta un potenziale punto di interruzione, poiché la negoziazione della crittografia varia a seconda della parte coinvolta.

Verificare le dipendenze relative alla cronologia SID. La cronologia SID garantisce l'accesso alle risorse; tuttavia, le chiavi di crittografia sono indipendenti. Un'applicazione che effettua l'autorizzazione tramite la cronologia SID ma emette ticket utilizzando le chiavi dell'account di destinazione potrebbe non funzionare correttamente se tali chiavi supportano solo l'algoritmo RC4.

Verificare che il DFL di destinazione sia almeno 2008. Nei processi di consolidamento che coinvolgono ambienti acquisiti, talvolta il DFL di destinazione risulta inferiore al previsto. Al di sotto del DFL 2008, la reimpostazione delle password non genera chiavi AES, pertanto l'intero piano di reimpostazione post-migrazione fallisce senza generare alcun avviso. Verificare prima del passaggio. Non durante.

Il vero rischio in questa fase risiede nelle combinazioni, non nei singoli fatti. Ad esempio:

• Migrazioni con copia delle password senza un intervallo di tempo documentato per la reimpostazione
• Identità a doppio funzionamento senza verifica percorso per percorso
• La cronologia SID viene considerata una soluzione per l'autenticazione
• Un problema relativo al DFL di destinazione individuato solo dopo il passaggio alla fase pilota

Si tratta di modelli specifici legati alla migrazione che trasformano risultati gestibili in scenari di interruzione del servizio.

Fase 6: Creare la matrice degli scenari di interruzione

Il risultato delle prime cinque fasi non è un semplice elenco di rischi. Si tratta di una matrice degli scenari di interruzione: una riga per ogni modo identificabile in cui la migrazione può fallire. Mantienila concisa. Per ogni riga, descrivi lo scenario, cosa lo innesca, come si manifesterà e l’azione necessaria prima del passaggio.

I risultati delle fasi 2, 3 e 4 costituiscono solitamente le prime righe.

La Fase 5 introduce gli scenari relativi esclusivamente alla migrazione che non compaiono nell'analisi dello stato stazionario.

Una volta compilata, questa matrice funge da strumento di monitoraggio del passaggio e costituisce la base per la decisione di procedere o meno.

Scenario	Grilletto	Come si manifesta	Azioni da intraprendere prima del passaggio
Account di servizio migrato con AES configurato ma senza chiavi AES	Transizione o prima richiesta Kerberos	L'autenticazione dell'app non va a buon fine dopo la migrazione; i processi pianificati o i servizi iniziano a non funzionare correttamente una volta scaduti i ticket memorizzati nella cache	Reimpostare la password nel dispositivo di destinazione, verificare la generazione della chiave AES, testare nuovamente l'app e programmare la modifica in una finestra di manutenzione
Host Linux o Unix con un keytab che supporta solo RC4	Luglio 2026: entrata in vigore o migrazione al dominio di destinazione	L'autenticazione Kerberos non riesce dall'host non Windows; il servizio passa alla modalità di ripiego o si arresta	Rigenerare il keytab con credenziali compatibili con AES dopo aver verificato che l'account migrato disponga di chiavi AES
Fiducia tra domini associata esplicitamente a RC4	Entrata in vigore nel luglio 2026	Le richieste di ticket tra regni falliscono durante la coesistenza o l'accesso graduale	Eliminare l'impostazione di affidabilità "solo RC4" e verificare il corretto funzionamento dell'affidabilità tramite traffico di test diretto prima del passaggio
Dominio di destinazione al di sotto del DFL 2008	Piano di ripristino post-migrazione	La reimpostazione della password sembra andare a buon fine, ma le chiavi AES non vengono mai generate e l'app continua a non funzionare	Aumentare il DFL target prima della migrazione, oppure riprogettare il percorso di correzione prima del primo progetto pilota
Configurazione Kerberos su Java, appliance o locale impostata in modo fisso su RC4	Passaggio al nuovo sistema, applicazione delle norme o prima richiesta di un nuovo biglietto	Un livello dell'app non funziona correttamente, nonostante le impostazioni sul lato AD sembrino corrette	Eliminare il pinning RC4, verificare la compatibilità del fornitore con AES e testare il percorso esatto dell'applicazione prima della messa in produzione
Identità a doppio funzionamento con autenticazione diversa tra origine e destinazione	Finestra di coesistenza o migrazione graduale	Il comportamento degli accessi varia a seconda del dominio, dell'host o del percorso, con conseguenze disomogenee per gli utenti	Documentare il comportamento di ciascun percorso, ridurre le sovrapposizioni ove possibile e verificare esplicitamente la coesistenza dei percorsi

Cosa troverai effettivamente

In tutti i progetti relativi alla migrazione, i risultati più significativi rientrano solitamente in quattro categorie:

• Account di servizio con AES configurato ma privi di chiavi AES. Si tratta spesso di account obsoleti, mai reimpostati, oppure di account migrati in cui le credenziali sono state copiate senza rigenerare le chiavi AES. L'attributo AD non è attendibile. La correlazione dei registri eventi della Fase 3 è l'unico modo affidabile per individuarli. Sono anche i più facili da correggere. Un ripristino della password in un ambiente DFL 2008 o superiore genera le chiavi AES. A volte si consigliano due ripristini sequenziali con un intervallo di tempo tra l'uno e l'altro come misura di sicurezza per la replica.
• Host Linux con keytab che utilizzano esclusivamente RC4. SSSD, Samba, Apache mod_auth_kerb, PostgreSQL con GSSAPI: tutte soluzioni comuni, che generano file keytab in base ai tipi di crittografia disponibili al momento della generazione. La soluzione consiste nel ricalcolare le chiavi in base al dominio di destinazione dopo la migrazione, ma ciò richiede che l'account migrato disponga già di chiavi AES.
• Il DFL dell'ambiente acquisito riserva delle sorprese. Quando l'entità acquisita è quella più piccola, o quando i consolidamenti avvengono nella direzione sbagliata, il DFL risulta inferiore a quello del 2008 e nessuno se ne accorge fino al momento del passaggio. Verificare nella Fase 0; verificare nuovamente prima di ogni fase di migrazione.
• Trust con attributi RC4 espliciti. Meno comune rispetto agli altri, ma di grande impatto quando presente. Un trust con msDS-SupportedEncryptionTypes = 0x4 comporterà il fallimento del meccanismo di migrazione stesso, non solo di account specifici.

Se il tempo a disposizione è limitato, date la priorità alla correlazione della Fase 3 (configurazione AES ma utilizzo di RC4) e all'inventario dei keytab della Fase 4. Insieme, questi due passaggi producono in genere il 60–80% dell'elenco effettivo delle violazioni.

Strumenti e risorse

Il lavoro di individuazione descritto sopra può essere realizzato utilizzando strumenti open source e comandi nativi di Active Directory. Di seguito sono riportate alcune risorse affidabili per l'individuazione e la mitigazione degli account che dipendono dall'algoritmo RC4; tutte queste risorse sono disponibili gratuitamente.

• Guida pratica alla verifica di Semperis RC4 : Come verificare la propria infrastruttura per la crittografia RC4, di Guido Grillenmeier e Rich Peckham. Query KQL e Splunk in condizioni di stabilità relative agli eventi 4768 e 4769. (Articolo di approfondimento relativo a questo post.)
• Il modulo PowerShell RC4-ADAssessment di Jan Tiedemann (BetaHydri). Correlazione tra configurazioni e registri eventi tra domini. Disponibile su PowerShell Gallery nella versione 4.0.0.
• Repository Kerberos-Crypto di Microsoft. Script PowerShell ufficiali, tra cui Get-KerbEncryptionUsage.ps1 e List-AccountKeys.ps1, forniti dal team Kerberos di Windows.
• KB5073381. Le linee guida ufficiali di Microsoft per l'implementazione relative alla vulnerabilità CVE-2026-20833.
• Individuazione e correzione dell'uso di RC4 in Kerberos su Microsoft Learn. La guida procedurale ufficiale per l'individuazione di RC4 a livello di ambiente.
• La serie "AD Hardening " di Jerry DeVore — Parte 4: Applicazione dell'AES per Kerberos. La fonte ufficiale di Microsoft per i dettagli sulla gestione delle credenziali con gli strumenti di migrazione.

Per le organizzazioni che effettuano questa valutazione nell'ambito di un progetto di migrazione in corso, Semperis Professional Services applica regolarmente questa metodologia come fase preliminare alla migrazione. La comunità di esperti di migrazione sta inoltre lavorando attivamente a soluzioni volte a ridurre i disagi causati agli utenti dal ripristino delle password dopo la migrazione; un prossimo articolo tratterà tali soluzioni man mano che saranno perfezionate.

Da dove cominciare questa settimana

Se avete in programma un progetto di migrazione che si protrarrà oltre luglio 2026 e non avete ancora iniziato i lavori, seguite questi quattro passaggi:

• Esegui oggi la Fase 0. Si tratta di un esercizio di 30 minuti per dominio che mette in luce le asimmetrie tra DFL e stato delle patch, che determinano tutto il resto.
• Verificate che il monitoraggio sia attivo in entrambi i domini (Fase 1). Se non lo è, risolvete il problema entro questa settimana. Ogni giorno in cui mancano i dati di telemetria è un giorno di rischio di interruzione che non potete vedere.
• Corri RC4-ADAssessment con -AnalyzeEventLogs rispetto a entrambi i domini (fasi 2 e 3 combinate). La categoria "Configurato per AES ma utilizza RC4" rappresenta il risultato di maggior valore.
• Pianificate i sopralluoghi con i responsabili delle applicazioni della Fase 4. Questo è il punto più critico. Iniziate subito e portateli avanti parallelamente a tutte le altre attività.

Il passaggio alla nuova piattaforma e la scadenza per l'adeguamento fissata a luglio 2026 sono due eventi distinti. Il lavoro di analisi che vi prepara per l'uno vi prepara anche per l'altro.

Inizia subito e la matrice che creerai fungerà da strumento di monitoraggio operativo per entrambi.

Hai domande su questa metodologia o su come Semperis possa aiutarti in un progetto di migrazione in corso? Contattaci: siamo qui per aiutarti.