В этой статье речь пойдет о подключении из Powershell к AAD через корпоративный прокси.

Существует несколько способов настройки, чтобы среда powershell узнала, как необходимо авторизоваться на существующем прокси.

Если у вас в IE прописана автоконфигурация, то это еще не значит, что Powershell ее подхватит. В идеале следует добавить все AAD endpoints в белый список на вашем файрволе, чтобы они не требовали аутентификацию. Но если это не так, то придется проходить аутентификацию на прокси.

Наилучший вариант — использовать те креденшелы для аутентификации, которые уже есть в Windows сессии. Это подойдет, если powershell запускается под тем же пользователем, которому разрешен доступ на прокси. При этом, для аутентификации в самом AAD могут использоваться креденшелы другого пользовтаеля.

Такую прокси аутентификацию можно настроить как на уровне самого сервера, так и в Powershell сессии.

На уровне сервера для начала проверяем конфигурацию прокси через cmd:

netsh winhttp show proxy

В ответ вы получите, что используется Direct access, даже при условии, что в IE вы настроили прокси — эта настройка действует только для конкретного пользователя.

Далее, можно скопировать все настройки из профиля текущего пользователя (запустите elevated cmd):

netsh winhttp import proxy source=ie

или задайте их вручную командой:

netsh winhttp set proxy proxy-server="http=ProxyServer:Port;https=ProxyServer:Port" bypass-list="<local>"

Эти настройки валидны в целом для Powershell сессии, но не пробрасываются в конкретные командлеты для подключения к Azure AD.

Аутентификация на прокси

Если при выполнении командлета Connect-AzureAD вы получаете ошибку, которая приведена ниже, то это признак того, что прокси вас не может аутентифицировать, но вы до него достучались.

Connect-AzureAD : The remote server returned an error: (407) Proxy Authentication Required.

При подключении к Azure ресурсам через прокси есть два варианта аутентификации: использовать SSO или указывать креденшелы вручную.

В случае SSO будут использованы те же логин и пароль, что в и Windows сессии, при условии, что прокси поддерживает Kerberos или NTLM аутентификацию. Код будет такой:

$Wcl = new-object System.Net.WebClient
$Wcl.Headers.Add(“user-agent”, “PowerShell”)
$Wcl.Proxy.Credentials = [System.Net.CredentialCache]::DefaultNetworkCredentials

Еще один вариант SSO — указать параметры прокси прямо в сессии Powershell (вместо netsh):

[system.net.webrequest]::defaultwebproxy = New-Object system.net.webproxy('http://proxy:port')
[system.net.webrequest]::defaultwebproxy.credentials = [System.Net.CredentialCache]::DefaultNetworkCredentials
[system.net.webrequest]::defaultwebproxy.BypassProxyOnLocal = $true

Разница в том, какой класс .NET вы используете WebClient или WebRequest. Работают оба.

Последний вариант — указать логин и пароль вручную или передать его в переменной из зашифрованного файла с паролем. Код такой:

$Wcl=New-Object System.Net.WebClient
$Creds=Get-Credential
$Wcl.Proxy.Credentials=$Creds

Естественно, в переменную $creds вы можете передать логин и пароль откуда угодно, не только с интерактивного ввода.

Далее — проверка соединения. Выполните строку ниже и вы должны получить результат OK:

(Invoke-WebRequest -Uri login.microsoftonline.com).StatusDescription

Важно! Не забудьте, что для подключения к AAD, требуется поддержка протокола TLS 1.2 и отключенный SSL3.0. Даже если это выполнено на уровне IE, такие настройки не распространяются на Powershell и WinHTTP.

Если вы в результате выполнения Connect-AzureAD получаете ошибки:

Connect-AzureAD : An error occurred while sending the request.
Connect-AzureAD : The underlying connection was closed: An unexpected error occurred on a send.

то причина кроется именно в настройках TLS. Как их проверить и исправить, вы можете прочитать в статье: Настройка протоколов TLS на Windows Server — Alexis Hardware World (hww.ru)

Насколько полезен этот пост?

Кликните на звезду, чтобы оценить!

Средний рейтинг 0 / 5. Количество голосов: 0

Еще нет голосов. Будь первым!

Поделиться:

Написано автором Александр Д.