Windows Server 2016 fine del supporto: aggiornamento controller di dominio Active Directory prima del 12 gennaio 2027

Un aggiornamento dei controller di dominio Active Directory per la fine del supporto di Windows Server 2016 è un progetto con una scadenza fissa, non una voce di backlog che si può continuare a rimandare. Il team Windows Server di Microsoft afferma chiaramente che «il supporto esteso di Windows Server 2016 terminerà il 12 gennaio 2027», e la scheda Microsoft Lifecycle per Windows Server 2016 conferma che il prodotto segue la Fixed Lifecycle Policy con una data di fine supporto esteso a gennaio 2027. Il supporto mainstream è già terminato a gennaio 2022.

La parte scomoda quasi mai riguarda i controller di dominio in sé. La maggior parte dei team può pianificare una ricostruzione dei DC. Ciò che li blocca è un breve elenco di host e appliance critici per il business che non possono essere aggiornati — e questi host non portano solo il proprio rischio. Poiché i valori predefiniti di cifratura Kerberos, i livelli funzionali e le impostazioni di hardening a livello di dominio sono proprietà del dominio, una manciata di macchine non aggiornabili blocca l'intero directory al loro livello di sicurezza.

Windows Server 2016 fine del supporto: scadenza dell'aggiornamento dei controller di dominio Active Directory

Windows Server 2016 segue la Fixed Lifecycle Policy di Microsoft, che garantisce «un minimo di cinque anni di supporto mainstream» più «un periodo aggiuntivo di supporto esteso per alcuni prodotti». La cifra di dieci anni spesso citata proviene da una pagina diversa: Microsoft descrive il Long Term Servicing Channel di Windows Server come dotato di «un minimo di 10 anni di supporto: cinque anni di supporto mainstream e cinque anni di supporto esteso, che include aggiornamenti di sicurezza regolari». Il supporto esteso è la fase che fornisce ancora aggiornamenti di sicurezza. Una volta terminato, questi si fermano.

L'inquadramento stesso di Microsoft di cosa significhi la fine del supporto per un sistema operativo server è diretto: una volta che un prodotto raggiunge la fine del supporto, «significa anche la fine degli aggiornamenti di sicurezza e dei bollettini», una situazione che «può causare problemi di sicurezza o conformità e mettere a rischio le applicazioni aziendali».

Il 25 febbraio 2026, Microsoft ha annunciato gli Extended Security Updates per Windows Server 2016. Questi aggiornamenti vengono forniti «tramite il portale Azure», e l'ESU «abilitato da Azure Arc» viene presentato come qualcosa che offre ulteriori vantaggi Azure, tra cui flessibilità di licenza e funzionalità di gestione Azure. La raccomandazione di Microsoft nello stesso post è di eseguire l'upgrade a Windows Server 2025 o migrare ad Azure — l'ESU viene presentato come un ponte, non una destinazione.

Per un controller di dominio in particolare, il rischio non è astratto. Il catalogo dei checkpoint Active Directory dell'ANSSI contiene un rilievo dedicato intitolato «DC/RODC with an obsolete operating system», che descrive i controller di dominio che eseguono «sistemi operativi per i quali Microsoft non pubblica più aggiornamenti di sicurezza. Pertanto, qualsiasi nuova vulnerabilità trovata su questi sistemi operativi resterà sfruttabile». La sua remediation si riassume in una riga: «Migrare questi sistemi operativi obsoleti il prima possibile, preferibilmente all'ultima versione di Windows».

Perché un solo host legacy blocca l'intero dominio

Questa è la parte controintuitiva, ed è dove la maggior parte dei piani di migrazione 2027 fallisce silenziosamente.

I livelli funzionali sono limitati dal vostro controller di dominio peggiore

Il livello funzionale di foresta e dominio determina quali funzionalità AD DS sono disponibili — e la matrice di interoperabilità dei livelli funzionali di Microsoft rende questa dipendenza esplicita. Un DC Windows Server 2012 R2 non può funzionare al livello funzionale Windows Server 2016. Un DC Windows Server 2016, 2019 o 2022 non può funzionare al livello funzionale Windows Server 2025.

Un solo controller di dominio 2012 R2 superstite blocca quindi l'intero dominio al livello 2012 R2, il che costa ogni funzionalità introdotta da allora — incluse le funzionalità a livello di dominio di Windows Server 2016 (rotazione automatica di NTLM e altri segreti basati su password per gli account configurati con Smart card required for interactive logon, supporto per consentire NTLM di rete quando un utente è limitato a dispositivi specifici uniti al dominio, e il SID di identità a chiave pubblica recente per i client Kerberos che si autenticano con la PKInit Freshness Extension) e la funzionalità opzionale di pagine database da 32k del livello Windows Server 2025.

La checklist dell'ANSSI tratta questo come un difetto valutato a sé stante, sotto «Insufficient forest and domains functional levels»: l'avviso scatta al primo livello di maturità quando il livello funzionale della foresta è inferiore a Windows Server 2008 R2, al livello 3 sotto Windows Server 2012 R2, e al livello 4 sotto il livello Windows Server 2016. La motivazione indicata è che «usare un livello funzionale debole priva la foresta di funzionalità di sicurezza importanti».

I client legacy tengono in ostaggio la vostra crittografia Kerberos

Lo stesso meccanismo si applica alla crittografia. La guida Microsoft su rilevamento e remediation dell'uso di RC4 in Kerberos spiega che RC4 «viene tipicamente usato negli ambienti Windows quando account o dispositivi non supportano tipi di cifratura più forti come AES-SHA1» — e che quando un account non ha alcun valore msDS-SupportedEncryptionTypes, il KDC ricade sul valore DefaultDomainSupportedEncTypes a livello di dominio.

Questo fallback è la trappola. Allentare DefaultDomainSupportedEncTypes per mantenere funzionante un'appliance «cambia il comportamento di tutti gli account che non hanno un valore impostato», nelle parole di Microsoft. Un host, una regressione a livello di dominio. È lo stesso meccanismo dietro al fallback Kerberos RC4, ed è ciò che mantiene il Kerberoasting economicamente vantaggioso: i ticket di servizio cifrati in RC4 si craccano offline molto più velocemente di quelli in AES.

Windows Server 2025 chiude completamente la porta, e l'avviso di Microsoft merita di essere citato per intero:

Rileggete questa ultima frase. Un singolo dispositivo limitato a RC4 non si limita a indebolire il dominio — può costringervi a mantenere controller di dominio più vecchi, il che a sua volta limita il vostro livello funzionale, il che a sua volta blocca l'hardening che stavate cercando di distribuire. La dipendenza risale dall'appliance al directory.

Il cambio del valore predefinito RC4 è già stato distribuito

Questo non è un problema futuro. KB5073381, che affronta la CVE-2026-20833, ha distribuito il cambiamento in fasi:

La via di fuga del rollback è sparita. Se una dipendenza legacy funzionava solo grazie al vecchio valore predefinito RC4, è già rotta oppure già coperta da un'eccezione esplicita.

Rilevamento

Iniziate con tre inventari. Nessuno richiede un agente, e tutti e tre sono abbastanza economici da eseguire ogni settimana.

1. Distribuzione dei sistemi operativi tra gli oggetti computer. L'attributo operatingSystem viene compilato dalla macchina stessa al momento della join al dominio e aggiornato all'avvio, quindi è una prima approssimazione ragionevole, pur non essendo una prova definitiva:

Get-ADComputer -Filter * -Properties OperatingSystem, OperatingSystemVersion, LastLogonDate |
    Where-Object { $_.Enabled -eq $true } |
    Group-Object OperatingSystem |
    Sort-Object Count -Descending |
    Select-Object Count, Name

Incrociate con LastLogonDate: un OS obsoleto che non si è autenticato da un anno è un'attività di pulizia, non un blocco alla migrazione. Trattate come vincolo reale quelli che si sono connessi questa settimana. Questo completa la revisione dell'identità macchina trattata in superficie di attacco degli oggetti computer in Active Directory — quell'articolo copre la scoperta di oggetti macchina obsoleti e pericolosi; questo copre cosa fare quando non potete eliminarli.

2. Versioni del sistema operativo dei controller di dominio e livelli funzionali attuali.

Get-ADDomainController -Filter * |
    Select-Object HostName, OperatingSystem, OperatingSystemVersion, IsGlobalCatalog, Site

(Get-ADForest).ForestMode
(Get-ADDomain).DomainMode
Get-ADObject (Get-ADDomain).DistinguishedName -Properties 'msDS-Behavior-Version'

3. Uso effettivo di RC4. Microsoft pubblica due script open source, List-AccountKeys.ps1 e Get-KerbEncryptionUsage.ps1, nel repository Kerberos-Crypto:

.\Get-KerbEncryptionUsage.ps1 -Encryption RC4

Per trovare gli account bloccati su RC4 per configurazione anziché per capacità, interrogate direttamente l'attributo — il valore decimale 4 significa solo RC4:

Get-ADObject -Filter "msDS-SupportedEncryptionTypes -eq 4" -Properties msDS-SupportedEncryptionTypes |
    Select-Object DistinguishedName, ObjectClass

Remediation

Passo 1 — Delimitare l'eccezione per account, mai per dominio. Microsoft offre due opzioni quando un account ricade sul valore predefinito del dominio, e solo una è sicura su larga scala: «Definire il valore specifico di msDS-SupportedEncryptionTypes nelle proprietà dell'account per assicurarsi che non ricada sul valore DefaultDomainSupportedEncTypes». Usate questa opzione. Riservate il valore a livello di dominio all'irrigidimento, non all'allentamento — il percorso di registro per forzare solo AES-SHA1 è HKEY_LOCAL_MACHINE\System\CurrentControlSet\services\KDC, valore DefaultDomainSupportedEncTypes (REG_DWORD) impostato a 0x18.

Passo 2 — Mettere in quarantena ciò che non potete aggiornare. Per ogni host che deve sopravvivere oltre il 12 gennaio 2027:

1. Negare il login Tier 0. Nessun Domain Admin, nessun account di servizio con diritti a livello di dominio, nessuna delega, dovrebbe mai autenticarsi su un host non aggiornabile.
2. Limitarlo a livello di rete alle sole porte e ai peer di cui ha realmente bisogno.
3. Delimitare gli etype Kerberos con una GPO mirata anziché una policy di dominio. In Configurazione computer > Criteri > Impostazioni Windows > Impostazioni di sicurezza > Criteri locali > Opzioni di sicurezza, impostate Sicurezza di rete: configura i tipi di crittografia consentiti per Kerberos, limitata all'OU contenente solo gli host legacy.
4. Applicare la firma ovunque altrove, in modo che l'host debole non possa essere usato come pivot di relay — vedere firma SMB e firma LDAP.

Passo 3 — Aggiornare prima i controller di dominio, e in modo pulito. Microsoft è esplicita su il metodo: «Il modo consigliato per aggiornare un dominio è utilizzare un'installazione pulita del sistema operativo per promuovere nuovi server a DC che eseguono una versione più recente di Windows Server e retrocedere i DC più vecchi secondo necessità. Questo metodo è preferibile all'aggiornamento del sistema operativo di un DC esistente». La sequenza documentata è: unire il nuovo server, installare il ruolo AD DS (che esegue automaticamente adprep), promuoverlo, spostare i ruoli FSMO con Move-ADDirectoryServerOperationMasterRole, quindi retrocedere e rimuovere il vecchio DC.

# Individuare gli attuali detentori dei ruoli FSMO prima di spostare qualsiasi cosa
Get-ADDomain | Format-List InfrastructureMaster, RIDMaster, PDCEmulator
Get-ADForest | Format-List DomainNamingMaster, SchemaMaster

Se invece scegliete un aggiornamento in-place, Microsoft richiede di «eseguire adprep /forestprep e adprep /domainprep manualmente» — forestprep una volta per foresta per ogni versione più recente di Windows Server, domainprep una volta in ogni dominio contenente DC che state aggiornando, di nuovo per versione.

Passo 4 — Scegliere il target giusto. Secondo i percorsi di aggiornamento in-place supportati di Microsoft, Windows Server 2016 può essere aggiornato in-place, tramite supporto di installazione, a Windows Server 2019, 2022 o 2025. Windows Server 2012 R2 può passare direttamente a Windows Server 2025, perché «a partire da Windows Server 2025, i sistemi non in cluster possono aggiornare fino a quattro versioni alla volta» — ma gli aggiornamenti rolling in cluster restano limitati a una versione alla volta.

Passo 5 — Alzare i livelli funzionali per ultimo. Solo dopo che l'ultimo DC legacy è stato retrocesso e rimosso. Notate che questo è in gran parte a senso unico: il rollback del livello funzionale di foresta si limita a un ritorno a Windows Server 2012 R2 o Windows Server 2008 R2 da un aggiornamento di quei livelli, e il rollback a livello di dominio esiste solo quando alzate a Windows Server 2016 con un livello di foresta Windows Server 2012 o inferiore.

🚨 Pericolo: non alzate il livello funzionale mentre un DC non supportato è ancora unito. La linea guida di Microsoft è che se la foresta contiene DC a un livello funzionale più vecchio di quanto supportato da un nuovo SO, «l'installazione viene bloccata» e quei DC «devono essere rimossi e il livello funzionale della foresta alzato a una versione supportata prima di aggiungere nuovi DC Windows Server alla vostra foresta».

Il sequenziamento conta più della velocità in questo caso. Mettere in quarantena, poi aggiornare i DC, poi alzare i livelli, poi irrigidire la crittografia a livello di dominio. Farlo in un altro ordine rompe la produzione oppure vi lascia con un dominio irrigidito solo sulla carta che ricade ancora sul suo membro più debole — uno degli schemi ricorrenti delle configurazioni di sicurezza errate di Active Directory più comuni.

Come EtcSec rileva tutto questo

EtcSec fa emergere questa esatta catena di dipendenza da un singolo audit in sola lettura, senza agenti sugli host legacy. COMPUTER_OS_OBSOLETE_NT, COMPUTER_OS_OBSOLETE_2008 e COMPUTER_OS_OBSOLETE_VISTA censiscono gli oggetti macchina i cui sistemi operativi non ricevono più aggiornamenti di sicurezza, classificati in base al fatto che si autentichino ancora. PR001_5_1_DC_OS_OBSOLETE isola il caso molto più grave — un controller di dominio che esegue esso stesso un OS obsoleto — perché è il controllo che determina se il vostro Tier 0 è aggiornabile o meno. ANSSI_R15_LOW_FUNCTIONAL_LEVEL riporta gli attuali livelli funzionali di foresta e dominio rispetto alla baseline raccomandata, così potete vedere immediatamente quale DC legacy sta limitando il directory.

Insieme, questi controlli rispondono all'unica domanda che conta prima del 12 gennaio 2027: quali host precisi stanno bloccando il dominio, e cosa succederebbe realmente se li rimuoveste. Rieseguire l'audit dopo ogni passo di remediation dimostra che il livello si è mosso — l'approccio descritto in audit della sicurezza Active Directory e dimostrazione della remediation.