Облікові дані проксі на другому переході 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 потребує проксі.

Схожі статті