Проблема с удаленным вызовом Invoke-WebRequest через корпоративный прокси

Question

У меня есть две машины в моей корпоративной сети. Весь веб-трафик c проходит через наш корпоративный прокси-сервер, который требует аутентификации с использованием логина и пароля.

Обе машины находятся за брандмауэром и прокси-сервером компании.

На компьютере 1 У меня есть следующий фрагмент в файле Powershell profile.ps1:

$proxyString = "http://our.proxy.corp:8080"
$proxyUri = new-object System.Uri($proxyString)
[System.Net.WebRequest]::DefaultWebProxy = new-object System.Net.WebProxy ($proxyUri, $true)
[System.Net.WebRequest]::DefaultWebProxy.Credentials = [System.Net.CredentialCache]::DefaultCredentials

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

Когда Invoke-WebRequest вызывается из локального сеанса powershell на компьютере 1, веб-запрос выполняется нормально:

​C:\ > Invoke-WebRequest https://www.youtube.com

StatusCode        : 200
StatusDescription : OK

Когда я удаленно выполняю ту же команду с компьютера 2 на компьютере 1, я получаю следующую ошибку:

Invoke-Command -ScriptBlock { Invoke-WebRequest http://www.youtube.com } -ComputerName Machine 1

Access Denied (authentication_failed)
Your credentials could not be authenticated: "General authentication failure due to bad user ID or authentication
token.". You will not be permitted access until your credentials can be verified.
This is typically caused by an incorrect username and/or password, but could also be caused by network problems.
For assistance, contact your network support team.
    + CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebExc
   eption
    + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand
    + PSComputerName        : Machine 1

Кажется, что конфигурация прокси не загружается при удаленном вызове команд на компьютере 1.

Я пытался:

• Явное получение файла профиля при удаленном вызове
• Использование параметров -Proxy и -ProxyCredentials
• Указание учетных данных непосредственно в URL-адресе прокси-сервера "* 10 28 *http://user:password@our.proxy.corp: 8080"

Но я продолжаю получать ту же ошибку.

Чего мне не хватает?

Answer 1

Это слишком длинный для простого комментария, но чтобы добавить к полезному ответу pip3r, эта вещь двойного прыжка не проблема PowerShell, а Windows правильное ограничение.

Тем не менее, есть несколько статей по этой проблеме аутентификации двойного прыжка, которые уже давно обсуждаются с нами при использовании PowerShell. Непосредственно от Microsoft, сотрудников Microsoft на местах и ​​бывших сотрудников, а также других лиц. Вот лишь некоторые из них, которые вы могли бы найти с помощью быстрого веб-поиска, 'PowerShell double hop' , на ваше рассмотрение (и t0 поговорите с руководством и членами команды ) если CredSSP получит откат, и с тех пор, как мне пришлось с этим справиться, это произойдет.

Выполнение второго прыжка в PowerShell Remoting

PowerShell Remoting и Kerberos Double Hop: старая проблема - новое безопасное решение

... вспомогательные функции для работы с ресурсным ограниченным делегированием Kerberos (RB KCD) и PowerShell Remoting:

• Enable-RBKCD, Disable-RBKCD, Get-RBKCD.
• Получить файлы и слайды на моем GitHub здесь .

RB KCD работает с ограниченным набором команд и функций, работающих под учетной записью SYSTEM в контексте ядра.

RB KCD не поддерживает удаленное взаимодействие WinRM / PowerShell, поскольку оно выполняется под учетной записью NETWORK.

Включить PowerShell Doubl e-Hop Remoting

Как избежать проблемы двойного прыжка с PowerShell

Устранить проблему двойного прыжка в PowerShell Remoting

Answer 2

Уверен, что это происходит из-за проблемы двойного прыжка с Kerberos. С учетом вашего описания выполнения: «Когда я выполняю ту же команду с машины 2 удаленно на машине 1 ...»

И это со страницы CredentialCache:

Применяется свойство DefaultCredentials только для NTLM, согласования и аутентификации на основе Kerberos.

Итак, в двух словах, ваш токен Kerberos, содержащий всю вашу информацию о безопасности, не может быть передан на второй компьютер * из-за того, как работает Kerberos. удаленный компьютер никогда не получает фактический токен в памяти для удаленно подключенного пользователя, поэтому на удаленном компьютере не с чем работать, чтобы снова перейти вперед. В этом случае к прокси-серверу.

CAVEATS:

• PowerShell предлагает способ обойти это (CredSSP), но это ужасно небезопасная технология, которая открывает дыры в безопасности вашей среды для пароля воровство, боковое движение и т. д. c .-- Я бы не рекомендовал это.

Источники:

• https://docs.microsoft.com/en-us/dotnet/api/system.net.credentialcache.defaultcredentials?view=netframework-4.8