Leer en inglés

Compartir a través de


Servidores proxy y WinRM

La administración remota de Windows (WinRM) usa HTTP y HTTPS para enviar mensajes entre los equipos cliente y servidor. En general, el cliente winRM envía mensajes directamente al servidor WinRM. Los clientes winRM también se pueden configurar para usar un servidor proxy.

Para obtener más información, consulte las secciones siguientes:

Configuración de un servidor proxy para WinRM 2.0

WinRM 2.0 admite una amplia gama de configuraciones de proxy. Por ejemplo, WinRM admite servidores proxy para transportes HTTP y HTTPS y para servidores proxy autenticados y no autenticados.

conexiones de proxy de HTTPS-Based

Para mejorar la seguridad y la afinidad basada en la conexión, se debe usar HTTPS como mecanismo de transporte.

Si el servidor proxy requiere autenticación, los clientes y servidores winRM deben usar HTTPS.

Nota

La autenticación en el servidor proxy es independiente de la autenticación al servidor de destino.

 

conexiones de proxy de HTTP-Based

Si no se requiere autenticación de servidor proxy, se pueden usar HTTP o HTTPs para el transporte. Sin embargo, las conexiones basadas en HTTP de un cliente WinRM a un servidor WinRM a través de un servidor proxy pueden ser problemáticas.

Es posible que se produzcan los siguientes problemas al usar conexiones basadas en HTTP:

  • El servidor proxy no admite la autenticación basada en la conexión, lo que puede hacer que la autenticación en el servidor de destino produzca un error de acceso denegado.
  • Se necesita más de un conjunto de credenciales para conectarse al servidor de destino y al servidor proxy.
  • Es posible que los servidores proxy basados en HTTP no admitan la capacidad de mantener las conexiones basadas en cliente y basadas en servidor asociadas. Si el proxy no vincula fuertemente un cliente a un servidor y mantiene la conexión TCP/IP, es posible que los clientes no autenticados obtengan acceso a los datos. Además, la falta de afinidad de conexión puede provocar un error en la autenticación en el servidor.

Si se debe usar HTTP como transporte, el servidor proxy debe admitir la siguiente configuración para lograr una mejor respuesta de WinRM y para evitar errores de acceso denegado para los clientes winRM:

  • Compatibilidad con HTTP/1.1. HTTP/1.1 es más estricto en la asignación de afinidad de conexión entre el cliente y el servidor.

  • Autenticación basada en conexión para la autenticación Negotiate, Kerberos y CredSSP.

    La autenticación de una solicitud requiere varios recorridos de ida y vuelta entre el cliente y el servidor. La mayoría de las negociaciones para la autenticación se completan después de que el servidor de autenticación (WinRM) envíe una respuesta al cliente que no es una respuesta 401 (no autorizado). Si el servidor WinRM devuelve una respuesta al cliente que no es una respuesta 401, el proxy no debe cerrar la conexión.

    Se pueden enviar varios pares de solicitud/respuesta entre el cliente y el servidor antes de enviar los datos de paquetes reales. WinRM 2.0 usa los esquemas de autenticación Negotiate y Kerberos con cifrado, que pueden agregar recorridos de ida y vuelta adicionales. Los datos no se pueden enviar al servidor hasta que se complete la autenticación.

    El servidor WinRM devuelve una respuesta de 200 niveles que indica que la autenticación está completa. Los servidores proxy basados en HTTP podrían finalizar la afinidad de autenticación basada en la conexión y cerrar la conexión TCP/IP después de recibir la respuesta de nivel 200 del servidor WinRM. El recorrido de ida y vuelta final del cliente al servidor no incluye el paquete de solicitud original. Si el servidor proxy cierra la conexión, el servidor intentará volver a autenticar el cliente y es posible que la solicitud de cliente nunca se envíe al servidor. Si no se mantiene la afinidad basada en la conexión, la autenticación en el servidor de destino puede producir un error de acceso denegado.

  • Persistencia de conexión. La conexión TCP/IP del cliente al proxy debe seguir asignando a la misma conexión TCP/IP desde el proxy al servidor. Mantener esta conexión ayuda a lograr un mayor nivel de rendimiento. Si no se mantiene la conexión, todas las solicitudes se deben volver a autenticar, lo que podría afectar al rendimiento.

Cifrado y WinRM 2.0

WinRM 2.0 admite el cifrado a través de HTTP mediante los esquemas de autenticación Negotiate, Kerberos y CredSSP. Si un servidor WinRM admite HTTP y se accede a través de un proxy, el servidor WinRM debe aplicar el cifrado y no permitir el tráfico de red sin cifrar.

En ninguna circunstancia se deben enviar solicitudes HTTP sin cifrar a través de servidores proxy. Cuando los datos deben pasar a través de un servidor proxy antes de enviarlos al servidor de destino, los siguientes problemas de seguridad son muy importantes:

  • Es posible que un servidor proxy malintencionado pueda examinar cada par de solicitudes y respuestas, incluidas las credenciales.
  • Si las conexiones TCP/IP no están fuertemente asignadas entre el cliente WinRM y el servidor proxy y entre el servidor proxy y el servidor de destino, un cliente no autorizado podría conectarse al servidor de destino mediante la misma conexión autenticada desde el servidor proxy al servidor de destino. El servidor de destino podría permitir el acceso de cliente no autenticado a los datos. Si se aplica el cifrado, el servidor de destino envía un mensaje de acceso denegado al cliente no autenticado.

El uso del cifrado mitigaría estos posibles problemas de seguridad.

Configuración de un servidor proxy para WinRM 1.1 y versiones anteriores

Si se requiere un proxy para llegar al servidor WinRM, el cliente winRM se basa en la configuración del proxy de servicios HTTP de Windows (WinHTTP). De forma predeterminada, WinHTTP no está configurado para usar un servidor proxy. La configuración del proxy WinHTTP se puede cambiar mediante las utilidades de línea de comandos ProxyCfg.exe o netsh .

WinRM 1.1 y versiones anteriores: WinRM no usa la configuración de proxy de Internet Explorer.