Starpniekservera akreditācijas dati otrajā PowerShell lēcienā

Nododiet paredzēto starpniekservera kontu Invoke-WebRequest, kas darbojas attālinātajā serverī, nevis pieņemiet, ka remoting pieteikšanās tiek deleģēta.

Tīmekļa pieprasījums, kas serverī B darbojas interaktīvi, var saņemt 407, kad tā pati komanda tur tiek izpildīta caur PowerShell remoting. Pieteikšanās no A uz B automātiski nedeleģē šo identitāti B nākamajai autentifikācijas apmaiņai.

A → remoting session on B → HTTP proxy → website

Viens atbalstīts risinājums ir skaidri nodot starpniekservera kontu izejošajam pieprasījumam. Ar esošu PSSession un pareizi iegūtu PSCredential objektu:

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
}

Akreditācijas objekts ir paredzēts starpniekservera kontam. Sesija joprojām izmanto parasto remoting autentifikāciju, un jebkura pieteikšanās vietnē paliek attiecīgā vietnes pieprasījuma daļa.

Tas ļauj izvairīties no paļaušanās uz pirmās pieteikšanās automātisku deleģēšanu. Tomēr tas prasa, lai attālinātais resursdators apstrādātu nodoto konta materiālu kā paredzētā administrēšanas risinājuma daļu. Citām arhitektūrām, piemēram, pārvaldītam RunAs galapunktam vai ierobežotai servisa piekļuvei, ir savas konfigurācijas prasības.

Ja nepareizais pieņēmums bija noklusējuma starpniekservera akreditācijas dati, pierakstiet kontu, ar kuru darbojas attālinātā komanda, un autentifikāciju, ko pieprasa starpniekserveris. Garāks tīmekļa pieprasījuma noildze nevar nodrošināt trūkstošus akreditācijas datus.

Starpniekservera opcijas New-PSSessionOption attiecas uz pašu remoting savienojumu. Konfigurējiet Invoke-WebRequest attālinātajā skripta blokā, kad tieši B izejošais tīmekļa savienojums ir tas, kam nepieciešams starpniekserveris.

Saistītie raksti