Kredencialet e proxy-t në kërcimin e dytë të PowerShell

Jepni llogarinë e synuar të proxy-t te Invoke-WebRequest në serverin e largët në vend që të supozoni se hyrja përmes remoting delegohet.

Një kërkesë web që funksionon në mënyrë interaktive në serverin B mund të marrë 407 kur e njëjta komandë ekzekutohet atje përmes PowerShell remoting. Hyrja nga A në B nuk e delegon automatikisht atë identitet për shkëmbimin e ardhshëm të vërtetimit të B.

A → remoting session on B → HTTP proxy → website

Një dizajn i mbështetur është të jepet shprehimisht llogaria e proxy-t për kërkesën dalëse. Me një PSSession ekzistuese dhe një objekt PSCredential të marrë si duhet:

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
}

Objekti i kredencialeve është për llogarinë e synuar të proxy-t. Sesioni vazhdon të përdorë vërtetimin e tij normal të remoting, dhe çdo hyrje në një sajt mbetet pjesë e kërkesës për atë sajt.

Kjo shmang mbështetjen në delegimin automatik të hyrjes së parë. Megjithatë kërkon që hosti i largët të trajtojë materialin e llogarisë së dhënë si pjesë të dizajnit të synuar të administrimit. Arkitekturat e tjera, si një pikë fundore RunAs e menaxhuar ose akses i kufizuar në shërbim, kanë kërkesat e tyre të konfigurimit.

Nëse kredencialet e parazgjedhura të proxy-t ishin supozimi i gabuar, shënoni llogarinë nën të cilën ekzekutohet komanda e largët dhe vërtetimin që kërkon proxy-i. Një afat më i gjatë i kërkesës web nuk mund të sigurojë kredenciale që mungojnë.

Opsionet e proxy-t në New-PSSessionOption kanë të bëjnë me vetë lidhjen e remoting. Konfiguroni Invoke-WebRequest brenda bllokut të skriptit të largët kur është lidhja dalëse e web-it e B ajo që ka nevojë për proxy.

Artikuj të ngjashëm