Migração de RC4 e AD: Descubra os cenários de falha que se escondem no seu domínio de origem

Imagina só.

Durante uma migração de rotina do Active Directory, tudo parece estar bem. Uma conta de serviço é transferida sem problemas de um domínio de origem para um de destino. As permissões parecem estar corretas. As filiações a grupos estão intactas. O histórico de SID é preservado.

Uma semana depois, a aplicação associada a essa conta começa a apresentar falhas intermitentes. Quando alguém consegue associar essas falhas à migração, o serviço de assistência já tem 40 tickets em aberto. E ninguém consegue explicar o que se passa.

O que mudou? A conta tinha chaves Kerberos apenas RC4 na origem. As ferramentas de migração padrão copiaram o hash NTLM. O domínio de destino — novo, atualizado e com as predefinições AES — não possui chaves AES para essa conta.

E, a partir de 14 de abril de 2026, os DCs atualizados deixarão de recorrer implicitamente à encriptação RC4 para contas sem uma configuração RC4 explícita. A autenticação simplesmente deixa de funcionar.

Se estiver a realizar um projeto de migração, consolidação ou identidade baseada em relações de confiança do Active Directory que se estenda para além do prazo de aplicação da RC4, em julho de 2026, este risco poderá já estar presente no seu ambiente.

No blog Como auditar o seu ambiente quanto à encriptação RC4, os meus colegas Guido Grillenmeier e Rich Peckham fornecem exemplos de consultas que pode utilizar como modelos para auditar o seu ambiente e localizar contas que dependem do RC4.

O que precisa agora é de um plano de ação que o ajude a evitar essas possíveis falhas na conta.

O que irá aprender neste artigo

• Onde é mais provável que ocorram falhas de migração relacionadas com o RC4
• Os tipos de falhas que podem ocorrer — e o que se deve ter em atenção
• Como avaliar sistematicamente o seu ambiente e identificar contas em risco de falha
• Que ferramentas gratuitas podem ajudá-lo na sua descoberta
• Medidas a tomar agora mesmo para se preparar para a transição para o AES

Por que razão os projetos de migração estão particularmente expostos às alterações no RC4?

O calendário de descontinuação do RC4 está bem documentado.

• Janeiro de 2026: A Microsoft introduziu a auditoria e o RC4DefaultDisablementPhase chave do Registo.
• Abril de 2026: A Microsoft alterou a configuração padrão do KDC para apenas AES nas contas que não têm o msDS-SupportedEncryptionTypes atributo definido explicitamente.
• Julho de 2026: A Microsoft remove o modo de auditoria e deixa de aceitar o RC4DefaultDisablementPhase reverter totalmente a chave do registo, deixando apenas as contas com exceções RC4 explícitas ainda capazes de receber bilhetes RC4.

O artigo sobre a demonstração da auditoria da Semperis aborda em pormenor a descoberta em estado estacionário. O que essa demonstração não aborda é o cenário de migração, em que o risco se manifesta de três formas específicas:

• As migrações transferem contas entre limites de segurança. Uma conta que hoje é autenticada com sucesso no sistema de origem pode falhar assim que chega a um destino com regras de segurança mais rigorosas, mesmo que o sistema de origem tenha regras mais flexíveis.
  
• As ferramentas de migração tratam as credenciais de forma assimétrica. As ferramentas de migração padrão copiam o hash NTLM, mas não copiam as chaves AES. A Série de Reforço do AD da Microsoft, Parte 4, é clara: se o domínio de destino não suportar RC4, será necessário redefinir a palavra-passe da conta no domínio de destino para que o Kerberos funcione. Isto aplica-se a todas as contas cujas chaves do lado de origem sejam exclusivamente RC4.
  
• As falhas são silenciosas. As dependências RC4 em estado estacionário manifestam-se como eventos KDCSVC 201–209. As falhas induzidas pela migração, por sua vez, muitas vezes não o fazem. Em vez disso, apresentam-se como erros de aplicação sem qualquer ligação óbvia ao tipo de encriptação. A causa principal tem de ser deduzida, não observada.

Em conjunto, estes fatores tornam insuficiente uma única consulta no PowerShell. As equipas de migração precisam de um processo de análise estruturado.

Que contas correm o risco de falhas na migração relacionadas com o RC4?

Antes de prosseguirmos, uma observação. As atualizações de abril de 2026 foram implementadas sem as falhas generalizadas que alguns meios de comunicação do setor antecipavam — pelo menos, de acordo com o que observámos na prática. Na maioria dos ambientes dos clientes, a encriptação Kerberos configurada foi mantida e a autenticação continua a funcionar normalmente.

Este artigo não pretende alarmar ninguém.
O que defende é que existe um padrão de falha específico e identificável — e que as transições de migração são precisamente os eventos mais propensos a revelá-lo.

Três situações que colocam uma conta em risco

As falhas silenciosas de migração relacionadas com o RC4 surgem normalmente quando se verificam as três condições seguintes:

• AES indicado, mas não entregue. A conta msDS-SupportedEncryptionTypes O atributo é preenchido com bits AES ou fica nulo, com o valor padrão do domínio definido como AES. O KDC interpreta isto como «AES é suportado» e tenta emitir bilhetes AES para a conta.
  
• Não existe material de chave AES no destino. As chaves AES são geradas apenas quando é definida uma palavra-passe num ambiente DFL 2008 ou superior. As contas de maior risco são as contas antigas que nunca foram redefiniidas e as contas migradas em que o material de credenciais foi copiado sem regenerar as chaves AES. O atributo indica AES; as chaves indicam apenas RC4.
  
• A conta está a ser autenticada ativamente através do Kerberos. A falha só se manifesta quando a conta solicita um bilhete Kerberos. Nesse momento, o KDC tenta utilizar o AES (conforme a condição 1), não encontra nenhuma chave AES (conforme a condição 2) e a autenticação falha. As contas inativas e as contas que se autenticam apenas através do NTLM permanecem invisíveis, uma vez que a situação de falha nunca chega a ser verificada.

Que tipos de contas estão em maior risco?

Na maioria das empresas, o conjunto de contas em risco não é aleatório. Tende a concentrar-se em cinco tipos de contas — categorias que vale a pena abordar em qualquer conversa de definição do âmbito antes da migração.

• Contas de serviço antigas da implementação inicial do AD, criadas entre 2000 e 2010 e cujas senhas nunca foram alteradas. Estas constituem o grupo mais numeroso na população em risco.
• Contas com PASSWD_CANT_CHANGE ou DONT_EXPIRE_PASSWORD Sinalizadores UAC definidos. Estes sinalizadores estão intimamente associados a palavras-passe definidas uma única vez durante o aprovisionamento e que nunca são alteradas.
• Sistemas que não sejam Windows com credenciais Kerberos armazenadas localmente — hosts Linux com ficheiros keytab, servidores de aplicações Java com credenciais codificadas krb5.conf, dispositivos NAS integrados no domínio, dispositivos de rede com credenciais armazenadas em cache.
• Contas de serviço pertencentes a administradores que já não estão na instituição, nas quais existem credenciais, mas o conhecimento institucional sobre o que depende dessas contas já se perdeu.
• Contas de computador em que a rotação automática de senhas deixou de funcionar — máquinas há muito tempo sem ligação à Internet, contas abandonadas, contas com PasswordNeverExpires definido de forma inadequada.

Em média, quantas contas podem ser afetadas pelo RC4 durante a migração para o AD?

Com base na experiência adquirida no terreno em projetos de migração, o número de contas em risco num determinado ambiente situa-se normalmente dentro destes intervalos.

Tipo de ambiente	População média em risco
Ambientes totalmente novos criados após 2010 com uma sólida gestão de identidades	0 a 10 contas
Empresa típica de média a grande dimensão com uma história de, pelo menos, uma década no Active Directory	20 a 200 contas
Ambientes criados através de fusões e aquisições sem uma consolidação subsequente da identidade	Algumas centenas a alguns milhares
Ambientes adquiridos em que a organização adquirente ainda não concluiu a racionalização das identidades	Altamente variável, chegando por vezes a exceder o intervalo de fusões e aquisições

NOTA: Estes são pontos de partida para definir o âmbito das conversas, não valores concretos. A dimensão real da população só poderá ser confirmada através do trabalho de análise que iremos realizar.

Por que é que a transição da migração do AD concentra o risco

Estas contas dependentes do RC4 podem permanecer em produção durante anos sem apresentar falhas. A sua autenticação Kerberos baseia-se em bilhetes armazenados em cache e em reautenticações pouco frequentes, o que mantém as chaves AES em falta invisíveis durante o funcionamento normal.

A transição de migração altera essa situação. Invalida simultaneamente as credenciais armazenadas em cache em toda a infraestrutura, obriga à emissão de novos AS-REQs e TGS-REQs num curto espaço de tempo e revela o modo de falha precisamente no momento em que o conhecimento dos responsáveis já se tornou obsoleto e a análise da causa raiz é mais difícil.

Os dois tipos de falha que está a procurar

Antes de entrarmos na metodologia de descoberta, é útil identificar as duas categorias distintas de risco de falha que se pretende identificar.

• Desvio de configuração latente. Contas que hoje parecem estar em ordem, mas que irão falhar quando a política for aplicada — a população em risco definida acima. Os atributos do AD indicam uma coisa; o material de chave real indica outra. Não é possível detectar isto apenas consultando os atributos do AD.
  
• Risco associado ao mecanismo de migração. Falhas que decorrem especificamente da forma como a migração transfere os dados de identidade. Estas não aparecem na telemetria em estado estacionário de nenhum dos lados e incluem:
  • Dependências históricas do SID
  • Cenários de execução dupla em que a mesma identidade lógica se autentica em ambos os domínios
  • O valor alvo do DFL é inferior ao de 2008 (o que provoca silenciosamente falhas em todas as redefinições de palavra-passe após a migração)
  • Incompatibilidades nos atributos de confiança.

Ambas as categorias exigem a identificação de evidências. Nenhuma delas é detetada de forma fiável por ferramentas que analisam apenas uma fonte de sinal.

Como preparar-se para a transição do RC4 para o AES: uma metodologia de análise da migração em seis fases

Compreender o contexto em que as suas contas dependentes do RC4 operam — bem como os potenciais tipos de falhas que poderá encontrar — proporciona-lhe uma estrutura de referência à medida que avança no processo de identificação dessas contas e na sua configuração para o AES.

Esta é a sequência testada na prática que utilizamos com os clientes em projetos de migração. Cada fase produz dados que alimentam a matriz final de cenários de falha.

Fase 0: Definir o âmbito de atuação

Antes de procurar problemas, documente tanto o ambiente de origem como o de destino. A assimetria entre os dois constitui, por si só, uma principal fonte de risco.

Para cada domínio, registe:

• Nível funcional da floresta e do domínio
• Versão do sistema operativo de cada servidor de domínio
• Última atualização cumulativa
• O valor de RC4DefaultDisablementPhase em cada controlador de domínio (DC)

É possível que alguns centros de distribuição não tenham RC4DefaultDisablementPhase ou DefaultDomainSupportedEncTypes não está definida de todo. Isso significa, normalmente, que a definição não está explicitamente configurada e que o DC está a seguir o comportamento predefinido atual para o seu sistema operativo e nível de atualização.

O que importa agora é saber se esse comportamento eficaz é consistente em todo o domínio e entre a fonte e o destino.

      $path = 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\' +
    'Policies\System\Kerberos\Parameters'
Invoke-Command -ComputerName (Get-ADDomainController -Filter *).HostName -ScriptBlock {
    Get-ItemProperty -Path $using:path -ErrorAction SilentlyContinue |
        Select-Object PSComputerName, RC4DefaultDisablementPhase,
                               DefaultDomainSupportedEncTypes
}

Procure por assimetrias: um domínio de origem no DFL 2003 com a fase não definida e emparelhado com um destino no DFL 2016 que já se encontra na fase 2 significa que todas as contas migradas que não possuam chaves AES deixarão de funcionar na transição.

Atenção a todos os servidores DC que executem o Server 2012 ou 2012 R2 com ESU expirada: esses servidores não receberão as atualizações de julho de 2026 e são fontes RC4 inalteráveis.

Se as chaves do registo estiverem em falta: verifique a versão do sistema operativo do DC, o nível de atualizações e se outros DCs no mesmo domínio apresentam valores explícitos. O sinal de alerta não é a ausência da própria chave, mas sim uma situação heterogénea em que alguns DCs se encontram efetivamente num determinado estado de comportamento e outros noutro.

Considere a incompatibilidade entre a fonte e o destino como um sinal de risco: a ausência de chaves na fonte, aliada a definições explícitas de fase no destino, ou valores padrão nulos num lado e exceções RC4 explícitas no outro, são precisamente as combinações que ocultam cenários de falha na migração até à transição.

Documentar a relação de confiança na migração: Um fundo fiduciário com msDS-SupportedEncryptionTypes A definição para 0x4 (apenas RC4) constitui um ponto de ruptura garantido em julho de 2026. Uma relação de confiança com o atributo nulo segue o comportamento padrão mais recente do AES e é muito menos provável que constitua o ponto de ruptura do que uma relação de confiança explicitamente fixada em RC4.

Fase 1: Confirmar se ambos os domínios conseguem detetar tráfego RC4

Não é possível encontrar o que não se regista. Verifique a auditoria do Kerberos em todos os controladores de domínio (DC) de ambos os domínios:

      auditpol /get /subcategory:"Serviço de Autenticação Kerberos"
auditpol /get /subcategory:"Operações de Bilhetes de Serviço Kerberos"

Ambos devem indicar «Sucesso» e «Falha». Caso contrário, aplique o Objeto de Política de Grupo (GPO) de auditoria Kerberos padrão na Unidade Organizacional (OU) do Controlador de Domínio antes de prosseguir.

Nos servidores DC atualizados com patches até janeiro de 2026 ou posteriores, o registo do sistema também deve estar a capturar os eventos 201–209 do provedor KDCSVC. A ausência total destes eventos num ambiente com aplicações legadas conhecidas significa, normalmente, uma lacuna no registo e não um ambiente isento de vulnerabilidades; por isso, verifique a aplicação dos patches e a recolha de dados antes de assumir que não existe exposição ao RC4.

Esteja também atento à visibilidade parcial: auditorias ativadas em alguns controladores de domínio, mas não noutros; eventos reencaminhados apenas de uma parte do ambiente; ou janelas de retenção demasiado curtas para captar contas de serviço de baixa frequência.

Fase 2: Detecção da camada de configuração

Esta fase identifica cenários de falha visíveis apenas nos atributos do AD. O caminho mais rápido é o de código aberto RC4-ADAssessment Módulo do PowerShell, a ser executado em ambos os domínios:

      Install-Module -Name RC4-ADAssessment
Import-Module RC4-ADAssessment

Invoke-RC4Assessment -Domain source.contoso.com -ExportResults
Invoke-RC4Assessment -Domain target.contoso.com -ExportResults

Este módulo inclui:

• Configuração da encriptação DC
• Criptografia de confiança
• Período de validade da palavra-passe KRBTGT
• Todas as contas de serviço marcadas como «apenas RC4» ou «compatíveis com DES»
• Contas junto ao USE_DES_KEY_ONLY Sinalizador UAC
• Contas com exceções RC4 explícitas
• Contas com palavras-passe desatualizadas

Cada resultado é exportado com comandos de correção prontos para copiar e colar. Considere o resultado como uma lista de candidatos por ordem de prioridade, e não como uma conclusão definitiva. A Fase 2 indica onde investigar, mas são os dados dos eventos e o contexto da aplicação que confirmam um cenário real de falha na migração.

Preste especial atenção às contas de serviço cujas PasswordLastSet é anterior à atualização do domínio de origem para o DFL 2008. Estes são candidatos de alta prioridade para a população em risco acima definida e devem ser validados com base nos dados de eventos e no histórico de migração.

Fase 3: Descoberta comportamental

A configuração indica o que é permitido. Os eventos indicam o que está realmente a acontecer. É frequente que haja discrepâncias entre ambos.

Execute a avaliação com a análise do registo de eventos ativada ou consulte diretamente o Sentinel ou o Splunk:

      Invoke-RC4Assessment -Domain source.contoso.com `
-AnalyzeEventLogs -EventLogHours 168 -ExportResults

O resultado mais significativo é a correlação entre a configuração AES e a utilização do RC4: contas em que o AD indica «Sou compatível com AES», mas os registos de eventos mostram que estão a ser emitidos bilhetes RC4. Essa discrepância é precisamente o tipo de falha que irá surgir durante a migração.

No que diz respeito especificamente aos projetos de migração, recupere também os pedidos TGS entre domínios. Em 4769 eventos, procure os tickets de assistência em que ServiceName está no outro mundo e TicketEncryptionType é 0x17. O tráfego RC4 entre domínios serve como indicador de falhas na via de confiança de migração em fase de implementação, e mesmo os resultados com baixo volume merecem uma investigação imediata, uma vez que a aplicação afetada pode ser crítica para o negócio.

Esteja também atento às contas de serviço que só se autenticam durante janelas de processamento em lote, processamento de fim de mês ou tarefas agendadas; estas contas são fáceis de ignorar em janelas de recolha curtas e são frequentemente a causa das surpresas mais desagradáveis durante a transição.

Fase 4: Descoberta na camada de aplicação

É aqui que a maioria das migrações acaba por falhar e onde as ferramentas compatíveis com o AD oferecem menos visibilidade.

Verifique todos os hosts Linux, Java e dispositivos de rede que utilizam o Kerberos baseado no AD.

Ficheiros keytab do inventário; qualquer coisa que contenha apenas arcfour-hmac As entradas estão fixadas no RC4. É de esperar que ainda existam alguns sistemas que não sejam Windows a utilizar keytabs gerados há anos.

Verificar /etc/krb5.conf para valores fixos default_tkt_enctypes ou permitted_enctypes indicando apenas o RC4. Ambos deixarão de funcionar após julho de 2026, independentemente do que o AD fizer — e a atualização das chaves do keytab para o domínio de destino exige que a conta migrada possua chaves AES, o que nos remete às conclusões da Fase 2.

Para cada aplicação que utilize a autenticação Kerberos, explique ao proprietário:

• A conta de serviço atualmente em uso e a sua msDS-SupportedEncryptionTypes valor
• Onde a aplicação está alojada
• Se está a ser utilizado um keytab e quando foi gerado
• Se a documentação do fornecedor especifica os tipos de encriptação Kerberos exigidos
• Se a pré-autenticação utiliza o RC4 como algoritmo fixo

É de esperar que haja lacunas na documentação. Muitos proprietários não saberão quando o keytab foi gerado nem se o fornecedor suporta o AES de forma adequada, e essa incerteza é, por si só, um indicador útil de risco.

Verifique também se existem configurações de encriptação fixas em locais onde a detecção de atributos do AD não chega, na segurança da rede:

• O Network security: Configure encryption types allowed for Kerberos Configuração do GPO
• Servidores ligados do SQL Server
• Identidades do conjunto de aplicações do IIS com palavras-passe desatualizadas
• Aplicações Java com -Dsun.security.krb5.permitted_enctypes Opções da JVM

Fase 5: Riscos específicos da migração

Os cenários de falha que iremos identificar nesta fase só se manifestam durante a transição da migração. Trata-se de características do mecanismo de migração e não de qualquer um dos domínios em estado de equilíbrio.

Analise a forma como a sua ferramenta de migração lida com as palavras-passe. Se a ferramenta copiar as palavras-passe, copiará todas as credenciais existentes. Uma conta que, na origem, utilize apenas chaves RC4 chegará ao destino com apenas chaves RC4. A medida de mitigação padrão — a redefinição forçada da palavra-passe após a migração — pode interromper o funcionamento de serviços dependentes, caso a aplicação esteja em execução.

Cada conta de serviço necessita de um plano documentado de reinicialização pós-migração, incluindo um intervalo de manutenção.

Avalie com objetividade as abordagens de sincronização de palavras-passe. Algumas ferramentas de migração oferecem filtros de sincronização de palavras-passe que captam as alterações nos controladores de domínio de origem e as reproduzem no destino. Estas soluções resolvem o problema da geração de chaves AES no destino, mas:

• Instalar um caminho de código privilegiado nos DCs de origem
• Expor texto simples temporariamente na memória
• Executar apenas em eventos de alteração de palavra-passe (ignorando completamente as contas inativas e as contas de serviço que não têm rotação de palavras-passe)
• Assumir o risco operacional caso o filtro falhe sem aviso prévio

A utilização dessas ferramentas é legítima em casos de coexistência limitada, em que as vantagens e desvantagens estão documentadas e são aceites — mas não substitui o trabalho de investigação acima referido.

Identifique cenários de execução dupla. Durante o período de migração, os utilizadores e os serviços podem existir tanto no ambiente de origem como no de destino. Identifique os casos em que a mesma identidade lógica se autentica em ambos os lados — normalmente através de relações de confiança entre domínios, federação ou um inquilino Entra ID sincronizado.

Cada um deles é um ponto de falha potencial, uma vez que a negociação da encriptação varia de lado para lado.

Identifique as dependências do histórico de SID. O histórico de SID preserva o acesso aos recursos; no entanto, as chaves de encriptação são independentes. Uma aplicação que autorize através do histórico de SID, mas que emita bilhetes utilizando as chaves da conta de destino, pode falhar se essas chaves forem exclusivamente RC4.

Confirme se o DFL de destino é, pelo menos, 2008. Em consolidações que envolvem ambientes adquiridos, o DFL de destino pode, por vezes, ficar num nível funcional de domínio (DFL) inferior ao esperado. Abaixo do DFL 2008, as redefinições de palavra-passe não geram chaves AES, pelo que todo o plano de redefinição pós-migração falha silenciosamente. Verifique antes da transição. Não durante.

O verdadeiro risco nesta fase reside nas combinações, e não em factos isolados. Por exemplo:

• Migrações com cópia de senha sem um período de redefinição documentado
• Identidades de execução dupla sem testes caminho a caminho
• O histórico do SID tratado como uma correção de autenticação
• Um problema no DFL de destino que só foi detetado após a transição da fase piloto

Estes são os padrões específicos da migração que transformam resultados controláveis em cenários de interrupção do serviço.

Fase 6: Elaborar a matriz de cenários de falha

O resultado das primeiras cinco fases não é uma lista genérica de riscos. Trata-se de uma matriz de cenários de falha: uma linha para cada forma identificável pela qual a migração pode falhar. Mantenha-a concisa. Para cada linha, descreva o cenário, o que o desencadeia, como se manifestará e as medidas necessárias antes da transição.

Os resultados das fases 2, 3 e 4 costumam constituir as primeiras linhas.

A Fase 5 inclui os cenários exclusivos de migração que não aparecem na descoberta em estado estacionário.

Depois de preenchida, esta matriz passa a servir de acompanhamento da transição e de base para a decisão de avançar ou não.

Cenário	Gatilho	Como se manifesta	Medidas a tomar antes da transição
Conta de serviço migrada com AES configurado, mas sem chaves AES	Mudança de sistema ou primeiro pedido novo de Kerberos	A autenticação da aplicação falha após a migração; as tarefas agendadas ou os serviços começam a falhar assim que os bilhetes armazenados em cache expiram	Reinicie a palavra-passe no sistema de destino, verifique a geração da chave AES, volte a testar a aplicação e agende a alteração para um período de manutenção
Servidor Linux ou Unix com um keytab apenas com RC4	Julho de 2026: implementação ou transição para o domínio de destino	A autenticação Kerberos falha no host que não é Windows; o serviço recorre a um mecanismo alternativo ou é interrompido	Regenerar o keytab com credenciais compatíveis com AES após confirmar que a conta migrada possui chaves AES
Confiança entre domínios explicitamente associada ao RC4	Entrada em vigor em julho de 2026	Os pedidos de bilhetes entre domínios falham durante a coexistência ou o acesso por fases	Remova a configuração de confiança exclusiva do RC4 e verifique o comportamento da confiança com tráfego de teste direto antes da transição
Domínio de destino abaixo do DFL 2008	Plano de redefinição pós-migração	A redefinição da palavra-passe parece ter sucesso, mas as chaves AES nunca são geradas e a aplicação continua a falhar	Aumentar o DFL alvo antes da migração ou redefinir o plano de correção antes do primeiro teste piloto
Configuração do Kerberos em Java, em dispositivos ou local fixada por código para RC4	Mudança de sistema, aplicação de regras ou primeiro pedido de bilhete novo	Uma camada de aplicações falha, apesar de as definições do lado do AD parecerem estar em bom estado	Remover a dependência do RC4, verificar se o fornecedor suporta o AES e testar o caminho exato da aplicação antes da entrada em produção
Execução dupla com autenticação de identidade diferente na origem e no destino	Janela de coexistência ou onda de migração faseada	O comportamento de acesso varia consoante o domínio, o servidor ou o caminho, o que gera um impacto inconsistente para o utilizador	Documentar o comportamento de cada caminho, reduzir a sobreposição sempre que possível e testar explicitamente a coexistência dos caminhos

O que irá realmente encontrar

Em todos os projetos de migração, as conclusões mais relevantes costumam enquadrar-se em quatro categorias:

• Contas de serviço com AES configurado, mas sem chaves AES. Trata-se frequentemente de contas antigas que nunca foram reiniciadas ou de contas migradas em que as credenciais foram copiadas sem regenerar as chaves AES. O atributo do AD apresenta dados incorretos. A correlação do registo de eventos da Fase 3 é a única forma fiável de as identificar. São também as mais fáceis de corrigir. Uma redefinição de palavra-passe num ambiente DFL 2008 ou superior gera as chaves AES. Recomenda-se, por vezes, duas redefinições sequenciais com um intervalo entre elas, como medida de segurança de replicação.
• Servidores Linux com keytabs apenas com RC4. SSSD, Samba, Apache mod_auth_kerb, PostgreSQL com GSSAPI — todos comuns, todos geram ficheiros keytab com base nos tipos de encriptação existentes no momento da geração. A solução consiste em gerar novas chaves para o domínio de destino após a migração, mas isso requer que a conta migrada disponha primeiro de chaves AES.
• O DFL do ambiente adquirido reserva surpresas. Quando a entidade adquirida era a de menor dimensão, ou quando as consolidações ocorreram na direção errada, o DFL acaba por ficar abaixo dos valores de 2008 e ninguém se apercebe disso até à transição. Verifique na Fase 0; verifique novamente antes de cada fase de migração.
• Trusts com atributos RC4 explícitos. Menos comum do que os outros, mas com grande impacto quando ocorre. Um fundo fiduciário com msDS-SupportedEncryptionTypes = 0x4 irá falhar o próprio mecanismo de migração, e não apenas contas específicas.

Se o tempo disponível for limitado, dê prioridade à correlação da Fase 3 (configurada para AES, mas utilizando RC4) e ao inventário de keytabs da Fase 4. Em conjunto, estas duas etapas geram normalmente 60 a 80 % da lista de quebras efetiva.

Ferramentas e recursos

O trabalho de deteção acima descrito pode ser realizado utilizando ferramentas de código aberto e comandos nativos do AD. Aqui estão alguns recursos fiáveis para a deteção e mitigação de contas que dependem do RC4; todos eles estão disponíveis gratuitamente.

• Guia de auditoria do Semperis RC4 : Como auditar o seu ambiente quanto à encriptação RC4, por Guido Grillenmeier e Rich Peckham. Consultas KQL e Splunk em estado estacionário relativas aos eventos 4768 e 4769. (Artigo complementar a esta publicação.)
• O módulo RC4-ADAssessment para PowerShell, da autoria de Jan Tiedemann (BetaHydri). Correlação entre configurações e registos de eventos entre domínios. Disponível na PowerShell Gallery na versão 4.0.0.
• Repositório Kerberos-Crypto da Microsoft. Scripts oficiais do PowerShell, incluindo Get-KerbEncryptionUsage.ps1 e List-AccountKeys.ps1, da equipa do Windows Kerberos.
• KB5073381. As orientações oficiais da Microsoft para a implementação relativas à vulnerabilidade CVE-2026-20833.
• Detetar e corrigir a utilização do RC4 no Kerberos no Microsoft Learn. A referência oficial de procedimentos para a deteção do RC4 em todo o ambiente.
• Série «AD Hardening» de Jerry DeVore — Parte 4: Aplicação do AES no Kerberos. A fonte oficial da Microsoft para informações específicas sobre o tratamento de credenciais na ferramenta de migração.

Para as organizações que realizam esta avaliação no âmbito de um projeto de migração em curso, a Semperis Professional Services aplica regularmente esta metodologia como parte de um serviço de preparação para a migração. A comunidade de migração também está a trabalhar ativamente em abordagens que reduzam os custos decorrentes da perturbação causada aos utilizadores pela redefinição de palavras-passe após a migração — um artigo posterior abordará essas abordagens à medida que forem amadurecendo.

Por onde começar esta semana

Se tem um projeto de migração previsto para julho de 2026 e ainda não iniciou este trabalho, comece por seguir estes quatro passos:

• Execute hoje a Fase 0. Trata-se de um exercício de 30 minutos por domínio que revela as assimetrias entre o DFL e o estado do patch, que determinam todo o resto.
• Verifique se a auditoria está ativa em ambos os domínios (Fase 1). Se não estiver, resolva isso esta semana. Cada dia em que falta telemetria é um dia de risco de falha que não consegue detectar.
• Correr RC4-ADAssessment com -AnalyzeEventLogs em relação a ambos os domínios (Fases 2 e 3 combinadas). A categoria de resultados «Configurado para AES, mas utiliza RC4» é o seu resultado de maior valor.
• Agende as visitas dos responsáveis pelas aplicações da Fase 4. Este é o ponto mais demorado. Comece já e leve-as a cabo em paralelo com todas as outras tarefas.

A transição para o novo sistema e o prazo de aplicação da lei em julho de 2026 são eventos distintos. O trabalho de análise que o prepara para um deles também o prepara para o outro.

Comece agora e a matriz que criar servirá de ferramenta de acompanhamento para ambos.

Tem dúvidas sobre esta metodologia ou sobre como a Semperis pode ajudar num projeto de migração em curso? Entre em contacto connosco — estamos aqui para ajudar.