Relação de Confiança entre Domínios

Introdução

Você já precisou que um usuário de uma empresa abrisse uma pasta ou entrasse em um sistema de outra empresa, sem criar uma conta nova para ele? Se sim, você já esbarrou no problema que a relação de confiança resolve.

Pense em uma situação bem comum: duas empresas acabaram de se fundir. Cada uma tem o seu próprio Active Directory, com os seus usuários, servidores e senhas. Na segunda-feira, o financeiro de uma precisa acessar o sistema da outra. Criar contas duplicadas para todo mundo vira bagunça rápido: duas senhas por pessoa, dois lugares para desativar quando alguém sai da empresa, e ninguém sabe qual conta é a oficial.

A saída é fazer os dois ambientes se reconhecerem. Você ajusta o DNS para que um encontre o outro, cria a relação de confiança entre eles e, depois, concede as permissões normalmente, como se o usuário fosse da casa. O resultado: cada pessoa continua entrando com a mesma conta de sempre e acessa os recursos do outro lado, enquanto cada empresa continua administrando o seu próprio ambiente.

Em outras palavras, a relação de confiança é o acordo que diz: "as contas autenticadas pelo domínio A podem receber acesso aos recursos do domínio B". Sem ela, cada domínio só reconhece as contas que ele mesmo criou.

Um detalhe antes de seguir: no Active Directory, a fronteira de segurança é a floresta, não o domínio. Domínios da mesma floresta já confiam uns nos outros automaticamente, e os administradores da raiz da floresta (o grupo Enterprise Admins) controlam todos eles. A relação de confiança que você cria à mão serve para ligar o que está fora dessa fronteira, ou seja, florestas diferentes.

Quando usar uma relação de confiança

Na prática, a necessidade aparece quando duas organizações, ou duas partes da mesma organização, precisam trabalhar juntas sem misturar a administração:

• Fusão de empresas: cada empresa tem a sua floresta, e os usuários das duas precisam acessar arquivos, sistemas e impressoras da outra desde o primeiro dia. A confiança resolve o acesso imediato, enquanto a integração definitiva é planejada.

• Cisão de empresas: uma empresa se divide em duas. A parte que sai ganha uma floresta própria, e uma confiança temporária mantém os sistemas compartilhados funcionando até a separação terminar. No fim, a confiança é removida.

• Migração entre florestas: para mover usuários, grupos e computadores de uma floresta para outra com o ADMT, as duas florestas precisam confiar uma na outra durante a migração.

• Parceiros e fornecedores: uma empresa externa precisa usar um sistema específico. Uma confiança de mão única, com autenticação seletiva, libera só os servidores escolhidos.

• Floresta de recursos: as contas ficam em uma floresta e os servidores em outra, separando quem administra pessoas de quem administra sistemas.

Confiança ou absorção?

A relação de confiança mantém as duas florestas: cada empresa continua com as suas contas e os seus administradores, e só os acessos são liberados. Quando a empresa A absorve a empresa B e quer o ambiente de B dentro da sua floresta, o caminho é outro, porque o Active Directory não junta florestas existentes. A empresa A cria um domínio filho (ou uma OU) na sua floresta e migra para lá, em etapas, os usuários, grupos, computadores e servidores de B, com ferramentas como o ADMT. Durante a migração, a TI da matriz resolve os conflitos (nomes repetidos, grupos, GPOs, permissões) e, no fim, a floresta antiga é desativada.

Esse processo é um projeto à parte, e a relação de confiança deste post é o primeiro passo dele: é ela que mantém todo mundo trabalhando enquanto os objetos mudam de casa. Para se aprofundar, veja os links da Microsoft em Para saber mais.

Matriz e filiais em vários países

E se a empresa for uma multinacional? Imagine a matriz na Inglaterra e filiais em vários países. A matriz quer ficar no topo, com todas as filiais abaixo dela, e definir as regras para os controladores de domínio e para os domínios de cada país. Isso pode ser feito de dois jeitos, e a escolha decide se você vai precisar criar relações de confiança à mão ou não.

Desenho 1, uma floresta com domínios filhos. A matriz é a raiz da floresta, e cada filial é um domínio filho. As confianças entre todos os domínios são criadas automaticamente, são de mão dupla e transitivas:

corp.lab                 raiz da floresta (matriz, Inglaterra)

├── br.corp.lab          filial Brasil

├── jp.corp.lab          filial Japão

└── de.corp.lab          filial Alemanha

É o desenho mais simples de administrar, mas a matriz controla tudo: os Enterprise Admins da raiz têm poder sobre todos os domínios filhos, e as filiais não têm isolamento entre si.

Desenho 2, florestas separadas ligadas por confiança. Cada filial mantém a sua própria floresta, e a matriz cria confianças com cada uma:

corp.lab (matriz)  <── confiança de floresta ──>  br-corp.lab (filial Brasil)

corp.lab (matriz)  <── confiança de floresta ──>  jp-corp.lab (filial Japão)

Cada filial administra o próprio ambiente, um problema de segurança em uma floresta não se espalha automaticamente para as outras, e a direção de cada confiança pode ser escolhida. Por exemplo, a filial confia na matriz para que os usuários da matriz acessem os sistemas locais, mas não o contrário. Esse desenho também facilita uma futura venda ou separação de uma filial, porque basta remover a confiança.

A matriz define as regras nos dois casos: no primeiro, pela estrutura da floresta; no segundo, pelas confianças e pelas permissões que cada lado concede. Este post trata do segundo desenho, que é onde a relação de confiança precisa ser configurada.

Quando não usar

• Domínios da mesma floresta: a confiança já existe e é automática.

• Poucos usuários ou um único sistema web: contas separadas ou federação (AD FS, ou o Keycloak como opção open source) costumam ser mais simples e seguras.

• Microsoft 365 e Entra ID: a colaboração entre tenants usa outro mecanismo (B2B e acesso entre tenants), não uma relação de confiança do AD.

• Laboratório ligado à produção: cada confiança aumenta a superfície de ataque. Se um lado for comprometido, o outro fica exposto.

Neste post, vamos montar duas florestas em laboratório, criar uma confiança de floresta entre elas usando o PowerShell, validar o acesso, limitar quem entra com autenticação seletiva, garantir o uso de criptografia AES e, por fim, remover a confiança. Tudo é feito pela linha de comando, então não há telas para acompanhar.

Cenário do laboratório

Para acompanhar, você precisa de duas florestas independentes, cada uma com pelo menos um controlador de domínio. No exemplo, a matriz usa Windows Server 2025 e a filial usa Windows Server 2019, justamente para mostrar que versões diferentes convivem sem problema. Tudo o que aparece aqui vale igualmente para o Windows Server 2022.

• Floresta da matriz: domínio corp.lab, nome NetBIOS CORP, controlador DC01 (Windows Server 2025), IP 192.168.10.10

• Floresta da filial: domínio br-corp.lab, nome NetBIOS BRCORP, controlador BRDC01 (Windows Server 2019), IP 192.168.20.10

• Servidor de arquivos na matriz: FS01.corp.lab, com a pasta compartilhada Financeiro, usada no teste de acesso

• Usuário de teste na filial: analista01, que vai acessar a pasta da matriz

As duas redes se comunicam por roteamento. Em uma VM só ou em um laboratório com uma rede única, os dois controladores podem ficar na mesma sub-rede, e o resto do processo é igual.

O nível funcional também não é obstáculo: a confiança de floresta exige nível funcional de floresta Windows Server 2003 ou superior, e qualquer floresta criada com Windows Server 2019 ou mais novo já atende.

Para criar a confiança, você vai precisar de uma conta do grupo Enterprise Admins (ou Domain Admins do domínio raiz) em cada floresta. Se você administra só um dos lados, combine com o administrador do outro lado: cada um pode criar a sua metade da confiança, como mostrado mais adiante.

Pré-requisitos

Quase todo erro na criação de uma confiança vem de três coisas: rede, horário e DNS. Vale conferir cada uma antes de abrir o assistente.

1. Rede e portas

Os controladores dos dois lados precisam se alcançar. Se houver um firewall entre as redes, ele deve liberar, nos dois sentidos, entre os controladores (e entre os clientes e os controladores do outro lado):

• 53 TCP e UDP: DNS

• 88 TCP e UDP: Kerberos

• 135 TCP: RPC Endpoint Mapper

• 389 TCP e UDP: LDAP

• 445 TCP: SMB, usado na criação da confiança

• 464 TCP e UDP: troca de senha do Kerberos

• 3268 TCP: catálogo global

• 49152 a 65535 TCP: portas dinâmicas de RPC (LSA, SAM e Netlogon)

O Windows Firewall dos controladores já libera essas portas quando a função AD DS é instalada. O que costuma bloquear é o firewall de rede entre os dois ambientes.

Para testar as portas principais a partir do DC01, em direção ao controlador da filial (repita no sentido inverso no BRDC01):

88, 135, 389, 445, 3268 | ForEach-Object {

    Test-NetConnection -ComputerName 192.168.20.10 -Port $_ |

        Select-Object RemotePort, TcpTestSucceeded

}

2. Horário

O Kerberos rejeita autenticações quando a diferença de horário entre os servidores passa de 5 minutos. Cada floresta sincroniza o horário a partir do seu próprio controlador raiz, então confira se os dois lados estão alinhados com a mesma referência externa. Esta consulta, executada no DC01, mostra a diferença em relação ao BRDC01:

w32tm /stripchart /computer:192.168.20.10 /samples:3 /dataonly

Valores de poucos segundos estão ótimos. Se a diferença for grande, corrija a fonte de horário do controlador raiz de cada floresta antes de seguir.

3. DNS

Cada floresta precisa encontrar a outra pelo nome, incluindo os registros SRV que indicam onde estão os controladores. A forma mais limpa é um encaminhador condicional em cada lado: o DNS da matriz passa a perguntar ao DNS da filial tudo o que termina em br-corp.lab, e vice-versa.

No DC01 (corp.lab), crie o encaminhador para a filial:

Add-DnsServerConditionalForwarderZone -Name "br-corp.lab" -MasterServers 192.168.20.10 -ReplicationScope "Forest"

No BRDC01 (br-corp.lab), crie o encaminhador para a matriz:

Add-DnsServerConditionalForwarderZone -Name "corp.lab" -MasterServers 192.168.10.10 -ReplicationScope "Forest"

O parâmetro ReplicationScope "Forest" grava o encaminhador no Active Directory, e assim todos os controladores com DNS da floresta passam a usá-lo. Pelo console, o mesmo é feito no DNS Manager, em Conditional Forwarders, com a opção de armazenar no Active Directory.

Agora teste a resolução nos dois sentidos. No DC01, o nome do domínio e o registro SRV dos controladores da filial devem responder:

Resolve-DnsName br-corp.lab

Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.br-corp.lab

No BRDC01, faça o mesmo teste para a matriz:

Resolve-DnsName corp.lab

Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.corp.lab

Se o registro SRV não responder, a confiança não vai ser criada, mesmo que o ping funcione. Para desfazer um encaminhador criado por engano:

Remove-DnsServerZone -Name "br-corp.lab" -Force

Com rede, horário e DNS conferidos, os dois lados estão prontos para a confiança.

Entender a direção da confiança

A direção é o ponto que mais confunde, então vale fixar a regra antes de criar qualquer coisa: quem confia é quem tem os recursos. Se os usuários da filial precisam acessar a pasta da matriz, a matriz confia na filial.

Na criação pelo PowerShell, a direção é sempre vista do lado onde o comando roda:

• Outbound (saída): a floresta local confia na remota. Os usuários da floresta remota podem receber acesso aos recursos locais.

• Inbound (entrada): a floresta remota confia na local. Os usuários locais podem receber acesso aos recursos remotos.

• Bidirectional (mão dupla): as duas coisas ao mesmo tempo.

No laboratório, vamos criar uma confiança de mão dupla, que é o cenário mais comum em uma fusão. Mais adiante aparece como criar só uma das metades, quando cada lado tem um administrador diferente.

A confiança também não libera nada sozinha. Ela só permite que o outro lado receba permissões. Enquanto ninguém conceder acesso a uma pasta ou a um sistema, os usuários da outra floresta continuam sem acesso a nada.

Criar a confiança pelo PowerShell

O módulo ActiveDirectory do PowerShell consulta confianças, mas não cria. Para criar, o PowerShell usa as classes do .NET que o próprio Windows usa por baixo do assistente gráfico. Os comandos funcionam igual no Windows Server 2019, 2022 e 2025.

Quando você administra os dois lados

No DC01 (corp.lab), abra o PowerShell como administrador e informe a credencial de um Enterprise Admin da floresta da filial:

$cred = Get-Credential -Message "Enterprise Admin da floresta br-corp.lab" -UserName "BRCORP\Administrator"

Depois, conecte nas duas florestas e crie a confiança de mão dupla:

$local  = [System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest()

$ctx    = New-Object System.DirectoryServices.ActiveDirectory.DirectoryContext('Forest', 'br-corp.lab', $cred.UserName, $cred.GetNetworkCredential().Password)

$remota = [System.DirectoryServices.ActiveDirectory.Forest]::GetForest($ctx)

$local.CreateTrustRelationship($remota, 'Bidirectional')

O comando cria as duas metades da confiança, uma em cada floresta, com uma senha interna gerada automaticamente. Se não houver mensagem de erro, a confiança foi criada.

Para uma confiança de mão única, troque Bidirectional por Outbound ou Inbound, seguindo a regra da seção anterior. Para os usuários da filial acessarem a matriz, rodando o comando na matriz, a direção é Outbound.

Quando cada lado tem o seu administrador

Em uma fusão ou com um parceiro, é comum ninguém ter a senha de administrador dos dois lados. Nesse caso, cada administrador cria a metade da sua floresta, e os dois combinam uma senha de confiança, que só é usada nessa criação.

No DC01 (corp.lab), o administrador da matriz cria a metade local:

$local = [System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest()

$local.CreateLocalSideOfTrustRelationship('br-corp.lab', 'Bidirectional', 'Senha-De-Confianca-Combinada')

No BRDC01 (br-corp.lab), o administrador da filial cria a outra metade, com a mesma senha:

$local = [System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest()

$local.CreateLocalSideOfTrustRelationship('corp.lab', 'Bidirectional', 'Senha-De-Confianca-Combinada')

A senha combinada não fica guardada em lugar nenhum depois da criação: o Windows troca essa senha sozinho a cada 30 dias. Mesmo assim, não deixe esses comandos em scripts ou no histórico do servidor.

Se preferir a ferramenta clássica, o netdom trust faz o mesmo e continua disponível em todas as versões. Os links estão em Para saber mais.

Validar a confiança

Primeiro, confira se a confiança existe e como ela foi criada. No DC01:

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

O resultado esperado para o laboratório: Name br-corp.lab, Direction BiDirectional, ForestTransitive True e SelectiveAuthentication False.

Depois, peça ao Windows para testar a confiança de verdade, contatando o outro lado:

$local  = [System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest()

$local.VerifyOutboundTrustRelationship('br-corp.lab')

Sem erro, a metade de saída está funcionando. Repita no BRDC01, trocando para corp.lab. O comando clássico nltest mostra as confianças que o controlador enxerga e testa o canal seguro com o outro domínio:

nltest /domain_trusts /all_trusts

nltest /sc_verify:br-corp.lab

O nltest deve terminar com "The command completed successfully" e mostrar o status de conexão NERR_Success.

Teste de acesso real

A confiança só prova que funciona quando um usuário do outro lado acessa algo. A boa prática é nunca dar permissão direto ao usuário de fora: crie um grupo de domínio local na matriz e coloque nele os usuários ou grupos da filial.

No DC01, crie o grupo e adicione o analista01 da filial:

New-ADGroup -Name "GL_Financeiro_Leitura" -GroupScope DomainLocal -GroupCategory Security -Path "CN=Users,DC=corp,DC=lab"

$usuario = Get-ADUser -Identity analista01 -Server br-corp.lab -Credential $cred

Add-ADGroupMember -Identity "GL_Financeiro_Leitura" -Members $usuario

O usuário da filial aparece no grupo como um Foreign Security Principal, que é a forma como o AD representa contas de outra floresta.

No FS01, dê ao grupo permissão de leitura no compartilhamento e na pasta (no exemplo, a pasta fica em D:\Financeiro):

Grant-SmbShareAccess -Name "Financeiro" -AccountName "CORP\GL_Financeiro_Leitura" -AccessRight Read -Force

icacls "D:\Financeiro" /grant "CORP\GL_Financeiro_Leitura:(OI)(CI)RX"

Agora, em uma estação da filial, entre como BRCORP\analista01 e teste o acesso. O klist mostra que o usuário recebeu um ticket Kerberos da floresta da matriz, o que confirma que o acesso passou pela confiança:

Test-Path "\\FS01.corp.lab\Financeiro"

klist

O Test-Path deve retornar True, e o klist deve listar um ticket para krbtgt/CORP.LAB e outro para cifs/FS01.corp.lab.

Limitar o acesso com autenticação seletiva

Por padrão, a confiança de floresta usa autenticação em toda a floresta: qualquer usuário do outro lado pode tentar se autenticar em qualquer servidor seu, e só as permissões decidem o que ele acessa. Com um parceiro ou fornecedor, é mais seguro usar a autenticação seletiva: os usuários de fora só se autenticam nos computadores que você liberar explicitamente.

No DC01, ative a autenticação seletiva para os usuários que vêm de br-corp.lab:

$local = [System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest()

$local.SetSelectiveAuthenticationStatus('br-corp.lab', $true)

A partir desse momento, o teste de acesso da seção anterior para de funcionar, e isso é esperado. Para liberar o FS01, conceda ao grupo a permissão Allowed to Authenticate no objeto de computador do servidor:

dsacls "CN=FS01,CN=Computers,DC=corp,DC=lab" /G "CORP\GL_Financeiro_Leitura:CA;Allowed to Authenticate"

Confira se a mudança foi aplicada:

(Get-ADTrust -Identity br-corp.lab).SelectiveAuthentication

Repita o teste na estação da filial (rode klist purge antes, para descartar os tickets antigos). O acesso ao FS01 volta a funcionar, e qualquer outro servidor da matriz continua fechado para os usuários da filial. Para voltar à autenticação em toda a floresta, rode o mesmo SetSelectiveAuthenticationStatus com $false.

Garantir o uso de AES

As confianças antigas usam RC4 para criptografar os tickets que passam de uma floresta para a outra. A Microsoft está removendo o RC4 do Kerberos ao longo de 2026, e as atualizações de segurança passam a bloquear o que ainda depende dele. Uma confiança que só aceita RC4 pode parar de funcionar depois de uma atualização, então vale garantir o AES desde o início.

A consulta da seção de validação já mostra a situação nas colunas UsesAESKeys e UsesRC4Encryption. Para conferir direto pelo ksetup, no DC01:

ksetup /getenctypeattr br-corp.lab

Se o resultado não listar AES, configure os dois tipos AES no objeto da confiança. No DC01:

ksetup /setenctypeattr br-corp.lab AES128-CTS-HMAC-SHA1-96 AES256-CTS-HMAC-SHA1-96

No BRDC01, faça o mesmo para o domínio da matriz:

ksetup /setenctypeattr corp.lab AES128-CTS-HMAC-SHA1-96 AES256-CTS-HMAC-SHA1-96

Configure os dois lados antes de testar. Se só um lado aceitar AES, a autenticação entre as florestas falha. Para desfazer, use ksetup /delenctypeattr com o nome do domínio. Depois da mudança, rode klist purge na estação de teste e repita o acesso ao FS01. Nos controladores, os eventos 4768 e 4769 do log de segurança mostram qual criptografia foi usada em cada ticket. Para entender o cronograma da Microsoft, veja Beyond RC4 for Windows authentication.

Remover a confiança

Ao fim de uma cisão, de uma migração ou de um contrato com parceiro, a confiança deve ser removida. Antes de remover, liste o que depende dela, como grupos com membros da outra floresta e permissões em pastas, para não deixar entradas órfãs.

Com a credencial do outro lado, um único comando remove as duas metades. No DC01:

$local  = [System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest()

$ctx    = New-Object System.DirectoryServices.ActiveDirectory.DirectoryContext('Forest', 'br-corp.lab', $cred.UserName, $cred.GetNetworkCredential().Password)

$remota = [System.DirectoryServices.ActiveDirectory.Forest]::GetForest($ctx)

$local.DeleteTrustRelationship($remota)

Quando cada lado tem o seu administrador, cada um remove a sua metade. No DC01, use br-corp.lab; no BRDC01, use corp.lab:

$local = [System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest()

$local.DeleteLocalSideOfTrustRelationship('br-corp.lab')

Por fim, limpe o que foi criado para a confiança: o grupo GL_Financeiro_Leitura, as permissões no FS01 e os encaminhadores condicionais de DNS dos dois lados, com o Remove-DnsServerZone mostrado nos pré-requisitos.

Problemas comuns

• "O domínio especificado não existe ou não pôde ser contatado": quase sempre é DNS. Confira os encaminhadores condicionais e o teste do registro SRV nos dois lados.

• "Acesso negado" na criação: a conta não é Enterprise Admin (ou Domain Admin do domínio raiz) na floresta remota, ou o nome de usuário foi informado sem o domínio. Use o formato DOMINIO\usuario.

• Nomes repetidos nas duas florestas: o mesmo nome NetBIOS (por exemplo, CORP dos dois lados) ou o mesmo sufixo UPN impede a confiança de floresta. Esse conflito precisa ser resolvido antes, e é comum em empresas que usaram o mesmo nome padrão.

• Erros de Kerberos com horário (KRB_AP_ERR_SKEW): a diferença de horário entre as florestas passou de 5 minutos. Corrija a fonte de horário dos controladores raiz.

• A confiança é criada, mas o acesso falha: confira as portas dinâmicas de RPC no firewall, se a autenticação seletiva está ativa sem a permissão Allowed to Authenticate, e se os dois lados aceitam AES.

• Funcionava e parou depois de uma atualização: suspeite do RC4. Veja a seção Garantir o uso de AES.

Checklist

• Rede, horário e DNS conferidos nos dois lados, incluindo o registro SRV

• Direção da confiança definida pela regra: quem confia é quem tem os recursos

• Confiança verificada com VerifyOutboundTrustRelationship e nltest /sc_verify

• Acesso concedido por grupos de domínio local, nunca direto ao usuário de fora

• Autenticação seletiva ativa para parceiros e fornecedores

• AES configurado nos dois lados da confiança

• Plano de remoção documentado: o que depende da confiança e quem remove cada metade

Para fechar

A relação de confiança é a ponte entre duas florestas que precisam trabalhar juntas sem se misturar. Com DNS, horário e portas no lugar, ela é criada em poucos comandos, e o controle continua nas suas mãos: a direção decide quem pode receber acesso, os grupos decidem o que cada um acessa, e a autenticação seletiva decide onde cada um pode entrar.

Em uma fusão de verdade, esta é só a primeira etapa. A migração dos objetos para uma floresta única é um projeto próprio, que começa exatamente com a confiança que você acabou de criar.

Para saber mais

• Como funcionam as relações de confiança entre florestas (Microsoft Learn)

• netdom trust (Microsoft Learn)

• Configurar o firewall para domínios e confianças do Active Directory (Microsoft Learn)

• Explore the Active Directory Migration Tool (Microsoft Learn)

• ADMT Guide: Migrating and Restructuring Active Directory Domains (Microsoft)