Active Directory Políticas de Autenticação, Silos, Tier 0: O Controle Kerberos que Quase Ninguém Implementa

Active Directory Políticas de Autenticação Silos Tier 0: O Que Elas Realmente São

A proteção active directory políticas de autenticação silos tier 0 é um único recurso do Windows Server 2012 R2 que a maioria dos ambientes ainda não ativou, mesmo uma década depois do lançamento. Um silo de política de autenticação é um contêiner do AD (objectClass msDS-AuthNPolicySilos) que agrupa as contas de usuário, computador e serviço que você deseja proteger. Uma política de autenticação (objectClass msDS-AuthNPolicies) é o conjunto de regras aplicado a esse contêiner — por quanto tempo um ticket-granting ticket (TGT) do Kerberos pode viver, de quais dispositivos uma conta pode até mesmo fazer logon, e quais principals podem se autenticar em um serviço que roda sob essa conta.

A proposta é simples: seus Domain Admins deveriam se autenticar apenas a partir de um punhado de Privileged Access Workstations (PAWs) e controladores de domínio. Políticas de autenticação e silos são o mecanismo que transforma essa suposição em algo que o KDC realmente aplica, em vez de uma regra que só existe em um documento de onboarding.

As contas podem pertencer a exatamente um silo. Uma vez atribuída, o controlador de domínio anexa um claim de silo de política de autenticação ao ticket Kerberos da conta no momento do logon, que recursos com suporte a claims podem usar em suas próprias verificações de acesso — além do que a política do silo já restringe.

O exemplo prático da própria Microsoft ilustra bem a intenção: construir um silo "Forest Administrators" contendo contas enterprise, schema e domain admin, e então anexar uma política para que o logon baseado em senha ou smartcard a partir de qualquer coisa que não seja um controlador de domínio ou um console de administração designado falhe completamente. Ao silo não importa como a credencial foi obtida — phishing, replay ou digitada corretamente pelo administrador real —, ele só se importa se o dispositivo de origem está na allow-list.

Um único silo pode conter as três classes de contas do Active Directory — usuário, computador e managed service account —, mas a política se comporta de forma diferente para cada classe. Contas de serviço e de computador nunca devem entrar no grupo Protected Users: a justificativa da Microsoft é que toda autenticação recebida falha para esses tipos de conta, e a associação não traz proteção local alguma, já que a senha ou o certificado sempre está presente no host. A Microsoft também recomenda não configurar uma vida útil de TGT para contas de computador. A distinção por tipo de conta importa tanto quanto a associação ao silo em si.

Como Funciona: Vida Útil do TGT, Claims e o Requisito de Armoring

As políticas de autenticação atuam em dois pontos da troca Kerberos: a troca AS (logon inicial, emissão do TGT) e a troca TGS (requisições de service ticket). Três coisas podem ser restringidas:

1. Vida útil do TGT — definida para um valor mais curto e não renovável que o padrão do domínio (4 horas é o que os membros do grupo Protected Users recebem automaticamente). Uma conta Tier 0 com um TGT não renovável de 1 hora reduz muito a janela para um atacante que rouba um ticket.
2. AllowedToAuthenticateFrom — o conjunto de dispositivos a partir dos quais um usuário pode fazer logon. É aplicado na troca AS.
3. AllowedToAuthenticateTo — o conjunto de principals autorizados a se autenticar em um serviço que roda sob essa conta. Aplicado na troca TGS.

As restrições de dispositivo são onde a maioria dos rollouts trava. Verificar AllowedToAuthenticateFrom exige Kerberos armoring (FAST): o KDC precisa do próprio TGT do dispositivo solicitante para validar sua identidade antes de decidir se esse dispositivo está na allow-list. As duas configurações de Política de Grupo que ativam o armoring vêm como Not Configured em um domínio padrão — já cobrimos essa lacuna separadamente —, então em um domínio não modificado a restrição de logon simplesmente não funciona, mesmo que a restrição de vida útil do TGT continue funcionando. Isso é um pré-requisito aqui, não um hardening opcional.

Todo silo de política de autenticação começa em modo somente auditoria — o equivalente em PowerShell ao -WhatIf. O modo de auditoria registra o que falharia sem bloquear nada, que é a forma pretendida de testar uma política antes que um administrador se tranque para fora do próprio domínio.

Por Que Esse Controle Fica Sem Uso na Maioria dos Ambientes Tier 0

Três pontos de atrito explicam por que políticas de autenticação e silos raramente saem da fase de piloto, mesmo em ambientes que levam administração em camadas a sério.

O Nível Funcional de Domínio que Ninguém Revisita

Vidas úteis de TGT personalizadas exigem o nível funcional de domínio Windows Server 2012 R2 no domínio de contas. Restringir o logon do usuário exige o mesmo DFL no domínio de contas com suporte a Dynamic Access Control, além de dispositivos cliente que suportem Dynamic Access Control por si mesmos. Restringir a emissão de service ticket é uma exigência do domínio de recursos, que precisa estar em DFL 2012 R2 por conta própria — então um ambiente Tier 0 entre domínios tem dois níveis funcionais para verificar, não um. Muitos domínios elevaram o DFL anos atrás por um motivo totalmente diferente — uma migração de forest trust, uma extensão de schema para outro projeto — e nunca voltaram para perguntar o que mais aquele nível funcional desbloqueou. Os silos de política de autenticação ficam sem uso nessa lista porque nada leva um administrador a procurá-los.

Sem Override, Sem Exceções

Assim que uma conta esbarra nas restrições de autenticação, não há solução alternativa — um Domain Admin bloqueado por um silo em modo enforced fica bloqueado, ponto final (exceto o RID 500). A Microsoft escreve sua versão direta desse aviso sobre o grupo Protected Users, não sobre silos, mas o modo de falha é o mesmo: as restrições de autenticação não têm workaround, Enterprise Admins e Domain Admins estão sujeitos a elas como qualquer outra conta, e inscrever todos os membros desses grupos de uma vez pode bloquear todos eles — incluindo as contas que normalmente resolveriam o problema. A orientação separada da Microsoft para políticas de autenticação e silos é procedimental, não tranquilizadora: manter clientes e controladores de domínio na rede, rotacionar as senhas das contas protegidas depois e desabilitar o logon em cache onde for possível. Esse perfil de risco já é suficiente para que a maioria das equipes pare em um piloto de uma ou duas contas de teste e nunca avance além disso.

A Dependência do Armoring

Para extrair valor real das restrições de dispositivo, o Kerberos armoring já precisa estar funcionando, e o próprio armoring é uma mudança de GPO separada tanto em controladores de domínio quanto em clientes que a maioria das equipes ainda não fez — veja o requisito acima. Pilotar políticas de autenticação sem primeiro ter o armoring significa pilotar um recurso que silenciosamente faz apenas metade do que deveria.

Nada disso é motivo para pular essa etapa. Um TGT encurtado e não renovável em contas Tier 0 reduz diretamente a janela para um ticket roubado — o caso de pass-the-ticket, em que um atacante retira um TGT legítimo da memória e o reutiliza enquanto ainda é válido.

Seja preciso sobre o que isso NÃO cobre. Uma política de autenticação molda o ticket que o KDC emite: o controlador de domínio retorna um TGT não renovável com a vida útil configurada ao responder a uma requisição AS, e verifica a restrição de logon contra o AS-REQ blindado. Um Golden Ticket é forjado offline com a chave krbtgt e nunca passa por uma troca AS, então carrega a vida útil e a identidade que o atacante escolher — a vida útil do TGT e a restrição de logon do silo não têm nenhum poder sobre ele. O que ainda pode afetar um ticket forjado é a verificação do lado TGS: um serviço cuja conta carrega uma condição AllowedToAuthenticateTo é avaliado quando o service ticket é solicitado, não quando o TGT foi emitido. Mesmo isso tem um limite — ainda é uma verificação do lado do KDC, e um Silver Ticket é forjado contra a própria chave do serviço e apresentado diretamente ao host sem que o controlador de domínio seja consultado, então nenhuma política de autenticação jamais o vê.

Configurando um Silo de Política de Autenticação

O passo a passo completo está no guia da Microsoft para configurar contas protegidas; o formato geral:

1. Habilitar o Kerberos Armoring

Via Política de Grupo, em controladores de domínio e clientes:

Computer Configuration > Administrative Templates > System > KDC
  "Key Distribution Center (KDC) client support for claims,
   compound authentication and Kerberos armoring" → Enabled, "Always provide claims"

Computer Configuration > Administrative Templates > System > Kerberos (clients)
  "Kerberos client support for claims, compound authentication
   and Kerberos armoring" → Enabled

Confirme com um logon de teste a partir de um cliente ingressado no domínio antes de mexer em qualquer política — falhas de armoring são silenciosas, e você não quer depurar dois recursos novos ao mesmo tempo.

2. Criar a Política de Autenticação

Defina uma vida útil de TGT em minutos:

New-ADAuthenticationPolicy -Name "Tier0-AdminPolicy" `
  -UserTGTLifetimeMins 60 `
  -Description "Tier 0 admin accounts - 1h non-renewable TGT"

3. Criar o Silo — Não Aplicado por Padrão

New-ADAuthenticationPolicySilo -Name "Tier0-Silo"

Todo silo novo começa em modo de auditoria. Adicione -Enforce somente depois que o período de auditoria estiver limpo — este é o equivalente embutido ao -WhatIf, e existe justamente para que um erro de digitação em uma condição de controle de acesso não bloqueie a conta que o corrigiria.

4. Conceder Acesso e Atribuir Contas

Grant-ADAuthenticationPolicySiloAccess -Identity "Tier0-Silo" -Account "da-jsmith"

Get-ADUser -Filter 'Name -like "da-*"' |
  Set-ADAccountAuthenticationPolicySilo -AuthenticationPolicySilo "Tier0-Silo" `
    -AuthenticationPolicy "Tier0-AdminPolicy"

Uma conta precisa tanto receber acesso ao silo quanto ter o par silo/política atribuído a ela — conceder acesso sozinho não inscreve a conta.

5. Testar e Depois Aplicar

Set-ADAuthenticationPolicySilo -Identity "Tier0-Silo" -Enforce $true
Set-ADAuthenticationPolicy -Identity "Tier0-AdminPolicy" -Enforce $true

Tanto o silo quanto a política têm sua própria flag Enforce — ativar apenas uma delas deixa a outra em modo de auditoria, o que é uma causa comum de confusão do tipo "por que isso não bloqueou nada" durante o rollout.

Detecção

Os eventos ficam em um log operacional desabilitado por padrão — habilitá-lo é o passo zero para que qualquer coisa disso fique visível:

Event Viewer > Applications and Services Logs > Microsoft > Windows >
Authentication > AuthenticationPolicyFailures-DomainController → Enable Log

Um pico de 105/106 depois que um silo passa de audit para enforced é ou um bloqueio legítimo que você precisa corrigir (uma PAW que ainda não está na allow-list) ou uma tentativa real de usar uma credencial Tier 0 de um lugar que não deveria — ambos valem um alerta.

Remediation

1. Inventarie as contas Tier 0 e o conjunto exato de hosts a partir dos quais elas devem se autenticar (PAWs, controladores de domínio — nada mais).
2. Habilite o Kerberos armoring via GPO em controladores de domínio e clientes elegíveis para Tier 0; confirme com um logon de teste antes de mexer em qualquer política.
3. Crie a política de autenticação e o silo em modo de auditoria; deixe-os sem enforcement por pelo menos um ciclo operacional completo.
4. Habilite o log AuthenticationPolicyFailures-DomainController e revise os eventos 305/306 em busca de falsos positivos — PAWs ausentes, jump hosts esquecidos.
5. Aplique o enforcement no silo e na política. Rotacione as senhas de toda conta inscrita imediatamente depois.
6. Combine isso com a associação ao grupo Protected Users para contas que não precisam de delegação Kerberos — o Protected Users também bloqueia NTLM, pré-autenticação DES/RC4 e tanto a delegação constrained quanto a unconstrained por completo. Nunca adicione contas de serviço ou computador ao Protected Users; toda autenticação recebida falha completamente para esses tipos de conta.

Como a EtcSec Detecta Isso

A auditoria de Active Directory da EtcSec sinaliza a ausência desse controle a partir de vários ângulos, em vez de uma única verificação: NOT_IN_PROTECTED_USERS identifica contas privilegiadas fora do grupo Protected Users, WEAK_KERBEROS_POLICY sinaliza um domínio que ainda mantém a vida útil máxima do ticket acima de 10 horas ou a janela de renovação acima de 7 dias, FGPP_NOT_CONFIGURED sinaliza um domínio sem nenhuma fine-grained password policy, e as verificações alinhadas à ANSSI ANSSI_R40_NO_PSO_TIER0 e ANSSI_R82_R83_ADMIN_ARCHITECTURE sinalizam especificamente grupos de admin Tier 0 que não são cobertos por uma política fine-grained dedicada nem por nenhum controle de restrição de logon.