- Área de tecnologia principal: Windows Server
- Áreas de tecnologia adicionais: Datacenter
- Dados do autor: https://linktr.ee/edupopov
A segurança de uma infraestrutura baseada em Active Directory Domain Services não depende apenas da proteção dos controladores de domínio ou da aplicação periódica de atualizações. Grande parte da confiança estabelecida dentro de um domínio está diretamente relacionada aos mecanismos utilizados para autenticar usuários, computadores, serviços e aplicações.
Com o Windows Server 2025, a Microsoft vem ampliando o processo de modernização desses mecanismos e estabelecendo uma postura de segurança mais rigorosa para ambientes corporativos. Dentro desse contexto, uma nova trilha disponibilizada no Microsoft Learn merece atenção dos administradores de infraestrutura e profissionais responsáveis por identidade e segurança: Active Directory Domain Services authentication and Kerberos hardening.
Link da trilha: Active Directory Domain Services Authentication and Kerberos Hardening - Training | Microsoft Learn
O módulo é classificado pela Microsoft como conteúdo avançado, direcionado principalmente a administradores e profissionais de identidade e acesso. Sua proposta é ensinar como diagnosticar e fortalecer os processos de autenticação utilizados em ambientes Active Directory, com especial atenção ao Kerberos, ao NTLM e às modificações introduzidas ou reforçadas pelo Windows Server 2025.
Mais do que uma introdução ao Kerberos, a trilha aborda um problema extremamente atual: como modernizar a autenticação de um domínio sem interromper aplicações e serviços que ainda dependem de mecanismos legados.
Autenticação como elemento central da segurança do Active Directory
O Active Directory Domain Services permanece como um dos principais componentes de identidade utilizados em infraestruturas corporativas. Quando um usuário acessa um compartilhamento de arquivos, uma aplicação integrada ao domínio, um servidor web, um banco de dados ou algum outro recurso protegido por autenticação Windows, diferentes componentes trabalham em conjunto para validar sua identidade e estabelecer o contexto de segurança utilizado posteriormente para autorizar o acesso.
Um dos pontos importantes apresentados pela nova trilha consiste justamente em compreender essa cadeia de autenticação.
As aplicações Windows normalmente não precisam implementar diretamente Kerberos ou NTLM. Elas podem utilizar a Security Support Provider Interface — SSPI, uma interface responsável por disponibilizar diferentes provedores de segurança ao sistema operacional e às aplicações.
Entre esses provedores encontra-se o mecanismo Negotiate, amplamente utilizado nas aplicações integradas ao Windows. Sua função é selecionar um protocolo de autenticação compatível com o cenário apresentado. Quando as condições necessárias estão disponíveis, o Kerberos normalmente é utilizado. Entretanto, problemas envolvendo nomes, Service Principal Names, contas de serviço, confiança entre domínios, tipos de criptografia ou conectividade com o Key Distribution Center podem resultar na utilização de NTLM como alternativa.
Esse comportamento é particularmente importante porque pode mascarar problemas existentes.
Uma aplicação pode aparentemente funcionar normalmente enquanto utiliza NTLM devido a uma falha na configuração necessária para utilização do Kerberos. O usuário consegue acessar o recurso e, consequentemente, o problema permanece invisível para a equipe responsável pela infraestrutura.
Quando políticas mais restritivas são posteriormente aplicadas, aquilo que parecia ser um ambiente saudável pode começar a apresentar falhas.
Compreendendo o fluxo do Kerberos
Outro mérito da trilha é apresentar o Kerberos como um processo que pode ser analisado e diagnosticado em diferentes etapas.
Em uma autenticação típica, um usuário ou computador solicita inicialmente ao Key Distribution Center — KDC um Ticket Granting Ticket, conhecido como TGT. Após sua emissão, esse ticket pode ser utilizado para solicitar tickets destinados a serviços específicos.
Quando o usuário precisa acessar determinado recurso, o cliente solicita ao KDC um ticket relacionado ao Service Principal Name correspondente ao serviço. Posteriormente, esse ticket é apresentado ao servidor de destino, que precisa ser capaz de validá-lo antes da construção do contexto de segurança utilizado na autorização.
Essa sequência permite compreender por que problemas de Kerberos nem sempre representam simplesmente uma falha de senha.
Um incidente pode estar relacionado, por exemplo, à emissão inicial do TGT, à solicitação de um ticket de serviço, ao SPN utilizado, à identidade responsável pelo serviço, ao tipo de criptografia disponível ou até mesmo ao processo de autorização executado depois que a autenticação foi concluída.
A trilha também relaciona essas etapas a evidências disponíveis nos logs de segurança do Windows, incluindo eventos como 4768, relacionado à solicitação de TGT, e 4769, associado à solicitação de tickets para serviços.
Essa abordagem é particularmente útil em processos de troubleshooting porque substitui a investigação baseada apenas em tentativa e erro por uma metodologia orientada por evidências.
Service Principal Names e a identidade dos serviços
Um dos elementos fundamentais para o funcionamento adequado do Kerberos são os Service Principal Names — SPNs.
Um SPN relaciona determinado serviço à conta do Active Directory responsável pela identidade utilizada para executá-lo. Em outras palavras, Kerberos não autentica simplesmente um nome de servidor; ele precisa identificar corretamente o principal de segurança responsável pelo serviço que será acessado.
Problemas envolvendo SPNs são relativamente comuns em ambientes corporativos, principalmente quando aplicações utilizam contas de serviço específicas, aliases DNS, servidores web, SQL Server ou arquiteturas compostas por diferentes camadas.
SPNs ausentes, duplicados ou registrados em contas incorretas podem impedir a utilização normal do Kerberos.
O problema torna-se ainda mais difícil de detectar quando o mecanismo Negotiate permite que a aplicação utilize NTLM posteriormente. Nesse cenário, a aplicação continua funcionando, mas o Kerberos encontra-se tecnicamente mal configurado.
Por essa razão, comandos como:
setspn -Qsetspn -Xsetspn -S
continuam sendo importantes instrumentos de diagnóstico e administração.
A própria trilha recomenda atenção especial ao uso do parâmetro -S, pois ele realiza uma verificação de duplicidade antes de registrar um novo SPN.
A migração de NTLM para Kerberos
Um dos capítulos mais relevantes do módulo é dedicado ao planejamento da migração de NTLM para Kerberos.
A Microsoft deixa clara uma ideia que considero essencial para qualquer projeto de modernização: bloquear NTLM não deve ser o primeiro passo do processo.
Antes da aplicação de restrições é necessário descobrir onde NTLM ainda está sendo utilizado, compreender por que determinado fluxo depende dele e identificar qual será a estratégia de correção.
Essa abordagem é extremamente importante em ambientes corporativos de maior porte.
Aplicações antigas, tarefas agendadas, equipamentos embarcados, sistemas de backup, ferramentas de gerenciamento, clusters, appliances, integrações entre florestas e aplicações desenvolvidas internamente podem apresentar dependências que não são imediatamente conhecidas pelos administradores.
Uma política de bloqueio aplicada indiscriminadamente pode, portanto, transformar uma iniciativa de segurança em uma indisponibilidade operacional.
A estratégia recomendada consiste inicialmente em realizar auditoria.
Os administradores devem identificar conexões que ainda utilizam NTLM e correlacioná-las com informações como cliente de origem, conta utilizada, servidor de destino, serviço acessado, processo responsável pela comunicação, nome utilizado para acessar o recurso e proprietário da aplicação.
Somente depois dessa descoberta é possível determinar a verdadeira causa da dependência.
Nem toda utilização de NTLM possui a mesma origem
Esse aspecto é particularmente interessante na nova trilha.
O administrador não deve simplesmente observar a presença de NTLM e classificá-la automaticamente como um problema isolado. É necessário determinar por que o Kerberos não foi utilizado.
Entre as causas possíveis encontram-se:
acesso ao servidor utilizando endereço IP;
utilização de aliases sem SPNs adequados;
SPNs inexistentes ou duplicados;
SPNs associados à conta de serviço incorreta;
aplicações configuradas explicitamente para utilizar NTLM;
bibliotecas que não implementam Negotiate corretamente;
problemas relacionados a DNS;
falhas de confiança entre domínios ou florestas;
incompatibilidade dos tipos de criptografia;
configurações incorretas de delegação;
dispositivos ou aplicações legadas sem suporte adequado ao Kerberos moderno.
O aprendizado mais importante aqui é que reduzir NTLM exige corrigir a causa que impede o uso do Kerberos.
Não se trata simplesmente de habilitar uma GPO.
Windows Server 2025 e o endurecimento do Kerberos
A terceira parte técnica do módulo concentra-se diretamente no Windows Server 2025.
A Microsoft apresenta diversas alterações que precisam ser consideradas durante projetos de implantação ou atualização de controladores de domínio.
Entre elas está uma mudança particularmente relevante: controladores de domínio Windows Server 2025 não emitem TGTs utilizando RC4.
Essa mudança representa um importante avanço na postura criptográfica do ambiente, mas também expõe dependências anteriormente mascaradas.
Contas de serviço antigas, equipamentos legados ou aplicações que ainda dependam de RC4 podem apresentar problemas quando começarem a depender de controladores de domínio executando Windows Server 2025.
Portanto, a atualização dos controladores de domínio não deve ser tratada exclusivamente como um procedimento de atualização de sistema operacional.
Ela deve incluir uma análise do ecossistema de autenticação.
O problema das contas antigas e das chaves AES
Existe ainda um detalhe técnico extremamente relevante.
Simplesmente permitir AES através de uma política não significa que todas as contas existentes no domínio possuem automaticamente material criptográfico adequado para utilizá-lo.
Contas de serviço antigas podem não possuir chaves AES apropriadas, principalmente quando suas senhas permanecem inalteradas há muitos anos.
A trilha demonstra que a escolha do tipo de criptografia utilizada pelo Kerberos depende de diferentes fatores, entre eles os tipos anunciados pelo cliente, as chaves disponíveis na conta, o atributo msDS-SupportedEncryptionTypes, as políticas aplicadas, as configurações existentes em relações de confiança e o suporte oferecido pelas aplicações envolvidas.
Por esse motivo, projetos de hardening precisam considerar também o ciclo de vida das contas utilizadas pelos serviços.
Em determinadas situações, a atualização ou redefinição da senha de uma conta pode ser necessária para que novas chaves criptográficas sejam geradas.
Também pode ser apropriado modernizar a identidade utilizada pelo serviço por meio de Group Managed Service Accounts — gMSA ou, quando os requisitos forem atendidos, delegated Managed Service Accounts — dMSA.
Identificando RC4 por meio dos eventos do Windows
Uma das partes que considero mais úteis para administradores é a abordagem prática de auditoria.
Os eventos 4768 e 4769, registrados nos controladores de domínio quando as políticas correspondentes de auditoria estão habilitadas, permitem investigar como os tickets Kerberos estão sendo emitidos.
Entre as informações que podem ser analisadas estão os tipos de criptografia anunciados pelo cliente, os algoritmos disponíveis para determinada conta, o tipo de criptografia utilizado no ticket e os códigos associados a uma eventual falha.
Por exemplo, um ticket de serviço identificado com o tipo 0x17 indica utilização de RC4.
Da mesma forma, erros relacionados à ausência de um tipo de criptografia compatível podem ajudar a identificar aplicações, contas ou dispositivos que precisam ser corrigidos antes de uma política criptográfica mais restritiva ser aplicada.
Essa metodologia transforma os próprios controladores de domínio em importantes fontes de telemetria para o processo de modernização.
SMB e o bloqueio de NTLM
O Windows Server 2025 também amplia as possibilidades relacionadas à redução do NTLM em conexões SMB.
O cliente SMB pode bloquear NTLM em conexões remotas de saída. Nesse modelo, uma conexão que anteriormente funcionava por meio de fallback para NTLM precisará utilizar Kerberos ou estar contemplada por uma exceção explicitamente definida.
Esse recurso possui duas funções importantes.
A primeira é diretamente relacionada à segurança, pois reduz a utilização de um mecanismo legado de autenticação.
A segunda é operacional: bloquear o fallback torna visíveis problemas de Kerberos que anteriormente permaneciam escondidos.
Assim, o bloqueio pode funcionar também como instrumento de validação durante um projeto controlado de migração.
Delegação e aplicações com múltiplas camadas
A trilha também aborda um cenário frequentemente associado a problemas complexos de autenticação: o conhecido double hop.
Imagine uma aplicação web na qual o usuário se autentica em um servidor de front-end. Posteriormente, esse servidor precisa acessar um banco de dados em outro equipamento utilizando a identidade do próprio usuário.
Nesse cenário, a simples autenticação no primeiro servidor não significa que a identidade poderá ser reutilizada automaticamente no segundo.
É necessário avaliar corretamente o modelo de delegação Kerberos utilizado.
A Microsoft apresenta conceitos relacionados à delegação irrestrita, delegação restrita, transição de protocolo e Resource-Based Constrained Delegation — RBCD, destacando que a delegação irrestrita oferece riscos maiores e deve ser evitada em novos projetos.
Compreender esse processo é fundamental para arquiteturas compostas por servidores web, bancos de dados, APIs e diferentes camadas de aplicação.
PKINIT e autenticação baseada em certificados
Outra evolução importante relacionada ao Windows Server 2025 envolve PKINIT, mecanismo utilizado quando a autenticação Kerberos inicial depende de criptografia de chave pública.
Isso inclui, por exemplo, determinados cenários de autenticação por certificados e smart cards.
O Windows Server 2025 amplia a agilidade criptográfica do PKINIT, permitindo que o mecanismo seja menos dependente de pressupostos rígidos relacionados aos algoritmos utilizados.
Entretanto, essa evolução não elimina a necessidade de uma infraestrutura PKI corretamente configurada.
Certificados dos controladores de domínio, cadeias de certificação, autoridades certificadoras confiáveis, templates, algoritmos utilizados e mapeamento dos certificados continuam sendo componentes fundamentais do processo.
Hardening precisa ser gradual
Talvez um dos ensinamentos mais importantes dessa trilha seja que segurança não deve ser implementada de forma desconectada da compatibilidade operacional.
A Microsoft recomenda uma abordagem progressiva e baseada em evidências.
Inicialmente, deve-se habilitar a auditoria e coletar informações sobre eventos Kerberos, utilização de NTLM, RC4 e autenticações dos serviços. Posteriormente, as dependências identificadas precisam ser classificadas e corrigidas.
Somente depois dessa etapa devem ser aplicadas políticas mais restritivas, preferencialmente começando por laboratórios e grupos piloto antes de atingir toda a organização.
Esse modelo reduz significativamente o risco de indisponibilidade.
Um bom projeto de hardening não é aquele que simplesmente bloqueia um protocolo antigo. É aquele que consegue demonstrar que as aplicações continuam funcionando utilizando os mecanismos de autenticação planejados pela organização.
Por que recomendo essa nova trilha
A nova trilha Active Directory Domain Services authentication and Kerberos hardening é especialmente interessante porque aborda autenticação de maneira integrada.
Ela não apresenta Kerberos apenas como um protocolo teórico.
O conteúdo conecta:
SSPI → Negotiate → Kerberos → NTLM → SPN → KDC → tickets → criptografia → delegação → auditoria → migração → hardening.
O módulo possui seis unidades e seus objetivos incluem compreender a interação entre SSPI, Negotiate, NTLM e Kerberos; acompanhar o fluxo de autenticação desde a emissão do TGT até a autorização; diagnosticar problemas envolvendo SPNs, delegação, PAC e criptografia; planejar a migração progressiva de NTLM para Kerberos; identificar e corrigir dependências de RC4; e preparar o ambiente para as mudanças introduzidas pelo Windows Server 2025.
Para administradores de Active Directory, esse conhecimento torna-se cada vez mais necessário.
Windows Server 2025 representa também uma mudança de postura
Durante muitos anos, ambientes Windows precisaram preservar elevada compatibilidade com tecnologias e aplicações desenvolvidas em gerações anteriores.
O problema é que essa compatibilidade frequentemente mantém ativos protocolos, algoritmos e configurações que já não representam o nível de segurança esperado de uma infraestrutura moderna.
O Windows Server 2025 demonstra uma evolução dessa postura.
A introdução de controles mais rígidos para Kerberos, a redução progressiva das dependências de NTLM, as mudanças relacionadas ao RC4, a possibilidade de bloqueio de NTLM no SMB e o fortalecimento dos métodos associados à alteração remota de senhas indicam uma direção clara: a compatibilidade legada não pode continuar sendo tratada como justificativa permanente para manter mecanismos fracos de autenticação.
Entretanto, essa modernização exige planejamento.
Conclusão
Administrar Active Directory no Windows Server 2025 significa compreender muito mais do que criação de usuários, grupos, GPOs ou controladores de domínio.
É necessário entender como a autenticação realmente acontece.
Saber identificar quando Kerberos está sendo utilizado, reconhecer um fallback para NTLM, compreender SPNs, analisar tickets, investigar eventos 4768 e 4769, avaliar tipos de criptografia e identificar contas ou aplicações que ainda dependem de RC4 tornou-se parte importante do trabalho de quem administra ou protege uma infraestrutura Microsoft.
Por esse motivo, considero a nova trilha do Microsoft Learn extremamente bem-vinda.
Ela não ensina apenas como fortalecer o Kerberos.
Ela ajuda o profissional a compreender como preparar um domínio Active Directory para uma arquitetura de autenticação mais moderna, auditável e resistente a mecanismos legados.
Para quem administra ambientes Windows Server 2025, trabalha com Active Directory, identidade ou segurança da informação, é uma trilha que merece entrar na lista de estudos.
E existe ainda uma reflexão importante: antes de simplesmente desabilitar NTLM ou RC4 em um ambiente de produção, precisamos ser capazes de responder a uma pergunta aparentemente simples:
Temos certeza de que nossas aplicações realmente estão utilizando Kerberos?
Essa resposta pode revelar muito sobre a maturidade da autenticação dentro de um ambiente Active Directory.