Compartilhar via

Servidores Proxy e WinRM

O WinRM (Gerenciamento Remoto do Windows) usa HTTP e HTTPS para enviar mensagens entre os computadores cliente e servidor. Em geral, o cliente WinRM envia mensagens diretamente para o servidor WinRM. Os clientes WinRM também podem ser configurados para usar um servidor proxy.

Para obter mais informações, consulte as seguintes seções:

Configurando um servidor proxy para WinRM 2.0

O WinRM 2.0 dá suporte a uma ampla gama de configurações de proxy. Por exemplo, o WinRM dá suporte a proxies para transportes HTTP e HTTPS e para servidores proxy autenticados e não autenticados.

conexões de proxy HTTPS-Based

Para uma melhor segurança e afinidade baseada em conexão, o HTTPS deve ser usado como o mecanismo de transporte.

Se o servidor proxy exigir autenticação, os clientes e servidores WinRM deverão usar HTTPS.

Nota

A autenticação no servidor proxy é independente da autenticação para o servidor de destino.

 

conexões de proxy HTTP-Based

Se nenhuma autenticação de servidor proxy for necessária, HTTP ou HTTPs poderão ser usados para transporte. No entanto, conexões baseadas em HTTP de um cliente WinRM para um servidor WinRM por meio de um servidor proxy podem ser problemáticas.

Os seguintes problemas podem ser encontrados ao usar conexões baseadas em HTTP:

  • O servidor proxy não dá suporte à autenticação baseada em conexão, o que pode fazer com que a autenticação no servidor de destino falhe com um erro de acesso negado.
  • Mais de um conjunto de credenciais é necessário para se conectar ao servidor de destino e ao servidor proxy.
  • Os servidores proxy baseados em HTTP podem não dar suporte à capacidade de manter as conexões baseadas no cliente e no servidor associadas. Se o proxy não vincular fortemente um cliente a um servidor e manter a conexão TCP/IP, os clientes não autenticados poderão obter acesso aos dados. Além disso, a falta de afinidade de conexão pode fazer com que a autenticação falhe no servidor.

Se o HTTP precisar ser usado como transporte, o servidor proxy deverá dar suporte à seguinte configuração para obter uma resposta WinRM melhor e evitar falhas de acesso negadas para clientes WinRM:

  • Suporte para HTTP/1.1. O HTTP/1.1 é mais rigoroso no mapeamento da afinidade de conexão entre o cliente e o servidor.

  • Autenticação baseada em conexão para autenticação Negotiate, Kerberos e CredSSP.

    A autenticação de uma solicitação requer várias viagens de ida e volta entre o cliente e o servidor. A maior parte da negociação para autenticação é concluída depois que o servidor WinRM (autenticação) envia uma resposta ao cliente que não é uma resposta 401 (não autorizada). Se o servidor WinRM retornar uma resposta ao cliente que não é uma resposta 401, o proxy não deverá fechar a conexão.

    Vários pares de solicitação/resposta podem ser enviados entre o cliente e o servidor antes que os dados reais do pacote sejam enviados. O WinRM 2.0 usa os esquemas de autenticação Negotiate e Kerberos com criptografia, que podem adicionar viagens de ida e volta extras. Os dados não podem ser enviados ao servidor até que a autenticação seja concluída.

    O servidor WinRM retorna uma resposta de 200 níveis que indica que a autenticação está concluída. Os servidores proxy baseados em HTTP podem encerrar a afinidade de autenticação baseada em conexão e fechar a conexão TCP/IP depois de receber a resposta de 200 níveis do servidor WinRM. A viagem de ida e volta final de cliente para servidor não inclui o pacote de solicitação original. Se o servidor proxy fechar a conexão, o servidor tentará autenticar novamente o cliente e a solicitação do cliente poderá nunca ser enviada ao servidor. Se a afinidade baseada em conexão não for mantida, a autenticação no servidor de destino poderá falhar com um erro de acesso negado.

  • Persistência de conexão. A conexão TCP/IP do cliente com o proxy deve continuar a ser mapeada para a mesma conexão TCP/IP do proxy para o servidor. Manter essa conexão ajuda a obter um nível mais alto de desempenho. Se a conexão não for mantida, cada solicitação deverá ser autenticada novamente, o que pode afetar o desempenho.

Criptografia e WinRM 2.0

O WinRM 2.0 dá suporte à criptografia via HTTP usando os esquemas de autenticação Negotiate, Kerberos e CredSSP. Se um servidor WinRM for compatível com HTTP e for acessado por meio de um proxy, o servidor WinRM deverá impor a criptografia e não permitir o tráfego de rede não criptografado.

Em nenhuma circunstância as solicitações HTTP não criptografadas devem ser enviadas por meio de servidores proxy. Quando os dados devem passar por um servidor proxy antes de serem enviados para o servidor de destino, os seguintes problemas de segurança são muito importantes:

  • É possível que um servidor proxy mal-intencionado possa examinar cada par de solicitação/resposta, incluindo credenciais.
  • Se as conexões TCP/IP não forem fortemente mapeadas entre o cliente WinRM e o servidor proxy e entre o servidor proxy e o servidor de destino, um cliente não autorizado poderá se conectar ao servidor de destino usando a mesma conexão autenticada do servidor proxy com o servidor de destino. O servidor de destino pode permitir que o cliente não autenticado acesse os dados. Se a criptografia for imposta, o servidor de destino enviará uma mensagem de acesso negado ao cliente não autenticado.

O uso da criptografia atenuaria esses possíveis problemas de segurança.

Configurando um servidor proxy para WinRM 1.1 e anterior

Se um proxy for necessário para alcançar o servidor WinRM, o cliente WinRM dependerá da configuração de proxy dos Serviços HTTP do Windows (WinHTTP). Por padrão, o WinHTTP não está configurado para usar um servidor proxy. A configuração do proxy WinHTTP pode ser alterada usando o ProxyCfg.exe ou netsh utilitários de linha de comando.

WinRM 1.1 e Anterior: o WinRM não usa as configurações de proxy do Internet Explorer.