Dopo gli aggiornamenti di Windows rilasciati nel 2025, diversi amministratori stanno riscontrando problemi di autenticazione su server clonati da template.
Il tema dei sid duplicati è improvvisamente balzato in cima alle ricerche, perché sistemi apparentemente configurati correttamente, ma con SID macchina duplicato, iniziano a mostrare errori Kerberos, fallback NTLM non riusciti, impossibilità di autenticarsi in dominio, errori tipo “Access Denied” dopo il join e comportamenti anomali rispetto a servizi che usano l’autenticazione delegata Kerberos.
L’origine del problema è chiara: Microsoft ha introdotto controlli più rigidi su SID e autenticazione, impedendo—finalmente—l’utilizzo di cloni non “syspreppati” all’interno di reti Active Directory.
Il problema dopo gli ultimi update di Ottobre 2025 su Windows 11 e Windows 2025
Prima di questi update, clonare una VM server senza rigenerare il SID era una cattiva pratica… ma spesso “funzionava lo stesso”. Oggi non più.
Microsoft ha rafforzato la sicurezza Kerberos/NTLM per ridurre:
- autenticazioni relay
- conflitti di identità macchina
- attacchi che sfruttano computer account duplicati
- escalation laterali tra server clonati
Risultato: se più PC o Server condividono lo stesso SID, le autenticazioni vengono bloccate.
E questa volta non si tratta di un malfunzionamento, ma di un comportamento voluto.
Cos’è un SID e perché crea problemi se duplicato
Un SID (Security Identifier) è l’identificatore univoco che Windows assegna a ogni entità di sicurezza: utenti, gruppi e macchine.
Non è il nome del computer a identificare realmente l’oggetto in AD, ma il SID.
Il SID macchina viene utilizzato per:
- Kerberos e NTLM authentication
- ACL su share e servizi
- deleghe
- identificazione in dominio
Due server con lo stesso SID = due identità che per AD sono “uguali” → conflitti di autenticazione.
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.
La soluzione definitiva: Sysprep
Non esistono scorciatoie sicure. La soluzione corretta è una sola: rigenerare il SID con Sysprep e creare template puliti. Questo significa generalizzare l’immagine prima del clone, così che ogni VM generata abbia un SID univoco.
Il comando più comune è: sysprep /generalize /oobe /shutdown
La procedura migliore è semplice, ma va rispettata: il template va preparato, aggiornato, configurato con tutto ciò che serve, ma non deve essere membro del dominio quando si esegue Sysprep. Solo dopo il deploy della VM clonata si procede con il join.
Dal momento in cui Sysprep entra nel processo, i problemi di autenticazione legati ai SID scompaiono. E non tornano.
Esistono anche altre soluzioni diverse da quella ufficiale Microsoft, come ad esempio SIDCHG - SID changer utility
Perché non ha senso “aggirare” il problema
Esistono modi per allentare i controlli e far finta che nulla sia successo.
Ma significherebbe disattivare protezioni pensate per prevenire attacchi basati su:
- furto di identità macchina
- relay delle autenticazioni
- movimenti laterali silenziosi
Sarebbe, di fatto, un downgrade della sicurezza solo per rimandare la soluzione vera.
E quando si parla di server in dominio, semplicemente non è una scelta intelligente.
Un approccio maturo ai template PC/Server
Una volta che Sysprep entra nel flusso standard, tutto diventa più pulito, prevedibile e sicuro.
- Il template rimane stabile.
- Le VM risultanti hanno identità certe.
- L’infrastruttura AD è più protetta.
È una di quelle buone pratiche che non portano benefici immediati “visibili”, ma che fanno la differenza quando contano davvero: nei log, nella sicurezza e nella continuità.
Conclusione
I nuovi controlli Microsoft non hanno “rotto” l’infrastruttura: hanno semplicemente reso evidente una falla che era lì da anni.
Oggi non si può più ignorare il problema dei sid duplicati, soprattutto nei template server.
La strada giusta è una sola: integrare Sysprep nel processo, garantire identità macchina univoche e lasciare che Kerberos faccia il suo lavoro.
Se vuoi migliorare la sicurezza della tua infrastruttura Windows o prevenire problemi legati all’autenticazione, Nexsys supporta aziende e PA con servizi di Hardening, Monitoring e Incident Response. Contattaci per un confronto tecnico.