Учетные данные прокси на втором переходе PowerShell

Передайте нужную учетную запись прокси в Invoke-WebRequest на удаленном сервере, вместо того чтобы предполагать, что вход через remoting делегируется.

Веб-запрос, который интерактивно работает на сервере B, может получить 407, когда та же команда выполняется там через PowerShell remoting. Вход с A на B не делегирует автоматически эту удостоверяющую информацию для следующего обмена аутентификацией на B.

A → remoting session on B → HTTP proxy → website

Один из поддерживаемых подходов — явно передать учетную запись прокси для исходящего запроса. С существующей PSSession и правильно полученным объектом 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
}

Объект учетных данных предназначен для нужной учетной записи прокси. Сеанс по-прежнему использует обычную аутентификацию remoting, а любой вход на веб-сайт остается частью запроса к этому сайту.

Это позволяет не полагаться на автоматическое делегирование первого входа. Однако требуется, чтобы удаленный узел обрабатывал переданные учетные данные как часть задуманной схемы администрирования. У других архитектур, например управляемой конечной точки RunAs или ограниченного доступа к службе, есть собственные требования к настройке.

Если ошибочным предположением были учетные данные прокси по умолчанию, запишите учетную запись, под которой выполняется удаленная команда, и аутентификацию, которую запрашивает прокси. Более длительный тайм-аут веб-запроса не может восполнить отсутствующие учетные данные.

Параметры прокси в New-PSSessionOption относятся к самому подключению remoting. Настраивайте Invoke-WebRequest внутри удаленного блока скрипта, когда именно исходящее веб-подключение B нуждается в прокси.

Похожие статьи