'n Webversoek wat interaktief op bediener B werk, kan 407 ontvang wanneer dieselfde opdrag daar via PowerShell-remoting uitgevoer word. Om van A na B aan te meld, delegeer nie outomaties daardie identiteit vir B se volgende verifikasie-uitruiling nie.

A → remoting session on B → HTTP proxy → website

Een ondersteunde ontwerp is om die proxyrekening eksplisiet te verskaf vir die uitgaande versoek. Met 'n bestaande PSSession en 'n toepaslik verkrygde PSCredential-objek:

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
}

Die referensie-objek is vir die proxy se beoogde rekening. Die sessie gebruik steeds sy normale remoting-verifikasie, en enige webwerf-aanmelding bly deel van daardie webwerfversoek.

Dit vermy die afhanklikheid van outomatiese delegasie van die eerste aanmelding. Dit vereis wel dat die afgeleë gasheer die verskafde rekeningmateriaal as deel van die beoogde administrasie-ontwerp hanteer. Ander argitekture, soos 'n bestuurde RunAs-eindpunt of beperkte dienstoegang, het hul eie konfigurasievereistes.

As verstek-proxybewyse die foutiewe aanname was, teken die rekening aan waaronder die afgeleë opdrag loop en die verifikasie wat die proxy versoek. 'n Langer webversoek-tydsperking kan nie ontbrekende bewyse verskaf nie.

Proxy-opsies op New-PSSessionOption raak die remoting-verbinding self. Konfigureer Invoke-WebRequest binne die afgeleë scriptblok wanneer B se uitwaartse webverbinding die een is wat die proxy nodig het.

Verwante artikels