No se puede lograr que la autenticación CredSSP funcione en PowerShell

Al intentar crear un script de PowerShell usando la comunicación remota, me encontré con lo que creo que es el problema del doble salto . En ese artículo, Perriman da una descripción sucinta del problema, así como los pasos específicos para resolver el problema (casi trivial si conoce los comandos, pero para alguien menos familiar como yo, ¡esa información fue invaluable!).

Ejecuté Enable-WSManCredSSP Serveren mi servidor Win7 sin incidentes, pero intentar ejecutar Enable-WSManCredSSP Client –DelegateComputer <FQDN of the server>en mi cliente Win7 generó este error:

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".

Ejecutar winrm quickconfig confirmó que mi servidor estaba ejecutando WinRM:

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

Y Get-WSManCredSSP confirmó que mi servidor estaba listo para aceptar credenciales de un cliente:

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

También encontré el artículo de Boessen sobre WinRM en el que describe la configuración general de WinRM y encontré un tidbit para obtener un punto de datos útil en el diagnóstico; Este comando ejecutado en el cliente utiliza la herramienta winrs para acceder de forma remota al servidor:

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

Ese comando devolvió el resultado esperado, el contenido del directorio raíz en el servidor, sin incidentes, confirmando que mi FQDN es correcto y que WinRM está habilitado.

Boessen indica que el puerto 5985 es el predeterminado para Win7; Este comando ejecutado en el servidor confirma un valor de 5985:

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

La pregunta: ¿Por qué no puedo ejecutar el comando Enable-WSManCredSSP en el lado del cliente?

2011.06.07 Actualizar

Encontré una solución a la pregunta anterior: invocar Enable-PSRemoting , anunciado para configurar una computadora para recibir comandos remotos, ¡permitió que Enable-WSManCredSSP en el cliente funcionara con éxito! Curioso, pero su página de manual indica que realiza una serie de acciones diferentes, por lo que supongo que uno de ellos hizo lo que necesitaba sin darse cuenta.

Pero luego llegué a otro obstáculo cuando intenté usar la autenticación CredSSP. Aquí está el comando:

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

Y aquí está la respuesta:

La conexión al servidor remoto falló con el siguiente mensaje de error:
El cliente WinRM no puede procesar la solicitud. Una política informática no permite
la delegación de las credenciales de usuario a la computadora de destino. Use gpedit.msc
y mire la siguiente política: Configuración de la computadora
-> Plantillas administrativas -> Sistema -> Delegación de credenciales
-> Permitir delegar nuevas credenciales. Verifique que esté habilitado y
configurado con un SPN apropiado para la computadora de destino. Por ejemplo,
para un nombre de computadora de destino "myserver.domain.com", el SPN puede ser uno de
lo siguiente: WSMAN /myserver.domain.com o WSMAN / *. domain.com.
Para obtener más información, consulte el tema de ayuda about_Remote_Troubleshooting.

Verifiqué la configuración tal como lo sugirió este mensaje de error notablemente útil, y me parece que está configurada correctamente.

La nueva pregunta: ¿Qué falla este intento de conexión remota con CredSSP?

Al responder, tenga en cuenta lo siguiente: Permítame disipar de antemano cualquier noción de que sé lo que estoy haciendo aquí, a pesar de cualquier apariencia en contrario. :-) ¡El administrador de Windows no es mi área de especialización!

Volví a esto después de una breve pausa para volver a mirar con ojos nuevos (tanto los míos como los compañeros de trabajo) y decidí volver a lo básico nuevamente:

En el cliente que ejecuté (en el shell del administrador):

enable-wsmancredssp -role client -delegatecomputer devremvm03 -force

En el servidor que ejecuté (en el shell del administrador):

enable-wsmancredssp -role server -force

Ambos devolvieron la salida normal indicando que CredSSP ahora era "verdadero".

Luego usé el siguiente código de ejercicio para caminar a través de niveles crecientes de complejidad:

$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 }
      }
}

Todo eso está en mi script run.ps1, por lo que la transcripción fue la siguiente (y esto se ejecutó en un shell no 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, solo funcionaba básica, remota y credencial. Ahora los 5 funcionan. ¡Uf!

Cuando tuve que hacer esto, esto es lo que hice para que funcionara (también puede haber algunas configuraciones de GPO, pero parece que las tienes cubiertas).

Para permitir que el CLIENTE use CredSSP para conectarse a cualquier máquina en el dominio:

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"

Luego ejecuté lo siguiente en cada máquina de destino (servidor) para habilitar la autenticación CredSSP:

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

Por supuesto, esto requiere que esté ejecutando el script con los permisos adecuados. Esto funcionó para mí, espero que te ayude.

Llegué a donde podía vivir migrar una VM de un servidor Hyper-v 2012R2 a otro, pero no pude volver a migrar. (Estoy tratando de usar SAMBA 4.2 como mi controlador de dominio y quería ver si podía vivir la migración con CredSSP ya que no podía usar la delegación restringida con Samba4).

Finalmente, fui al hyper-v que funcionaba y copié las entradas del registro en hklm: \ SOFTWARE \ Policies \ Microsoft \ Windows \ CredentialsDelegation al hyper-v que no funciona. Funcionó bien en ambos sentidos después de eso.