Kerberos Constrained Delegation (KCD) em Ambientes Híbridos: Guia Completo e Didático para Administradores de Windows Server

A delegação de credenciais é um tema crítico para ambientes corporativos — especialmente quando há integração entre servidores locais e serviços na nuvem. Porém, é também um dos assuntos menos compreendidos no mundo Windows.

Neste artigo, vamos simplificar tudo usando analogias e explicações claras, para que até quem está começando consiga entender conceitos como:

• Kerberos

• SPN

• Delegação Constrained (KCD)

• WinRM e WMI

• Como tudo isso funciona junto no dia a dia

E ao final, mostramos um diagrama visual para fixar o aprendizado.

Entendendo Kerberos de forma simples

Antes de entrar em KCD, vamos simplificar o cenário.

Imagine que sua empresa de TI é um prédio corporativo cheio de salas. Cada sala representa um serviço:

• WinRM

• WMI

• File Server

• SQL

• Web Apps

• APIs internas

E na entrada do prédio existe um porteiro inteligente: o Kerberos.

Esse “porteiro” faz três coisas:

1. Confere sua identidade

2. Entrega um crachá de acesso (ticket Kerberos)

3. Diz exatamente quais salas você pode acessar

   
   

Se o porteiro não reconhecer a sala ou o visitante → ele não emite o crachá → acesso negado.

O que é SPN?

SPN (Service Principal Name) é o número da sala dentro desse prédio.

Sem SPN:

• O Kerberos não sabe qual crachá emitir.

• O serviço não sabe para qual identidade responder.

• A autenticação cai para NTLM (pior e insegura).

• Delegação não funciona.

  
  

Use esse comando para visualizar SPNs de um servidor:

setspn -L NOME-DO-SERVIDOR

E para encontrar duplicações:

setspn -x

SPN duplicado = duas salas com o mesmo número → o porteiro se confunde → Kerberos falha.

O que é Kerberos Constrained Delegation (KCD)?

KCD é o mecanismo que permite que um serviço intermediário realize ações em nome do usuário, porém somente em serviços autorizados.

Analogia simples:

Você autoriza o Motta (serviço intermediário) a entrar apenas na sala 305 e 402 por você. Ele não pode entrar em qualquer sala, apenas nas que você escolheu.

É delegação segura e limitada.

É diferente da delegação irrestrita (que praticamente dá um crachá total para o serviço — e não é recomendada).

Entendendo WinRM e WMI

WinRM — o interfone do servidor

WinRM (Windows Remote Management) é como o interfone da sala. É por onde o Windows Admin Center envia comandos para um servidor remoto.

Ações via WinRM:

• Executar comandos PowerShell

• Instalar roles

• Reiniciar servidor

• Gerenciar serviços

• Abrir logs

Sem WinRM funcionando, grande parte do gerenciamento remoto simplesmente não funciona.

WMI — o relatório técnico da sala

WMI (Windows Management Instrumentation) é quem diz:

• “quanto de CPU está usando”

• “qual o tamanho da memória”

• “quais discos existem”

• “qual o status dos drivers”

• “quais processos estão rodando”

Se WinRM é o interfone, WMI é o relatório de inspeção técnica que o administrador recebe.

Como tudo funciona junto (cenário prático do dia a dia)

Vamos colocar tudo na mesma história:

1️⃣ O usuário acessa o Windows Admin Center (WAC).

Ele se autentica via Kerberos → ganha um crachá.

2️⃣ O WAC precisa acessar outro servidor (SRV-ARQ01).

Ele não tem suas credenciais, então usa KCD.

3️⃣ O WAC pergunta ao Domain Controller:

“Posso acessar esse servidor em nome do usuário?”

4️⃣ O DC verifica:

• Existe SPN do serviço solicitado?

• O WAC está autorizado para esse SPN?

• A conexão está usando Kerberos (não NTLM)?

5️⃣ O DC emite o ticket Kerberos.

Agora o WAC tem um crachá temporário para acessar WinRM e WMI do servidor.

Se qualquer um desses itens falhar…

❌ SPN errado❌ SPN duplicado❌ DNS incorreto❌ Delegação não configurada❌ NTLM ativado

…o WAC mostra erros como:

• “Kerberos: principal unknown”

• “Access denied”

• “NTLM fallback not allowed”

  
  

Como configurar KCD corretamente

1. Identifique o serviço intermediário

Exemplos:

• Servidor do Windows Admin Center

• Aplicação web interna

• Servidor proxy

• Gateway de automação

  
  

2. Liste os SPNs dos destinos

setspn -L servidor-alvo

Exemplo de SPNs comuns:

HOST/servidor.dominio.local
WSMAN/servidor.dominio.local
CIFS/servidor.dominio.local
MSSQLSvc/servidor:1433

3. Configure a delegação no AD

Em Active Directory Users and Computers:

Objeto do servidor → Propriedades → Aba Delegation:

Selecione:

✔ Trust this computer for delegation to specified services only✔ Use Kerberos only

Adicione os SPNs permitidos.

Como testar KCD rapidamente

Ver tickets Kerberos:

klist

Testar execução remota:

Invoke-Command -ComputerName servidor -ScriptBlock { hostname }

Ver logs de delegação:

Event Viewer →Applications and Services Logs → Microsoft → Windows → Kerberos

Problemas comuns e como resolver

❌ 1. SPN inexistente

Erro típico: principal unknown✔ Corrigir com setspn -a.

❌ 2. SPN duplicado

✔ Resolver com setspn -d após validar.

❌ 3. Autenticação caiu para NTLM

✔ Verificar DNS✔ Conectar usando FQDN✔ Validar registro PTR

❌ 4. Delegação não configurada

✔ Revisar SPNs permitidos✔ Validar conta certa no AD✔ Garantir uso de Kerberos

📘 Conclusão

Kerberos, SPNs, WinRM/WMI e KCD compõem uma arquitetura essencial em ambientes corporativos modernos. Mesmo sendo tecnologias antigas, permanecem como base:

• da gestão remota

• da segurança

• da delegação de acesso

• dos cenários híbridos

• 
  

Dominar esses conceitos evita falhas difíceis de diagnosticar e garante que ferramentas como Windows Admin Center e serviços corporativos funcionem de forma estável e segura.