Prokuraj akreditaĵoj ĉe la dua PowerShell-salto

Reta peto, kiu funkcias interage sur servilo B, povas ricevi 407 kiam la sama komando plenumiĝas tie per PowerShell remoting. Ensaluti de A al B ne aŭtomate delegas tiun identecon por la sekva aŭtentiga interŝanĝo de B.

A → remoting session on B → HTTP proxy → website

Unu subtenata dezajno estas eksplicite provizi la prokuran konton por la elira peto. Kun ekzistanta PSSession kaj taŭge akirita PSCredential-objekto:

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
}

La akreditaĵa objekto estas por la celita konto de la prokuro. La seanco daŭre uzas sian normalan remoting-aŭtentigon, kaj ajna reteja ensaluto restas parto de tiu reteja peto.

Tio evitas fidi aŭtomatan delegadon de la unua ensaluto. Ĝi tamen postulas, ke la fora gastiganto traktu la provizitan kontan materialon kiel parton de la celita administra dezajno. Aliaj arkitekturoj, kiel administrata RunAs-finpunkto aŭ limigita serva aliro, havas proprajn agordajn postulojn.

Se la defaŭltaj prokuraj akreditaĵoj estis la malĝusta supozo, registru la konton sub kiu la fora komando funkcias kaj la aŭtentigon, kiun la prokuro postulas. Pli longa retpeta tempolimo ne povas provizi mankantajn akreditaĵojn.

La prokuraj opcioj ĉe New-PSSessionOption koncernas la remoting-konekton mem. Agordu Invoke-WebRequest ene de la fora skriptbloko kiam la ekstera reta konekto de B estas tiu, kiu bezonas la prokuron.