Прокси акредитиви на вториот 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 е таа што бара прокси.

Поврзани статии