Como Configurar e Proteger Trusts do Active Directory

O Que São Trusts do Active Directory

Trusts do Active Directory permitem que um controlador de domínio em um domínio ateste a identidade de uma conta autenticada em outro domínio ou floresta. Internamente, cada trust é armazenado como um Trusted Domain Object (TDO), que registra o nome do domínio confiável, a direção, a transitividade e um segredo compartilhado — a senha do trust — usada para proteger o tráfego de autenticação que atravessa essa fronteira. Trusts do Active Directory são o que torna uma floresta multi-domínio utilizável: sem eles, cada domínio seria uma ilha de autenticação isolada, sem forma de referenciar usuários ou grupos de qualquer outro lugar.

Um trust, por si só, não concede nenhum acesso. Ele apenas estende o caminho de autenticação — o que a conta solicitante consegue realmente alcançar do outro lado continua sendo governado por ACLs, associação a grupos e configurações de delegação. Ainda assim, um trust mal configurado amplia o raio de impacto de um comprometimento em qualquer um dos lados, motivo pelo qual a configuração de trusts merece a mesma disciplina de qualquer outra mudança Tier 0.

Tipos de Trust e Transitividade

Nem todo trust se comporta da mesma forma. Duas propriedades determinam até onde um trust realmente alcança: a direção (qual lado pode autenticar usuários no outro) e a transitividade (se o trust se estende implicitamente a domínios nos quais o lado confiável também confia).

Duas consequências importam para o hardening:

• Cadeias de transitividade. Um trust de floresta transitivo não para na raiz da floresta — ele se estende a todos os domínios dentro dessa floresta. Confiar em uma floresta significa confiar em todo administrador de domínio dela, não apenas na equipe que solicitou a integração.
• A direção limita a exposição. Um trust unidirecional em que o domínio A confia no domínio B permite que usuários de B se autentiquem em A, mas não o contrário. Sempre que a necessidade do negócio é unidirecional, configurar um trust bidirecional "por segurança" apenas adiciona um caminho de autenticação que ninguém pediu. O TRUST_BIDIRECTIONAL no catálogo da EtcSec sinaliza todo trust bidirecional do tipo external, forest ou cross-tree (trusts parent-child são excluídos, já que são bidirecionais por design) — um sinal de configuração a ser revisado, não uma constatação de que o tráfego flui em uma única direção na prática.

Como Configurar um Trust Seguro Passo a Passo

Os passos abaixo focam em trusts external e forest — os casos que exigem hardening deliberado. Trusts parent-child e tree-root são criados automaticamente pelo processo de promoção de domínio e floresta e herdam os padrões de toda a floresta; o SID filtering não se aplica a eles por design, já que o histórico de SID entre domínios da mesma floresta é esperado.

Passo 1 — Planejar o Trust Antes de Criá-lo

Anote, antes de abrir qualquer console: qual lado inicia a autenticação, se ele precisa ser unidirecional ou bidirecional, quais recursos o lado confiável realmente precisa alcançar, quem é o responsável pela relação, e uma data de revisão. Um trust sem responsável e sem data de revisão é exatamente aquele que continua aberto cinco anos depois de o projeto que o solicitou ter terminado.

Passo 2 — Criar o Trust

Crie o trust pelo console Active Directory Domains and Trusts (New Trust Wizard), ou de forma não interativa com netdom:

netdom trust TrustingDomain /domain:TrustedDomain /add /twoway /userD:AdminAccount /passwordD:*

Remova /twoway para um trust unidirecional — ajuste à necessidade real definida no Passo 1, não ao que é mais rápido de clicar.

Passo 3 — Restringir a Criptografia do Trust para AES

Novos trusts nunca devem ficar no padrão de criptografia. Verifique o atributo msDS-SupportedEncryptionTypes da conta de trust interdomínio e defina-o como somente AES (0x18) assim que todo sistema que se autentica através do trust suportar AES:

$trustDN = (Get-ADTrust -Filter {Name -eq "trusted.example.com"}).DistinguishedName
Set-ADObject $trustDN -Replace @{'msDS-SupportedEncryptionTypes' = 24}

Um atributo indefinido não é um padrão seguro para presumir em nenhuma direção — a própria orientação da Microsoft observa que o AES só é suportado por padrão em controladores de domínio, controladores de domínio somente leitura e trusts depois que o DC implantado recebe as correções das mudanças de RC4 do Kerberos de 2022, e um trust desatualizado ou nunca ajustado ainda pode negociar RC4. O TRUST_AES_DISABLED dispara sempre que o atributo não reporta suporte a AES, inclusive quando está simplesmente indefinido. O TRUST_RC4_ONLY é mais restrito: só dispara quando o trust reporta explicitamente suporte a RC4 sem AES, de forma que um atributo apenas indefinido não o aciona.

Passo 4 — Ativar o SID Filtering (Quarentena)

O SID filtering vem ativado por padrão em novos trusts external e forest, mas é rotineiramente desativado durante migrações que dependem de sIDHistory e depois nunca é reativado. Confirme isso explicitamente:

netdom trust TrustingDomain /domain:TrustedDomain /quarantine:Yes

O TRUST_SID_FILTERING_DISABLED sinaliza qualquer trust external ou forest em que isso esteja desativado. Não alterne isso às cegas — se uma migração depende atualmente do histórico de SID para preservar o acesso, a quarentena vai quebrar esse acesso até que a migração seja concluída.

Passo 5 — Delimitar a Selective Authentication

A Selective Authentication transforma "todo usuário autenticado do lado confiável pode tentar alcançar qualquer coisa deste lado" em uma lista de permissões nomeada. Ative-a no lado de saída do trust e conceda o direito estendido Allowed to Authenticate apenas aos objetos de computador específicos que as contas do lado confiável realmente precisam:

Get-ADTrust -Filter * | Select-Object Name, Direction, SelectiveAuthentication

O TRUST_EXTERNAL_NO_SELECTIVE_AUTH dispara quando um trust external não tem Selective Authentication configurada — a lacuna mais comum em trusts criados para uma integração pontual com parceiros.

Passo 6 — Validar o Trust

Confirme que o trust se comporta da forma pretendida no Passo 1 antes de considerar a mudança concluída:

Get-ADTrust -Filter * | Select-Object Name, Direction, ForestTransitive, `
    SIDFilteringQuarantined, SelectiveAuthentication

Em seguida, force uma tentativa real de autenticação através do trust e leia o tipo de criptografia negociado com klist. O estado de configuração e o que realmente é negociado na prática podem divergir se uma GPO downstream ou um membro legado sobrepuser a configuração própria do trust.

Detecção

A criação e a modificação de trusts são eventos registrados, não mudanças silenciosas — se o desvio de configuração de um trust só aparece em uma auditoria periódica em vez de em um alerta, a lacuna está no pipeline de logging, não na visibilidade.

Um único evento prova muito pouco isoladamente — um 4716 que desativa SidFilteringEnabled é rotina durante uma migração planejada e alarmante em qualquer outro contexto. Alerte sobre o evento e depois confira-o com o ticket de mudança.

Remediation e Checklist de Hardening

1. Inventariar todo trust com Get-ADTrust -Filter * e registrar um responsável, uma justificativa de negócio e uma data de revisão para cada um.
2. Alinhar a direção à necessidade real — não mantenha um trust bidirecional quando a autenticação só flui em uma direção.
3. Ativar o SID filtering em todo trust external e forest que não esteja em plena migração.
4. Delimitar a Selective Authentication aos sistemas específicos que o lado confiável precisa, não ao domínio inteiro.
5. Migrar para criptografia somente AES assim que todo sistema autenticador der suporte a isso.
6. Remover trusts sem responsável ou necessidade de negócio atual, em vez de deixá-los "documentados" indefinidamente.

Para a checklist completa com PowerShell para cada verificação e o mapeamento de compliance, veja Auditoria de Trust do Active Directory: Filtragem de SID e Autenticação Seletiva. Para a narrativa de ataque contra a qual esses controles defendem, veja Ataques de Confiança do Active Directory: do Domínio Filho à Raiz da Floresta.

Ciclo de Vida do Trust: Trusts Bidirecionais, Transitivos e Inativos

Trusts são fáceis de criar e fáceis de esquecer. Três findings do catálogo visam exatamente essa lacuna de ciclo de vida:

• TRUST_BIDIRECTIONAL — sinaliza todo trust bidirecional fora de parent-child com base apenas na configuração, independentemente do uso observado. Se a necessidade de negócio é unidirecional, restringi-lo a unidirecional remove um caminho de autenticação sem perda de funcionalidade.
• TRUST_FOREST_TRANSITIVE — um trust de floresta herda todo domínio dentro da floresta confiável, não apenas o domínio que solicitou a integração. Antes de aprovar um trust de floresta, revise a própria lista de domínios e a higiene administrativa da floresta confiável, não apenas o recurso que o solicitante precisa.
• TRUST_INACTIVE — um trust cuja senha interdomínio não é rotacionada há mais de 180 dias. O Windows rotaciona automaticamente a senha de um trust ativo a cada 30 dias aproximadamente, então um pwdLastSet desatualizado é um indício de um trust abandonado que ninguém mantém, mais do que uma medida direta de tráfego de autenticação. Um trust inativo que ninguém usa ainda é um caminho de autenticação vivo que ninguém está monitorando. Se a necessidade de negócio terminou, remova o trust pelo processo normal de mudança, em vez de deixá-lo "por precaução".

Nenhum desses três exige um comprometimento para importar — são problemas de configuração e higiene de ciclo de vida que reduzem a superfície de ataque antes de um incidente, não depois.

Como a EtcSec Detecta Isso

A EtcSec lê diretamente a bitmask trustAttributes de cada Trusted Domain Object e o atributo msDS-SupportedEncryptionTypes da conta de trust interdomínio — as mesmas propriedades que Get-ADTrust e Get-ADObject expõem acima. Ela sinaliza TRUST_SID_FILTERING_DISABLED, TRUST_EXTERNAL_NO_SELECTIVE_AUTH, TRUST_BIDIRECTIONAL, TRUST_FOREST_TRANSITIVE, TRUST_INACTIVE, TRUST_RC4_ONLY e TRUST_AES_DISABLED em todo trust do ambiente, com os findings vinculados ao objeto de trust específico, para que a remediation aponte exatamente para o comando necessário.

Leituras Relacionadas

Para a cadeia de ataque contra a qual esses controles defendem, veja Ataques de Confiança do Active Directory: do Domínio Filho à Raiz da Floresta. Para a checklist de auditoria aprofundada sobre filtragem de SID, autenticação seletiva e criptografia, veja Auditoria de Trust do Active Directory: Filtragem de SID e Autenticação Seletiva. A rotação da senha do trust é abordada em Rotação de Senha krbtgt, Conta de Confiança, Senha de Máquina do Controlador de Domínio, e o risco de delegação que frequentemente atravessa uma fronteira de trust é abordado em Ataques de Delegação Kerberos: de Não Restrita a Abuso de RBCD. Para onde a revisão de trusts se encaixa em uma auditoria completa do ambiente, veja Auditar a Segurança do Active Directory: O Que Revisar Primeiro e Como Provar a Remediation.

Referências Primárias

• Forest Design Models
• netdom trust command
• MS-PAC: SID Filtering and Claims Transformation
• Event ID 4706 — A new trust was created
• Event ID 4716 — Trusted domain information was modified
• Event ID 4769 — A Kerberos service ticket was requested
• Detecting and remediating RC4 usage for Kerberos
• Securing domain controllers against attack