Un evento 4024 significa che una password è stata compromessa?

No. Registra un tentativo SSO con credenziali derivate da NTLMv1. È evidenza di utilizzo e di esposizione a crittografia debole, non prova autonoma di compromissione.

Enforce blocca anche quando l'utente digita una password?

La KB afferma che l'inserimento manuale delle credenziali continua a funzionare. Il comportamento dell'applicazione va comunque testato: l'evento riguarda la richiesta SSO specifica, non ogni autenticazione successiva.

← Field Guides

Active DirectoryAuthenticationCredential GuardHardeningKerberosNTLMSecurity

NTLMv1 e BlockNtlmv1SSO a ottobre 2026: cosa auditare, cosa si blocca e cosa smette di funzionare

Q: Posso impostare BlockNtlmv1SSO=0 per sempre?

La KB documenta 0 come modalità Audit e consente un valore esplicito. Governalo come eccezione di compatibilità con owner, rischio accettato, monitoraggio e data di revisione: non è la remediation finale di una dipendenza legacy.

Q: IAKerb o Local KDC risolvono automaticamente questa dipendenza?

Non è documentato come risultato automatico. Sono capacità Kerberos di una roadmap per scenari specifici; verifica disponibilità, prerequisiti e supporto applicativo nelle fonti e note di rilascio correnti.

Pubblicato: 3 ottobre 2026Aggiornato: 3 ottobre 2026

Topic

Devo cambiare qualcosa prima di ottobre 2026? Sì: identifica i dispositivi Windows 11 24H2 e Windows Server 2025 interessati, raccogli gli eventi 4024 e l'audit NTLM avanzato, verifica Credential Guard e prova l'Enforce in un gruppo pilota. Microsoft ha annunciato che un futuro aggiornamento porterà BlockNtlmv1SSO da Audit a Enforce come default soltanto quando il valore non è stato distribuito esplicitamente. Al 3 ottobre 2026 la KB consultata continua a descrivere un aggiornamento futuro: controlla le note cumulative e il Windows Message Center prima di dichiarare il rollout effettivo.

Risposta rapida

Non è la disabilitazione di NTLM: è il blocco del SSO che richiede credenziali derivate da NTLMv1.
BlockNtlmv1SSO=0 registra e consente; =1 blocca. Il valore esplicito 0 mantiene Audit anche quando cambia il default.
4024 è il warning di Audit; 4025 è l'errore di Enforce. Per scoprire NTLM in generale usa anche 4020-4023.
Credential Guard attivo rende inapplicabili i controlli BlockNtlmv1SSO; non disattivarlo per provare la chiave.
Pianifica audit, pilot, owner applicativi e rollback prima dell'aggiornamento.

Indice

Ambito: cosa cambia e cosa no
- Fatto documentato da Microsoft
- Sistemi nuovi e sistemi precedenti
NTLMv1 SSO non è la disabilitazione di NTLM
Eventi: quale domanda risponde ciascun ID
- Query PowerShell e parsing XML per nome
Inventario della chiave e Credential Guard
- - Raccolta remota PowerShell su un perimetro approvato
Cosa può smettere di funzionare
Piano operativo: inventario, audit, remediation, enforcement
Laboratorio isolato: impostare Enforce e osservare il 4025
Gestione GPO e criteri di rollback
Scheda di evidenza per ogni dipendenza
Verificare il rollout prima di cambiare il default
- Go/no-go per ogni ring
FAQ
Fonti e collegamenti
Ultimo aggiornamento
Disclaimer

Ambito: cosa cambia e cosa no

Fatto documentato da Microsoft

Microsoft ha rimosso il protocollo NTLMv1 da Windows 11, versione 24H2 e Windows Server 2025, e dalle versioni successive. Alcuni scenari possono tuttavia usare primitive crittografiche derivate da NTLMv1: Microsoft cita esplicitamente MS-CHAPv2 in ambienti domain-joined. BlockNtlmv1SSO riguarda la generazione e l'uso di credenziali derivate da NTLMv1 per il Single Sign-On (SSO), non una policy generale che disabilita NTLM. KB5066470

La chiave è:

HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
BlockNtlmv1SSO    REG_DWORD

Dato	Modalità	Effetto documentato
`0`	Audit	Registra il tentativo SSO e lo consente; genera un warning.
`1`	Enforce	Blocca il tentativo SSO; genera un errore.
Valore assente	Default del sistema	Oggi Audit; Microsoft prevede il passaggio predefinito a Enforce con un futuro aggiornamento.

Il cambio di ottobre si applica ai dispositivi dove il valore non è stato distribuito esplicitamente. La KB non nomina un singolo aggiornamento cumulativo, build minima o giorno preciso. La timeline è marcata come tentativo e soggetto a modifica: verifica l'articolo KB, le release notes cumulative per il tuo prodotto e il Windows Message Center. Non dedurre il rollout dalla sola data del calendario.

Sistemi nuovi e sistemi precedenti

Sistema	Cosa si può concludere	Cosa non si può concludere
Windows 11 24H2 e successivi	NTLMv1 è rimosso; restano alcuni usi di primitive derivate, controllati dalla funzione introdotta con gli aggiornamenti indicati da Microsoft.	Non significa che ogni autenticazione NTLM fallisca.
Windows Server 2025	NTLMv1 è rimosso; auditing e controllo sono distribuiti con una timeline distinta dal client.	Non assumere che tutti i server abbiano ricevuto la funzione nello stesso giorno.
Versioni Windows precedenti nel dominio	Possono continuare a implementare NTLMv1 in base a versione, patch e configurazione. Inventariale separatamente.	Impostare la chiave su un client recente non forza i sistemi più vecchi del dominio a comportarsi allo stesso modo.
Appliance e sistemi non Windows	Il comportamento dipende dal client/protocollo e dalla modalità di autenticazione.	La chiave Windows non è un interruttore globale per ogni NAS, RADIUS o appliance.

Per la data esatta e l'aggiornamento di abilitazione per ogni OS/build, usare la matrice di applicabilità aggiornata nella KB5066470; se la KB non la specifica, registrare l'informazione come da confermare, non inferirla dai soli mesi iniziali della timeline.

NTLMv1 SSO non è la disabilitazione di NTLM

NTLM comprende più versioni e percorsi. Questa modifica riguarda SSO basato su credenziali derivate da NTLMv1. Non è la fine di NTLM, non equivale alle policy Restrict NTLM e non blocca in generale NTLMv2. Microsoft descrive la disabilitazione di NTLM di rete per default come una fase separata della roadmap di modernizzazione dell'autenticazione, legata a future release principali client/server. Le versioni già distribuite continuano a supportare NTLM; non c'è in questa modifica una data per una disattivazione generale.

IAKerb e Local KDC mirano a coprire alcuni scenari in cui Kerberos non era praticabile: autenticazione Kerberos mediata senza line-of-sight diretto al DC e autenticazione Kerberos con account locali. Sono elementi della roadmap, non un rimedio automatico a ogni dipendenza NTLM. Al 3 ottobre 2026 non ho verificato una fonte Microsoft che confermi lo stato di rollout della Fase 2 H2 2026: controlla documentazione, note di rilascio e message center prima di inserirlo in un piano con date. Roadmap Windows authentication

Per audit generale, Restrict NTLM, fallback Kerberos, SPN e trust, consulta la guida da audit NTLM a enforcement in Active Directory, la guida agli SPN e la guida sul fallback Kerberos verso NTLM. Non ripeto qui il relativo runbook.

Eventi: quale domanda risponde ciascun ID

Tutti gli eventi citati sono nel canale Microsoft-Windows-NTLM/Operational; verifica che esista, sia abilitato e sia inoltrato. La distinzione importante è l'obiettivo della ricerca:

ID	Lato e livello	Uso corretto
`4020`	Client, Information	Tentativo NTLM in condizioni standard; audit NTLM generale.
`4021`	Client, Warning	Tentativo NTLM con downgrade/condizione di sicurezza da investigare; include contesto del client.
`4022`	Server, Information	Tentativo NTLM in ingresso in condizioni standard.
`4023`	Server, Warning	Tentativo NTLM in ingresso con condizione di sicurezza da investigare.
`4024`	Client, Warning	Richiesta SSO con credenziali derivate da NTLMv1 in Audit, consentita.
`4025`	Client, Error	Richiesta SSO con credenziali derivate da NTLMv1 bloccata in Enforce.

I nuovi eventi 4020-4023 aggiungono informazioni su chi/processo, motivo d'uso e destinazione per autenticazioni NTLM. L'evento Information non è una prova di NTLMv1: normalmente indica NTLMv2 o altro uso NTLM senza il downgrade descritto dall'audit. Il livello Warning segnala un downgrade, che può includere NTLMv1 e altre condizioni. Gli eventi esistenti delle policy Restrict NTLM continuano a essere separati. KB5064479: audit NTLM avanzato

4024/4025 non sono contatori di tutte le autenticazioni NTLMv1 né sostituiscono l'audit domain-wide o i log client/server. Usali per la specifica richiesta SSO con credenziali NTLMv1-derived; per la domanda "chi usa NTLM in generale?" raccogli gli eventi client e server 4020-4023 e gli eventi domain-wide pertinenti, oltre ai normali log già in uso.

Query PowerShell e parsing XML per nome

Esegui la query su una macchina aggiornata e conserva il raw XML durante la validazione. I nomi dei campi EventData possono variare tra eventi/build; non fare affidamento su Properties[n].

# Leggi gli eventi recenti dell'audit NTLM avanzato e del controllo NTLMv1 SSO
$eventIds = 4020, 4021, 4022, 4023, 4024, 4025
$events = Get-WinEvent -FilterHashtable @{
    LogName = 'Microsoft-Windows-NTLM/Operational'
    Id = $eventIds
    StartTime = (Get-Date).AddDays(-14)
} -ErrorAction SilentlyContinue

# Estrai i valori XML usando l'attributo Name, non l'indice Properties
$rows = foreach ($event in $events) {
    [xml]$xml = $event.ToXml()
    $namedData = [ordered]@{}
    foreach ($item in $xml.Event.EventData.Data) {
        $fieldName = [string]$item.Name
        if ($fieldName) {
            $namedData[$fieldName] = [string]$item.'#text'
        }
    }
    [pscustomobject]@{
        TimeCreated = $event.TimeCreated
        Computer = $event.MachineName
        EventId = $event.Id
        Level = $event.LevelDisplayName
        Provider = $event.ProviderName
        EventDataJson = ConvertTo-Json -InputObject $namedData -Compress
        Message = $event.Message
    }
}

# Conserva i dati in una forma importabile dal SIEM o da Excel
$rows | Export-Csv -Path '.\ntlm-events.csv' -NoTypeInformation -Encoding utf8

Prima di usarlo in produzione, valida l'output con almeno un evento reale per ciascun ID che ti interessa e controlla l'XML del provider sulla tua build. Il testo Message è localizzato; per correlazioni stabili usa ID, timestamp, host e campi XML nominati. Evita di esportare identità o nomi host fuori dai canali autorizzati.

Per la raccolta centralizzata, inoltra il canale Operational tramite Windows Event Forwarding (WEF) verso un collector oppure connettore SIEM. Verifica sottoscrizione, latenza, retention, volume, permessi di lettura e preservazione dell'host sorgente. L'evento va raccolto sui client/server che lo generano; non presumere che un DC osservi l'evento locale del processo client.

Inventario della chiave e Credential Guard

Prima di un pilot, identifica OS/build e presenza/dato della chiave su client e server gestiti. La presenza esplicita di 0 è diversa dal valore assente quando il default cambierà.

# Ispeziona la configurazione locale senza modificarla
$path = 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0'
$key = Get-ItemProperty -Path $path -Name BlockNtlmv1SSO -ErrorAction SilentlyContinue
[pscustomobject]@{
    Computer = $env:COMPUTERNAME
    OS = (Get-CimInstance Win32_OperatingSystem).Caption
    Version = (Get-CimInstance Win32_OperatingSystem).Version
    KeyExists = $null -ne $key
    BlockNtlmv1SSO = if ($null -ne $key) { $key.BlockNtlmv1SSO } else { $null }
}

# Controlla se Credential Guard è effettivamente in esecuzione
$deviceGuard = Get-CimInstance -Namespace 'root\Microsoft\Windows\DeviceGuard' `
    -ClassName Win32_DeviceGuard -ErrorAction SilentlyContinue
[pscustomobject]@{
    Computer = $env:COMPUTERNAME
    CredentialGuardRunning = $deviceGuard.SecurityServicesRunning -contains 1
    SecurityServicesRunning = ($deviceGuard.SecurityServicesRunning -join ',')
}

Per una flotta, applica la stessa lettura con gestione remota autorizzata/Configuration Manager/Intune o inventario EDR. Il risultato deve contenere hostname, edizione/versione, build/UBR, valore e origine della configurazione, stato Credential Guard, data dell'ultimo check e owner. Il codice CIM dipende da OS e permessi: validalo sui sistemi reali e non interpretare un campo vuoto come prova di protezione disattivata.

Raccolta remota PowerShell su un perimetro approvato

Questo esempio legge una lista CSV via PowerShell Remoting e non modifica il sistema. L'errore di connessione rimane visibile; una chiave non leggibile non viene convertita in un falso valore zero.

ComputerName,Owner
W11-PILOT-01,Workplace
APP-PILOT-02,Application Operations

# Usa solo un elenco approvato e account autorizzati alla lettura
$computers = Import-Csv '.\ntlm-pilot-computers.csv'
$results = foreach ($computer in $computers) {
  try {
    Invoke-Command -ComputerName $computer.ComputerName -ErrorAction Stop -ScriptBlock {
      $path = 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0'
      $setting = Get-ItemProperty -Path $path -Name BlockNtlmv1SSO `
        -ErrorAction SilentlyContinue
      $os = Get-CimInstance Win32_OperatingSystem -ErrorAction Stop
      $guard = Get-CimInstance -Namespace 'root\Microsoft\Windows\DeviceGuard' `
        -ClassName Win32_DeviceGuard -ErrorAction SilentlyContinue
      [pscustomobject]@{
        ComputerName = $env:COMPUTERNAME
        OS = $os.Caption
        Version = $os.Version
        Build = $os.BuildNumber
        KeyExists = $null -ne $setting
        BlockNtlmv1SSO = if ($setting) { $setting.BlockNtlmv1SSO } else { $null }
        CredentialGuardRunning = $guard.SecurityServicesRunning -contains 1
        QueryStatus = 'Success'
      }
    } | ForEach-Object {
      $_ | Add-Member Owner $computer.Owner -PassThru
    }
  }
  catch {
    [pscustomobject]@{
      ComputerName = $computer.ComputerName
      Owner = $computer.Owner
      OS = $null
      Version = $null
      Build = $null
      KeyExists = $null
      BlockNtlmv1SSO = $null
      CredentialGuardRunning = $null
      QueryStatus = $_.Exception.Message
    }
  }
}
$results | Export-Csv '.\ntlm-pilot-inventory.csv' -NoTypeInformation -Encoding utf8

Il remoting deve essere già autorizzato dal baseline: non abilitarlo sui sistemi di produzione per comodità. Prova una macchina raggiungibile e una non raggiungibile; la seconda deve produrre un errore esplicito, non dati di policy inventati. Ripeti la lettura dopo il refresh GPO/MDM. La configurazione sull'endpoint, non la sola assegnazione di una policy nel portale, è l'evidenza dell'applicazione.

Credential Guard va verificato come stato effettivamente running, non dedotto soltanto dall'esistenza della policy. Microsoft afferma che, se Credential Guard è attivo, le modifiche BlockNtlmv1SSO non hanno effetto: Credential Guard già protegge dalle primitive crittografiche NTLMv1. Non spegnerlo per far funzionare il test della chiave. Verifica comunque compatibilità applicativa secondo la documentazione Credential Guard.

Cosa può smettere di funzionare

In Enforce si blocca la richiesta SSO che richiede credenziali derivate da NTLMv1. L'inserimento manuale delle credenziali continua a funzionare secondo la KB: non equivale a garantire che l'intera applicazione o il protocollo sottostante sia compatibile. La prova determinante è un 4025 correlato alla funzione che fallisce. Di seguito separo il caso documentato dalla dipendenza plausibile, che non va dichiarata presente senza evento o riproduzione.

Scenario	Sintomo possibile	Cosa aspettarsi nel log	Stato dell'evidenza	Remediation/mitigazione
MS-CHAPv2 in ambiente domain-joined	Autenticazione di rete o accesso remoto rifiutato/non completato quando si tenta SSO con credenziali derivate.	`4024` in Audit o `4025` in Enforce sul client che genera la richiesta, se il flusso attiva quel controllo.	MS-CHAPv2 domain-joined è citato da Microsoft come scenario che usa primitive NTLMv1; non è garantito che ogni flusso generi l'evento.	Identifica chi richiede le credenziali, il metodo EAP/PPP/RADIUS e il supporto del vendor. Migra a metodo moderno supportato o mantieni Audit esplicito durante il piano di sostituzione.
VPN con autenticazione MS-CHAPv2	Login VPN fallito dopo cambio; possibile funzionamento con reinserimento manuale o con un diverso metodo.	`4025` solo se si verifica la specifica richiesta SSO derivata NTLMv1. Un errore VPN senza 4025 non dimostra relazione causale.	Plausibile in base a MS-CHAPv2; dipende dal client, dal profilo VPN, dal plugin e dall'uso SSO.	Prova il profilo con account di test; raccogli log client VPN, NPS/RADIUS e NTLM Operational; aggiorna profilo/vendor o metodo EAP.
Wi-Fi 802.1X / NPS / RADIUS	Autenticazione wireless fallita per alcuni utenti o dispositivi.	Correlare eventuale `4025` lato endpoint con gli eventi NPS/RADIUS; NPS non è il punto in cui assumere a priori che il 4025 venga scritto.	Plausibile soltanto se la negoziazione usa uno scenario MS-CHAPv2/SSO interessato. Non tutte le reti 802.1X usano MS-CHAPv2.	Verifica EAP scelto, policy NPS, identità macchina/utente e catena dei certificati; preferisci un metodo supportato non dipendente dalle primitive coinvolte.
Applicazione legacy domain-joined	Accesso a una risorsa o avvio di un componente non completato; richiesta credenziali ripetuta.	`4025` con processo, target e identità se il componente richiede l'SSO specifico.	Plausibile; “legacy” da solo non prova uso di NTLMv1-derived SSO.	Identifica processo e chiamante dal record; chiedi al vendor se usa MS-CHAPv2 o credenziali derivate; aggiorna/configura il metodo.
NAS o appliance	Accesso SMB, VPN o autenticazione centralizzata fallisce solo da determinati client.	Possibile `4025` sul client se è lì che viene richiesta la credenziale derivata. La mancanza dell'evento non esclude problemi di protocollo distinti.	Da testare: supporto NTLMv1/NTLMv2 e autenticazione appliance variano per firmware e flusso.	Verifica firmware e modalità negoziata; testa Kerberos/NTLMv2 o metodo supportato; non attribuire ogni errore SMB a questa chiave.
Servizio Windows o attività pianificata	Job fallisce sotto identità di servizio o senza sessione interattiva.	`4025` soltanto se il job invoca la generazione SSO interessata; controlla PID/processo, account e ora.	Ipotesi da testare; servizi e scheduled task non usano automaticamente NTLMv1.	Riproduci sotto lo stesso account e tipo di logon; verifica credenziali salvate, task history e destinazione; migra a gMSA/Kerberos dove appropriato.
Software di terze parti datato	Errore SSO o richiesta di password dopo aggiornamento.	`4025` dà una prova utile se il software ha richiesto le credenziali bloccate; altrimenti cercare il log specifico del prodotto.	Da confermare con il vendor o in laboratorio; l'età del software non prova la dipendenza.	Aggiorna il prodotto, configura un provider supportato o documenta temporaneamente Audit esplicito con scadenza.

Una richiesta manuale di username/password non è una mitigazione universale: Microsoft documenta che l'inserimento manuale continua a funzionare, ma il risultato dipende da come l'applicazione usa quelle credenziali e dal protocollo successivo. Non confondere un fallback UI riuscito con la rimozione della dipendenza crittografica.

Percorso osservato	Comportamento documentato/atteso	Evidenza da raccogliere
SSO automatico dell'utente connesso, Audit	La richiesta NTLMv1-derived è consentita e genera 4024.	Processo, target, account, orario e risultato funzionale.
Stessa richiesta SSO, Enforce	La richiesta viene bloccata e dovrebbe generare 4025.	Evento sul client e fallimento dello stesso workflow.
Inserimento esplicito delle credenziali	Microsoft afferma che continua a funzionare; il risultato applicativo dipende dall'uso successivo.	Richiesta manuale in test, log dell'app e protocollo negoziato.
NTLMv2 o Kerberos	Non è l'uso bloccato da questa specifica chiave.	Conferma con le evidenze del protocollo, non dal solo esito dell'accesso.
App continua a fallire senza 4025	La chiave non è dimostrata come causa.	Log app/VPN/RADIUS, Restrict NTLM e telemetria del target.

Per confrontare SSO e richiesta manuale in modo controllato, usa lo stesso client isolato, account di test, target e operazione. Registra il protocollo e non riutilizzare credenziali salvate tra le prove. Se il percorso SSO viene bloccato ma quello manuale riesce, hai verificato la differenza funzionale documentata; non hai dimostrato che il servizio remoto abbia cambiato protocollo o che la dipendenza sia stata rimossa.

Se la richiesta manuale riesce ma non compare 4025, non concludere che il sistema non abbia mai usato NTLMv1-derived SSO: la prompt può aver bypassato il percorso automatico. Ripeti il test del percorso originale separatamente e conserva i due risultati sotto lo stesso change ID.

Piano operativo: inventario, audit, remediation, enforcement

1. Inventario e baseline

Esporta tutti i device Windows 11 24H2+ e Windows Server 2025, separando client, server applicativi e sistemi che terminano VPN/RADIUS.
Registra versione/build/UBR, patch cumulativa, ruolo, owner, criticità e finestra di test.
Rileva chiave assente, 0, 1 e la provenienza (GPO, MDM, script, configurazione locale).
Verifica Credential Guard running e prerequisiti, senza dedurlo dalla sola edizione Windows.
Individua workload MS-CHAPv2 documentati in configurazioni VPN/802.1X/RADIUS; marca come ipotesi quelli non confermati.

2. Audit

Conferma presenza della feature sulle build da osservare seguendo KB5066470; non dare per universale il rollout per mese.
Raccogli 4024 per NTLMv1-derived SSO e 4020-4023 per NTLM generale da client/server; conserva gli eventi di dominio e Restrict NTLM già usati.
Fai forward del canale con WEF/SIEM; mantieni almeno un ciclo di business completo, inclusi turni, backup, batch e recovery.
Arricchisci ogni evento con processo, target, account, origine, owner applicativo e test riproducibile.
Se il 4024 non appare, non concludere che il dispositivo sia privo di dipendenze: controlla patch, canale, forwarding e frequenza reale del workflow.

3. Remediation e test

Classifica la dipendenza come documentata, osservata nel proprio log oppure ipotesi da provare.
Chiedi al vendor il protocollo e il supporto a Kerberos o metodi moderni; non riscrivere stringhe SPN/trust qui, usa le guide interne specifiche.
Crea un gruppo pilota rappresentativo e privo di servizi Tier 0 o dipendenze non comprese.
Prova Enforce solo su endpoint senza Credential Guard attivo, perché la chiave non ha effetto quando Credential Guard è running.
Valida login interattivo, task, VPN, Wi-Fi, applicazioni line-of-business, failover, riavvio e help desk; correlazione attesa: evento 4025 e impatto funzionale nello stesso intervallo.

4. Enforcement graduale

Estendi per ring/OU/profilo di dispositivo, con owner approvato e finestra change.
Controlla 4025, ticket, errori applicativi e fallimenti di autenticazione; definisci soglie e durata del monitoraggio prima di partire.
Mantieni un registro delle eccezioni BlockNtlmv1SSO=0: sistema, responsabile, motivazione, scadenza, remediation e controllo compensativo.
Dopo ogni ring, conferma GPO/MDM resultant configuration e verifica che i valori siano quelli attesi sul client, non solo nel portale.
Rimuovi l'eccezione Audit solo dopo aver validato il percorso alternativo e concordato il ritiro con l'owner.

Checklist di review

Laboratorio isolato: impostare Enforce e osservare il 4025

Il cambio di DWORD non produce da solo l'evento 4025. Serve un'applicazione o un flusso controllato che chieda davvero credenziali SSO derivate da NTLMv1. Microsoft cita MS-CHAPv2 in ambienti domain-joined, ma non garantisce che ogni implementazione o richiesta generi quel record. Se non disponi di un trigger documentato e riproducibile, il laboratorio deve fermarsi alla verifica della configurazione: non simulare l'evento con dati inventati.

Componente	Baseline raccomandata
Client	VM di test Windows 11 24H2 aggiornata, snapshot e rete isolata
Identità	Account e password di test; nessuna credenziale reale o privilegiata
Servizio	Implementazione di test MS-CHAPv2/RADIUS autorizzata e configurata per il dominio lab
Log	NTLM Operational abilitato e raccolta raw XML locale
Sicurezza	Credential Guard disabilitato solo se il laboratorio approvato deve testare la chiave; non modificare host di produzione
Cleanup	Ripristino snapshot o restore esplicito della configurazione precedente

Registra OS/build, patch e stato Credential Guard; abilita Microsoft-Windows-NTLM/Operational e annota l'ora.
Esporta la chiave corrente e salva se il valore esiste. Non proseguire se la VM non è isolata o se lo scenario usa identità reali.
Riproduci una volta il flusso supportato in Audit (0) e cerca 4024. Se non lo produce, verifica che il flusso sia quello documentato; non assumere che un login MS-CHAPv2 sia sufficiente.
Imposta Enforce (1) sulla sola VM, ripeti la stessa richiesta e confronta timestamp, processo, target e risultato con la baseline.
Risultato atteso solo se la richiesta SSO coinvolta viene esercitata: evento 4025 e SSO bloccato. Eventi assenti o un errore RADIUS senza 4025 non provano che BlockNtlmv1SSO sia la causa.
Ripristina 0 esplicito per tornare in Audit e ripeti il test; se non puoi ricostruire lo stato precedente, ripristina lo snapshot.

# Solo sulla VM isolata: abilita il canale e imposta Enforce
$logName = 'Microsoft-Windows-NTLM/Operational'
wevtutil set-log $logName /enabled:true
$regPath = 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0'
New-Item -Path $regPath -Force | Out-Null
New-ItemProperty -Path $regPath -Name BlockNtlmv1SSO `
    -PropertyType DWord -Value 1 -Force | Out-Null
Get-ItemProperty -Path $regPath -Name BlockNtlmv1SSO

# Dopo il test: imposta esplicitamente Audit, non lasciare il valore assente
Set-ItemProperty -Path $regPath -Name BlockNtlmv1SSO -Type DWord -Value 0
Get-WinEvent -FilterHashtable @{
    LogName = $logName
    Id = 4024, 4025
    StartTime = (Get-Date).AddMinutes(-30)
} -ErrorAction SilentlyContinue | Format-List TimeCreated, Id, LevelDisplayName, Message

La prova non è un'autorizzazione a eseguire MS-CHAPv2 o modificare l'autenticazione della produzione. Per testare il cambiamento del default, usa una seconda VM senza valore esplicito dopo aver ricevuto l'aggiornamento Microsoft applicabile e verifica la KB/release notes: non anticipare il comportamento futuro disinstallando update o facendo supposizioni sulla build.

Gestione GPO e criteri di rollback

Non esiste in questa guida una policy Restrict NTLM equivalente: BlockNtlmv1SSO è un valore di registro. Puoi distribuirlo con Group Policy Preferences > Windows Settings > Registry (Hive HKEY_LOCAL_MACHINE, key SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0, value BlockNtlmv1SSO, type REG_DWORD) o con lo strumento di gestione endpoint approvato. Filtra lo scope, controlla precedence e conflitti, e misura il risultato sul client. Per rimanere esplicitamente in Audit dopo il cambio del default, crea il valore 0; non cancellarlo.

Distribuzione GPO del valore Audit

Configura la preferenza Registry in una GPO separata e con targeting del ring approvato:

Campo GPP	Valore
Action	Update
Hive	`HKEY_LOCAL_MACHINE`
Key Path	`SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0`
Value name	`BlockNtlmv1SSO`
Type	`REG_DWORD`
Data	`0`
Targeting	Gruppo computer pilota o OU laboratorio

Update crea o modifica il valore indicato senza cancellare dati non correlati. Se Audit ed Enforce sono gestiti da GPO diverse, gli scope devono essere mutuamente esclusivi oppure la precedence va documentata. Un endpoint non deve ricevere in modo ambiguo sia 0 sia 1.

Sequenza change:

Crea una GPO pilota con change ID e modalità espliciti nel nome.
Collega la policy soltanto all'OU isolata o usa security filtering per i computer approvati.
Esporta gpresult e chiave corrente prima della modifica.
Esegui gpupdate /target:computer /force nella finestra autorizzata.
Verifica il valore registro sul client e salva il report resultant set of policy.
Ripeti query eventi e test funzionali dopo l'applicazione.
Rimuovi o restringi il targeting solo dopo aver verificato la rimozione dell'impostazione residua.

# Esegui dal client pilota durante la finestra approvata
gpupdate /target:computer /force
gpresult /scope computer /h '.\gpresult-ntlmv1-pilot.html'
Get-ItemProperty `
  -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0' `
  -Name BlockNtlmv1SSO

Non abilitare contemporaneamente il deny generale delle policy Restrict NTLM nello stesso pilot: BlockNtlmv1SSO e Restrict NTLM sono controlli diversi, e un doppio blocco rende più difficile attribuire l'impatto.

Rollback: se un servizio critico presenta un fallimento correlato a 4025 e la remediation immediata non è disponibile, il responsabile change può impostare BlockNtlmv1SSO=0 esplicitamente sul gruppo impattato, verificare la distribuzione e ri-testare il workflow. Registrare motivazione, owner, scadenza, rischio residuo, monitoraggio e piano per eliminare l'eccezione. Il rollback del valore non ripristina NTLMv1 come protocollo sui sistemi dai quali è stato rimosso, non disabilita Credential Guard e non corregge altri errori di autenticazione.

Scenario	In Audit (`0`)	In Enforce (`1`)	Azione consigliata
Nessuna richiesta NTLMv1-derived SSO	Nessun 4024 per quel percorso osservato.	Nessun impatto atteso da questa chiave.	Continua a monitorare per una finestra che copra i workflow periodici.
Richiesta SSO identificata dal 4024	Warning registrato; la richiesta è consentita.	Il tentativo è bloccato e dovrebbe generare 4025.	Identifica processo e owner; prova alternativa prima di applicare Enforce.
MS-CHAPv2 domain-joined	Può continuare se la specifica generazione SSO è consentita; il comportamento dipende dal flusso.	Può fallire se usa credenziali derivate e chiede SSO.	Conferma con eventi e test; non dedurre dal solo nome del protocollo.
Credential Guard attivo	Il controllo BlockNtlmv1SSO non ha effetto.	Lo stesso; la chiave non forza un secondo controllo.	Mantieni Credential Guard e verifica che sia running.
Sistema più vecchio senza la feature	Dipende dalla versione e dalle policy disponibili.	Il valore non implica supporto uniforme al controllo.	Fare inventario e consultare la documentazione specifica dell'OS.
Servizio critico interrotto e correlato a 4025	Tornare a `0` consente la richiesta interessata.	SSO bloccato finché Enforce resta attivo.	Rollback mirato e temporaneo, owner e scadenza; migrare il flusso.

Rispondere a un'interruzione correlata a 4025

Tratta l'evento come un problema di disponibilità circoscritto finché le evidenze non indicano altro. Non ripristinare l'intero protocollo NTLM, non disattivare Credential Guard e non cambiare in blocco le policy di autenticazione.

Conferma che il client interessato è in Enforce e che il 4025 coincide con il fallimento del workflow.
Verifica che non sia un secondo controllo, come Restrict NTLM o una policy applicativa, a bloccare la connessione.
Identifica servizio, owner e impatto; valuta se isolare il device o usare un percorso alternativo approvato.
Se il change owner autorizza l'eccezione, imposta BlockNtlmv1SSO=0 esplicitamente per il solo endpoint/ring interessato tramite la sorgente di configurazione governata.
Conferma localmente la modalità Audit, ripeti il workflow con l'owner e osserva se la richiesta viene consentita.
Se il problema persiste senza 4024, ripristinare il valore non è una diagnosi: continua il troubleshooting del protocollo/applicazione.
Registra la scadenza e l'owner per la rimozione dell'eccezione; non trasformare il rollback urgente in una policy permanente non tracciata.

Se la policy arriva da GPO/MDM, modifica la configurazione sorgente per lo scope autorizzato. Un Set-ItemProperty locale può essere sovrascritto al successivo refresh e creare divergenza dal configuration management. Usalo soltanto in una VM isolata o quando il runbook aziendale autorizza esplicitamente l'azione locale.

# Esempio locale per un endpoint di test o rollback esplicitamente autorizzato
$path = 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0'
New-Item -Path $path -Force | Out-Null
Set-ItemProperty -Path $path -Name BlockNtlmv1SSO -Type DWord -Value 0
Get-ItemProperty -Path $path -Name BlockNtlmv1SSO

Questo comando non ripristina il protocollo NTLMv1 sulle versioni Windows che lo hanno rimosso; consente soltanto il percorso SSO derivato controllato da questa chiave dove la funzione è disponibile. Dopo il servizio ripristinato, conserva l'evento, il change, il valore effettivo e il test che conferma l'esito.

Triage di un evento 4024 o 4025

Preserva l'evento originale e raccogli il contesto prima di assegnare un owner. La lettura di un solo campo testuale può confondere account fornito, identità del processo e destinazione.

Evidenza	Uso nel triage
Ora evento e fuso	Correlazione con ticket, log applicativi e tentativo utente. Conserva l'ora originale e normalizza in UTC nel SIEM.
Host sorgente	Identifica il dispositivo che ha generato la richiesta; il server target può essere un host diverso.
Event ID, livello e provider	Distingue audit SSO da blocco SSO e dagli eventi NTLM generali.
PID e nome processo	Punto di partenza per trovare l'applicazione o il servizio chiamante.
User, domain e LUID	Distingue l'utente presentato dall'identità del processo/sessione.
Target server e Mechanism OID	Aiutano a legare il tentativo al servizio, ma l'OID va interpretato solo con documentazione pertinente.
Registro e Credential Guard al momento	Permettono di confrontare l'evento con la configurazione allora effettiva; il valore attuale non prova quello storico.

Procedura suggerita:

Filtra il client per ID e orario ristretto del malfunzionamento.
Apri l'XML raw e individua i campi nominati presenti in quella build.
Associa il nome processo a un servizio, package o prodotto usando inventario/EDR.
Confronta la destinazione con la telemetria applicativa; per VPN o RADIUS usa anche i log specifici del vendor.
Riproduci con un account e endpoint di test mantenendo costanti le altre variabili.
Tratta 4025 più fallimento funzionale nello stesso flusso come evidenza forte; un errore applicativo senza 4025 non dimostra la causa.
Registra build, patch, valore chiave, stato Credential Guard, owner, test e decisione di rollback.

Il testo Microsoft del 4025 è: An attempt to use NTLMv1-derived credentials for Single Sign-On was blocked due to policy. La KB elenca target server, supplied user/domain, PID/nome processo, LUID, identità del processo e Mechanism OID. Considera questi nomi esempi documentati, non uno schema XML immutabile: il parser deve usare il nome effettivo presente nel record raccolto.

Un processo svchost.exe può ospitare più servizi; PID e nome da soli non sempre individuano il componente. Correlali con service control manager, EDR e catalogo applicativo. Il Mechanism OID non identifica da solo il protocollo applicativo o l'owner.

# Conserva XML originale per i soli eventi SSO recenti
$since = (Get-Date).AddHours(-2)
Get-WinEvent -FilterHashtable @{
  LogName = 'Microsoft-Windows-NTLM/Operational'
  Id = 4024, 4025
  StartTime = $since
} -ErrorAction SilentlyContinue |
  ForEach-Object { $_.ToXml() } |
  Set-Content '.\ntlmv1-sso-events.xml' -Encoding utf8

Prima dell'importazione nel SIEM, valida il documento con un parser XML e proteggilo come telemetria di autenticazione: può includere nomi utente, host, processo e target interni. Limita accesso e retention alle regole approvate.

Misurare l'esito del pilot

Confronta finestre pre/post equivalenti e risultati per workflow, non soltanto il numero totale. Retry automatici possono replicare lo stesso 4025; un evento raro può invece coincidere con un job di recovery importante.

Indicatore	Evidenza pre-change	Gate prima di estendere
Eventi 4024	Host, processo, target e fascia oraria distinti.	Dipendenza e owner identificati; alternativa testata o eccezione approvata.
Eventi 4025	Host/processi/target unici oltre al conteggio righe.	Nessun blocco critico non spiegato nella finestra di osservazione.
Errori applicativi e VPN	Baseline di failure ratio e severità.	Nessun aumento oltre la soglia concordata con il service owner.
Ticket service desk	Categoria, impatto, utenti e orari.	Nessun trend irrisolto dopo la durata approvata.
Stato configurazione	Copertura del valore previsto sul ring.	Host in scope verificati; esclusioni con motivazione.
Qualità della raccolta	Host sorgente e ritardo di inoltro.	Nessun gap che renda il pilot non osservabile.

Il change owner definisce soglie e durata in base a volume e criticità: Microsoft non pubblica una soglia universale per autorizzare l'enforcement.

Scheda di evidenza per ogni dipendenza

Non aggregare subito tutti gli eventi per account o macchina. Crea prima una riga per combinazione distinta di client, processo, destinazione e workflow; più processi sullo stesso endpoint possono rappresentare dipendenze diverse.

Campo	Contenuto da conservare
ID finding/change	Identificatore stabile del ticket e del change.
Prima/ultima osservazione	Timestamp e fuso, mantenendo la sorgente originale.
Client e ruolo	Host sorgente, utente interattivo o identità servizio, funzione aziendale.
Sistema operativo	Edizione, release, build/UBR e aggiornamento cumulativo.
Configurazione	Valore chiave, origine GPO/MDM/locale, stato Credential Guard.
Evento	ID, livello, provider, channel e nome campi XML effettivamente presenti.
Evidenza grezza	Percorso protetto dell'XML originale e retention applicata.
Processo	Nome, PID al momento del log, account e servizio proprietario se identificato.
Identità fornite	User/domain forniti e identità del processo, mantenute distinte.
Destinazione	Target registrato, servizio e indirizzo rilevato se disponibile.
Protocollo	Metodo applicativo osservato e fonte della conferma; non dedurlo da un prompt.
Motivazione NTLM	Usage Id/Reason degli eventi avanzati quando presente.
Impatto	Funzione fallita, utenti, criticità e frequenza, non solo volume eventi.
Owner	Referente tecnico, business owner e vendor/case aperto.
Test	ID del test, account non privilegiato, build e risultato prima/dopo.
Decisione	Remediation, eccezione, rischio accettato, approvatore e scadenza.
Verifica chiusura	Evento assente nel periodo concordato, test funzionale superato e log raccolti.

Pseudonimizza le identità nei report destinati a gruppi che non devono conoscere i nomi utente. Conserva l'associazione reversibile soltanto nel sistema di gestione incidenti autorizzato. Un conteggio privo di processo e destinazione è utile per capacità/volume ma non è sufficiente per approvare Enforce.

Verificare il rollout prima di cambiare il default

La data riportata nella KB è una timeline prevista, non la prova che l'aggiornamento sia già arrivato sul tuo parco. Per registrare il fatto osservato, raccogli in un change log:

Campo	Evidenza da registrare
Data di verifica	Data, ora e fuso della consultazione.
Fonte Microsoft	KB e sezione consultata; release notes del prodotto/KB cumulativa; eventuale Message Center ID.
Sistema verificato	Edizione, release, build e UBR del client/server.
Stato chiave	Assente, `0` o `1`; annota se GPO/MDM l'ha impostata.
Stato Credential Guard	Running/non-running, raccolto sullo stesso endpoint.
Prova del comportamento	Audit 4024 o Enforce 4025 da test autorizzato; se non osservato, scrivi "non riprodotto".
Decisione	Ring interessato, owner approvatore, eccezione, data di riesame e rollback.

Prima di chiamare il cambio "distribuito", verifica più di una macchina e il suo update cumulativo, confronta la documentazione applicabile e conferma se il valore è esplicito o assente. Una policy che imposta 0 può mascherare il nuovo default intenzionalmente; una chiave assente su una build non ancora aggiornata può semplicemente non avere ricevuto la modifica.

Go/no-go per ogni ring

Procedi al ring successivo soltanto quando tutti questi punti sono veri:

il team di endpoint ha confermato release, build/UBR e aggiornamento Microsoft applicabile;
l'owner applicativo ha esaminato i 4024 e le ipotesi MS-CHAPv2 pertinenti;
la copertura WEF/SIEM è sufficiente a osservare i client del ring;
Credential Guard è stato classificato per device e la chiave non è usata come controllo di test dove è già running;
la prova in Enforce ha un criterio funzionale, owner business e finestra approvata;
il rollback a 0 esplicito è testato e il gruppo di eccezione ha scadenza;
il service desk conosce sintomi e percorso di escalation per il ring.

Fermati e resta in Audit se non puoi attribuire una richiesta a un processo/owner, non hai log dal computer che genera il SSO, trovi un 4025 su workflow critico non classificato o il test non riproduce lo stato effettivo di produzione.

Il change record dovrebbe separare tre stati, senza comprimerli in "NTLM disattivato":

Annunciato da Microsoft: l'articolo KB prevede un futuro default Enforce e può ancora essere soggetto a modifica.
Disponibile nel prodotto: release note o aggiornamento identifica il prodotto/build a cui si applica.
Osservato nel parco: inventario/configurazione e test sui device mostrano il risultato dopo l'aggiornamento.

Solo il terzo stato consente di descrivere l'impatto realmente osservato nell'ambiente; il primo e il secondo non sostituiscono il test funzionale.

FAQ

NTLMv1 viene disattivato ovunque a ottobre 2026?

No. Il cambiamento riguarda il SSO con credenziali derivate da NTLMv1 sui dispositivi applicabili senza chiave esplicita. NTLMv2 resta consentito e la roadmap di disabilitazione di NTLM di rete è un'iniziativa distinta.

Posso impostare `BlockNtlmv1SSO=0` per sempre?

La KB documenta 0 come modalità Audit e consente di mantenere il valore esplicito. È una mitigazione di compatibilità da governare con owner, rischio accettato, monitoraggio e data di revisione, non la remediation finale di una dipendenza crittografica legacy.

Un 4024 significa che una password è stata compromessa?

No. È un evento di audit di un tentativo SSO con credenziali derivate da NTLMv1. Trattalo come evidenza di utilizzo e superficie crittografica debole, non come prova autonoma di compromissione.

Enforce blocca anche quando l'utente digita la password?

La KB afferma che l'inserimento manuale delle credenziali continua a funzionare. Il comportamento dell'applicazione resta da testare: l'evento copre la richiesta SSO specifica, non tutte le possibili autenticazioni successive.

Devo attendermi un 4025 da ogni client o DC?

No. L'evento è legato al tentativo SSO che viene bloccato e al componente che effettua la richiesta. Non assumerne la presenza sui DC per una chiamata generata sul client; usa la documentazione dei canali e l'host sorgente.

Come distinguo NTLMv1 da NTLMv2?

Usa gli eventi e i campi specifici della feature, non solo un accesso riuscito o Authentication Package: NTLM. Gli eventi generali 4020-4023 aiutano a trovare l'uso NTLM ma non sono da soli un indicatore univoco di NTLMv1.

IAKerb o Local KDC risolvono automaticamente questa dipendenza?

Non è documentato come automatismo. Sono capacità Kerberos in una roadmap per scenari specifici; verifica disponibilità, prerequisiti e supporto dell'applicazione nella documentazione e nelle release notes correnti.

Fonti e collegamenti

Microsoft Support, KB5066470: upcoming changes to NTLMv1 in Windows 11 24H2 and Windows Server 2025.
Microsoft Support, KB5064479: NTLM auditing enhancements.
Microsoft Learn, Credential Guard overview.
Microsoft Learn, NTLM deprecation and Windows authentication resources.
Windows IT Pro Blog, The evolution of Windows authentication.
Per audit NTLM generale e rollback delle policy: Da audit a enforcement NTLM in Active Directory.
Per i prerequisiti di SPN e fallback: SPN in Active Directory e Fallback Kerberos verso NTLM.
Per valutare una policy di protezione account senza usarla come interruttore generico: Protected Users: limiti in produzione.

Ultimo aggiornamento

Ultimo aggiornamento: 3 ottobre 2026. Al controllo odierno, la KB descrive ancora il cambio di default come un futuro aggiornamento e la timeline resta tentativo. Ricontrolla le note cumulative e il Windows Message Center; quando il rilascio sarà identificabile, aggiorna questa nota con KB, build e data osservate.

Disclaimer

Le istruzioni di laboratorio sono destinate a VM e reti isolate. Non applicare Enforce, non cambiare Credential Guard e non modificare metodi VPN/Wi-Fi/RADIUS in produzione senza inventario, change approvato, test funzionale, monitoraggio e rollback. Gli scenari marcati plausibili o da confermare non sono comportamenti garantiti da Microsoft. Verifica le fonti e il comportamento della tua build prima di agire.

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

Active Directory / Authentication