Active Directory RC4 remediation: service account da RC4 ad AES senza reset password

Laboratorio su pwdLastSet, User must change password at next logon e ticket Kerberos

Se stai lavorando su RC4 remediation, Kerberos hardening o migrazione AES-only in Active Directory, il problema operativo e quasi sempre lo stesso: come portare un service account legacy da RC4 ad AES senza introdurre outage o coordinare un reset password ad alto impatto.

Durante una attività di remediation RC4 in ambiente Active Directory, insieme al collega Riccardo Verdi abbiamo osservato e testato un comportamento molto interessante:

Un account creato in condizioni compatibili con solo RC4, dopo il semplice toggle dell'opzione User must change password at next logon e la configurazione di msDS-SupportedEncryptionTypes = 24, ha iniziato ad autenticarsi correttamente verso un client/server configurato AES-only, senza che la password venisse realmente modificata.

Approfondendo, è emerso che la parte documentata da Microsoft in merito è abbastanza chiara: il flag User must change password at next logon agisce anche sull'attributo pwdLastSet. Microsoft documenta che, per forzare un utente a cambiare password al prossimo logon, si imposta pwdLastSet = 0; per rimuovere il requisito si imposta pwdLastSet = -1. L'attributo pwdLastSet rappresenta data e ora dell'ultimo cambio password dell'account e viene valorizzato dal sistema.
Fonte Microsoft: User Must Change Password at Next Logon - LDAP Provider, Pwd-Last-Set attribute, MS-ADA3 pwdLastSet

La parte non esplicitamente documentata, e quindi da trattare come evidenza sperimentale, è questa:

Nel laboratorio, dopo il toggle del flag, l'account ha iniziato a produrre ticket Kerberos AES verificabili tramite Event Viewer, pur senza un reset password tradizionale e senza conoscere o modificare la password dell'account.

Questo articolo separa volutamente le due cose:

• fatti documentati da Microsoft;
• comportamento osservato in laboratorio;
• metodo di verifica tramite eventi 4768, 4769, 4771 e 4624.

Se vuoi collocare questa guida nel resto del percorso di hardening, i riferimenti piu utili sono:

• Timeline e fasi della dismissione RC4 in Active Directory
• Fallback Kerberos -> NTLM in Active Directory
• SPN in Active Directory: guida pratica con KCD e RBCD

---

Premessa tecnica

RC4, AES e account storici

In Active Directory, Kerberos può utilizzare diversi tipi di cifratura per ticket e session key. L'attributo msDS-SupportedEncryptionTypes indica i tipi di encryption supportati da un account user o computer oppure da una trust relationship, secondo valori bitmapped definiti nelle specifiche Microsoft.
Fonte Microsoft: MS-ADTS - msDs-supportedEncryptionTypes

Microsoft, nella documentazione relativa a CVE-2022-37966, spiega che i domain controller usano msDS-SupportedEncryptionTypes per determinare i tipi di encryption supportati sugli account Active Directory per i quali il valore è vuoto o non impostato. La stessa documentazione specifica anche che computer account specifici impostano automaticamente msDS-SupportedEncryptionTypes, mentre user account, gMSA e altri account in Active Directory non lo impostano automaticamente.
Fonte Microsoft: KB5021131 - How to manage the Kerberos protocol changes related to CVE-2022-37966

Nel contesto RC4/AES, i valori più comuni da conoscere sono:

Valore	Significato
0x04	RC4-HMAC
0x08	AES128-CTS-HMAC-SHA1-96
0x10	AES256-CTS-HMAC-SHA1-96
0x18 / 24	AES128 + AES256

Nota: 24 in decimale corrisponde a 0x18 in esadecimale, cioè 0x08 + 0x10.

---

Cosa dice Microsoft su pwdLastSet

Qui conviene essere molto precisi, separando "ciò che Microsoft documenta" da "ciò che osserviamo in lab".

Cosa è documentato ufficialmente

Microsoft definisce pwdLastSet come timestamp dell'ultimo cambio password (formato FILETIME, intervalli da 100 ns dal 1 gennaio 1601 UTC). Inoltre specifica che:

• pwdLastSet = 0 forza il cambio password al prossimo logon;
• pwdLastSet = -1 rimuove il requisito di cambio al prossimo logon;
• il valore non è liberamente impostabile ad altri numeri da admin, fuori dai valori speciali previsti.

Fonti Microsoft: Pwd-Last-Set attribute, User Must Change Password at Next Logon - LDAP Provider

Cosa succede, fase per fase

Da qui la nostra intuizione:

se la modifica del pwdLastSet rimanda la scadenza della password e AD la interpreta come un vero e proprio cambio, verranno modificati anche gli encryptionTypes associati?

Questa lettura operativa aiuta a preparare i casi che analizzeremo dopo (password gia scaduta, never expires, account buono, account RC4-only):

1. Stato iniziale pwdLastSet contiene una data/ora valida dell'ultimo cambio password, oppure 0 se l'account e in stato "must change". In base a quanto definito nella Default Domain Policy in relazione alla durata della password, questo attributo definisce se la password è ancora valida oppure scaduta.

2. Attivazione "User must change password at next logon" AD scrive pwdLastSet = 0. Effetto funzionale: l'utente deve cambiare password al primo logon interattivo valido.

3. Rimozione della spunta "must change" AD usa il valore speciale -1. Effetto funzionale: il sistema ricalcola il timestamp e PasswordLastSet viene valorizzato con data/ora corrente.

4. Punto chiave per questo articolo Questo flusso descrive con certezza la gestione di pwdLastSet, ma non equivale automaticamente a dire "password reset completo" via API o "rigenerazione chiavi Kerberos sempre garantita in ogni scenario".

Perche questa distinzione è importante

Nel prosieguo dell'articolo useremo proprio questa base per confrontare i casi limite:

• account con password gia scaduta;
• account con password never expires;
• account in stato "buono";
• account legacy RC4-only da portare verso AES.

In tutti i casi, la parte pwdLastSet è ben documentata. Quello che va dimostrato ogni volta è invece l'effetto crittografico reale (ticket RC4 vs AES) tramite Event ID 4768/4769 e verifica Kerberos senza fallback NTLM.

---

Cosa Microsoft documenta sulla generazione delle chiavi

Nella documentazione ufficiale degli eventi di sicurezza Kerberos (versioni aggiornate di Event ID 4768 e 4769) Microsoft riporta un passaggio molto utile:

Available Keys: List of available keys for the account stored in Active Directory. These keys are generated during password sets and password changes.

Inoltre Microsoft aggiunge che, con Domain Functional Level (DFL) superiore a Windows 2008 e almeno una rotazione password, le chiavi AES diventano disponibili per gli account.

Fonti Microsoft: Event 4768, Event 4769

Questa è una base documentale forte per dire che password set/change e disponibilita delle chiavi sono collegati.

Quello che resta non esplicitato da Microsoft è se il solo toggle di ChangePasswordAtLogon (con passaggio pwdLastSet = 0 e poi -1) attivi internamente anche la pipeline di rigenerazione chiavi in ogni scenario/versione.

---

Ipotesi del laboratorio

L'ipotesi da dimostrare non è semplicemente che pwdLastSet venga aggiornato. Quello è già documentato.

L'ipotesi interessante è:

Il toggle del flag User must change password at next logon, combinato con l'impostazione dell'attributo msDS-SupportedEncryptionTypes = 24, renderà disponibili chiavi AES Kerberos per un account precedentemente utilizzabile solo in RC4, senza modificare la password nota all'applicazione?

Questo comportamento deve essere verificato non "a sensazione", ma osservando:

• attributi Active Directory prima/dopo;
• eventi Kerberos sul Domain Controller;
• ticket presenti sul client;
• assenza di fallback NTLM.

---

Ambiente di laboratorio

Componenti

Di seguito l'ambiente usato per riprodurre il comportamento:

Componente	Note
2 Domain Controller	Windows Server 2016 e 2025 - patchati a Giugno 2026
Functional Level	Windows Server 2016
Client di test	Windows 11 25H2 - domain joined
Account di test	User account standard, non privilegiato, local admin sul client di test
Policy Kerberos client/server	AES-only o comunque senza RC4
Audit sul DC	Kerberos Authentication Service e Kerberos Service Ticket Operations abilitati

Importante: usare un account di laboratorio, non un service account reale di produzione.

---

Audit policy necessarie

Sul Domain Controller devono essere attive le Advanced Audit Policy relative a Kerberos.

Percorso GPO:

Computer Configuration
 └─ Policies
    └─ Windows Settings
       └─ Security Settings
          └─ Advanced Audit Policy Configuration
             └─ Audit Policies
                └─ Account Logon

Abilitare almeno:

Audit Kerberos Authentication Service: Success and Failure
Audit Kerberos Service Ticket Operations: Success and Failure

Queste policy permettono di osservare rispettivamente gli eventi:

Policy	Eventi principali
Audit Kerberos Authentication Service	4768, 4771
Audit Kerberos Service Ticket Operations	4769

Microsoft documenta l'evento 4768 come generato quando il KDC emette un Kerberos Ticket Granting Ticket, e l'evento 4769 come generato quando il KDC riceve una richiesta TGS per un service ticket.
Fonti Microsoft: Event 4768, Event 4769

---

Eventi da cercare CHIARAMENTE ED ESATTAMENTE

Questa è la sezione più importante dell'articolo.

Tutti gli eventi sotto vanno cercati sui Domain Controller, nel log:

Event Viewer
 └─ Windows Logs
    └─ Security

Evento 4768 - Kerberos authentication ticket, TGT

Cosa rappresenta

L'evento 4768 indica che è stato richiesto un Kerberos Authentication Ticket, cioè un TGT.

Microsoft descrive l'evento come:

4768 (S, F): A Kerberos authentication ticket (TGT) was requested.

Fonte Microsoft: Event 4768

Filtro Event Viewer

Nel log Security del DC filtrare:

Event ID: 4768

Campi da controllare

Nel dettaglio dell'evento cercare questi campi:

Campo	Cosa verificare
Account Name / TargetUserName	Deve essere l'account di test
Service Name	Di norma krbtgt
Ticket Encryption Type	Tipo di cifratura del TGT
Status	0x0 se successo
Client Address / IpAddress	IP del client che sta facendo il test
Account Supported Encryption Types	Se presente, encryption type supportati dall'account
Account Available Keys	Se presente, chiavi disponibili per l'account
Client Advertized Encryption Types	Se presente, etype proposti dal client

Valori da confrontare

Valore	Significato
0x17	RC4-HMAC
0x11	AES128-CTS-HMAC-SHA1-96
0x12	AES256-CTS-HMAC-SHA1-96

Microsoft mostra nel modello aggiornato dell'evento 4768 il campo TicketEncryptionType e altri campi come AccountSupportedEncryptionTypes, AccountAvailableKeys, ServiceSupportedEncryptionTypes, ServiceAvailableKeys, DCSupportedEncryptionTypes e DCAvailableKeys.
Fonte Microsoft: Event 4768

Evidenza attesa

Prima della remediation:

Event ID: 4768
Account Name: account.rc4
Service Name: krbtgt
Ticket Encryption Type: 0x17
Status: 0x0

Dopo msDS-SupportedEncryptionTypes = 24 e toggle del flag:

Event ID: 4768
Account Name: account.rc4
Service Name: krbtgt
Ticket Encryption Type: 0x12
Status: 0x0

oppure:

Ticket Encryption Type: 0x11

L'evidenza forte è il passaggio da 0x17 a 0x11 o 0x12.

---

Evento 4769 - Kerberos service ticket, TGS

Cosa rappresenta

L'evento 4769 indica che è stato richiesto un Kerberos Service Ticket.

Microsoft descrive l'evento come:

4769 (S, F): A Kerberos service ticket was requested.

Fonte Microsoft: Event 4769

Perché è fondamentale

L'evento 4768 dimostra come viene emesso il TGT.

L'evento 4769 è spesso ancora più importante per questo scenario, perché mostra il tipo di cifratura del ticket rilasciato per il servizio richiesto.

Se stai testando un accesso a:

\\SRVAPP01\Share

oppure a un servizio HTTP, SQL, CIFS, HOST o altro SPN, l'evento 4769 ti dice se il service ticket è RC4 o AES.

Filtro Event Viewer

Nel log Security del DC filtrare:

Event ID: 4769

Campi da controllare

Nel dettaglio dell'evento cercare questi campi:

Campo	Cosa verificare
Account Name / TargetUserName	Account che richiede il ticket
Service Name	SPN/servizio richiesto, es. cifs/SRVAPP01, HTTP/app.contoso.local, HOST/SRVAPP01
Service ID	Account AD associato al servizio, se presente
Ticket Encryption Type	Tipo di cifratura del service ticket
Status	0x0 se successo
Client Address / IpAddress	IP del client di test
Service Supported Encryption Types	Se presente, encryption type supportati dal servizio
Service Available Keys	Se presente, chiavi disponibili per il servizio
DCSupportedEncryptionTypes	Se presente, etype supportati dal DC
DCAvailableKeys	Se presente, chiavi disponibili sul DC
Client Advertized Encryption Types	Se presente, etype proposti dal client

Microsoft documenta l'evento 4769 come evento generato quando il KDC riceve una richiesta TGS, e mostra nel payload aggiornato campi come TicketEncryptionType, ServiceSupportedEncryptionTypes, ServiceAvailableKeys, DCSupportedEncryptionTypes, DCAvailableKeys e ClientAdvertizedEncryptionTypes.
Fonte Microsoft: Event 4769

Evidenza attesa

Prima della modifica:

Event ID: 4769
Account Name: account.rc4
Service Name: cifs/SRVAPP01
Ticket Encryption Type: 0x17
Status: 0x0

Dopo msDS-SupportedEncryptionTypes = 24 + toggle flag:

Event ID: 4769
Account Name: account.rc4
Service Name: cifs/SRVAPP01
Ticket Encryption Type: 0x12
Status: 0x0

oppure:

Ticket Encryption Type: 0x11

Questa è una delle prove più solide dell'articolo.

---

Evento 4771 - Kerberos pre-authentication failed

Cosa rappresenta

L'evento 4771 viene generato quando fallisce la pre-autenticazione Kerberos.

In questo laboratorio serve soprattutto per documentare il comportamento prima della remediation, se l'account non riesce ad autenticarsi nel contesto AES-only.

Filtro Event Viewer

Nel log Security del DC filtrare:

Event ID: 4771

Campi da controllare

Campo	Cosa verificare
Account Name	Account di test
Client Address	Client da cui parte il test
Failure Code	Codice di errore Kerberos
Pre-Authentication Type	Tipo di pre-auth
Ticket Options	Opzioni del ticket

Codici interessanti

In uno scenario di incompatibilità encryption type, il codice più interessante da cercare è:

0xE - KDC has no support for encryption type

Questo codice è utile se il test fallisce perché client, DC e account non riescono a negoziare un tipo di cifratura comune.

Nota: non è detto che ogni test produca 4771. Dipende dal punto esatto in cui fallisce l'autenticazione e dal tipo di richiesta Kerberos generata.

---

Evento 4624 - Logon riuscito

Cosa rappresenta

L'evento 4624 indica un logon riuscito.

In questo laboratorio non basta dimostrare che il logon riesce: bisogna dimostrare che il logon riesce usando Kerberos e non NTLM.

Dove cercarlo

L'evento 4624 può essere cercato:

• sul server/host di destinazione a cui accede l'account;
• in alcuni casi anche sul client, a seconda dello scenario di logon/accesso.

Log:

Event Viewer
 └─ Windows Logs
    └─ Security

Filtro:

Event ID: 4624

Campi da controllare

Campo	Valore atteso
Account Name	Account di test
Logon Type	Dipende dallo scenario, spesso 3 per accesso di rete
Authentication Package	Kerberos
Logon Process	Tipicamente coerente con Kerberos/Negotiate
Workstation Name / Source Network Address	Client di test

Evidenza attesa

Event ID: 4624
Account Name: account.rc4
Logon Type: 3
Authentication Package: Kerberos

Questo serve a chiudere una possibile obiezione:

L'accesso funziona perché sta facendo fallback NTLM.

Se 4624 mostra Authentication Package: Kerberos e 4769 mostra Ticket Encryption Type: 0x12, la prova è molto più forte.

---

Procedura dimostrativa

Fase 1 - Creazione account RC4-only

Creare un account di laboratorio:

New-ADUser `
  -Name "account.rc4" `
  -SamAccountName "account.rc4" `
  -UserPrincipalName "account.rc4@contoso.local" `
  -AccountPassword (Read-Host "Password" -AsSecureString) `
  -Enabled $true

Impostare o lasciare l'account in una condizione iniziale compatibile con RC4-only.

Esempio esplicito:

Set-ADUser account.rc4 -Replace @{
  'msDS-SupportedEncryptionTypes' = 4
}

Verifica attributi:

Get-ADUser fg_account_rc4 -Properties `
  'msDS-SupportedEncryptionTypes', `
  pwdLastSet, `
  PasswordLastSet |
Select-Object SamAccountName, 'msDS-SupportedEncryptionTypes', pwdLastSet, PasswordLastSet

Atteso:

msDS-SupportedEncryptionTypes = 4

oppure un valore coerente con l'uso RC4 nel tuo laboratorio.

Effettuando un test di logon su un client AES-only otterremo un errore di password sbagliata.

---

Fase 2 - Toggle impostazione: attivazione flag

Attivare:

User must change password at next logon

Da PowerShell:

Set-ADUser fg_account_rc4 -ChangePasswordAtLogon $true

Verificare:

Get-ADUser fg_account_rc4 -Properties pwdLastSet, PasswordLastSet |
Select-Object SamAccountName, pwdLastSet, PasswordLastSet

Atteso:

pwdLastSet = 0
PasswordLastSet = <vuoto/non valorizzato oppure equivalente>

Questo è il comportamento documentato da Microsoft: pwdLastSet = 0 forza il cambio password al prossimo logon.
Fonte Microsoft: User Must Change Password at Next Logon - LDAP Provider

Fase 3 - Set msDS-SupportedEncryptionTypes = 24

Impostare AES128 + AES256:

Set-ADUser fg_account_rc4 -Replace @{
  msDS-SupportedEncryptionTypes = 24
}

Verifica:

Get-ADUser fg_account_rc4 -Properties msDS-SupportedEncryptionTypes |
Select-Object SamAccountName, msDS-SupportedEncryptionTypes

Atteso:

msDS-SupportedEncryptionTypes = 24

Dove:

24 decimal = 0x18 hexadecimal = AES128 + AES256

Fonte Microsoft sui bitmapped values: MS-ADTS - msDs-supportedEncryptionTypes

---

Fase 4 - Rimozione toggle

Rimuovere la spunta:

User must change password at next logon

Da PowerShell:

Set-ADUser fg_account_rc4 -ChangePasswordAtLogon $false

Verifica:

Get-ADUser fg_account_rc4 -Properties `
  msDS-SupportedEncryptionTypes, `
  pwdLastSet, `
  PasswordLastSet |
Select-Object SamAccountName, msDS-SupportedEncryptionTypes, pwdLastSet, PasswordLastSet

Atteso:

msDS-SupportedEncryptionTypes = 24
PasswordLastSet = <data/ora corrente>

Microsoft documenta che per rimuovere il requisito di cambio password al prossimo logon si imposta pwdLastSet = -1, e l'attributo viene gestito dal sistema.
Fonte Microsoft: User Must Change Password at Next Logon - LDAP Provider

---

Fase 5 - Test autenticazione Kerberos

Effettuare un logon al client AES-only. La password ora verrà accettata e l'utente riuscirà a completare il login.

Prima di testare ulteriormente, pulire i ticket lato client:

klist purge

Poi generare una richiesta Kerberos reale, ad esempio accedendo a una share:

dir \\SRVAPP01\Share

oppure a un servizio/SPN controllato:

whoami /all

Poi verificare i ticket lato client:

klist

Cercare nel ticket il campo relativo all'encryption type.

Evidenza lato DC

Sul Domain Controller cercare subito dopo il test:

Event ID: 4768
Account Name: fg_account_rc4
Ticket Encryption Type: 0x11 oppure 0x12
Status: 0x0

E soprattutto:

Event ID: 4769
Account Name: fg_account_rc4
Service Name: <SPN testato>
Ticket Encryption Type: 0x11 oppure 0x12
Status: 0x0

Evidenza lato server/target

Sul server target cercare:

Event ID: 4624
Account Name: fg_account_rc4
Authentication Package: Kerberos

Se invece compare:

Authentication Package: NTLM

la prova non è valida per dimostrare Kerberos AES, in quanto si è presentato un fallback verso NTLM e sarà necessario approfondirne il motivo.

---

Evidenza 1 - Stato iniziale account

Output PowerShell:

Get-ADUser fg_account_rc4 -Properties msDS-SupportedEncryptionTypes,pwdLastSet,PasswordLastSet |
Select-Object SamAccountName,msDS-SupportedEncryptionTypes,pwdLastSet,PasswordLastSet

---

Query PowerShell utili per estrarre eventi

Cercare eventi 4768 per account

$Account = "fg_account_rc4"

Get-WinEvent -FilterHashtable @{
  LogName = 'Security'
  Id      = 4768
} | Where-Object {
  $_.Properties.Value -contains $Account
} | Select-Object TimeCreated, Id, Message

Cercare eventi 4769 per account

$Account = "fg_account_rc4"

Get-WinEvent -FilterHashtable @{
  LogName = 'Security'
  Id      = 4769
} | Where-Object {
  $_.Properties.Value -contains $Account
} | Select-Object TimeCreated, Id, Message

Estrarre velocemente ticket RC4/AES dai messaggi

$Account = "fg_account_rc4"

Get-WinEvent -FilterHashtable @{
  LogName = 'Security'
  Id      = 4769
} | Where-Object {
  $_.Message -match $Account
} | Select-Object TimeCreated, Id, @{
  Name = 'TicketEncryptionType'
  Expression = {
    if ($_.Message -match 'Ticket Encryption Type:\s+(0x[0-9A-Fa-f]+)') {
      $Matches[1]
    }
  }
}, Message

Cercare logon Kerberos 4624 sul server target

$Account = "fg_account_rc4"

Get-WinEvent -FilterHashtable @{
  LogName = 'Security'
  Id      = 4624
} | Where-Object {
  $_.Message -match $Account -and
  $_.Message -match 'Authentication Package:\s+Kerberos'
} | Select-Object TimeCreated, Id, Message

---

Esito del test e cosa dimostra davvero

Microsoft documenta che pwdLastSet viene usato per forzare/rimuovere il cambio password al prossimo logon (0 e -1) e che le Available Keys Kerberos sono generate durante password set e password change. Microsoft non documenta in modo esplicito che il solo toggle di User must change password at next logon comporti sempre rigenerazione chiavi AES/RC4. In questo articolo trattiamo quindi tale effetto come evidenza di laboratorio, verificata con eventi 4768/4769 (passaggio da 0x17 a 0x11/0x12) e con controllo 4624 Kerberos senza fallback NTLM.

---

Considerazioni operative

Se confermata in piu ambienti e su piu versioni di Domain Controller, questa tecnica puo essere utile nella remediation RC4 perchè:

• non richiede di conoscere la password del service account;
• non cambia la password usata dall'applicazione;
• aggiorna PasswordLastSet;
• consente di verificare l'effetto tramite eventi Kerberos;
• può ridurre drasticamente l'impatto operativo rispetto a un reset password classico.

Tuttavia, prima di applicarla in produzione, è necessario:

• validarla in laboratorio;
• testarla su account non critici;
• confermare gli eventi 4768 e 4769;
• confermare che l'autenticazione avvenga in Kerberos e non in NTLM;
• verificare replica AD tra i Domain Controller;
• documentare ogni modifica effettuata;
• prevedere rollback operativo.

Se nel tuo ambiente non trovi una dichiarazione Microsoft esplicita sul toggle come meccanismo di rigenerazione chiavi, tratta questo passaggio come "validato in laboratorio" e non come garanzia di prodotto universale. Ripeti sempre il test nel tuo dominio prima di una remediation massiva.

---

Limitazioni e minacce alla validita

1) Replica AD e timing tra DC

Se il test usa DC diversi in tempi ravvicinati, puoi leggere attributi e ticket su repliche non allineate.

Contromisura pratica:

• eseguire modifica attributi e verifica eventi sullo stesso DC quando possibile;
• verificare convergenza replica prima del test conclusivo;
• annotare sempre quale DC ha emesso il 4768/4769 usato come prova.

2) Cache ticket lato client/server

Ticket gia emessi possono inquinare il risultato e far sembrare invariato un comportamento che invece e cambiato.

Contromisura pratica:

• klist purge lato client prima di ogni prova;
• nuova autenticazione reale verso SPN target dopo il purge;
• correlazione temporale stretta tra azione, 4768/4769 e eventuale 4624.

3) Stato iniziale dell'account non omogeneo

Un account che ha gia avuto password rotation recente puo gia avere chiavi AES disponibili, anche se usa ancora RC4 in alcuni flussi.

Contromisura pratica:

• catturare baseline con msDS-SupportedEncryptionTypes, pwdLastSet, PasswordLastSet;
• verificare nei nuovi campi evento la presenza di Account Available Keys e Service Available Keys quando disponibili;
• conservare evidenza "prima" e "dopo" per lo stesso account e stesso SPN.

4) Differenze di build e hardening policy

Patch level dei DC, policy Kerberos, e configurazioni legacy possono cambiare l'esito della negoziazione etype.

Contromisura pratica:

• riportare versione OS DC e livello patch usato nel laboratorio;
• riportare policy Kerberos lato client/server (AES-only, RC4 disabilitato, ecc.);
• ripetere il test su almeno due combinazioni di versione DC/client.

5) Ambiguita tra "chiave disponibile" e "chiave usata"

Che una chiave sia disponibile non implica automaticamente che verra selezionata nel ticket finale; la scelta dipende dalla negoziazione tra client, KDC e account/servizio.

Contromisura pratica:

• usare come prova primaria Ticket Encryption Type su 4769 (service ticket);
• usare 4768 come supporto sul TGT;
• usare 4624 per dimostrare Kerberos e non fallback NTLM.

6) Portata della conclusione

La conclusione corretta non e "il toggle rigenera sempre chiavi in ogni ambiente" ma:

Nel perimetro del laboratorio descritto, il toggle associato a msDS-SupportedEncryptionTypes = 24 e seguito da verifica eventi ha prodotto ticket AES osservabili.

---

Checklist finale di verifica

Step	Verifica	Evidenza
1	Account creato/forzato RC4-only	msDS-SupportedEncryptionTypes = 4 o stato equivalente
2	Ticket iniziale RC4	Event 4768/4769 con Ticket Encryption Type = 0x17
3	Toggle attivato	pwdLastSet = 0
4	AES impostato	msDS-SupportedEncryptionTypes = 24
5	Toggle rimosso	PasswordLastSet aggiornato
6	Ticket finale AES	Event 4768/4769 con Ticket Encryption Type = 0x11 o 0x12
7	Logon Kerberos	Event 4624 con Authentication Package = Kerberos
8	Nessun fallback NTLM	Assenza di 4624 con Authentication Package = NTLM per lo stesso test

---

Fonti ufficiali Microsoft

• User Must Change Password at Next Logon - LDAP Provider
• Pwd-Last-Set attribute - Active Directory Schema
• MS-ADA3 - Attribute pwdLastSet
• MS-ADTS - msDs-supportedEncryptionTypes
• KB5021131 - How to manage the Kerberos protocol changes related to CVE-2022-37966
• Event 4768 - A Kerberos authentication ticket (TGT) was requested
• Event 4769 - A Kerberos service ticket was requested
• ms-DS-KeyVersionNumber attribute - Active Directory Schema

---

Conclusione

Il comportamento documentato da Microsoft è il seguente:

• il flag User must change password at next logon modifica pwdLastSet;
• pwdLastSet = 0 forza il cambio password al prossimo logon;
• pwdLastSet = -1 rimuove il requisito e aggiorna il valore tramite il sistema;
• msDS-SupportedEncryptionTypes controlla i tipi di encryption supportati dall'account.

Il comportamento osservato in laboratorio è più interessante:

dopo aver attivato il flag, impostato msDS-SupportedEncryptionTypes = 24 e rimosso il flag, un account precedentemente legato a RC4 ha iniziato ad autenticarsi correttamente in AES, con evidenza tramite eventi Kerberos 4768/4769.

La prova non deve essere basata sull'impressione che "il login funziona", ma su evidenze oggettive:

4768 / 4769 prima  = 0x17 RC4-HMAC
4768 / 4769 dopo   = 0x11 AES128 oppure 0x12 AES256
4624 finale        = Authentication Package: Kerberos

Se confermato su più ambienti, questo comportamento può diventare un tassello molto utile nelle attività di remediation RC4, soprattutto per service account legacy dove un reset password tradizionale può essere complesso, rischioso o difficilmente coordinabile.