← Field Guides
Active DirectoryKerberosRC4HardeningEntra ID

RC4 Deprecation in Active Directory: From Audit Phase to Full Enforcement

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 il percorso di dismissione formale nel novembre 2022 con KB5021131, introducendo eventi di audit per tracciare l'uso di RC4 in Kerberos. Da lì in poi, ogni major update ha stretto ulteriormente la vite, fino alle due fasi di enforcement che hanno segnato la finestra da gennaio a luglio 2026.

La timeline completa

| Data | KB / Aggiornamento | Cosa cambia | |---|---|---| | Novembre 2022 | KB5021131 | Aggiunge eventi di audit (Event ID 14, 16, 27 su KDC) per RC4 in Kerberos AS Exchange | | Luglio 2023 | KB5028166 | RC4 disabilitato di default per AS Exchange; le richieste RC4 iniziano a essere rifiutate se il KDC supporta AES | | Ottobre 2024 | Cumulative Update | DefaultDomainSupportedEncTypes aggiornato; nuovi domini creati non includono più RC4 per default | | Gennaio 2026 | Enforcement Phase 1 | RC4 rimosso dal set di cifrature negoziabili sul KDC per i nuovi ticket TGT; ambienti senza flag AES su account e DC iniziano a registrare fallimenti di autenticazione | | Luglio 2026 | Enforcement Phase 2 | Blocco completo: RC4-HMAC non viene più offerto né accettato dal KDC nelle installazioni aggiornate |

Il punto critico è che la fase di gennaio non è stata semplicemente un cambio di default: ha introdotto un comportamento di rifiuto attivo per account il cui attributo msDS-SupportedEncryptionTypes era assente o impostato a valori che non includevano AES.

Nota: gli ambienti che non hanno ancora applicato i Cumulative Update di gennaio 2026 non sono soggetti all'enforcement automatico, ma rimangono esposti alle vulnerabilità RC4 descritte di seguito.

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 di ordini di grandezza.

AS-REP Roasting: per gli account con la 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 legacy (scanner, 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:

| Valore | Significato | |---|---| | 0 | Nessun valore esplicito — il KDC usa i default del dominio (storicamente includeva RC4) | | 4 | Solo DES-CBC-MD5 (mai usare) | | 8 | Solo RC4-HMAC (da eliminare) | | 16 | AES128-CTS-HMAC-SHA1-96 | | 24 | AES128 + AES256 | | 28 | AES128 + AES256 + RC4 (utile nella fase di transizione se ci sono client legacy) |

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 vengono aggiornati automaticamente quando la macchina fa il netlogon (al riavvio o al cambio di password del computer account, ogni 30 giorni per default). Impostare il valore via AD prima che il client si connetta garantisce che alla prossima negoziazione il KDC offra solo AES.

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

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.

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, avviare una sincronizzazione delta da Entra Connect e verificare che non ci siano errori nella scheda Synchronization Service Manager > Operations:

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

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 in una sessione privata. 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 deprecando Seamless SSO a favore del Primary Refresh Token (PRT), che garantisce SSO tramite dispositivi Entra ID-joined o Hybrid Entra ID-joined senza richiedere un account Kerberos dedicato nel dominio. Per i nuovi tenant, Seamless SSO non è più disponibile. Negli ambienti esistenti, è consigliabile pianificare la migrazione verso Hybrid Join o Entra ID Join piuttosto che investire nella manutenzione a lungo termine di AZUREADSSOACC$.

Il percorso operativo da gennaio a luglio

In un programma di hardening di 7 mesi, la distribuzione del lavoro è tipicamente questa:

Gennaio — Assessment e baseline

  • Deploy della raccolta event ID 4768/4769 su tutti i DC
  • Export CSV del profilo RC4 dell'ambiente
  • Classificazione degli account per priorità (service account con SPN > computer account > utenti ordinari)

Febbraio–Marzo — Remediation account

  • Aggiornamento msDS-SupportedEncryptionTypes su service account per OU
  • Test di regressione su applicazioni critiche (SQL, Java, scanner)
  • Gestione dei casi problematici identificati

Aprile–Maggio — GPO rollout progressivo

  • GPO AES-only applicata prima ai DC in staging, poi produzione
  • Rollout su server membri per OU (partendo da ambienti non produttivi)
  • Monitoraggio continuo dei log; ogni picco di Event ID 4769 con 0x17 è un segnale di un account non ancora sistemato

Giugno — Completamento workstation e legacy cleanup

  • GPO estesa alle workstation
  • Bonifica trust cross-forest se presenti
  • Documentazione degli account esclusi temporaneamente (eccezioni formali)

Luglio — Validation e chiusura

  • Zero Event ID 4769 con encryption type 0x17 per 2 settimane consecutive
  • Review degli account con msDS-SupportedEncryptionTypes = 28 (transitori): migrazione al valore 24
  • Aggiornamento del runbook di onboarding (nuovi account devono nascere già con AES)
  • Sign-off formale

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 è uno di quei 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.

Book a strategy call