Gerenciamento Remoto do Windows sobre Domínios Não Confiáveis

Question

No momento, estou tentando habilitar o Gerenciamento Remoto do Windows (especificamente, o Powershell Remoting) entre dois domínios não confiáveis e não ter sorte.

Uma breve descrição da minha configuração:

• domain1 - minha estação de trabalho está neste domínio
• domain2 - o servidor ao qual desejo me conectar está neste domínio

Não há confiança entre esses domínios.

Estou tentando criar a conexão remota Powershell usando os seguintes comandos da minha estação de trabalho (unidos ao domínio1):

param (
    [Parameter(Mandatory=$True)]
    $server
)

$username = "domain\user"
$password = read-host "Enter Password for $username" -AsSecureString

$credential = New-Object System.Management.Automation.PSCredential($username, $password)

$session = New-PSSession "$server" -Authentication CredSSP -Credential $credential -UseSSL -SessionOption (New-PSSessionOption -SkipCACheck -SkipCNCheck)
Enter-PSSession $session

O que resulta na seguinte mensagem de erro:

New-PSSession : [computername.domain2.com] Connecting to remote server computername.domain2.com failed with the following error message : The WinRM client
cannot process the request. A computer policy does not allow the delegation of the user credentials to the target computer because the computer is not trusted. The identity of the target
computer can be verified if you configure the WSMAN service to use a valid certificate using the following command: winrm set winrm/config/service '@{CertificateThumbprint=""}'  Or
you can check the Event Viewer for an event that specifies that the following SPN could not be created: WSMAN/. If you find this event, you can manually create the SPN using
setspn.exe .  If the SPN exists, but CredSSP cannot use Kerberos to validate the identity of the target computer and you still want to allow the delegation of the user credentials to the target
computer, use gpedit.msc and look at the following policy: Computer Configuration -> Administrative Templates -> System -> Credentials Delegation -> Allow Fresh Credentials with NTLM-only
Server Authentication.  Verify that it is enabled and configured with an SPN appropriate for the target computer. For example, for a target computer name "myserver.domain.com", the SPN can be
one of the following: WSMAN/myserver.domain.com or WSMAN/*.domain.com. Try the request again after these changes. For more information, see the about_Remote_Troubleshooting Help topic.

Eu tentei / verifiquei o seguinte:

1. Verifiquei que existe um SPN para ambos WSMAN \ computername & WSMAN \ computername.domain2.com no domínio2.
2. Verificado essa configuração do computador - > Modelos Administrativos - > Sistema - > Delegação de credenciais - > Permitir credenciais novas apenas com NTLM A autenticação do servidor foi definida corretamente.
3. Configurado winrm no computador de destino para usar ssl.
4. Configure o CredSSP no computador de destino e minha estação de trabalho local usando os seguintes comandos:

Enable-WSManCredSSP -Role Server #on the target computer
Enable-WSManCredSSP -Role Client -DelegateComputer * -Force

5. Confirmei que nenhuma regra de FW, local para os computadores ou para a rede, está bloqueando meu acesso.

Nenhuma delas me permitiu conectar com êxito ao computador de destino no domínio2 da estação de trabalho no domínio1. Eu posso conectar com êxito a outros servidores que estão associados ao domínio1, mas não aos servidores no domínio2. Há mais alguma coisa que eu deveria estar procurando e / ou tentar fazer com que isso funcione?

ATUALIZAÇÃO 06/08/2015 Na verdade, consegui verificar se posso conectar-me ao servidor a partir da minha estação de trabalho sem usar o CredSSP, o que seria ótimo; no entanto, eu preciso ser capaz de executar scripts contra o SharePoint, e fazê-lo sem o CredSSP falhar com um erro de permissões.

    

Answer 1

Este artigo MSDN mostra como configurar o WinRM para vários Suporte à loja que também aborda a criação de conexões quando o Kerberos não é uma opção. Breve resumo abaixo.

Windows Remote Management (WinRM) supports the delegation of user credentials across multiple remote computers. The multi-hop support functionality can now use Credential Security Service Provider (CredSSP) for authentication. CredSSP enables an application to delegate the user's credentials from the client computer to the target server.

CredSSP authentication is intended for environments where Kerberos delegation cannot be used. Support for CredSSP was added to allow a user to connect to a remote server and have the ability to access a second-hop machine, such as a file share.

Especificamente, a seção no artigo referente à Entrada de Registro / Configuração de Diretiva de Grupo AllowFreshCredentialsWhenNTLMOnly solucionou o problema que eu estava tendo. Do artigo:

If neither Kerberos authentication nor certificate thumbprints are available, the user can enable NTLM authentication. If NTLM authentication is used, the Allow Fresh Credentials with NTLM-only Server Authentication (AllowFreshCredentialsWhenNTLMOnly) policy must be enabled, and an SPN with the WSMAN prefix must be added to the policy. This setting is less secure than both Kerberos authentication and certificate thumbprints, because credentials are sent to an unauthenticated server.

For more information about the AllowFreshCredentialsWhenNTLMOnly policy, see the policy description provided by the Group Policy editor and KB 951608. The AllowFreshCredentialsWhenNTLMOnly policy is located at the following path: Computer Configuration\Administrative Templates\System\Credentials Delegation.