Logons de domínio filho para domínios de confiança de floresta cruzada

Acredito que o que você está vendo na caixa suspensa "Fazer logon em" em um membro do Domínio C seja um comportamento normal. Essa caixa suspensa mostrará apenas os domínios adjacentes (o transitivo não conta), mas isso não deve impedir que você faça login em um membro do DomainC com um nome de usuário DomainA\joeqwerty ou joeqwerty@DomainA. Se for muito importante para você ver o DomainA na caixa suspensa quando estiver em um computador no DomainC, você poderá conseguir isso com um atalho de confiança.

Este documento contém algumas boas pepitas de sabedoria:

http://technet.microsoft.com/en-us/library/cc773178(v=WS.10).aspx

Tal como,

Confiar nos limites de pesquisa

Quando um cliente procura um caminho de confiança, a pesquisa é limitada a relações de confiança estabelecidas diretamente com um domínio e aquelas que são transitivas dentro de uma floresta. Um domínio filho, por exemplo, não pode usar uma confiança externa entre seu domínio pai e um domínio em outra floresta. Isso ocorre porque um caminho de confiança completo deve ser construído antes que um cliente possa começar a trabalhar ao longo do caminho para um domínio de recurso solicitado. O Windows Server 2003 não oferece suporte a referências cegas; se um cliente não puder identificar um caminho confiável, ele não tentará acessar um recurso solicitado em outro domínio. Domínios filhos não podem identificar confianças externas ou confianças de realm para autoridades de segurança fora de sua floresta porque os TDOs que representam essas relações de confiança são publicados apenas dentro do domínio que compartilha a confiança, não para Catálogos Globais. Os clientes, portanto, não têm conhecimento das relações de confiança que seus domínios compartilham com autoridades de segurança que não sejam seus domínios pai ou filho e, portanto, não podem usá-los para acessar recursos.

Editar

Com base na sua edição:

por exemplo, se eu quiser adicionar um usuário do domínio C ao grupo Remote Desktop Users Domain Local no domínio AI, não posso chegar lá porque não vejo o domínio C em locais no domínio A.

Isso pode ser pedante, mas eu pessoalmente não adicionaria um usuário ao grupo Remote Desktop Users Domain Local. Eu apenas aninharia grupos de segurança lá, não usuários/contas individuais. Os artigos do TechNet vinculados abaixo também recomendam o uso e o aninhamento de grupos de segurança de controle de acesso baseado em função como prática recomendada, em vez de atribuir permissões para indivíduos a recursos.

De qualquer forma, no link do TechNet abaixo:

• Grupos com escopo local de domínio podem ter os seguintes membros: contas, grupos com escopo universal e grupos com escopo global, todos de qualquer domínio. Este grupo também pode ter como membros outros grupos com escopo local de domínio dentro do mesmo domínio.

E,

Para agrupar os usuários de uma floresta que requerem acesso semelhante aos mesmos recursos em uma floresta diferente, crie grupos universais que correspondam às funções do grupo global. Por exemplo, em ForestA, crie um grupo universal chamado SalesAccountsOrders e adicione os grupos globais SalesOrder e AccountsOrder ao grupo.

Duas outras coisas a serem lembradas que podem ajudá-lo a atingir essa meta são Grupos restritos de política de grupo para adicionar o grupo desejado a Usuários de área de trabalho remota e o direito de usuário "Permitir logon por meio de serviços de terminal".

Talvez você não consiga navegar graficamente pelas contas na outra floresta por meio de uma confiança transitiva, mas apenas digite o nome da conta totalmente qualificado, por exemplo , [email protected]ou DomainA\GroupInDomainA, etc.

Mais recursos:

http://technet.microsoft.com/en-us/library/cc772808(v=WS.10).aspx

http://technet.microsoft.com/en-us/library/cc776499(v=ws.10).aspx