Então, eu tenho duas florestas, vamos chamá-lasalfa.exemplo.comebravo.exemplo.com. Os nomes NETBIOS dos domínios são ALPHA e BRAVO, respectivamente. Isso parece implicar que não há problema com a nomenclatura do domínio, eles têm dois nomes diferentes, tanto no DNS quanto no NETBIOS.
Tenho os seguintes servidores como controladores de domínio:
- dc01.alpha.example.com
- dc02.alpha.example.com
- dc01.bravo.exemplo.com
Quando tento estabelecer uma confiança de floresta entre ALPHA e BRAVO dessa forma, recebo "Nenhum servidor de logon disponível para atender à solicitação de logon" quando se trata de realmente verificar a confiança. encontreialguns tópicos do fórumonline, bem como ouvi algumas evidências anedóticas de que há problemas ao conectar dois domínios onde há os mesmos nomes para os controladores de domínio em ambos os domínios. Isso não parece fazer sentido para mim e parece ser um bug nas ferramentas da Microsoft.
Não achei que isso fosse um problema, já que dc01.alpha.example.com e dc01.bravo.example.com são obviamente duas máquinas diferentes, mas o Windows não parece concordar comigo.
Estou faltando alguma informação que me permitiria fazer essa configuração funcionar? Infelizmente, renomear os controladores de domínio é uma resposta ruim para nós, porque o resultado final é conectar muitas florestas com controladores de domínio com o mesmo nome. Isso significaria renomear vários DC:s.
Para que conste, renomear um dos controladores de domínio me permite estabelecer uma confiança, mas eu realmente não quero ter que fazer isso no mundo real, se puder evitar.
Todas as máquinas no laboratório estão executando o Windows Server 2012 R2 com patches atualizados, mas sem hotfixes especiais instalados.
O DNS é configurado da seguinte maneira: no domínio ALPHA, uma zona stub é adicionada para bravo.example.com, apontando para o endereço IP de dc01.bravo.example.com. Por sua vez, dc01.bravo.example.com usa dc01.alpha.example.com e dc01.bravo.example.com como DNS upstream. É uma configuração um pouco hackeada (porque é um laboratório ...), mas o resultado é uma resolução de DNS correta em ambos os sentidos. dc01.bravo.example.com pode resolver nomes em bravo.example.com (porque é autoritativo) e os nomes alpha.exaple.com são resolvidos corretamente porque o DNS upstream é autoritativo para ele. Os resolvedores em alfa podem resolver os nomes do bravo corretamente por causa da zona de stub (que é adicionada ao AD para que ambos os servidores DNS o obtenham).
Eu também tentei:
- Mudando de uma zona de stub para um encaminhador condicional
- Executando um trust florestal em vez de um trust externo
Nenhuma alteração nos sintomas.
Responder1
Seus problemas se devem ao que é chamado de roteamento de sufixo de nome. O artigo a seguir descreve o problema: https://technet.microsoft.com/en-us/library/cc784334%28v=ws.10%29.aspx Afirma que o netdom pode ser usado para resolver o problema.
O artigo afirma em parte
Roteando sufixos de nomes entre florestas
O roteamento de sufixo de nome é um mecanismo usado para gerenciar como as solicitações de autenticação são roteadas entre florestas do Windows Server 2003 unidas por relações de confiança de floresta. Para simplificar a administração de solicitações de autenticação, quando uma confiança de floresta é criada inicialmente, todos os sufixos de nomes exclusivos são roteados por padrão. Um sufixo de nome exclusivo é um sufixo de nome dentro de uma floresta, como um sufixo de nome principal de usuário (UPN), sufixo de nome principal de serviço (SPN) ou floresta DNS ou nome de árvore de domínio, que não está subordinado a nenhum outro sufixo de nome. Por exemplo, o nome da floresta DNS microsoft.com é um sufixo de nome exclusivo na floresta microsoft.com.
As florestas podem conter vários sufixos de nomes exclusivos e todos os filhos de sufixos de nomes exclusivos são roteados implicitamente. Em domínios e relações de confiança do Active Directory, os sufixos de nome aparecem com um asterisco (*) no início por causa disso. Por exemplo, se a sua floresta utiliza.microsoft.com como um sufixo de nome exclusivo e, em seguida, solicitações de autenticação para todos os filhos de microsoft.com (.child.microsoft.com) serão roteados porque os domínios filho fazem parte do sufixo do nome microsoft.com.
Se existir uma confiança de floresta entre duas florestas, os sufixos de nome que não existem em uma floresta poderão ser usados para rotear solicitações de autenticação para uma segunda floresta. Quando um novo sufixo de nome filho (.child.widgets.com) é adicionado a um sufixo de nome exclusivo (.widgets.com), o sufixo do nome filho herdará a configuração de roteamento do sufixo do nome exclusivo ao qual pertence. Quaisquer novos sufixos de nome exclusivos criados após o estabelecimento de uma confiança de floresta ficarão visíveis na caixa de diálogo Propriedades da confiança de floresta após a verificação da confiança. No entanto, o roteamento para esses novos sufixos de nomes exclusivos será desabilitado por padrão. Para obter mais informações sobre como verificar uma relação de confiança, consulte Verificar uma relação de confiança.
Quando um sufixo de nome duplicado for detectado, o roteamento para o sufixo de nome mais recente será desabilitado por padrão. Para obter mais informações sobre como rotear sufixos de nome, consulte Habilitar ou desabilitar um sufixo de nome existente do roteamento. Os administradores podem usar a caixa de diálogo Propriedades de confiança da floresta para impedir manualmente que solicitações de autenticação para sufixos de nomes específicos sejam roteadas para uma floresta.
Notas • Não adicione o sinal @ ao sufixo UPN ou a um nome de usuário. Quando as solicitações de autenticação são roteadas para uma floresta confiável, todos os caracteres antes do primeiro símbolo @ são interpretados como o nome de usuário e tudo após o primeiro símbolo @ como o sufixo UPN.
• A autoridade de segurança local (LSA) bloqueará o roteamento para qualquer sufixo UPN que não seja um nome DNS válido. Por exemplo, adicionar um símbolo @ a um sufixo UPN fará com que ele seja desativado automaticamente.