Proxy-legitimasjon på det andre PowerShell-hoppet

Ein nettførespurnad som fungerer interaktivt på server B, kan få 407 når same kommando vert køyrd der via PowerShell remoting. Innlogging frå A til B delegerer ikkje automatisk den identiteten for den neste autentiseringsutvekslinga til B.

A → remoting session on B → HTTP proxy → website

Ei støtta løysing er å oppgi proxykontoen eksplisitt for den utgåande førespurnaden. Med ein eksisterande PSSession og eit rett anskaffa PSCredential-objekt:

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
}

Legitimasjonsobjektet er for den tiltenkte kontoen til proxyen. Økta brukar framleis den vanlege remoting-autentiseringa si, og kvar innlogging på ein nettstad vert verande ein del av førespurnaden til den nettstaden.

Dette unngår å stole på automatisk delegering av den første innlogginga. Det krev likevel at fjernverten handterer kontomaterialet som vert oppgjeve, som ein del av det tiltenkte administrasjonsdesignet. Andre arkitekturer, som eit administrert RunAs-endepunkt eller avgrensa tenestetilgang, har eigne konfigurasjonskrav.

Viss standard proxy-legitimasjon var den feilaktige føresetnaden, registrer kontoen som fjernkommandoen køyrer under, og autentiseringa proxyen ber om. Ein lengre tidsfrist for nettførespurnaden kan ikkje skaffe manglande legitmasjon.

Proxyvala på New-PSSessionOption gjeld sjølve remoting-tilkoplinga. Konfigurer Invoke-WebRequest inne i den eksterne skriptblokka når det er den utgåande nettilkoplinga til B som treng proxyen.