Proxy-legitimationsoplysninger på det andet PowerShell-hop

Angiv den tilsigtede proxykonto til Invoke-WebRequest på fjernserveren i stedet for at antage, at remoting-loginet delegeres.

En webforespørgsel, der virker interaktivt på server B, kan få 407, når den samme kommando kører der via PowerShell remoting. Login fra A til B delegerer ikke automatisk den identitet til B's næste godkendelsesudveksling.

A → remoting session on B → HTTP proxy → website

Et understøttet design er at angive proxykontoen eksplicit for den udgående forespørgsel. Med en eksisterende PSSession og et korrekt erhvervet 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
}

Legitimationsobjektet er til proxyens tilsigtede konto. Sessionen bruger stadig sin normale remoting-godkendelse, og ethvert webstedslogin forbliver en del af den pågældende webstedsforespørgsel.

Det undgår at stole på automatisk delegering af det første login. Det kræver til gengæld, at fjernværten håndterer det medsendte kontomateriale som en del af det tilsigtede administrationsdesign. Andre arkitekturer, såsom et administreret RunAs-endpoint eller begrænset tjenesteadgang, har deres egne konfigurationskrav.

Hvis standard-proxylegitimationsoplysningerne var den fejlagtige antagelse, skal du registrere den konto, som fjernkommandoen kører under, og den godkendelse, som proxyen anmoder om. En længere timeout for webforespørgslen kan ikke levere manglende legitimationsoplysninger.

Proxyindstillingerne på New-PSSessionOption vedrører selve remoting-forbindelsen. Konfigurer Invoke-WebRequest inde i det fjernede scriptblok, når det er B's udgående webforbindelse, der har brug for proxyen.

Relaterede artikler