Kerberos RC4: Migrar para AES após o Enforcement de Julho 2026
Neste artigo
- Por que o RC4 no Kerberos é um problema
- O calendário oficial das três fases
- Auditoria: os eventos KDCSVC 201–209
- Event IDs 4768 e 4769: os campos que importam
- Corrigir contas: atributo msDS-SupportedEncryptionTypes
- Fallback para dispositivos não-Windows: keytabs e o valor 0x24
- Desactivar RC4 no domínio: GPO e registo
- Plano de migração para PME
- Verificação e monitorização contínua
- Erros comuns
- Checklist rápido de verificação
- Como evitar no futuro
A Microsoft desactivou a encriptação RC4 no Kerberos do Active Directory em três fases ao longo de 2026. A fase final, com os updates de Julho de 2026, removeu o último mecanismo de rollback: o enforcement está activo nos controladores de domínio desde os updates de Julho de 2026, e contas que dependam de RC4 já perdem autenticação sem aviso. Este artigo explica o calendário oficial, como auditar a utilização de RC4 no domínio e como migrar para AES-SHA1 — agora em modo de recuperação, para quem está a descobrir falhas depois do enforcement.
Os updates de Julho de 2026 removeram o valor de registo RC4DefaultDisablementPhase e o modo Audit — não há regressão ao comportamento anterior. O domínio que não preparou as contas de serviço antes desta data tem falhas de autenticação permanentes — não temporárias — nos sistemas que só falam RC4; a correcção é corrigir as contas (msDS-SupportedEncryptionTypes ou reset de passwords), porque não há volta a dar.
Por que o RC4 no Kerberos é um problema
O RC4 (RC4-HMAC, etype 0x17) foi o tipo de encriptação por omissão do Kerberos em Windows durante anos, mantido por compatibilidade com sistemas antigos. Hoje é considerado um algoritmo quebrado: com tickets de serviço capturados, um atacante consegue fazer cracking offline das passwords de contas de serviço — o ataque conhecido como Kerberoasting. Não é um cenário teórico: o Kerberoasting contra contas com chaves RC4 é uma das vias de escalada de privilégios mais usadas em ambientes Active Directory comprometidos.
A resposta da Microsoft tem duas ondas. A primeira, em Novembro de 2022 (KB5021131, resposta ao CVE-2022-37966), mudou o tipo de encriptação por omissão para AES-SHA1 nas contas sem configuração explícita. A segunda, em curso durante 2026, elimina o RC4 do caminho por omissão do KDC em resposta ao CVE-2026-20833 — uma vulnerabilidade de divulgação de informação (CVSS 5.5) que permite a um atacante autenticado obter tickets de serviço com encriptação fraca para atacar as passwords offline.
O ponto central do CVE-2026-20833: mesmo com as alterações de 2022, os controladores de domínio continuavam a emitir tickets RC4 para contas sem chaves AES ou sem o atributo msDS-SupportedEncryptionTypes definido. A alteração de 2026 muda a omissão do KDC para AES-SHA1 apenas (0x18) e fecha o fallback implícito.
O calendário oficial das três fases
A Microsoft documentou o rollout em três fases (KB5073381, publicado a 13 de Janeiro de 2026, com alterações verificadas a 14 de Abril):
| Fase | Data | O que acontece |
|---|---|---|
| Fase 1 — Auditoria | Updates desde 13/01/2026 | Eventos KDCSVC de auditoria (201–209) no log System; valor de registo RC4DefaultDisablementPhase disponível para antecipar a alteração |
| Fase 2 — Enforcement com rollback manual | Updates desde 14/04/2026 | O valor por omissão de DefaultDomainSupportedEncTypes passa para 0x18 (AES-SHA1 apenas); pedidos RC4 de contas sem configuração explícita passam a ser bloqueados; rollback manual possível via registo |
| Fase 3 — Enforcement definitivo | Updates desde Julho 2026 | O valor RC4DefaultDisablementPhase deixa de ser lido; o modo Audit é removido; sem forma de voltar atrás |
Duas notas da documentação oficial que apanharam administradores desprevenidos durante o rollout:
- Instalar os updates de Janeiro 2026 não mitigava o CVE-2026-20833 por si só — o modo Audit apenas registava eventos; a mitigação completa exigia Enforcement manual ou a activação programática de Abril.
- O modo Enforcement activado pelos updates de Abril bloqueava ligações de dispositivos não conformes, mantendo a auditoria obrigatória — e desde os updates de Julho de 2026 já não existe rollback: nem Audit, nem reversão manual.
Auditoria: os eventos KDCSVC 201–209
Os eventos de auditoria chegam ao log System dos controladores de domínio (Windows Server 2012 e mais recentes), com a origem Kdcsvc. São nove identificadores e a lógica divide-se em dois grupos:
- Eventos 201–202 (aviso → erro 203–204 em Enforcement): o cliente anuncia apenas RC4 ou o serviço só tem chaves inseguras, e nem o serviço nem o domínio têm configuração explícita de encriptação. São o sinal mais comum — dispositivos ou contas sem nenhuma configuração.
- Eventos 206–209 (aviso → erro 208–209 em Enforcement): o serviço tem
msDS-SupportedEncryptionTypesdefinido como AES-SHA1 apenas, mas o cliente não anuncia AES (206/208) ou a conta de serviço não tem chaves AES (207/209). Indicam contas com configuração explícita mas incompleta. - Evento 205 (aviso permanente): o domínio tem
DefaultDomainSupportedEncTypesconfigurado explicitamente com cifras inseguras. Este evento nunca desaparece enquanto a configuração insegura existir — é intencional, para forçar a revisão.
Em Enforcement, os eventos 203, 204, 208 e 209 são erros — cada um corresponde a um pedido de autenticação bloqueado.
A consulta mais directa sobre contas com chaves disponíveis é feita com os scripts oficiais da Microsoft no repositório Kerberos-Crypto (open source):
">.\List-AccountKeys.ps1 # enumera as chaves disponíveis por conta
.\Get-KerbEncryptionUsage.ps1 # mostra os tipos de encriptação em uso
.\Get-KerbEncryptionUsage.ps1 -Encryption RC4 # filtra apenas RC4
