Прокси идентификационни данни при втория 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 се нуждае от проксито.

Подобни статии