Удобная штука 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 действующего сертификата явно в реестре:
Быстро поправить ситуацию с помощью 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
[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
А что вы думаете по этому поводу?