Dopo gli aggiornamenti di sicurezza distribuiti da Microsoft dalla fine di agosto 2025, alcune installazioni Windows create clonando immagini o macchine virtuali senza un processo di generalizzazione supportato possono iniziare a mostrare errori di autenticazione Kerberos e NTLM. Il problema riguarda in particolare Windows 11 24H2 e 25H2 e Windows Server 2025 quando sono presenti SID macchina duplicati.
Microsoft documenta il comportamento come una misura di sicurezza intenzionale: i nuovi controlli bloccano gli handshake di autenticazione tra dispositivi con SID duplicati. Nei log di sistema il segnale più utile è l’evento LsaSrv 6167, spesso accompagnato da richieste ripetute di credenziali, “Access denied”, impossibilità di raggiungere share di rete o problemi con RDP e Failover Clustering.
In breve Se un server o un client è stato duplicato da un’immagine Windows non preparata correttamente con Sysprep, gli aggiornamenti 2025 possono rendere visibile un problema di identità macchina che in precedenza rimaneva latente. |
Cosa è cambiato con gli aggiornamenti Windows del 2025
Microsoft ha introdotto controlli aggiuntivi sull’univocità dei SID con gli aggiornamenti rilasciati dal 29 agosto 2025. La protezione è stata poi inclusa nei successivi aggiornamenti cumulativi, tra cui quello del 9 settembre 2025. Non è quindi corretto considerare il blocco un semplice bug introdotto da un singolo update: si tratta di un enforcement di sicurezza destinato a rimanere.
La conseguenza pratica è che un processo di clonazione che prima poteva sembrare funzionare può oggi causare errori di autenticazione. Il comportamento non va aggirato disabilitando protezioni o forzando fallback: va corretta la modalità con cui viene creata e distribuita l’immagine Windows.
Machine SID e SID dell’oggetto computer in Active Directory: non sono la stessa cosa
Un SID (Security Identifier) identifica un security principal Windows. È importante però distinguere il SID locale della macchina dal SID dell’oggetto computer creato nel dominio Active Directory. Quando un computer viene unito al dominio, Active Directory assegna all’oggetto computer una propria identità di dominio.
Il problema descritto da Microsoft nasce quando più installazioni Windows derivano da una duplicazione non supportata e conservano lo stesso machine SID. I controlli introdotti nel 2025 rilevano questa condizione durante l’autenticazione e possono rifiutare l’handshake. Per questo rinominare il computer o rimuoverlo e riaggiungerlo al dominio non costituisce una remediation affidabile del problema alla radice.
Sintomi tipici dei SID duplicati
- Richieste ripetute delle credenziali nonostante username e password corretti.
- Errori “Access denied” o autenticazione negata su risorse di rete.
- Share SMB non raggiungibili tramite nome host o indirizzo IP.
- Sessioni RDP che non si stabiliscono, anche attraverso strumenti PAM o gateway di terze parti.
- Problemi Failover Clustering con errore di accesso negato.
- Event ID 6167 di LsaSrv nel registro System, associato a un mismatch dell’identità macchina.
Come verificare se il problema è realmente un SID duplicato
- Controllare la versione di Windows e verificare se il sistema rientra tra Windows 11 24H2/25H2 o Windows Server 2025 con update successivi al 29 agosto 2025.
- Aprire Event Viewer > Windows Logs > System e cercare eventi LsaSrv con ID 6167 in corrispondenza dei tentativi di autenticazione falliti.
- Ricostruire la provenienza della VM o del template: immagine clonata, snapshot trasformato in template, copia VHD/VHDX o duplicazione di un’installazione già avviata.
- Verificare il processo di image engineering: l’immagine di riferimento deve essere stata generalizzata correttamente prima della duplicazione.
- Evitare di concludere che la causa sia il SID solo perché Kerberos fallisce: DNS, SPN, trust, time skew e configurazioni AD restano cause distinte da escludere.

Kerberos e NTLM non ci stanno più: e fanno bene
Quando un server tenta di autenticarsi in dominio, oggi Kerberos controlla con più precisione l’identità della macchina. Se trova incongruenze o duplicazioni, si rifiuta di procedere. Il sistema prova allora a ripiegare su NTLM, ma anche lì i nuovi controlli impediscono che una macchina “dubbia” venga autenticata.
Risultato: autenticazione bloccata.
Non un bug, non un errore di configurazione: una scelta di sicurezza.

Paradossalmente, questi problemi emergono spesso dopo un update: è proprio l’aggiornamento a introdurre controlli più severi.
Remediation permanente: ricostruire i sistemi con Sysprep
La soluzione permanente indicata da Microsoft è ricostruire i dispositivi interessati usando un metodo supportato di clonazione o duplicazione, in modo che ogni installazione abbia un SID univoco. Nei processi basati su immagini Windows questo significa integrare Sysprep con l’opzione /generalize prima di acquisire o distribuire il template.
sysprep /generalize /oobe /shutdown
Il comando va inserito in un processo di deployment controllato, non eseguito alla cieca su un server di produzione. Prima di generalizzare un’immagine occorre considerare ruoli installati, applicazioni, agent, licenze, stato del dominio e requisiti specifici del workload.
Perché SID changer e workaround non sono la prima scelta
Utility che modificano il SID o workaround che riducono i controlli possono sembrare più rapidi, ma non equivalgono al processo di duplicazione supportato da Microsoft. Su sistemi aziendali e server di dominio la priorità deve essere ripristinare una catena di deployment corretta e documentata.
Microsoft prevede anche una Group Policy speciale come mitigazione temporanea per alcuni scenari, ma deve essere richiesta al supporto Microsoft for Business. Va trattata come misura transitoria mentre si pianifica il rebuild dei dispositivi con SID duplicati, non come configurazione definitiva.
Se gli errori Kerberos/NTLM non dipendono solo dal template ma fanno emergere problemi di SPN, deleghe, protocolli legacy o configurazioni del dominio, conviene verificare l’intera postura di Active Directory. |

Come evitare che il problema si ripresenti
- Definire una golden image distinta per ruolo e versione del sistema operativo.
- Generalizzare l’immagine prima di trasformarla in template o distribuirla.
- Automatizzare naming, join al dominio, agent e configurazioni post-deploy anziché “congelarle” nel template.
- Documentare il ciclo di vita delle immagini e rigenerarle periodicamente.
- Validare Kerberos, NTLM, RDP, SMB e workload applicativi su un clone di test prima della messa in produzione.
- Ridurre progressivamente la dipendenza da NTLM dove possibile, senza confondere questo progetto con la remediation dei SID duplicati.
SID duplicati, Kerberos e NTLM: cosa NON fare
- Non disabilitare aggiornamenti di sicurezza per mantenere in vita template non supportati.
- Non usare il rejoin al dominio come unica remediation se l’immagine di origine conserva un SID duplicato.
- Non attribuire automaticamente ogni errore Kerberos a un SID duplicato: verificare evento 6167 e contesto.
- Non modificare SID su Domain Controller o sistemi critici con tool non supportati.
- Non trasformare la pagina in una guida generale a NTLM o Active Directory: mantenere il focus sul caso duplicate SID.
FAQ
Cosa causa gli errori Kerberos e NTLM con SID duplicati?
Gli aggiornamenti Windows rilasciati dal 29 agosto 2025 applicano controlli di sicurezza aggiuntivi sull’univocità dei SID. Se più installazioni Windows derivano da una duplicazione non supportata e condividono lo stesso machine SID, l’autenticazione tra i dispositivi può essere bloccata.
Quale evento indica il problema dei SID duplicati?
Microsoft indica l’evento LsaSrv ID 6167 nel registro System come uno dei principali indicatori dei fallimenti di autenticazione correlati ai nuovi controlli sui SID.
Rimuovere e riaggiungere il computer al dominio risolve il problema?
Non necessariamente. Il join al dominio crea o rinnova l’oggetto computer di Active Directory, ma non corregge alla radice una duplicazione non supportata dell’installazione Windows. La remediation permanente richiede un processo di rebuild o deployment supportato con SID univoci.
Sysprep è la soluzione corretta per i template Windows?
Sì. Per la duplicazione supportata di un’installazione Windows, l’immagine deve essere generalizzata correttamente prima della clonazione. Nei processi basati su immagini si utilizza Sysprep con /generalize secondo la procedura Microsoft.
Esiste un workaround temporaneo?
Microsoft mette a disposizione una Group Policy speciale tramite il supporto Microsoft for Business per mitigare temporaneamente alcuni scenari. Non sostituisce la remediation permanente dei dispositivi con SID duplicati.
Quando il problema è più ampio del singolo clone Errori di autenticazione, NTLM legacy, SPN errati, deleghe e percorsi di escalation spesso convivono nello stesso ambiente Windows. Un assessment AD permette di distinguere il problema puntuale dai rischi strutturali. |


