Una richiesta web che funziona in modo interattivo sul server B può ricevere 407 quando lo stesso comando viene eseguito lì tramite PowerShell remoting. L'accesso da A a B non delega automaticamente tale identità per il successivo scambio di autenticazione di B.

A → remoting session on B → HTTP proxy → website

Una soluzione supportata è fornire esplicitamente l'account proxy per la richiesta in uscita. Con una PSSession esistente e un oggetto PSCredential ottenuto correttamente:

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
}

L'oggetto credenziali è per l'account previsto del proxy. La sessione continua a usare la normale autenticazione remoting e qualsiasi accesso a un sito web resta parte della richiesta a quel sito.

Questo evita di affidarsi alla delega automatica del primo accesso. Richiede però che l'host remoto tratti il materiale dell'account fornito come parte della progettazione amministrativa prevista. Altre architetture, come un endpoint RunAs gestito o un accesso ai servizi limitato, hanno i propri requisiti di configurazione.

Se le credenziali proxy predefinite erano il presupposto errato, registra l'account con cui viene eseguito il comando remoto e l'autenticazione richiesta dal proxy. Un timeout più lungo della richiesta web non può fornire credenziali mancanti.

Le opzioni proxy di New-PSSessionOption riguardano la connessione remoting stessa. Configura Invoke-WebRequest all'interno del blocco di script remoto quando è la connessione web in uscita di B ad aver bisogno del proxy.

Articoli correlati