• Guide, Sicurezza, Sistemi Operativi
• 8 Maggio 2026

Negli ultimi anni Microsoft sta seguendo una direzione abbastanza chiara: rendere Windows sempre meno tollerante verso configurazioni storicamente “funzionanti” ma non necessariamente sicure.

Non parliamo solo di nuove funzionalità, nuove baseline o nuovi controlli opzionali. Parliamo di un cambio più profondo: Windows sta iniziando a trattare l’identità della macchina, il processo di autenticazione e l’elevazione amministrativa come superfici di sicurezza da proteggere in modo molto più rigoroso.

Il recente articolo pubblicato sul Windows IT Pro Blog, “Hardening administrative actions: What IT pros need to know“, va esattamente in questa direzione. Microsoft segnala che alcune modifiche di hardening possono richiedere cambiamenti operativi nelle procedure di imaging, cloning e autenticazione, soprattutto negli ambienti dove i dispositivi Windows sono stati duplicati senza usare Sysprep. Nel Windows Message Center Microsoft collega esplicitamente queste modifiche all’hardening introdotto con gli aggiornamenti da agosto/settembre 2025 e ai possibili errori Kerberos e NTLM su macchine clonate senza Sysprep. Per maggiori informazioni è possibile consultare la documentazione ufficiale.

Il punto interessante è che, in molti casi, ciò che oggi viene percepito come “problema dopo l’aggiornamento” è in realtà una configurazione non supportata che l’aggiornamento ha semplicemente smesso di tollerare.

In altre parole: la patch non rompe l’ambiente. Lo illumina. E a volte, quando accendi la luce in cantina, trovi cose che sarebbe stato meglio sistemare anni prima.

Il tema centrale: identità macchina e SID duplicati

Per capire il problema bisogna partire dal concetto di SID, Security Identifier.

In Windows, il SID è uno degli elementi fondamentali usati per identificare in modo univoco utenti, gruppi, computer e domini. Quando viene creata un’installazione di Windows, il sistema genera un SID macchina. Questo identificatore diventa la base per la generazione dei SID degli account locali creati su quel computer.

Microsoft ricorda da tempo che, quando si distribuisce un’immagine Windows duplicata, è necessario usare Sysprep prima della cattura dell’immagine. Sysprep rimuove dati specifici del sistema, compreso il Computer SID, e prepara l’installazione per essere distribuita correttamente su altri dispositivi.

Il problema nasce quando una macchina viene clonata “così com’è”, senza generalizzazione. In quel caso più dispositivi possono ritrovarsi con lo stesso SID macchina. Per anni questa pratica è sopravvissuta in molti ambienti perché, nella quotidianità, spesso sembrava funzionare. Magari non era supportata, magari non era pulita, ma il file server rispondeva, RDP entrava, gli script giravano e tutti erano moderatamente felici.

Fino a quando Windows non ha iniziato a usare queste informazioni in modo più rigoroso nei controlli di autenticazione.

Cosa cambia con gli aggiornamenti recenti

Secondo Microsoft, gli aggiornamenti Windows rilasciati a partire dal 29 agosto 2025 introducono protezioni aggiuntive che applicano controlli sui SID. Quando due dispositivi hanno SID duplicati, l’autenticazione può fallire perché Windows blocca gli handshake tra quei sistemi. Il problema riguarda Windows 11 versioni 24H2 e 25H2 e Windows Server 2025 dopo l’installazione degli aggiornamenti interessati.

Figura 1 – Tabella riassuntiva

Il sintomo più importante da cercare è l’evento LsaSrv Event ID 6167 nel registro eventi System della macchina di destinazione. Microsoft indica anche possibili errori nel Security log, tra cui SEC_E_NO_CREDENTIALS, e scenari in cui non si riescono a stabilire sessioni RDP o si verificano errori “access denied” in contesti come Failover Clustering.

Questo è un dettaglio fondamentale per chi gestisce infrastrutture Windows: se dopo un aggiornamento iniziano a fallire RDP, accessi SMB, autenticazioni NTLM o Kerberos tra macchine clonate, non bisogna partire subito con il classico rito tribale del reset password, del riavvio casuale o del “sarà DNS”.

Potrebbe essere un problema di identità macchina duplicata.

E quando l’identità è duplicata, Kerberos giustamente inizia a fare domande scomode.

Perché questo è un hardening di sicurezza

Il punto non è semplicemente “Microsoft vuole obbligarci a usare Sysprep”. Il tema è più profondo.

Sui dispositivi joined a dominio, LSASS applica policy di sicurezza e filtra i token di autenticazione di rete. Questo comportamento serve anche a evitare che un amministratore locale possa ottenere privilegi elevati in modo improprio attraverso accessi remoti. Microsoft spiega che alcuni scenari Kerberos, in particolare quelli legati al loopback e alla verifica incoerente dell’identità macchina, potevano essere sfruttati per bypassare controlli di sicurezza.

Con gli aggiornamenti rilasciati dal 26 agosto 2025, l’identità macchina non viene più trattata solo come qualcosa di legato alla singola sessione di avvio. Microsoft introduce componenti persistenti dell’identità macchina, combinando elementi per-boot e cross-boot, così da rendere più difficile riutilizzare dati di autenticazione in modo improprio. Questo permette di rilevare e bloccare meglio determinati abusi, ma può anche far emergere problemi negli ambienti dove più host Windows condividono lo stesso identificativo a causa di cloning non corretto.

Il messaggio, quindi, è abbastanza netto: l’identità della macchina non è un dettaglio cosmetico. È parte del modello di trust.

Figura 2 – Hardening

Il falso mito del “tanto funziona”

Molte organizzazioni hanno procedure di deploy nate anni fa, spesso stratificate nel tempo.

Una golden image.

Un clone veloce.

Un template virtuale.

Uno script post-deploy.

Un join al dominio.

E via, produzione.

Finché tutto funziona, nessuno ha molta voglia di rimettere mano alla catena di provisioning. Il problema è che “funziona” non significa “è corretto”, e soprattutto non significa “sarà accettato dai controlli di sicurezza futuri”.

Microsoft, nella documentazione sulla duplicazione dei dischi Windows, è esplicita: se un’immagine è stata creata senza Sysprep, non è supportato eseguire Sysprep dopo la distribuzione per riportare il computer in conformità. Sysprep deve essere eseguito prima della cattura dell’immagine.

Questo passaggio è importante perché chiude una scappatoia molto comune: “posso sistemarlo dopo?”. In questo caso, no. O almeno non nel modo in cui molti spererebbero.

La risoluzione permanente indicata da Microsoft per i dispositivi con SID duplicati è ricostruirli usando metodi supportati, in modo che abbiano SID univoci. Per gestire la transizione è prevista una Group Policy speciale ottenibile tramite Microsoft Support for Business, ma Microsoft la presenta come soluzione temporanea, non come strategia definitiva.

Administrator Protection: l’altro lato del problema

L’articolo Microsoft si inserisce anche in un contesto più ampio: la riduzione del rischio legato ai privilegi amministrativi.

Con Administrator Protection, Windows 11 introduce un modello in cui l’utente resta in uno stato deprivilegiato e ottiene privilegi amministrativi solo quando necessario, tramite elevazione just-in-time e approvazione esplicita. L’elevazione è integrata con Windows Hello e il token amministrativo viene creato per l’operazione richiesta e poi eliminato quando il processo termina.

Questa impostazione cambia il modo in cui alcune applicazioni e alcuni script storici si aspettano di lavorare. Microsoft segnala che alcune applicazioni potrebbero dipendere dalla presenza costante di diritti amministrativi o dall’accesso al profilo elevato anche quando vengono eseguite in modalità non elevata. In questi casi, con il nuovo modello, potrebbero essere necessari aggiornamenti o modifiche operative.

Anche qui il concetto è lo stesso: Windows sta progressivamente riducendo lo spazio per le ambiguità.

Un admin non è più semplicemente “un utente potente sempre acceso”. Diventa un’identità che deve dimostrare, azione per azione, perché sta chiedendo privilegi elevati.

Cosa devono fare gli amministratori IT

La prima attività è verificare le procedure di imaging e deployment.

Se esistono workflow che clonano macchine Windows senza Sysprep, vanno fermati e ripensati. Questo vale per immagini client, template VDI, macchine virtuali, server clonati da template, ambienti lab promossi a produzione e qualsiasi altro processo in cui “abbiamo sempre fatto così” viene usato come standard tecnico.

La seconda attività è cercare i sintomi negli ambienti già aggiornati. L’evento LsaSrv 6167 diventa un indicatore importante per capire se le nuove protezioni stanno bloccando autenticazioni tra sistemi con identità non coerente. Non va trattato come un errore generico ma come un segnale preciso di mismatch nell’identità macchina.

La terza attività è rivedere gli strumenti di automazione. Script di provisioning, template di virtualizzazione, procedure di gold image e strumenti di cloning devono essere allineati ai metodi supportati. Sysprep non deve essere una postilla nella documentazione ma un passaggio strutturale della catena di distribuzione.

La quarta attività è prepararsi al nuovo modello di amministrazione. Administrator Protection può impattare applicazioni, installer, script schedulati, tool legacy e workflow che presumono la presenza di un token amministrativo sempre disponibile. Microsoft indica anche eventi ETW specifici, come 15031 per elevazione approvata e 15032 per elevazione negata o fallita, utili per monitorare questi scenari.

Impatto pratico negli ambienti enterprise

Gli ambienti più esposti sono quelli dove la standardizzazione delle immagini è cresciuta in modo rapido ma non sempre governato.

Pensiamo a infrastrutture VDI, laboratori tecnici, ambienti OT o industriali, postazioni kiosk, template server, ambienti scolastici, aziende con deployment massivi storici o realtà dove la virtualizzazione ha reso troppo facile duplicare sistemi senza chiedersi se l’identità della macchina venisse davvero rigenerata.

In questi contesti, il rischio non è solo tecnico. È operativo.

Un aggiornamento può far emergere improvvisamente problemi su RDP, SMB, autenticazione NTLM, Kerberos o accessi amministrativi remoti. Dal punto di vista dell’utente, “prima funzionava”. Dal punto di vista della sicurezza, invece, prima funzionava perché Windows non stava ancora applicando controlli più severi.

Ed è qui che serve comunicazione interna: non basta dire che “la patch ha creato problemi”. Bisogna spiegare che l’aggiornamento ha reso visibile una fragilità precedente.

Una checklist operativa

Per affrontare correttamente il tema, una possibile checklist iniziale potrebbe essere questa:

1. Verificare quali sistemi Windows 11 24H2, 25H2 e Windows Server 2025 sono stati distribuiti da immagini o template.
2. Identificare eventuali processi di cloning che non prevedono Sysprep prima della cattura dell’immagine.
3. Cercare eventi LsaSrv 6167 sui sistemi che presentano errori di autenticazione.
4. Correlare gli errori con accessi RDP, SMB, NTLM, Kerberos e scenari di amministrazione remota.
5. Pianificare la ricostruzione dei dispositivi con SID duplicati usando metodi supportati.
6. Evitare workaround permanenti basati su rollback delle protezioni.
7. Testare Administrator Protection su gruppi pilota prima di abilitarlo su larga scala.
8. Aggiornare script, installer e tool legacy che assumono la presenza continua di privilegi amministrativi.
9. Documentare il nuovo processo di imaging.
10. Inserire il controllo sulle immagini nel ciclo di governance infrastrutturale.

Figura 3 – Mappa

Conclusioni

Il messaggio di Microsoft è chiaro: la sicurezza di Windows sta diventando meno permissiva verso configurazioni storicamente tollerate.

Questo può creare attrito, soprattutto negli ambienti dove alcune procedure sono nate anni fa e sono diventate standard solo perché nessuno le ha mai messe davvero in discussione. Ma è anche un passaggio necessario.

Clonare una macchina senza rigenerarne correttamente l’identità non è un dettaglio. È una debolezza del modello di trust. Usare privilegi amministrativi persistenti come se fossero normali privilegi utente “un po’ più potenti” non è più sostenibile. Considerare UAC, Kerberos, LSASS e SID come elementi separati è una semplificazione che non regge più.

La direzione è quella di un Windows più rigoroso, più legato all’identità e meno disposto a concedere fiducia per abitudine.

Per gli amministratori IT questo significa una cosa molto concreta: bisogna rivedere le procedure prima che siano gli aggiornamenti a farlo per noi.

Perché, come spesso accade nella sicurezza, il problema non è quando qualcosa smette di funzionare. Il problema è scoprire che aveva funzionato per anni nel modo sbagliato.

Stay tuned!