Share via


Windows PowerShell: El segundo salto

Puede meterse en situaciones complicadas cuando realiza comunicaciones remotas con Windows PowerShell. Tenga cuidado con el número de saltos que realiza.

Don Jones

Windows PowerShell Remoting es una manera increíble para administrar varios equipos remotos como fácilmente como si sólo estaban administrando uno. En un entorno de dominio, simplemente funciona. Dicho que hay algunas salvedades a ver para te realmente puede meterse. El "segundo salto" es uno de esos.

Especialmente lo fresco de Remoting es qué tan bien se integra con las tecnologías específicas de Windows, como el Protocolo de autenticación Kerberos. A diferencia de las herramientas anteriores que podrían aceptar y ejecutar comandos remotos, Remoting no se ejecuta bajo la cuenta LocalSystem Todopoderoso. En cambio, cuando se conecte, sus credenciales de Windows (el uno con el que usted conectado o especificado al hacer la conexión) se delega en el equipo remoto o equipos.

Delegación es una función nativa de Kerberos y Active Directory. Es completamente seguro. La contraseña no es transmitida a través de la red en el claro, cifrado o. En la mayoría, se utiliza como una clave de cifrado compartida.

Delegación significa que copia del equipo remoto de Windows PowerShell puede ejecutar comandos como lo hace, es decir Remoting se convierte en transparente en seguridad. Nada que tienes permiso, podrá hacer de forma remota. Si usted no tiene permiso, usted no puede hacerlo. Remoting es ejecutar comandos como usted.

Así que se siente en el equipo cliente y conecte a ServerA, que es una máquina remota. Su credencial se delega en esa máquina. De ServerA, ahora iniciar otra conexión de algún tipo a una tercera parte de la máquina. No tiene que ser una conexión remota. Podría intentar asignar una unidad de red al tercer equipo, acceder a un almacén de certificados o hacer cualquier otra cosa. Usted acaba de hacer un segundo salto.

El primer salto fue de su cliente a ServerA. El segundo es de ServerA a otro equipo al que está intentando conectar. El problema surge porque las credenciales no se puede delegar una segunda vez.

Es realmente una característica de seguridad, diseñada para evitar que su credencial que se pasa alrededor sin su conocimiento. Para que su segunda operación de salto falla, porque ServerA no es capaz de enviar cualquier credenciales a lo largo de su viaje.

En casi cada clase de Windows PowerShell que he enseñado, hay alguien que ha encontrado esto. Es fácil olvidar que estás remoto en una máquina porque es tan transparente y fácil de hacer. Así que es fácil terminar tratando de control remoto para una tercera máquina sin darse cuenta le está iniciando un segundo salto.

No existe ninguna delegación de credencial, se produce un error en el segundo salto, ves mensajes de error extraños y uno termina confundido. Esto puede ocurrir incluso en algunos casos donde sólo tienes un salto, pero intenta realizar una operación en el equipo remoto que requiere una credencial de delegado.

La Windows PowerShell Blog post, "CredSSP remoto de segundo salto," describe lo que sucede. También describe la solución, que es permitir que el nuevo protocolo de autenticación CredSSP. Esto tiene que estar activada en el equipo cliente y los equipos a los que va a control remoto. Puede ejecutar un comando para que pueda:

Enable-WSManCredSSP –Role client –DelegateComputer * Enable-WSManCredSSP –Role server

Debería ser obvio que se ejecute en el cliente y que uno en el servidor. También puede habilitar este protocolo a través de un objeto de directiva de grupo (GPO) en la configuración de administración remota de Windows (WinRM). También deberá especificar el protocolo CredSSP cuando utilice Invoke-comando, Enter-PSSession, nueva PSSession o cualquier otro cmdlet que utiliza Remoting.

Desproteger PDF gratis, "Guía de un laico de PowerShell 2.0 Remoting," por Ravikanth Chaganti. Incluye más detalles (especialmente en el capítulo 10) sobre la cuestión del segundo salto y cómo resolver cualquier confusión. Por ejemplo, observa que los controladores de dominio no necesitan CredSSP para hacer la magia del segundo salto, debido a están configurados para apoyarlo por defecto.

Hay un montón de otros escenarios difíciles que se puede ejecutar en con interacción remota. Puedes encontrar equipos de no dominio, conexiones de dominios, servicios remotos a través de un servidor proxy y así sucesivamente. En Windows PowerShell, ejecute about_remote_troubleshooting ayuda para leer instrucciones detalladas para hacer frente a estos y otros escenarios. Si todavía le pegan, me cae una línea.

Don Jones

Don Jones es un receptor de Microsoft MVP Award y autor de "Aprender Windows PowerShell en un mes de comidas" (publicaciones de Manning, 2011), un libro diseñado para ayudar a cualquier administrador en vigencia con Windows PowerShell. Jones también ofrece formación pública y en el sitio Windows PowerShell. Contactar con él a través de ConcentratedTech.com o bit.ly/AskDon.

Contenido relacionado