Spletna zahteva, ki na strežniku B deluje interaktivno, lahko prejme 407, ko se isti ukaz tam izvede prek PowerShell remotinga. Prijava z A na B te identitete ne prenese samodejno za naslednjo izmenjavo preverjanja pristnosti na B.

A → remoting session on B → HTTP proxy → website

Ena podprta rešitev je izrecno posredovati račun proxy za odhodno zahtevo. Z obstoječo PSSession in pravilno pridobljenim objektom PSCredential:

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
}

Objekt poverilnic je namenjen predvidenemu računu proxyja. Seja še vedno uporablja običajno preverjanje pristnosti remotinga, vsaka prijava na spletno mesto pa ostane del zahteve do tega mesta.

S tem se izognete zanašanju na samodejno delegiranje prve prijave. Zahteva pa, da oddaljeni gostitelj obravnava posredovano gradivo računa kot del predvidene zasnove upravljanja. Druge arhitekture, kot so upravljana končna točka RunAs ali omejen dostop do storitve, imajo svoje konfiguracijske zahteve.

Če so bile napačna domneva privzete poverilnice proxyja, zabeležite račun, pod katerim se izvaja oddaljeni ukaz, in preverjanje pristnosti, ki ga zahteva proxy. Daljši časovni limit spletne zahteve ne more zagotoviti manjkajočih poverilnic.

Možnosti proxyja v New-PSSessionOption zadevajo samo povezavo remotinga. Konfigurirajte Invoke-WebRequest znotraj oddaljenega skriptnega bloka, ko je prav odhodna spletna povezava B tista, ki potrebuje proxy.

Sorodni članki