← Field Guides
Active DirectoryEncryptionEntra IDHardeningKerberosLinuxLoad BalancerNetApp ONTAPNTLMSPNvSphere

Deprecazione RC4 in Active Directory: date e fasi

Pubblicato: Aggiornato:

Contesto

RC4-HMAC (RC4-HMAC-MD5) è stato il tipo di cifratura predefinito per Kerberos in Windows dal 2000. Per decenni ha garantito compatibilità retroattiva in ambienti eterogenei, ma è anche stato al centro di alcune delle tecniche di attacco più diffuse nell'ambito dell'Active Directory: Kerberoasting, AS-REP Roasting, e alcune varianti di pass-the-hash che sfruttano proprio la debolezza crittografica dello stream cipher RC4.

Microsoft ha iniziato a rafforzare Kerberos nel 2022 con KB5021131. Per la protezione da CVE-2026-20833, KB 5073381 definisce invece una distribuzione distinta in tre fasi, da gennaio a luglio 2026. Non è un unico interruttore che rende RC4 impossibile in ogni configurazione: il comportamento predefinito cambia per gli account senza cifrature configurate esplicitamente, mentre le impostazioni esplicite vanno verificate e gestite separatamente.

Questa guida RC4 per Active Directory e Kerberos spiega quando e come passare da RC4 ad AES senza outage su servizi enterprise, NAS, sistemi Linux e integrazioni SSO.

Indice

Quando Microsoft disabilita RC4 in Active Directory?

Risposta breve: il cambiamento predefinito è entrato nella fase di enforcement con gli aggiornamenti del 14 aprile 2026; gli aggiornamenti di luglio hanno rimosso il rollback temporaneo. Questo non equivale a vietare RC4 per ogni account configurato esplicitamente.

Data degli aggiornamenti DCFaseCosa cambiaCosa fare
13 gennaio 2026Distribuzione inizialeAggiunge gli eventi di audit KDCSVC 201-209 e il valore temporaneo RC4DefaultDisablementPhase.Aggiornare i DC e monitorare il log System; correggere le dipendenze evidenziate prima di attivare l'enforcement.
14 aprile 2026Enforcement con rollback manualePer gli account senza msDS-SupportedEncryptionTypes esplicito, il default KDC diventa AES-SHA1 (DefaultDomainSupportedEncTypes = 0x18). Il valore temporaneo consente ancora il rollback alla modalità Audit.Verificare eventi, chiavi AES e interoperabilità; trattare separatamente le configurazioni esplicite di account o dominio.
Luglio 2026Enforcement programmaticoGli aggiornamenti di luglio rimuovono il supporto a RC4DefaultDisablementPhase e attivano programmaticamente l'enforcement.La chiave non è più un'opzione di rollback sui DC aggiornati; correggere le dipendenze e validare i servizi.

Queste sono date di rilascio degli aggiornamenti, non scadenze che si applicano senza patch: controlla versione e aggiornamento cumulativo installato su ogni Domain Controller. Microsoft raccomanda di abilitare l'enforcement dopo aver verificato gli eventi KDCSVC e mitigato le dipendenze. Per i dettagli aggiornati, consulta Microsoft KB 5073381: modifiche RC4 per l'emissione di ticket Kerberos.

RC4DefaultDisablementPhase: cos'è e quali valori supporta?

RC4DefaultDisablementPhase è un valore temporaneo che controlla la transizione del KDC. È stato introdotto con gli aggiornamenti dal 13 gennaio 2026; gli aggiornamenti rilasciati da luglio 2026 ne rimuovono il supporto.

Percorso del registro sul Domain Controller:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters
Value: RC4DefaultDisablementPhase
Type: REG_DWORD
Valore DWORDComportamento documentato
0Nessun audit, nessun cambiamento.
1Registra warning per l'uso RC4 predefinito. È il default della fase iniziale.
2Il KDC presume che RC4 non sia abilitato per default. È il comportamento di enforcement.

Microsoft indica che è richiesto il riavvio del Domain Controller. Applica il valore soltanto quando gli eventi KDCSVC di audit mostrano che è sicuro farlo e pianifica un riavvio controllato, DC per DC. Con valore 2, il KDC presume che RC4 non sia abilitato per default per gli account senza msDS-SupportedEncryptionTypes esplicito; non disattiva le configurazioni esplicite degli account.

Esempio PowerShell, valido solo sui DC aggiornati nella finestra in cui il valore è supportato e dopo il triage degli eventi:

# Esegui sul DC approvato per il test; pianifica il riavvio richiesto
$regPath = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters"
Set-ItemProperty -Path $regPath -Name "RC4DefaultDisablementPhase" -Value 2 -Type DWord
Get-ItemProperty -Path $regPath -Name "RC4DefaultDisablementPhase"

Se serve tornare alla modalità di audit prima degli aggiornamenti di luglio 2026, imposta il valore 1 e riavvia il DC secondo il change plan. Sugli aggiornamenti di luglio o successivi il valore temporaneo non viene più letto: non è una leva di rollback permanente.

FAQ sulla dismissione RC4

RC4 è deprecato?

Sì: Microsoft ne sta rimuovendo l'uso predefinito nel rollout 2026 per gli account senza cifrature configurate esplicitamente. Non è però un divieto universale: le configurazioni esplicite di msDS-SupportedEncryptionTypes e DefaultDomainSupportedEncTypes vanno verificate separatamente e possono mantenere RC4, conservando il rischio di CVE-2026-20833.

Cosa significa la fase di luglio 2026?

Gli aggiornamenti rilasciati da luglio rimuovono il valore temporaneo RC4DefaultDisablementPhase e abilitano programmaticamente l'enforcement. Non significa che ogni configurazione esplicita RC4 venga ignorata.

RC4 può causare problemi a MSOL_* o AZUREADSSOACC$?

Può evidenziare dipendenze di cifratura o chiavi AES mancanti. Controlla msDS-SupportedEncryptionTypes, gli eventi KDCSVC e le chiavi realmente disponibili; per Entra Connect e Seamless SSO segui la sezione dedicata più avanti, senza applicare un valore in modo indiscriminato.

Perché RC4 è un problema concreto, non solo teorico

Kerberoasting: un attaccante con accesso autenticato al dominio può richiedere un ticket di servizio (TGS) per qualsiasi SPN registrato. Se il tipo di cifratura negoziato è RC4-HMAC, il ticket è brute-forceable offline con strumenti come Hashcat. Con AES256, il costo computazionale aumenta in ordini di grandezza.

AS-REP Roasting: per gli account con il flag Do not require Kerberos preauthentication attiva, un attaccante può richiedere un AS-REP senza autenticarsi. Se il tipo di cifratura è RC4, l'hash nella risposta è offline-crackable.

Downgrade attack: in assenza di enforcement lato KDC, un client può forzare la negoziazione RC4 anche in ambienti che supportano AES, riducendo il livello di sicurezza dell'intera sessione Kerberos.

Fase 1: capire chi sta ancora usando RC4

Prima di disabilitare qualsiasi cosa, è indispensabile sapere cosa usa RC4 nel proprio ambiente. I Domain Controller loggano i tipi di cifratura nelle richieste Kerberos, e l'encryption type 0x17 corrisponde esattamente a RC4-HMAC.

Event ID 4768 (Kerberos Authentication Service Request — TGT) e Event ID 4769 (Kerberos Service Ticket Request — TGS) includono entrambi il campo Ticket Encryption Type. Filtrare per 0x17 su tutti i DC nell'arco di 2-4 settimane dà una mappa attendibile dell'utilizzo residuo.

# Raccolta event ID 4769 con RC4 (0x17) dagli ultimi 30 giorni su tutti i DC
$startDate = (Get-Date).AddDays(-30)
$dcs = (Get-ADDomainController -Filter *).Name

foreach ($dc in $dcs) {
    Get-WinEvent -ComputerName $dc -FilterHashtable @{
        LogName   = "Security"
        Id        = 4769
        StartTime = $startDate
    } -ErrorAction SilentlyContinue |
    Where-Object {
        $_.Properties[6].Value -eq "0x17"
    } |
    Select-Object TimeCreated,
        @{ N="ServiceName";  E={ $_.Properties[0].Value } },
        @{ N="ClientName";   E={ $_.Properties[3].Value } },
        @{ N="EncryptType";  E={ $_.Properties[6].Value } },
        @{ N="DC";           E={ $dc } }
} | Sort-Object TimeCreated -Descending | Export-Csv rc4-usage.csv -NoTypeInformation -Encoding UTF8

Dal CSV ottenuto, i pattern da cercare sono:

  • Service account con SPN registrati (candidati Kerberoasting, priorità alta)
  • Computer account in cui il valore msDS-SupportedEncryptionTypes è 0 o assente
  • Applicazioni o sistemi legacy (scanner e stampanti, NAS, ERP, middleware) che appaiono ripetutamente come ClientName

Fase 2: sistemare gli account

L'attributo msDS-SupportedEncryptionTypes controlla quali algoritmi un account è in grado di negoziare. Il valore è una bitmask:

ValoreSignificato
0Nessun valore esplicito — il KDC usa i default del dominio (storicamente includeva RC4)
4Solo DES-CBC-MD5 (mai usare)
8Solo RC4-HMAC (da eliminare)
16AES128-CTS-HMAC-SHA1-96
24AES128 + AES256
28AES128 + AES256 + RC4 (utile nella fase di transizione se ci sono client legacy)
31DES-CBC-CRC + DES-CBC-MD5 + RC4 + AES128 + AES256 (uno dei più presenti in produzione con sistemi obsoleti)

Per gli account utente e di servizio, il valore target finale è 24 (solo AES). Durante la transizione, usare 28 consente di non interrompere applicazioni che utilizzano solo RC4.

# Imposta msDS-SupportedEncryptionTypes su AES128+AES256 per tutti i service account in una OU
$ouPath = "OU=ServiceAccounts,DC=contoso,DC=com"
Get-ADUser -SearchBase $ouPath -Filter * -Properties msDS-SupportedEncryptionTypes |
    Where-Object { $_.msDS-SupportedEncryptionTypes -ne 24 } |
    ForEach-Object {
        Set-ADUser $_ -Replace @{ "msDS-SupportedEncryptionTypes" = 24 }
        Write-Output "Updated: $($_.SamAccountName)"
    }

Per i computer account (workstation, server membri di dominio):

# Verifica computer senza AES abilitato
Get-ADComputer -Filter * -Properties msDS-SupportedEncryptionTypes |
    Where-Object {
        $_.msDS-SupportedEncryptionTypes -eq $null -or
        $_.msDS-SupportedEncryptionTypes -lt 16
    } |
    Select-Object Name, msDS-SupportedEncryptionTypes |
    Export-Csv computers-no-aes.csv -NoTypeInformation -Encoding UTF8

I computer account in Active Directory possono aggiornare automaticamente il valore di msDS-SupportedEncryptionTypes quando la macchina esegue netlogon, per esempio al riavvio o al cambio password del computer account (default: 30 giorni). L'aggiornamento però non è sempre immediato né prevedibile: il valore può variare in base a versione OS, stato del sistema, rinnovo chiavi Kerberos e identità di servizio usate all'avvio.

Impostare manualmente msDS-SupportedEncryptionTypes lato Active Directory prima che il client si connetta è una buona pratica, perché aumenta la probabilità che alla successiva negoziazione Kerberos il Domain Controller utilizzi solo AES, evitando RC4. Questo approccio è particolarmente utile nelle fasi di hardening e durante la dismissione di RC4.

È però importante sapere che il valore può essere sovrascritto successivamente dal client stesso. Per questo è fondamentale monitorare nel tempo i computer account: se msDS-SupportedEncryptionTypes torna a includere algoritmi non desiderati o viene resettato, occorre analizzare il sistema coinvolto (versione OS, modalità di join, strumenti di provisioning/gestione) e intervenire con remediation mirata. Le azioni tipiche includono l’applicazione di policy coerenti, l’aggiornamento dei sistemi legacy e, se necessario, la gestione controllata del lifecycle dei computer account per garantire che la configurazione AES-only rimanga stabile nel tempo.

Fase 3: configurare la Group Policy

La GPO Network security: Configure encryption types allowed for Kerberos (percorso: Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options) controlla quali algoritmi il client e il server accettano a livello di negoziazione Kerberos.

Configurazione raccomandata per i Domain Controller durante la transizione:

  • AES128_HMAC_SHA1 ✓
  • AES256_HMAC_SHA1 ✓
  • Future encryption types ✓
  • RC4_HMAC_MD5 — disabilitare solo dopo aver completato la verifica degli account

Configurazione raccomandata per le workstation/server membri:

Stessa configurazione dei DC, ma applicata progressivamente per OU, partendo da sistemi non critici.

Attenzione: non disabilitare RC4 sulla GPO prima di aver sistemato msDS-SupportedEncryptionTypes su tutti gli account. L'ordine corretto è: account → GPO DC → GPO workstation.

I casi problematici più comuni

Nella maggior parte degli ambienti Active Directory, il vero ostacolo alla dismissione di RC4 non sono utenti o server Windows, ma le integrazioni Kerberos accumulate negli anni: appliance Linux, NAS, load balancer, piattaforme VMware, sistemi IBM, middleware Java, dispositivi embedded e applicazioni di terze parti. Individuarli durante l'assessment è spesso il fattore che determina il successo o il fallimento del programma di hardening.

1. Applicazioni Java con JGSS/JAAS

Molte applicazioni Java usano librerie Kerberos che hanno RC4 come algoritmo preferito nel krb5.conf. Dopo l'enforcement, iniziano a ricevere KrbException: KDC has no support for encryption type. La soluzione è aggiornare il krb5.conf dell'applicazione:

[libdefaults]
    default_tgs_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
    default_tkt_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
    permitted_enctypes   = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96

2. SQL Server con autenticazione Kerberos e SPN

Se il service account di SQL Server non ha AES abilitato in msDS-SupportedEncryptionTypes, le connessioni Kerberos passano al fallback NTLM silenziosamente. Non è un errore visibile, ma è una regressione di sicurezza. Verificare con:

SELECT auth_scheme FROM sys.dm_exec_connections WHERE session_id = @@SPID

Se il risultato non è KERBEROS, il problema è sull'account o sullo SPN.

3. Trust cross-forest

I trust Active Directory tra forest diverse usano un trust account con la propria configurazione di cifratura. Se la forest remota è ad un livello funzionale o di patch inferiore, il trust continuerà a usare RC4 anche dopo l'enforcement nella forest locale. Verificare:

Get-ADTrust -Filter * | Select-Object Name, TrustAttributes, TrustDirection

I trust con flag UsesRC4Encryption richiederanno intervento coordinato su entrambe le forest per continuare a funzionare correttamente.

4. Server Linux domain-joined

I server Linux integrati nel dominio via SSSD o Winbind/Samba gestiscono Kerberos attraverso il proprio /etc/krb5.conf, indipendentemente dalla GPO Windows. Dopo l'enforcement RC4, le autenticazioni Linux iniziano a fallire con errori del tipo KDC has no support for encryption type o GSSAPI Error: Unspecified GSS failure, spesso senza log chiari sul DC.

Il problema è duplice:

  1. Il computer account in AD deve avere AES abilitato in msDS-SupportedEncryptionTypes (valore 24 o 28)
  2. Il file /etc/krb5.conf del server Linux deve listare AES come algoritmo permesso

Per il krb5.conf:

[libdefaults]
    default_tgs_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
    default_tkt_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
    permitted_enctypes   = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96

Dopo aver modificato msDS-SupportedEncryptionTypes sul computer account in AD, il keytab del server Linux deve essere rigenerato — altrimenti il KVNO (Key Version Number) nella keytab non corrisponde a quello in AD e le autenticazioni continuano a fallire anche se l'algoritmo è corretto.

Con SSSD e adcli:

# Rigenera il keytab aggiornando le chiavi AES sul computer account
adcli update --computer-name=$(hostname -s) --verbose

# Verifica la keytab risultante
klist -ket /etc/krb5.keytab

Con Winbind/Samba:

net ads keytab create -U Administrator
net ads keytab list

Verifica finale: tentare un kinit con l'account di servizio locale e controllare che l'encryption type nel ticket sia AES256 (etype: aes256-cts-hmac-sha1-96) e non RC4 (etype: arcfour-hmac).

5. Account speciali: MSOL_* e AZUREADSSOACC$

Questi due account vengono creati automaticamente da Microsoft Entra Connect (ex Azure AD Connect) e finiscono quasi sempre fuori dall'inventario normale dei service account — con il risultato che ci si ricorda di loro solo quando le autenticazioni iniziano a fallire dopo l'enforcement RC4.

MSOL_xxxxxxxxxxxxxxxx

È l'account che Entra Connect usa per connettersi all'Active Directory on-premise ed eseguire le operazioni di sincronizzazione (lettura oggetti, scrittura attributi, gestione password). Viene creato nel container CN=Users,DC=contoso,DC=com al momento dell'installazione del connettore AD, con un nome nel formato MSOL_ seguito da una stringa hex casuale.

Poiché non è in nessuna OU gestita normalmente, msDS-SupportedEncryptionTypes è spesso assente o impostato a 0. Dopo l'enforcement, il processo di sincronizzazione inizia a ricevere errori Kerberos silenziosi e la sincronizzazione si degrada o si blocca.

Per trovarlo:

Get-ADUser -Filter { SamAccountName -like "MSOL_*" } -Properties msDS-SupportedEncryptionTypes, PasswordNeverExpires, Description |
    Select-Object SamAccountName, msDS-SupportedEncryptionTypes, PasswordNeverExpires, Description

Remediation:

$msolAccount = Get-ADUser -Filter { SamAccountName -like "MSOL_*" }
Set-ADUser $msolAccount -Replace @{ "msDS-SupportedEncryptionTypes" = 24 }

Test di funzionamento: dopo la modifica, impostare la nuova password nelle proprietà del connettore sotto Connect to Active Directory Forest, avviare una sincronizzazione full da Entra Connect e verificare che non ci siano errori in Synchronization Service Manager > Operations:

# Da eseguire sul server Entra Connect
Start-ADSyncSyncCycle -PolicyType Initial

Se la sincronizzazione completa senza errori di connettività AD, la remediation è riuscita.

AZUREADSSOACC$

A differenza di MSOL_*, questo è un computer account (non un utente), creato da Entra Connect quando si abilita la funzionalità Seamless SSO. Si trova tipicamente in CN=Computers,DC=contoso,DC=com e viene usato per decriptare i ticket Kerberos emessi durante il flusso di autenticazione Seamless SSO.

Poiché è un computer account e non viene mai rinnovato automaticamente come una normale workstation (non fa mai netlogon), msDS-SupportedEncryptionTypes rimane nel valore predefinito e non viene aggiornato. La conseguenza dopo l'enforcement RC4 è che il processo di decifrazione del ticket Kerberos SSO fallisce silenziosamente, e gli utenti iniziano a ricevere prompt di credenziali su browser e client dove prima l'autenticazione era trasparente.

Remediation: la modifica deve avvenire sia sull'oggetto AD che sul lato Entra Connect, che deve rigenerare le chiavi Kerberos dell'account.

# Passo 1: aggiorna msDS-SupportedEncryptionTypes sull'oggetto computer
$ssoAccount = Get-ADComputer -Identity "AZUREADSSOACC"
Set-ADComputer $ssoAccount -Replace @{ "msDS-SupportedEncryptionTypes" = 24 }

Passo 2: da Entra Connect, rinnova il segreto Kerberos dell'account SSO. Aprire PowerShell sul server Entra Connect con il modulo AzureADSSO:

Import-Module "$env:ProgramFiles\Microsoft Azure Active Directory Connect\AzureADSSO.psd1"
New-AzureADSSOAuthenticationContext  # autenticazione Global Admin
Update-AzureADSSOForest -OnPremCredentials (Get-Credential)  # credenziali Domain Admin

Test di funzionamento: da un browser su una macchina domain-joined (senza MFA attivo sull'account di test), aprire https://myapps.microsoft.com. Se l'autenticazione avviene senza prompt di credenziali, Seamless SSO funziona correttamente. In alternativa, verificare che nei log di Entra ID Sign-ins il metodo di autenticazione risulti Seamless SSO e non Password Hash Sync o Password.

Nota sulla deprecazione: Microsoft sta progressivamente spostando l'attenzione da Seamless SSO verso Primary Refresh Token (PRT), che abilita SSO su dispositivi Entra ID-joined o Hybrid Entra ID-joined senza richiedere un account Kerberos dedicato nel dominio. Anche se Seamless SSO è ancora supportato negli ambienti esistenti, non è più la soluzione di riferimento per nuovi scenari. Dove possibile, pianificare la migrazione verso Hybrid Join o Entra ID Join invece di investire nella manutenzione a lungo termine di AZUREADSSOACC$.

6. Kemp LoadMaster e Kerberos Constrained Delegation (KCD)

I bilanciatori Kemp LoadMaster configurati con KCD sono tra i casi più insidiosi durante la dismissione di RC4. Il front-end può apparire stabile, ma il backend continua a negoziare cifrature legacy se account di delega, SPN o key material non sono allineati ad AES.

Checklist minima:

  • verificare SPN HTTP e backend associati agli account di delega
  • verificare che account delegati non siano RC4-only (msDS-SupportedEncryptionTypes = 8)
  • testare end-to-end la delega dopo il passaggio a 24 (AES only)

7. VMware vSphere e vCenter Server

Negli ambienti vSphere, il problema tipico è la coesistenza di componenti aggiornati e integrazioni SSO/LDAP legacy. Dopo l'enforcement RC4, i sintomi possono comparire in autenticazioni amministrative, plugin o workflow automation.

Punti pratici:

  • verificare versione vCenter/PSC e compatibilità Kerberos AES
  • verificare keytab o credenziali salvate nei connettori AD
  • testare login e autorizzazioni da account AD dopo remediation

8. Sistemi IBM (AIX, WebSphere, Cognos)

I prodotti IBM in ambienti enterprise estesi mantengono spesso configurazioni Kerberos storiche. La remediation richiede quasi sempre revisione di keytab, principal e file di configurazione applicativa, non solo il tuning lato AD.

Punti di attenzione:

  • keytab datate generate in epoca RC4-first
  • principal di servizio non riallineati all'account AD attuale
  • file Kerberos applicativi con etype legacy ancora presenti

9. NAS Synology, QNAP e NetApp

I NAS sono una fonte frequente di traffico RC4 residuo perché rimangono in produzione per anni con join AD stabile ma configurazione Kerberos mai rivista.

Controlli consigliati:

  • verificare lo stato del join AD e del computer account NAS
  • verificare supporto AES sul firmware/OS del NAS
  • confermare che gli accessi SMB usino Kerberos AES e non fallback NTLM

9.1 Focus NetApp ONTAP e dismissione RC4

In base alle KB ufficiali NetApp, l'impatto dipende dalla release ONTAP, dalla configurazione CIFS Kerberos e dal modo in cui è stato creato/aggiornato il CIFS server nel tempo. In ambienti meno recenti può essere necessario un allineamento esplicito ad AES prima dell'enforcement Microsoft.

Riferimenti ufficiali:

Checklist operativa ONTAP:

  • verificare release ONTAP e prerequisiti CIFS Kerberos documentati da NetApp
  • verificare che il computer account CIFS in AD abbia encryption types coerenti con AES
  • validare autenticazione SMB post-change da client domain-joined
  • in caso di failure, seguire la remediation NetApp (ri-join/rinnovo credenziali/aggiornamento config Kerberos secondo KB)

Verifica AD lato account NAS:

Get-ADComputer NAS01 -Properties msDS-SupportedEncryptionTypes,KerberosEncryptionType |
Select-Object Name,msDS-SupportedEncryptionTypes,KerberosEncryptionType

10. Scanner multifunzione, stampanti e appliance embedded

Molti programmi di remediation RC4 si bloccano su dispositivi considerati secondari. In realtà, scanner MFP, stampanti enterprise e appliance OT spesso usano stack Kerberos/SMB datati e diventano i primi candidati a fallback o failure.

Approccio pragmatico:

  • identificare dispositivi che autenticano verso share AD
  • classificare firmware supportati vs non supportati
  • applicare eccezioni temporanee solo con owner e piano di rimozione

11. Linux con keytab statiche e servizi applicativi

Anche con computer account AD correttamente configurato per AES, un host Linux può continuare a usare RC4 se keytab locale e configurazione Kerberos non sono state rigenerate dopo la remediation.

Pratica consigliata:

  • aggiornare etype in krb5.conf
  • rigenerare keytab
  • validare kinit/klist verificando etype AES

Percorso operativo dopo gli aggiornamenti 2026

Le date di gennaio, aprile e luglio 2026 sono milestone già trascorse. Per verificare lo stato attuale, applica questa sequenza a tutti i Domain Controller e ai servizi che li usano:

  1. Inventaria il livello di patch dei DC. Verifica che tutti abbiano gli aggiornamenti cumulativi correnti; la data di calendario non abilita la protezione su un DC non aggiornato.
  2. Leggi gli eventi KDCSVC 201-209 nel log System e gli eventi Security 4768/4769. L'evento 205 segnala una configurazione esplicita insicura di DefaultDomainSupportedEncTypes; gli eventi 201-209 identificano richieste o policy da valutare secondo il dettaglio Microsoft.
  3. Classifica account e dipendenze. Cerca account senza msDS-SupportedEncryptionTypes, account privi di chiavi AES e client/keytab che non negoziano AES-SHA1. Includi MSOL_*, AZUREADSSOACC$, trust, NAS e servizi non Windows.
  4. Remedia e prova il ticket reale. Configura AES solo dopo aver verificato che le chiavi AES siano disponibili; testa le applicazioni e gli eventuali keytab. Se RC4 è indispensabile, documenta l'eccezione esplicita, lo scope, il proprietario e il piano di rimozione: non trattarla come una remediation sicura.
  5. Valida dopo ogni rollout. Confronta gli eventi prima/dopo e verifica il tipo di cifratura dei ticket. Sugli aggiornamenti di luglio 2026 o successivi RC4DefaultDisablementPhase non è più un meccanismo di rollback; concorda prima le procedure di recovery per ciascun servizio.

L'obiettivo è eliminare l'uso RC4 non previsto e le configurazioni implicite insicure. Non usare un target “zero eventi 4769 RC4” senza distinguere le eccezioni RC4 esplicite approvate dai fallback o dalle dipendenze che vanno corrette.

Validazione finale

Due query per verificare che il lavoro sia completo.

Nessun account con RC4 ancora abilitato come unico algoritmo:

Get-ADObject -Filter {
    (ObjectClass -eq "user" -or ObjectClass -eq "computer") -and
    msDS-SupportedEncryptionTypes -eq 8
} -Properties SamAccountName, msDS-SupportedEncryptionTypes |
Select-Object SamAccountName, msDS-SupportedEncryptionTypes

Monitoraggio residuo RC4 negli ultimi 7 giorni:

Get-WinEvent -FilterHashtable @{
    LogName   = "Security"
    Id        = 4769
    StartTime = (Get-Date).AddDays(-7)
} |
Where-Object { $_.Properties[6].Value -eq "0x17" } |
Measure-Object | Select-Object Count

Il risultato atteso è Count: 0. Se ci sono ancora occorrenze, il campo ClientName nell'evento identifica la fonte esatta.

Note finali

La dismissione di RC4 è una di quelle operazioni di hardening che ha un impatto reale sulla postura di sicurezza dell'ambiente, ma richiede una gestione per fasi precisa per non causare interruzioni. Il rischio principale non è tecnico ma operativo: saltare la fase di assessment e applicare la GPO senza aver prima sistemato gli account porta a fallimenti di autenticazione difficili da tracciare, soprattutto su applicazioni legacy che non loggano correttamente l'algoritmo Kerberos usato.

Se stai avviando questo percorso o ti trovi a metà di un enforcement fermo per incidenti inattesi, contattami: spesso bastano poche ore di analisi dei log per sbloccare situazioni che sembrano complesse.

I contenuti di questa guida sono forniti a titolo informativo, senza garanzie. L'applicazione di qualsiasi procedura è sotto la responsabilità dell'utente. Disclaimer.

Apprezzamento

Se questa guida ti è utile, lascia un like.

Guide correlate

Continua ad approfondire

Active Directory / Hardening

SPN in Active Directory: Cos'è, Come Verificarlo e Registrarlo

Leggi la guida->

Active Directory / Event Viewer

Perché il fallback da Kerberos a NTLM è un problema in Active Directory (e come eliminarlo davvero)

Leggi la guida->

Active Directory / Authentication

Audit NTLM in Active Directory: dal monitoraggio al blocco

Leggi la guida->

Active Directory / Domain Controllers

Protected Users in Active Directory: cos'è, limiti, adminCount e rollout senza lockout

Leggi la guida->
LinkedIn