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

Question

Ao tentar criar um script do PowerShell usando o remoting, encontrei o que acredito ser o problema de salto duplo . Nesse artigo, Perriman dá uma descrição sucinta do problema, bem como os passos específicos 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 Server no meu servidor Win7 sem incidentes, mas a tentativa de executar Enable-WSManCredSSP Client –DelegateComputer <FQDN of the server> no meu cliente Win7 gerou esse 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 o 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 sobre o WinRM de Boessen, no qual 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?

Atualização de 2011.06.07

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 para trabalhar com sucesso! Curioso, mas a sua página de manual indica que ele realiza várias ações diferentes, então presumo que uma delas aqueles que, inadvertidamente, fizeram o que eu precisava.

Mas depois 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:

Connecting to remote server 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. Use gpedit.msc
and look at the following policy: Computer Configuration
-> Administrative Templates -> System -> Credentials Delegation
-> Allow Delegating Fresh Credentials.  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.
For more information, see the about_Remote_Troubleshooting Help topic.

Eu verifiquei as configurações exatamente como essa mensagem de erro notavelmente útil sugeriu, e parece que ela está configurada corretamente.

A nova pergunta: O que esta tentativa de conexão remota com o CredSSP falha?

Ao responder, lembre-se do seguinte: Deixe-me explicar antecipadamente qualquer noção de que eu saiba o que estou fazendo aqui, qualquer que seja a aparência contrária, não obstante :-) O administrador do Windows não é minha área de especialização!

    

Answer 1

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

No cliente que 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".

Depois, usei o seguinte código de exercitador para percorrer os 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, então a transcrição foi a seguinte (e isso foi executado em um shell não -administrator):

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 funcionava o básico, remoto e credencialA. Agora todos os 5 trabalhos. Ufa!

    

Answer 2

Quando tive que fazer isso, isso foi o que fiz para que funcionasse (também pode ter havido algumas configurações de GPO, mas parece que você as abordou).

Para permitir que o CLIENTE use o 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 ativar a autenticação CredSSP:

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

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

    

Answer 3

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

Por fim, fui ao hyper-v de trabalho e copiei as entradas de registro em hklm: \ SOFTWARE \ Policies \ Microsoft \ Windows \ CredentialsDelegation para o hyper-v não funcional. Trabalhou bem em ambos os sentidos depois disso.