Relação de confiança entre florestas: um AD acessando recursos do outro
O vídeo é carregado do YouTube quando você clica em reproduzir.
Como criar uma relação de confiança de floresta bidirecional entre a matriz e uma empresa adquirida, conferir os pré-requisitos de DNS e portas, e testar o acesso a uma pasta da matriz com a conta da adquirida.
Pré-requisitos
- Dois controladores de domínio em florestas diferentes que se enxergam pela rede (aqui, o MCAIT01, do mcait.local, e o MCACLOUD01, do mcacloud.local).
- Nível funcional das duas florestas Windows Server 2003 ou superior.
- Uma conta de administrador em cada floresta (Domain Admins ou Enterprise Admins da raiz).
- Um usuário de teste com acesso e outro sem acesso na floresta adquirida (aqui, a Camila Silva e o José Augusto).
No artigo anterior, as duas empresas passaram a sincronizar para o mesmo tenant, sem relação de confiança entre os ADs. Isso resolve o login na nuvem, mas não o acesso aos recursos locais: um usuário da empresa comprada ainda não consegue abrir uma pasta num servidor da matriz.
É para isso que serve a relação de confiança. Com ela, o AD da matriz passa a aceitar a autenticação feita pelo AD da adquirida, e o usuário acessa os recursos com a própria conta e senha.
Não é só para aquisição. Uso o cenário de uma empresa comprada porque é o fio da série, mas o passo a passo é o mesmo para quaisquer dois ADs que precisem acessar recursos um do outro: duas empresas parceiras, filiais com florestas próprias ou um ambiente de testes e o de produção. Onde aparece matriz, leia “o AD que tem o recurso”; onde aparece adquirida, “o AD que tem a conta”.
A relação não dá permissão sozinha. Ela só permite que a outra floresta se autentique. Quem decide o que cada usuário acessa continuam sendo as permissões de cada pasta ou recurso.
O que precisa estar pronto
Antes de criar a relação, os dois DCs precisam se enxergar, se encontrar pelo nome e conversar pelas portas certas:
| O que precisa | Por quê |
|---|---|
| Rede nos dois sentidos | Cada DC precisa chegar no outro. |
| DNS nos dois sentidos | A relação encontra o DC do outro lado pelo registro SRV. |
| Horário sincronizado | O Kerberos não aceita mais de 5 minutos de diferença entre os servidores. |
| Portas liberadas | DNS (53), Kerberos (88), RPC (135), LDAP (389), SMB (445), troca de senha do Kerberos (464) e catálogo global (3268). Em produção, o RPC também usa as portas dinâmicas (49152–65535). |
Passo a passo
Confira a rede e o nome
No MCACLOUD01, o ping para o IP do MCAIT01 responde, mas o ping pelo nome falha: o DNS da adquirida ainda não sabe onde fica o domínio da matriz.
ping 192.168.68.67
ping mcait01.mcait.local
Crie o encaminhador condicional na adquirida
O MCAIT01 já tem um encaminhador para o mcacloud.local, criado no laboratório das duas redes. Falta o caminho de volta.
No MCACLOUD01, abra Server Manager › Tools › DNS, clique com o botão direito em Conditional Forwarders › New Conditional Forwarder. Em DNS Domain, informe mcait.local e, em IP addresses of the master servers, o IP do MCAIT01 (192.168.68.67).
E o X vermelho? Aparece porque o laboratório não tem zona reversa: o DNS não consegue descobrir o nome do servidor a partir do IP. O encaminhador funciona normalmente, e a própria janela avisa isso no rodapé.
Confira o DNS e o registro SRV (opcional)
No vídeo, a conferência foi o ping pelo nome, que já mostra que o encaminhador funciona. Para ir além, confira também o registro SRV, que é o que a relação de confiança usa para encontrar o controlador de domínio do outro lado. No MCACLOUD01:
Resolve-DnsName mcait.local
nslookup -type=srv _ldap._tcp.dc._msdcs.mcait.local
O “DNS request timed out” no começo do nslookup também vem da falta de zona reversa e não atrapalha a resposta.
Teste as portas
Ainda no MCACLOUD01, teste as portas no MCAIT01. O comando demora alguns minutos, porque cada porta faz também um teste de ping antes:
$portas = 53,88,135,389,445,464,3268
$portas | % { Test-NetConnection 192.168.68.67 -Port $_ -WarningAction 0 } |
ft RemotePort,TcpTestSucceeded
No laboratório não há firewall entre as redes. Numa empresa, essa lista vai para o time de rede.
Crie a relação de confiança
No MCAIT01, abra Server Manager › Tools › Active Directory Domains and Trusts e clique com o botão direito em mcait.local › Properties.
Vá na aba Trusts. As duas listas, de saída e de entrada, ainda estão vazias. Clique em New Trust e, na tela de boas-vindas, em Next.
Em Trust Name, informe o domínio da floresta adquirida, mcacloud.local.
Em Trust Type, escolha Forest trust. A externa liga só um domínio a outro e usa NTLM; a de floresta liga as florestas inteiras, é transitiva e usa Kerberos.
Em Direction of Trust, escolha Two-way: as duas empresas vão acessar recursos uma da outra. Lembre que o acesso vai no sentido contrário da confiança: quem confia é quem tem o recurso.
Em Sides of Trust, escolha Both this domain and the specified domain e informe a conta de administrador da adquirida (MCACLOUD\Administrator). Assim o assistente cria a relação nos dois ADs de uma vez, sem precisar repetir no outro DC.
Em Outgoing Trust Authentication Level, que aparece duas vezes (uma para cada floresta), escolha Forest-wide authentication: os usuários da outra floresta podem se autenticar aqui, e o acesso continua definido pelas permissões. A Selective authentication exige liberar servidor por servidor e vale ser avaliada em produção, quando a outra empresa não é de total confiança.
Avance pelo resumo e responda Yes, confirm em Confirm Outgoing Trust e em Confirm Incoming Trust.
O aviso de sufixo em conflito
Ao terminar, aparece um aviso: a relação foi criada, mas alguns sufixos de nome existem nas duas florestas. É o mcasecurity.com.br, adicionado como sufixo UPN nos dois ADs para o login na nuvem.
O aviso era esperado e não é problema. Como o sufixo está nas duas florestas, o Windows desativa a rota dele entre elas. A autenticação por DOMÍNIO\usuário continua funcionando, e o login na nuvem com @mcasecurity.com.br não muda, nem o Entra Connect. Clique em No para não salvar o log.
Valide a relação
Na aba Trusts, o mcacloud.local aparece nas duas listas, de saída e de entrada. Selecione-o e clique em Properties › Validate. Um Validate só testa os dois sentidos: escolha Yes, validate the incoming trust e informe a conta de administrador da adquirida.
Na pergunta seguinte, sobre atualizar o roteamento de sufixos de nome, responda No. Ela serve para quando entram domínios novos na outra floresta.
Confira do lado da adquirida
No MCACLOUD01, em Active Directory Domains and Trusts › mcacloud.local › Properties › Trusts, o mcait.local aparece nas duas listas. O assistente rodou só no MCAIT01 e criou a relação nos dois ADs.
Na aba Name Suffix Routing, o mcacloud.local está habilitado e o mcasecurity.com.br desabilitado. Não habilite o sufixo em comum: os logins da matriz com esse sufixo passariam a ser enviados para a adquirida.
Testando o acesso
Crie a pasta na matriz
No MCAIT01, crie a pasta C:\Adquirida com um arquivo de texto dentro. Em Properties › Sharing › Advanced Sharing, compartilhe como Adquirida e, em Permissions, remova o Everyone e adicione a usuária da adquirida com Change. Em Locations, o mcacloud.local já aparece: a matriz lê os usuários direto do AD da adquirida, por causa da relação de confiança.
Na aba Security › Advanced, clique em Disable inheritance, converta as permissões herdadas e remova o grupo Users. Depois adicione a mesma usuária com Modify.
Por que remover o Users? Num controlador de domínio, o grupo Users inclui os usuários autenticados. Com a relação de confiança, isso vale também para quem vem da outra floresta. Permissão ampla com relação de confiança é porta aberta.
Teste com quem tem acesso
No MCACLOUD01, simule a sessão da usuária sem precisar entrar numa máquina com ela:
net use \\mcait01.mcait.local\Adquirida /user:MCACLOUD\camila.silva *Abra o caminho \\mcait01.mcait.local\Adquirida no Explorador de Arquivos: a Camila vê o arquivo, abre e salva. Para trocar de usuário, desconecte a sessão e limpe os tickets do Kerberos:
net use * /delete /y
klist purge
Teste com quem não tem acesso
Repita o net use com o José Augusto, que também é da adquirida mas não está nas permissões da pasta. Ele se autentica, mas o acesso é negado.
Esse é o resultado esperado: a relação de confiança deixa a outra floresta se autenticar, e a permissão da pasta decide quem entra.
Resumindo
Com DNS nos dois sentidos, horário sincronizado e as portas liberadas, um único assistente no DC da matriz cria a relação de confiança de floresta nos dois ADs. O usuário da empresa adquirida passa a acessar os recursos da matriz com a própria conta e senha, e o controle continua nas permissões de cada recurso. No próximo vídeo da série, fechamos o ciclo: desativar o Entra Connect e deixar os usuários só na nuvem.
Referência: Understanding When to Create a Forest Trust (Microsoft Learn).
