Acreditări de proxy la al doilea salt PowerShell

Furnizați contul de proxy dorit către Invoke-WebRequest de pe serverul la distanță în loc să presupuneți că autentificarea remoting este delegată.

O cerere web care funcționează interactiv pe serverul B poate primi 407 când aceeași comandă rulează acolo prin PowerShell remoting. Autentificarea de la A la B nu deleagă automat acea identitate pentru următorul schimb de autentificare al lui B.

A → remoting session on B → HTTP proxy → website

Un proiect acceptat este să furnizați explicit contul de proxy pentru cererea de ieșire. Cu o PSSession existentă și un obiect PSCredential obținut corect:

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
}

Obiectul de acreditări este pentru contul dorit al proxy-ului. Sesiunea folosește în continuare autentificarea remoting obișnuită, iar orice autentificare pe un site rămâne parte din cererea către acel site.

Aceasta evită dependența de delegarea automată a primei autentificări. Totuși, cere ca gazda la distanță să trateze materialul de cont furnizat ca parte din proiectul administrativ dorit. Alte arhitecturi, cum ar fi un endpoint RunAs administrat sau acces restricționat la serviciu, au propriile cerințe de configurare.

Dacă acreditările de proxy implicite au fost presupunerea greșită, notați contul sub care rulează comanda la distanță și autentificarea cerută de proxy. Un timeout mai lung al cererii web nu poate furniza acreditările lipsă.

Opțiunile de proxy din New-PSSessionOption privesc conexiunea remoting în sine. Configurați Invoke-WebRequest în blocul de script de la distanță atunci când conexiunea web de ieșire a lui B este cea care are nevoie de proxy.

Articole similare