В этой статье речь пойдет о подключении из 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)
