Proxy-legitimasjon på det andre PowerShell-hoppet

Oppgi den tiltenkte proxykontoen til Invoke-WebRequest på fjernserveren i stedet for å anta at remoting-innloggingen delegeres.

En nettforespørsel som fungerer interaktivt på server B, kan få 407 når samme kommando kjøres der via PowerShell remoting. Innlogging fra A til B delegerer ikke automatisk den identiteten for Bs neste autentiseringsutveksling.

A → remoting session on B → HTTP proxy → website

En støttet løsning er å oppgi proxykontoen eksplisitt for den utgående forespørselen. Med en eksisterende PSSession og et riktig anskaffet 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 proxyens tiltenkte konto. Økten bruker fortsatt sin vanlige remoting-autentisering, og enhver innlogging på et nettsted forblir en del av forespørselen til nettstedet.

Dette unngår å stole på automatisk delegering av den første innloggingen. Det krever likevel at fjernverten håndterer det oppgitte kontomaterialet som en del av det tiltenkte administrasjonsdesignet. Andre arkitekturer, som et administrert RunAs-endepunkt eller begrenset tjenestetilgang, har egne konfigurasjonskrav.

Hvis standard proxy-legitimasjon var den feilaktige antakelsen, registrer kontoen som fjernkommandoen kjører under, og autentiseringen proxyen ber om. En lengre tidsavbrudd for nettforespørselen kan ikke skaffe manglende legitimasjon.

Proxyvalgene på New-PSSessionOption gjelder selve remoting-tilkoblingen. Konfigurer Invoke-WebRequest inne i den eksterne skriptblokken når det er Bs utgående nettilkobling som trenger proxyen.

Relaterte artikler