PowerShell remoting com uma confiança unidirecional

Question

Minha pergunta é semelhante a Powershell Remoting: Confiança unidirecional , no entanto, há diferenças e a resolução (somando o servidor para a lista confiável) não funciona para mim.

Cenário:
Eu tenho dois domínios. DOMAIN e DOMAINDMZ. DOMAIN tem uma confiança de entrada de DOMAINDMZ. Isso é DOMAINDMZ confia em DOMAIN, mas não vice-versa.

Eu tenho um usuário administrativo DOMAIN\myadmin que é membro do grupo local Administradores em vários servidores no domínio DOMAINDMZ: servera.domaindmz.com , serverb.domaindmz.com , serverc.domaindmz.com , etc. Eu posso fazer login nesses servidores com DOMAIN \ myadmin do console ou RDP.

Estou tentando fazer login no SERVERA e executar um script do PowerShell no SERVERB usando o controle remoto do PowerShell. O Gerenciamento Remoto está habilitado no SERVERB. Eu inicio uma sessão elevada do PowerShell no SERVERA e, em seguida, tento usar o cmdlet Invoke-Command . Eu recebo o seguinte erro:

PS C:\Windows\system32> Invoke-Command -ComputerName serverb.domaindmz.com -ScriptBlock {hostname}    
[serverb.domaindmz.com] Connecting to remote server failed with the following error message : WinRM cannot process the request. The following error occured while using Kerberos authentication: The network path was not found.
     Possible causes are:
      -The user name or password specified are invalid.
      -Kerberos is used when no authentication method and no user name are specified.
      -Kerberos accepts domain user names, but not local user names.
      -The Service Principal Name (SPN) for the remote computer name and port does not exist.
      -The client and remote computers are in different domains and there is no trust between the two domains.
     After checking for the above issues, try the following:
      -Check the Event Viewer for events related to authentication.
      -Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport.
     Note that computers in the TrustedHosts list might not be authenticated.
       -For more information about WinRM configuration, run the following command: winrm help config. For more information, see the about_Remote_Troubleshooting Help topic.
        + CategoryInfo          : OpenError: (:) [], PSRemotingTransportException
        + FullyQualifiedErrorId : PSSessionStateBroken

Se eu fornecer um objeto de credencial contendo um usuário no domínio DOMAINDMZ, o erro desaparece e o scriptblock é executado como esperado:

PS C:\Windows\system32> Invoke-Command -ComputerName serverb.domaindmz.com -Credential DOMAINDMZ\Administrator -ScriptBlock {hostname}
SERVERB

Pergunta:
Dado o erro, suspeito que o problema esteja relacionado à confiança e ao Kerberos, mas não estou claro o que posso fazer para resolver. Devo estar configurando um SPN para DOMAIN \ myadmin ou SERVERB? Há algo mais que eu possa tentar?

    

Answer 1

Como Joeqwerty disse, geralmente é aceito que você usará a autenticação NTLM com uma confiança externa e Kerberos com uma confiança de floresta.

No entanto, é possível obter a autenticação Kerberos funcionando com um domínio externo, mas há condições.

A confiança deve ser criada usando o nome de domínio totalmente qualificado (FQDN). A referência de Kerberos falha se o FQDN estiver ausente no objeto de domínio confiável.

A sintaxe do nome de usuário é UPN e o sufixo UPN pode ser resolvido para um DC no DNS (UPN implícito)

As portas UDP 389, UDP / TCP 88 e UDP / TCP 464 estão abertas para os controladores de domínio no domínio do usuário.

O nome do servidor no domínio de recursos confiante deve ser o FQDN, e o sufixo de domínio do nome do servidor deve corresponder ao FQDN de DNS do domínio do AD DS.

Se ainda estiver causando azia depois disso, recomendo mudar para Negotiate authentication protected with SSL.

Algumas leituras / referências adicionais:

link

link