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


12

Atualmente, estou tentando habilitar o Gerenciamento Remoto do Windows (especificamente, o Powershell Remoting) entre dois domínios não confiáveis ​​e sem 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 do Powershell usando os seguintes comandos da minha estação de trabalho (ingressada no domínio1):

param (
    [Parâmetro (obrigatório = $ True)]
    $ server
)

$ nome_de_usuário = "domínio \ usuário"
$ password = read-host "Digite a senha para $ username" -AsSecureString

$ credential = Novo-objeto System.Management.Automation.PSCredential ($ nome de usuário, $ senha)

$ session = New-PSSession "$ server" -Autenticação CredSSP -Credential $ credencial -UseSSL -SessionOption (Nova-PSSessionOption -SkipCACheck -SkipCNCheck)
Sessão Enter-PSSession $

O que resulta na seguinte mensagem de erro:

New-PSSession: [computername.domain2.com] A conexão ao servidor remoto computername.domain2.com falhou com a seguinte mensagem de erro: O cliente WinRM
não pode processar a solicitação. Uma política de computador não permite a delegação das credenciais do usuário no computador de destino porque o computador não é confiável. A identidade do alvo
o computador pode ser verificado se você configurar o serviço WSMAN para usar um certificado válido usando o seguinte comando: winrm set winrm / config / service '@ {CertificateThumbprint = ""}' Ou
você pode verificar o Event Viewer para um evento que especifique que o seguinte SPN não pôde ser criado: WSMAN /. Se você encontrar esse evento, poderá criar manualmente o SPN usando
setspn.exe. Se o SPN existir, mas o CredSSP não puder usar o Kerberos para validar a identidade do computador de destino e você ainda deseja permitir a delegação das credenciais do usuário no destino.
computador, use gpedit.msc e observe a seguinte diretiva: Configuração do Computador -> Modelos Administrativos -> Sistema -> Delegação de Credenciais -> Permitir Novas Credenciais com Somente NTLM
Autenticação de servidor. Verifique se está ativado e configurado com um SPN apropriado para o computador de destino. Por exemplo, para um nome de computador de destino "myserver.domain.com", o SPN pode ser
um dos seguintes: WSMAN / myserver.domain.com ou WSMAN / *. domain.com. Tente a solicitação novamente após essas alterações. Para obter mais informações, consulte o tópico da Ajuda about_Remote_Trou Troubleshooting.

Eu tentei / verifiquei o seguinte:

  1. Eu verifiquei que existe um SPN para o WSMAN \ nome_do_computador e WSMAN \ nome_do_computador.domínio2.com no domínio2.
  2. Verificou que Configuração do computador -> Modelos administrativos -> Sistema -> Delegação de credenciais -> Permitir credenciais novas com autenticação de servidor somente NTLM foi definida corretamente.
  3. Winrm configurado no computador de destino para usar ssl.
  4. Configurei o CredSSP no computador de destino e na minha estação de trabalho local usando os seguintes comandos:
Servidor de função Enable-WSManCredSSP #no computador de destino
Enable-WSManCredSSP -Role Client -DelegateComputer * -Force
  1. Eu verifiquei que nenhuma regra do FW, local para os computadores ou a rede, está bloqueando meu acesso.

Nada disso me permitiu conectar com êxito ao computador de destino no domínio2 da minha estação de trabalho no domínio1. Posso conectar-me com sucesso a outros servidores ingressados ​​no domínio1, mas não nos servidores do domínio2. Há algo mais que eu deva procurar e / ou tentar fazer com que isso funcione?

ATUALIZAÇÃO 06/08/2015 Na verdade, consegui verificar se consigo me conectar ao servidor da minha estação de trabalho sem usar o CredSSP, o que seria bom; no entanto, preciso executar scripts no SharePoint e fazê-lo sem o CredSSP falhará com um erro de permissão.


Você já tentou ser mais específico sobre o que está delegando suas credenciais? Por exemplo Enable-WSManCredSSP -Role Client -DelegateComputer WSMAN/computername.domain2.com( msdn.microsoft.com/en-us/library/ee309365(v=vs.85).aspx , ponto 3.)
John

Há também o seguinte: serverfault.com/questions/277573/...
john

Infelizmente, nenhuma dessas sugestões funcionou.
Nick DeMayo


1
Oooo! Encontrei a resposta no artigo que você vinculou também. Eu tentei na configuração anterior "AllowFreshCredentialsDomain" ter um SPN, mas isso não funcionou. Acontece que eu poderia definir "AllowFreshCredentialsWhenNTLMOnly" e "AllowFreshCredentialsWhenNTLMOnlyDomain" e funciona! user2320464, se você puder postar seu comentário como resposta, eu o aceitarei e você receberá a recompensa!
Nick DeMayo

Respostas:


2

Este artigo do MSDN mostra como configurar o WinRM para suporte multi-hop, que também trata de fazer conexões quando o Kerberos não é uma opção. Breve resumo abaixo.

O Gerenciamento Remoto do Windows (WinRM) oferece suporte à delegação de credenciais de usuário em vários computadores remotos. A funcionalidade de suporte multi-hop agora pode usar o CredSSP (Credential Security Service Provider) para autenticação. O CredSSP permite que um aplicativo delegue as credenciais do usuário do computador cliente para o servidor de destino.

A autenticação CredSSP destina-se a ambientes em que a delegação Kerberos não pode ser usada. Foi adicionado suporte ao CredSSP para permitir que um usuário se conecte a um servidor remoto e tenha a capacidade de acessar uma máquina de segundo salto, como um compartilhamento de arquivo.

Especificamente, a seção no artigo referente à Entrada de Registro / Configuração de Diretiva de Grupo AllowFreshCredentialsWhenNTLMOnovo problema foi resolvido. Do artigo:

Se nem a autenticação Kerberos nem as impressões digitais de certificado estiverem disponíveis, o usuário poderá habilitar a autenticação NTLM. Se a autenticação NTLM for usada, a política Permitir credenciais recentes com autenticação de servidor somente NTLM (AllowFreshCredentialsWhenNTLMOnly) deverá ser ativada e um SPN com o prefixo WSMAN deverá ser adicionado à política. Essa configuração é menos segura que as impressões digitais de autenticação e certificado Kerberos, porque as credenciais são enviadas para um servidor não autenticado.

Para obter mais informações sobre a política AllowFreshCredentialsWhenNTLMOnly, consulte a descrição da política fornecida pelo editor de Diretiva de Grupo e pela KB 951608. A política AllowFreshCredentialsWhenNTLMOnly está localizada no seguinte caminho: Configuração do Computador \ Modelos Administrativos \ System \ Credentials Delegation.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.