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

Падобныя артыкулы