Proxyreferinsjes op 'e twadde PowerShell-hop

Jou it bedoelde proxy-akkount oan Invoke-WebRequest op 'e fiere server yn stee fan oan te nimmen dat de remoting-oanmelding delegarre wurdt.

In webferkiezing dy't ynteraktyf op server B wurket, kin 407 krije as itselde kommando dêr fia PowerShell remoting útfierd wurdt. Oanmelde fan A nei B delegarret dy identiteit net automatysk foar de folgjende autentikaasje-útwikseling fan B.

A → remoting session on B → HTTP proxy → website

Ien stipe ûntwerp is om it proxy-akkount eksplisyt te jaan foar de útgeande ferkiezing. Mei in besteande PSSession en in goed bemachtige 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
}

It referinsje-objekt is foar it bedoelde akkount fan 'e proxy. De sesje brûkt noch altyd syn normale remoting-autentikaasje, en elke webside-oanmelding bliuwt part fan dy websideferkiezing.

Dit foarket it fertrouwen op automatyske delegasje fan 'e earste oanmelding. It freget lykwols dat de fiere host it levere akkountmateriaal behannelet as part fan it bedoelde behearûntwerp. Oare arsjitektueren, lykas in beheard RunAs-einpunt of beheinde tsjinsttagong, hawwe har eigen konfiguraasje-easken.

As de standert proxyreferinsjes de ferkearde oanname wiene, registrearje dan it akkount dêr't it fiere kommando ûnder rint en de autentikaasje dy't de proxy freget. In langere tiidlimit foar de webferkiezing kin gjin ûntbrekkende referinsjes leverje.

De proxy-opsjes op New-PSSessionOption geane oer de remoting-ferbining sels. Konfigurearje Invoke-WebRequest binnen it fiere skriptblok as it de útgeande webferbining fan B is dy't de proxy nedich hat.

Relatearre artikelen