Não é possível obter a autenticação CredSSP para funcionar no PowerShell

Ao tentar criar um script do PowerShell usando o sistema remoto, deparei-me com o que acredito ser o problema do salto duplo . Nesse artigo, Perriman fornece uma descrição sucinta do problema, bem como as etapas específicas para resolver o problema (quase trivial se você conhece os comandos, mas para alguém menos familiarizado como eu, essa informação era inestimável!).

Eu executei Enable-WSManCredSSP Serverno meu servidor Win7 sem incidentes, mas a tentativa de executar Enable-WSManCredSSP Client –DelegateComputer <FQDN of the server>no meu cliente Win7 gerou este erro:

Enable-WSManCredSSP : The client cannot connect to the destination specified
in the request. Verify that the service on the destination is running and
is accepting requests.
Consult the logs and documentation for the WS-Management service running
on the destination, most commonly IIS or WinRM. If the destination
is the WinRM service, run the following com mand on the destination
to analyze and configure the WinRM service: "winrm quickconfig".

A execução do winrm quickconfig confirmou que meu servidor estava executando o WinRM:

WinRM already is set up to receive requests on this machine.
WinRM already is set up for remote management on this machine.

E Get-WSManCredSSP confirmou que meu servidor estava pronto para aceitar credenciais de um cliente:

The machine is not configured to allow delegating fresh credentials.
This computer is configured to receive credentials from a remote client computer.

Também encontrei o artigo de Boessen sobre o WinRM, em que ele descreve a configuração geral do WinRM e encontrou um petisco para obter um ponto de dados útil no diagnóstico; este comando executado no cliente usa a ferramenta winrs para acessar remotamente o servidor:

winrs -r:http://<FQDN of my server>:5985 -u:<myDomain>\msorens "dir c:\"

Esse comando retornou o resultado esperado, o conteúdo do diretório raiz no servidor, sem incidentes, confirmando que meu FQDN está correto e que o WinRM está ativado.

Boessen indica que a porta 5985 é o padrão para o Win7; este comando executado no servidor confirma um valor de 5985:

get-item wsman:\localhost\listener\listener*\port

A pergunta: Por que não consigo executar o comando Enable-WSManCredSSP no lado do cliente?

2011.06.07 Atualizar

Encontrei uma solução para a pergunta acima: invocar o Enable-PSRemoting , anunciado para configurar um computador para receber comandos remotos, permitiu que o Enable-WSManCredSSP no cliente funcionasse com sucesso! Curioso, mas sua página de manual indica que ele realiza várias ações diferentes, então suponho que um deles tenha feito o que eu precisava inadvertidamente.

Mas, em seguida, cheguei a outro obstáculo quando tentei usar a autenticação CredSSP. Aqui está o comando:

Invoke-Command { Write-Host "hello, world" } -computername $serverName `
-credential $testCred  -Authentication Credssp

E aqui está a resposta:

A conexão ao servidor remoto 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. Use gpedit.msc
e observe a seguinte diretiva: Configuração do Computador
-> Modelos Administrativos -> Sistema -> Delegação de Credenciais
-> Permitir delegar novas credenciais. 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
o seguinte: WSMAN /myserver.domain.com ou WSMAN / *. domain.com.
Para obter mais informações, consulte o tópico da Ajuda about_Remote_Trou Troubleshooting.

Verifiquei as configurações exatamente como sugeriu esta mensagem de erro extremamente útil, e parece-me que ela está configurada corretamente.

A nova pergunta: O que essa conexão remota tenta com o CredSSP falha?

Ao responder, lembre-se do seguinte: Deixe-me dissipar antecipadamente qualquer noção de que eu sei o que estou fazendo aqui, apesar de qualquer aparência em contrário. :-) O administrador do Windows não é minha área de especialização!

Voltei a isso depois de um breve hiato para olhar novamente com novos olhos (tanto meus quanto de um colega de trabalho) e decidi voltar ao básico novamente:

No cliente que eu executei (no shell do administrador):

enable-wsmancredssp -role client -delegatecomputer devremvm03 -force

No servidor que eu executei (no shell do administrador):

enable-wsmancredssp -role server -force

Ambos retornaram a saída normal, indicando que o CredSSP agora era "verdadeiro".

Em seguida, usei o seguinte código do exercitador para percorrer níveis crescentes de complexidade:

$block = {
  Write-Host ("hello, world: {0}, {1}" -f $env:USERNAME, (hostname))
}
$username = "test_user"
$password = "..."   
$adjPwd = $password | ConvertTo-SecureString -asPlainText -Force
$testCred = (New-Object System.Management.Automation.PSCredential($username,$adjPwd))    

switch ($choice)
{
  "basic"       { Invoke-Command $block }
  "remote"      { Invoke-Command $block -computername $serverName }
  "credentialA" { Invoke-Command $block -computername $serverName -credential $testCred  }
  "credentialB" { Invoke-Command $block -computername $serverName -credential $testCred  -Authentication Credssp}
  "session"     { 
      $testSession = New-PSSession -computername $serverName -credential $testCred -Authentication Credssp
      if ($testSession) { Invoke-Command $block -Session $testSession; Remove-PSSession $testSession }
      }
}

Tudo isso está no meu script run.ps1, portanto, a transcrição foi a seguinte (e isso foi executado em um shell não administrador):

PS C:\> .\run.ps1 basic
hello, world: msorens, MyLocalMachine
PS C:\> .\run.ps1 remote MyRemoteServer
hello, world: msorens, MyRemoteServer
PS C:\> .\run.ps1 credentialA MyRemoteServer
hello, world: test_user, MyRemoteServer
PS C:\> .\run.ps1 credentialB MyRemoteServer
hello, world: test_user, MyRemoteServer
PS C:\> .\run.ps1 session MyRemoteServer
hello, world: test_user, MyRemoteServer

Anteriormente, apenas básico, remoto e credencialA funcionavam. Agora todos os 5 funcionam. Ufa!

Quando precisei fazer isso, foi o que fiz para fazê-lo funcionar (também pode ter havido algumas configurações de GPO, mas parece que você as cobre).

Para permitir que o CLIENTE use CredSSP para conectar-se a qualquer máquina no domínio:

Enable-WSManCredSSP -Role Client -DelegateComputer "*.my.domain.com" -Force | out-null
#the following is used because -delegatecomputer (above) doesn't appear to actually work properly.
Set-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\Credssp\PolicyDefaults\AllowFreshCredentialsDomain -Name WSMan -Value "WSMAN/*.my.domain.com"

Em seguida, executei o seguinte em cada máquina de destino (servidor) para habilitar a autenticação CredSSP:

Connect-WSMan -ComputerName $computer 
Set-Item "WSMAN:\$computer\service\auth\credssp" -Value $true 

Obviamente, isso exige que você esteja executando o script com as permissões apropriadas. Isso funcionou para mim - espero que ajude você.

Cheguei onde eu poderia viver, migrar uma VM de um servidor hyper-v 2012R2 para outro, mas não consegui migrá-la de volta. (Estou tentando usar o SAMBA 4.2 como meu controlador de domínio e queria ver se eu poderia migrar ao vivo com CredSSP porque não podia usar delegação restrita com o Samba4).

Por fim, fui ao hyper-trabalho em funcionamento e copiei as entradas do registro em hklm: \ SOFTWARE \ Policies \ Microsoft \ Windows \ CredentialsDelegation para o hyper-funcionamento que não funciona. Funcionou bem nos dois sentidos depois disso.