Poświadczenia proxy na drugim przeskoku PowerShell

Przekaż zamierzone konto proxy do Invoke-WebRequest na serwerze zdalnym, zamiast zakładać, że logowanie remoting jest delegowane.

Żądanie sieciowe, które działa interaktywnie na serwerze B, może otrzymać 407, gdy to samo polecenie zostanie tam uruchomione przez PowerShell remoting. Logowanie z A do B nie deleguje automatycznie tej tożsamości na potrzeby następnej wymiany uwierzytelniania B.

A → remoting session on B → HTTP proxy → website

Jednym z obsługiwanych rozwiązań jest jawne przekazanie konta proxy dla żądania wychodzącego. Z istniejącą sesją PSSession i prawidłowo uzyskanym obiektem PSCredential:

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
}

Obiekt poświadczeń dotyczy zamierzonego konta proxy. Sesja nadal używa zwykłego uwierzytelniania remoting, a każde logowanie do witryny pozostaje częścią żądania do tej witryny.

Pozwala to uniknąć polegania na automatycznym delegowaniu pierwszego logowania. Wymaga jednak, aby host zdalny traktował przekazany materiał konta jako część zamierzonego projektu administracyjnego. Inne architektury, takie jak zarządzany punkt końcowy RunAs czy ograniczony dostęp do usługi, mają własne wymagania konfiguracyjne.

Jeśli błędnym założeniem były domyślne poświadczenia proxy, zapisz konto, na którym działa zdalne polecenie, oraz uwierzytelnianie, którego wymaga proxy. Dłuższy limit czasu żądania sieciowego nie dostarczy brakujących poświadczeń.

Opcje proxy w New-PSSessionOption dotyczą samego połączenia remoting. Skonfiguruj Invoke-WebRequest wewnątrz zdalnego bloku skryptu, gdy to wychodzące połączenie sieciowe B wymaga proxy.

Powiązane artykuły