Fim do Suporte do Windows Server 2016: Atualizacao de Controladores de Dominio Active Directory Antes de 12 de Janeiro de 2027

Uma atualização de controladores de domínio Active Directory motivada pelo fim do suporte do Windows Server 2016 é um projeto datado com um prazo fixo, não um item de backlog que se pode continuar adiando. A equipe do Windows Server da Microsoft afirma claramente que "o suporte estendido do Windows Server 2016 terminará em 12 de janeiro de 2027", e a entrada do Microsoft Lifecycle para o Windows Server 2016 confirma que o produto segue a Fixed Lifecycle Policy, com uma data final estendida em janeiro de 2027. O suporte mainstream já havia terminado em janeiro de 2022.

A parte desconfortável raramente são os próprios controladores de domínio. A maioria das equipes consegue agendar a reconstrução de um DC. O que as bloqueia é uma lista curta de hosts e appliances críticos para o negócio que não podem ser atualizados — e esses hosts não carregam apenas o próprio risco. Como os padrões de criptografia Kerberos, os níveis funcionais e as configurações de hardening válidas para todo o domínio são propriedades do domínio, um punhado de máquinas que não podem ser corrigidas prende todo o diretório ao nível de segurança delas.

Fim do Suporte do Windows Server 2016: Prazo para Atualização do Controlador de Domínio Active Directory

O Windows Server 2016 segue a Fixed Lifecycle Policy da Microsoft, que garante "um mínimo de cinco anos de Suporte Mainstream" mais "um período adicional de Suporte Estendido para alguns produtos". O número de dez anos que as pessoas citam vem de uma página diferente: a Microsoft descreve o Long Term Servicing Channel do Windows Server como tendo "um mínimo de 10 anos de suporte: cinco anos de suporte mainstream e cinco anos de suporte estendido, que inclui atualizações de segurança regulares". O suporte estendido é a fase que ainda entrega atualizações de segurança. Quando ele termina, isso cessa.

O próprio enquadramento da Microsoft sobre o que significa o fim do suporte para um sistema operacional de servidor é direto: quando os produtos atingem o fim do suporte, "isso também significa o fim das atualizações e boletins de segurança", uma situação que "pode causar problemas de segurança ou conformidade e colocar em risco as aplicações de negócio".

Em 25 de fevereiro de 2026, a Microsoft anunciou as Extended Security Updates para o Windows Server 2016. Essas atualizações são entregues "através do portal do Azure", e o ESU "habilitado pelo Azure Arc" é posicionado como oferecendo benefícios adicionais do Azure, incluindo flexibilidade de licenciamento e recursos de gerenciamento do Azure. A recomendação da Microsoft no mesmo post é atualizar para o Windows Server 2025 ou migrar para o Azure — o ESU é apresentado como uma ponte, não um destino.

Para um controlador de domínio especificamente, o risco não é abstrato. O catálogo de checkpoints de Active Directory da ANSSI traz um achado dedicado intitulado "DC/RODC com sistema operacional obsoleto", e descreve como controladores de domínio executando "sistemas operacionais para os quais a Microsoft não publica mais atualizações de segurança. Assim, qualquer nova vulnerabilidade encontrada nesses sistemas operacionais permanecerá explorável." Sua remediação é uma linha: "Migrar esses sistemas operacionais obsoletos o mais rápido possível, preferencialmente para a última versão do Windows."

Por Que Um Único Host Legado Prende Todo o Domínio

Esta é a parte contraintuitiva, e é onde a maioria dos planos de migração para 2027 falha silenciosamente.

Os níveis funcionais são limitados pelo seu pior controlador de domínio

O nível funcional de floresta e de domínio determina quais recursos do AD DS estão disponíveis — e a matriz de interoperabilidade de níveis funcionais da Microsoft torna essa dependência explícita. Um DC com Windows Server 2012 R2 não pode operar no nível funcional do Windows Server 2016. Um DC com Windows Server 2016, 2019 ou 2022 não pode operar no nível funcional do Windows Server 2025.

Um único controlador de domínio 2012 R2 sobrevivente, portanto, limita todo o domínio ao nível 2012 R2, o que custa todos os recursos introduzidos desde então — incluindo os recursos de nível de domínio do Windows Server 2016 (rotação automática de NTLM e outros segredos baseados em senha em contas configuradas para Smart card required for interactive logon, suporte para permitir NTLM de rede quando um usuário está restrito a dispositivos ingressados no domínio específicos, e o novo SID de identidade de chave pública para clientes Kerberos que autenticam com a PKInit Freshness Extension) e o recurso opcional de páginas de banco de dados de 32k do nível do Windows Server 2025.

O checklist da ANSSI trata isso como um defeito graduado por si só, em "Níveis funcionais de floresta e domínios insuficientes": o alerta dispara em seu primeiro nível de maturidade quando o nível funcional de floresta está abaixo do Windows Server 2008 R2, no nível 3 abaixo do Windows Server 2012 R2, e no nível 4 abaixo do nível do Windows Server 2016. A justificativa apresentada é que "usar um nível funcional fraco priva a floresta de recursos de segurança importantes".

Clientes legados mantêm sua criptografia Kerberos refém

O mesmo mecanismo se aplica à criptografia. A orientação da Microsoft sobre detecção e remediação do uso de RC4 no Kerberos explica que o RC4 "é tipicamente usado em ambientes Windows quando contas ou dispositivos não suportam tipos de criptografia mais fortes, como AES-SHA1" — e que quando uma conta não tem valor definido em msDS-SupportedEncryptionTypes, o KDC recorre ao valor DefaultDomainSupportedEncTypes válido para todo o domínio.

Esse fallback é a armadilha. Afrouxar o DefaultDomainSupportedEncTypes para manter um appliance funcionando "altera o comportamento de todas as contas que não têm um valor definido", nas palavras da Microsoft. Um host, uma regressão em todo o domínio. Esse é o mesmo mecanismo por trás do fallback do Kerberos RC4, e é o que mantém o Kerberoasting economicamente viável: tickets de serviço criptografados com RC4 são quebrados offline muito mais rapidamente do que os criptografados com AES.

O Windows Server 2025 fecha essa porta por completo, e o aviso da Microsoft vale a pena citar na íntegra:

Leia essa última frase de novo. Um único dispositivo restrito a RC4 não apenas enfraquece o domínio — ele pode forçá-lo a manter controladores de domínio mais antigos, o que por sua vez limita o seu nível funcional, o que por sua vez bloqueia o hardening que você estava tentando implementar. A dependência corre no sentido inverso, do appliance para o diretório.

A mudança do padrão RC4 já está em produção

Isso não é um problema futuro. A KB5073381, que trata da CVE-2026-20833, implementou a mudança em fases:

A saída de emergência do rollback deixou de existir. Se uma dependência legada só funcionava por causa do antigo padrão RC4, ela já está quebrada ou já foi tratada com uma exceção explícita.

Detecção

Comece com três inventários. Nenhum deles exige um agente, e todos os três são baratos o suficiente para rodar semanalmente.

1. Distribuição de sistemas operacionais entre os objetos de computador. O atributo operatingSystem é preenchido pela própria máquina ao ingressar no domínio e é atualizado na inicialização, portanto é uma primeira aproximação razoável — ainda que não definitiva:

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

Cruze com o LastLogonDate: um SO obsoleto que não autentica há um ano é uma tarefa de limpeza, não um bloqueador de migração. Trate como restrição real apenas os que autenticaram nesta semana. Isso complementa a revisão de identidade de máquina abordada em superfície de ataque de objetos de computador do Active Directory — aquele artigo cobre encontrar objetos de máquina obsoletos e perigosos; este cobre o que fazer quando você não pode excluí-los.

2. Versões de SO dos controladores de domínio e níveis funcionais atuais.

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 real de RC4. A Microsoft publica dois scripts de código aberto, List-AccountKeys.ps1 e Get-KerbEncryptionUsage.ps1, no repositório Kerberos-Crypto:

.\Get-KerbEncryptionUsage.ps1 -Encryption RC4

Para encontrar contas presas a RC4 por configuração, e não por incapacidade, consulte o atributo diretamente — o valor decimal 4 significa somente RC4:

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

Remediação

Etapa 1 — Delimite a exceção por conta, nunca por domínio. A Microsoft oferece duas opções quando uma conta recorre ao padrão do domínio, e apenas uma delas é segura em escala: "Definir o valor específico de msDS-SupportedEncryptionTypes nas propriedades da conta para garantir que ela não recorra ao valor de DefaultDomainSupportedEncTypes." Use essa opção. Reserve o valor válido para todo o domínio para endurecer, não para afrouxar — o caminho de registro para impor somente AES-SHA1 é HKEY_LOCAL_MACHINE\System\CurrentControlSet\services\KDC, valor DefaultDomainSupportedEncTypes (REG_DWORD) definido como 0x18.

Etapa 2 — Coloque em quarentena o que você não pode atualizar. Para cada host que precisa sobreviver além de 12 de janeiro de 2027:

1. Negue logon Tier 0. Nenhum Domain Admin, nenhuma conta de serviço com direitos válidos para todo o domínio, nenhuma delegação, deve jamais autenticar em um host que não pode ser corrigido.
2. Restrinja-o na camada de rede às portas e pares específicos de que ele realmente precisa.
3. Delimite os etypes Kerberos com uma GPO direcionada, em vez de uma política de domínio. Em Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options, defina Network security: Configure encryption types allowed for Kerberos, escopada apenas para a OU que contém os hosts legados.
4. Aplique assinatura em todo o resto, para que o host fraco não possa ser usado como pivô de relay — veja assinatura SMB e assinatura LDAP.

Etapa 3 — Atualize primeiro os controladores de domínio, e de forma limpa. A Microsoft é explícita sobre o método: "A forma recomendada de atualizar um domínio é usar uma instalação limpa do SO para promover novos servidores a DCs que executam uma versão mais recente do Windows Server e rebaixar os DCs mais antigos conforme necessário. Esse método é preferível a atualizar o sistema operacional de um DC existente." A sequência documentada é: ingressar o novo servidor, instalar a função AD DS (que executa o adprep automaticamente), promovê-lo, mover as funções FSMO com Move-ADDirectoryServerOperationMasterRole, e então rebaixar e remover o DC antigo.

# Locate the current FSMO holders before you move anything
Get-ADDomain | Format-List InfrastructureMaster, RIDMaster, PDCEmulator
Get-ADForest | Format-List DomainNamingMaster, SchemaMaster

Se você optar por uma atualização in-place, a Microsoft exige que você "execute adprep /forestprep e adprep /domainprep manualmente" — forestprep uma vez por floresta para cada versão mais recente do Windows Server, domainprep uma vez em cada domínio que contém DCs que você está atualizando, novamente por versão.

Etapa 4 — Escolha o destino certo. De acordo com os caminhos de atualização in-place suportados da Microsoft, o Windows Server 2016 pode ser atualizado in-place, via mídia de instalação, para o Windows Server 2019, 2022 ou 2025. O Windows Server 2012 R2 pode ir diretamente para o Windows Server 2025, porque "a partir do Windows Server 2025, sistemas não agrupados em cluster podem avançar até quatro versões de uma só vez" — mas as atualizações em rolling de cluster ainda avançam apenas uma versão de cada vez.

Etapa 5 — Eleve os níveis funcionais por último. Somente depois que o último DC legado for rebaixado e removido. Observe que isso é, em grande parte, de mão única: o rollback do nível funcional de floresta é limitado a retornar ao Windows Server 2012 R2 ou ao Windows Server 2008 R2 a partir de uma atualização desses níveis, e o rollback em nível de domínio só existe quando você eleva para o Windows Server 2016 com um nível de floresta igual ou inferior ao Windows Server 2012.

🚨 Perigo: Não eleve o nível funcional enquanto um DC não suportado ainda estiver ingressado. A orientação da Microsoft é que, se a floresta contiver DCs em um nível funcional mais antigo do que um novo SO suporta, "a instalação é bloqueada" e esses DCs "devem ser removidos e o nível funcional da floresta elevado para uma versão suportada antes de você adicionar novos DCs com Windows Server mais recente à sua floresta."

O sequenciamento importa mais do que a velocidade aqui. Quarentena, depois atualização dos DCs, depois elevação dos níveis, depois endurecimento da criptografia em todo o domínio. Fazer isso em qualquer outra ordem ou quebra a produção ou deixa você com um domínio endurecido apenas no papel, que ainda recorre ao seu membro mais fraco — um dos padrões recorrentes nas configurações incorretas de segurança do Active Directory mais comuns.

Como a EtcSec Detecta Isso

A EtcSec expõe exatamente essa cadeia de dependência a partir de uma única auditoria somente leitura, sem agentes nos hosts legados. COMPUTER_OS_OBSOLETE_NT, COMPUTER_OS_OBSOLETE_2008 e COMPUTER_OS_OBSOLETE_VISTA inventariam os objetos de máquina cujos sistemas operacionais não recebem mais atualizações de segurança, classificados por autenticarem ou não ainda. PR001_5_1_DC_OS_OBSOLETE isola o caso muito mais grave — um controlador de domínio em si executando um SO obsoleto — porque essa é a verificação que determina se o seu Tier 0 pode ou não ser corrigido. ANSSI_R15_LOW_FUNCTIONAL_LEVEL reporta os níveis funcionais atuais de floresta e domínio em relação à linha de base recomendada, para que você veja imediatamente qual DC legado está limitando o diretório.

Lidas em conjunto, essas verificações respondem à única pergunta que importa antes de 12 de janeiro de 2027: quais hosts específicos estão segurando o domínio para baixo, e o que realmente quebraria se você os removesse. Reexecutar a auditoria após cada etapa de remediação comprova que o nível avançou — a abordagem descrita em auditar a segurança do Active Directory e comprovar a remediação.