Você não nos dá detalhes suficientes para responder a essa pergunta com certeza. Por exemplo, você não nos fornece nenhuma informação sobre a natureza exata do tráfego que está sendo bloqueado, que tipo de tráfego é, floresta ou confiança externa, quais portas são permitidas entre membros de cada domínio, como exatamente você está tentando para se conectar ao servidor, (área de trabalho remota? Mapeamento de unidade?), etc. etc.
Eu vou levar uma punhalada de qualquer maneira. Vamos supor que estou tentando usar o cliente da área de trabalho remota para se conectar ao servidor na outra floresta. Portanto, sabemos que pelo menos a porta TCP 3389 deve ser permitida entre o cliente e o servidor.
(Para referência, Este documento é basicamente o bíblia de como o Active Directory usa o Kerberos Um dos melhores artigos do TechNet na Web, IMHO. Aqui está outro artigo TechNet extremamente relevante sobre trusts de AD para você marcar.
Durante a autenticação usando o Kerberos, uma das etapas finais é que o cliente envie seu ticket de serviço e autenticador diretamente para o serviço remoto que está tentando acessar. (KRB_AP_REQ e, em seguida, um KRB_AP_REP opcional de volta do servidor para o cliente). Se isso não pode acontecer porque as portas estão sendo bloqueadas, a autenticação do Kerberos não pode acontecer. Se eu receber uma remessa de TGS do meu CD que me direciona para seu controlador de domínio, e não posso consultar diretamente seu controlador de domínio, não posso usar o Kerberos.
Talvez seja um pouco do tráfego que você está vendo sendo descartado.
Então, o que acontece quando o Kerberos falha? Normalmente, o cliente retorna ao próximo provedor de segurança, por exemplo, NTLM. Você pode passar credenciais protegidas por NTLM para o servidor diretamente na mesma porta 3389. Nesse ponto, o servidor precisa apenas validar suas credenciais. Por favor, consulte a seção chamada "NTLM Referral Processing" no segundo artigo que eu vinculei.
NTLM Referral Processing
If the client uses NTLM for authentication, the initial request for authentication goes directly from the client to the resource server in the target domain. This server creates a challenge to which the client responds. The server then sends the user’s response to a domain controller in its computer account domain. This domain controller checks the user account against its security accounts database. If the account does not exist in the database, the domain controller determines whether to perform pass-through authentication, forward the request, or deny the request by using the following logic:
Does the current domain have a direct trust relationship with the user’s domain?
◦ If yes, the domain controller sends the credentials of the client to a domain controller in the user’s domain for pass-through authentication.
◦ If no, go to the next step.
Does the current domain have a transitive trust relationship with the user’s domain?
◦ If yes, pass the authentication request on to the next domain in the trust path. This domain controller repeats the process by checking the user’s credentials against its own security accounts database.
◦ If no, send the client a logon-denied message.
Então, em última análise, dadas as informações limitadas que você nos forneceu, esse é o processo que acredito que você está testemunhando quando se autentica em um serviço no outro domínio.