Credenciales de proxy en el segundo salto de PowerShell

Una solicitud web que funciona de forma interactiva en el servidor B puede recibir 407 cuando el mismo comando se ejecuta allí mediante PowerShell remoting. Iniciar sesión de A a B no delega automáticamente esa identidad para el siguiente intercambio de autenticación de B.

A → remoting session on B → HTTP proxy → website

Un diseño admitido es proporcionar la cuenta de proxy explícitamente para la solicitud saliente. Con una PSSession existente y un objeto PSCredential obtenido correctamente:

Invoke-Command -Session $session -ArgumentList $proxyCredential -ScriptBlock {
    param([pscredential]$outboundProxyCredential)

    $requestOptions = @{
        Uri = 'https://api.example/'
        Proxy = 'http://proxy.example:8080'
        ProxyCredential = $outboundProxyCredential
    }
    Invoke-WebRequest @requestOptions
}

El objeto de credenciales corresponde a la cuenta prevista del proxy. La sesión sigue usando su autenticación de remoting habitual, y cualquier inicio de sesión en un sitio web sigue formando parte de esa solicitud.

Esto evita depender de la delegación automática del primer inicio de sesión. Sí exige que el host remoto trate el material de cuenta suministrado como parte del diseño administrativo previsto. Otras arquitecturas, como un punto de conexión RunAs administrado o un acceso de servicio restringido, tienen sus propios requisitos de configuración.

Si las credenciales de proxy predeterminadas eran el supuesto erróneo, registre la cuenta con la que se ejecuta el comando remoto y la autenticación que solicita el proxy. Un tiempo de espera más largo de la solicitud web no puede aportar credenciales que faltan.

Las opciones de proxy de New-PSSessionOption afectan a la propia conexión de remoting. Configure Invoke-WebRequest dentro del bloque de script remoto cuando sea la conexión web saliente de B la que necesite el proxy.