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

10

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!

Michael Sorens
fuente
¡Sin embargo, otro ejemplo enloquecedor de que la EM cambia las cosas por el simple hecho de cambiarlo! No estoy interesado en la migración en vivo ni nada de eso, solo quiero poder iniciar sesión en los 3 servidores Hyper-V 2012 que tengo y crear / eliminar / iniciar / detener / reiniciar máquinas virtuales en ellos, funcionó perfectamente desde mi escritorio WIn7, ahora estoy en win 10 y tengo que saltar a través de los aros hacia la izquierda y el centro para hacer algo que antes era simple, Windows 10 actualmente me está volviendo loco: - /
shawty

Respuestas:

8

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!

Michael Sorens
fuente
CredSSP es una buena solución? Microsoft dice: Precaución: la autenticación del proveedor de servicios de seguridad de credenciales (CredSSP), en la que las credenciales del usuario se pasan a una computadora remota para autenticarse, está diseñada para comandos que requieren autenticación en más de un recurso, como acceder a un recurso compartido de red remoto. Este mecanismo aumenta el riesgo de seguridad de la operación remota. Si la computadora remota se ve comprometida, las credenciales que se le pasan pueden usarse para controlar la sesión de red.
Kiquenet
2

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.

jbsmith
fuente
Gracias por la sugerencia, pero todavía falló con el mismo resultado.
Michael Sorens
No estoy seguro de si esto hace la diferencia, pero mi publicación original puede haber sido engañosa. Ejecuté todos estos comandos desde la máquina CLIENTE . Así "$ ordenador" en el segundo bloque de código anterior era el nombre del servidor que yo estaba tratando de conectar A .
jbsmith
Lo había descubierto de alguna manera porque no tenía sentido que el servidor tuviera que conocer a priori a los clientes. Sin embargo, solo volví a repetir la secuencia completa para estar seguro, y falla con el mismo error. Otra variación: omití el parámetro -Authentication y confirmó que todo lo demás en mi declaración funciona ( Invoke-Command { Write-Host "hello, world" } -computername $serverName -credential $testCred). Por lo tanto, la autenticación CredSSP es estrictamente el problema.
Michael Sorens
De acuerdo: WinRM básico está bien; No sé cuál es el problema exacto, pero sospecho que está relacionado con la política 'permitir nuevas credenciales' y el SPN que configuró. Echaría un vistazo más de cerca a esa configuración de política y tal vez profundice un poco más para asegurarme de que su kerberos funciona correctamente. Parece que este enlace podría ser útil: [link] msdn.microsoft.com/en-us/library/ee309365(v=vs.85).aspx
jbsmith
¿Por qué usar Connect-WSMan to Server, mejor usar enable-wsmancredssp -role server, no?
Kiquenet
1

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.

Bruce
fuente
La copia del árbol de registro también funcionó para mí. hklm: \ SOFTWARE \ ... \ CredentialsDelegation no existía, el valor se almacenó en hklm: \ SOFTWARE \ Wow6432Node \ ... \ CredentialsDelegation y en HKEY_USERS \ ... \ Group Policy Objects \ ... \ CredentialDelegation.
Der_Meister