Главная


А АThursday, 7 May 2020

PowerShell Web Access и SSL.

Всем привет.

Удобная штука PowerShell Web Access (PSWA), но ее использование без шифрования трафика с помощью SSL чревато. К счастью штатно она имеет в своем арсенале настройки использования SSL. Для настройки PSWA с использованием SSL сертификата есть несколько вариантов:

  • при установке самого web-приложения с помощью Pwersehll указать ключик -UseTestCertificate;
  • создать самозаверенный сертификат в оснастке диспетчера IIS;
  • обратиться в центр сертификации и получить нормальный сертификат, который затем и установить.
Далее  я опишу все шаги которые я прошел, уверен что часть из них могут быть лишними для вас. Но что было то было.

Итак, первый вариант был самым простым, но созданный таким образом сертификат PowerShellWebAccessTestWebSite (на 90 дней) оказался бесполезным даже  в тестовой среде. Поэтому после недолгих мучений с ним я перешел ко второму варианту. Для этой цели я создал самозаверенный сертификат, но с помощью известного скрипта. Увы, автоматизация бывает не всегда полезна. Дело в том что созданный таким образом сертификат оказался заточен на короткое имя сервера, а не на его FQDN. Почему так отработал скрипт - непонятно. Поэтому пришлось ручками сгенерировать третий самозаверенный сертификат в оснастке диспетчера IIS.



Установил созданный сертификат в настройках веб-сайта по умолчанию и выбрал пункт «Привязки». Указал  тип подключения https и выбрал нужный SSL-сертификат.



Осталось только включить поддержку SSL. Чтобы максимально защитить подключение можно включить использование сертификатов на стороне клиента. Для этого в свойствах веб-приложения выбираем параметры SSL  и отмечаем пункт «Требовать SSL». Имейте в виду, что в этом случае придется устанавливать сертификат сервера на каждого клиента. Поэтому рабочий вариант PSWA я оставил таким как ниже.



На этом конфигурирование PSWA можно считать законченным. В классическом варианте. Но я же шел длинным путем поэтому мой слушатель службы WinRM оказался привязан к предыдущему (второму) сертификату.


Быстро поправить ситуацию с помощью Powershell мне не удалось:

$thumbprint = "‎11e281d98636753a1fc14d45b869d50a7e326591"
Get-ChildItem -Path cert:\LocalMachine\My -Recurse | Where-Object { $_.Thumbprint -eq $thumbprint } | Select-Object *

$selector_set = @{
    Address = "*"
    Transport = "HTTPS"
}
$value_set = @{
    CertificateThumbprint = "‎11e281d98636753a1fc14d45b869d50a7e326591"
}

New-WSManInstance -ResourceURI "winrm/config/Listener" -SelectorSet $selector_set -ValueSet $value_set

Поэтому был вынужден указать certThumbprint действующего сертификата явно в реестре:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Listener\*+HTTPS]
"hostname"="LOG01"
"uriprefix"="wsman"
"certThumbprint"="11E281D98636753A1FC14D45B869D50A7E326591"

Вот теперь точно все. Подключаемся к шлюзу, набрав в строке адреса https://ServerPSWA.forza.com/pswa (1), вводим свои учетные данные (2) и полное имя (3) целевого компьютера (например myhost01.forza.com). Не забываем указать ниже что мы хотим использовать SSL(4). Если учетные данные на шлюзе и на конечном сервере различаются, то задаем их в дополнительных параметрах подключения.


И последнее - добиваться первого успешного входа лучше используя Internet Explorer. Не Edge. И только потом переходить на Chrome. Все таки сказывается степень интеграции Internet Explorer в саму Windows.

Успехов.

No comments:

Post a Comment

А что вы думаете по этому поводу?

Версия на печать

Популярное