Настраиваем PowerShell Web Access “под себя”

Заканчиваем рассматривать работу с PowerShell Web Access (PSWA) на Windows Server 2012. В нем будет мы настроем его “под себя”, для нужд использования в своем домене.
В предыдущих постах мы рассматривали следующее:

• Установка PSWA
• Конфигурирование
• Тестирование

В этом посте мы рассмотрим, как удалить тестовые правила, установить сертификат домена, создадим правила домена для PSWA, протестируем их и вкратце обозначим, что вообще можно делать дальше. Подробности под катом.

Удаляем тестовые правила

Для начала я собираюсь удалить все созданные мною тестовые правила. Позже я настрою несколько правил для домена, но сейчас я собираюсь перепроверить настроенные правила с помощью командлета Invoke-Command, чтобы удаленно запустить команду на веб-сервере с работающим PSWA.

PS C:\> invoke-command {Get-PSwaAuthorizationRule} -comp chi-web01 

Все правила можно удалить, передав в Remove-PswaAuthorizationrule.

PS C:\> invoke-command {Get-PSwaAuthorizationRule | Remove-PSwaAuthorizationRule -force } -comp chi-web01 

Шлюз PSWA все равно будет запущен, однако никто не сможет его использовать, пока мы не зададим новые правила.

Устанавливаем сертификат домена

Сначала мы установили PowerShell Web Access с использованием тестового сертификата для SSL. (см. пост “PowerShell Web Access: руководство по установке”). Мне нужно переконфигурировать эту веб-службу для использования валидного сертификата из моей службы сертификации домена (domain certificate service). Хотя управление IIS можно осуществлять через PowerShell, однако проще это сделать с помощью графических инструментов управления IIS. Внимание: В зависимости от того как вы изначально настроили веб-сервер, вам может потребоваться установить IIS Management Tools, IIS Management Service и сконфигурировать сервер для осуществления удаленного управления.
На сервере CHI-WEB01 я установлю сертификат веб-сервера, выпущенный центром сертификации (CA) моего домена. Необходимо адаптировать привязки к сайту (site bindings) для использования этого сертификата. В IIS Manager я выберу сайт и отредактирую привязки (bindings).

Сейчас я выберу https binding и нажму Edit.

На скриншоте выше я выбрал установленный мною сертификат CHI-WEB01. Затем открываем браузер и переходим на https://chi-web01/pswa/en-US/logon.aspx. Никаких предупреждений безопасности не проявилось (см. пост про тестирование PSWA).

Все то же самое можно сделать сразу же при конфигурировании PSWA. Запустите Install-PswaWebApplication на веб-сервере и затем вручную сконфигурируйте сертификат. Но вы захотите также настроить SSL сертификат, трастовый для пользователей в вашем домене.

Создаем правила домена в PSWA

На следующем этапе создаем необходимые правила авторизации. Эти правила должны быть установлены на веб-сервере. Я буду использовать удаленное управление (remoting) с Credssp, так как команде понадобится осуществить повторное подключение (second hop) для доступа к Active Directory.

PS C:\> enter-pssession chi-web01 -Authentication Credssp -Credential globomantics\jeff 

Первое правило, которое я создам, позволит членам группы Domain Admins получать доступ к любому компьютеру с использованием конечной точки Microsoft.PowerShell.

[chi-web01]: PS C:\> Add-PswaAuthorizationRule -rulename DomainAdmins -usergroupname "globomantics\domain admins" -computername * -configurationname microsoft.powerShell -force 

Эта команда предоставит доменным администраторам полный удаленный доступ к PowerShell.
Также я хотел бы дать группе администраторов БД (DBA) доступ к SQL Server – но только к этому серверу.

[chi-web01]: PS C:\> Add-PswaAuthorizationRule -rulename SQLDBA -usergroupname "globomantics\chicago dba" -computername CHI-DB01 -configurationname microsoft.powerShell -force 

Последнее правило, которое я создаем,- предустановленная ограниченная конечная точка (pre-established constrained endpoint). Эта конечная точка, на CHI-FP01, позволит пользователям, входящим в группу Help Desk, решать проблемы с файлами и папками, используя PowerShell.

[chi-web01]: PS C:\> Add-PswaAuthorizationRule -rulename HelpDesk -usergroupname "globomantics\help desk" -computername CHI-FP01 -configurationname FileMgmt -force 

Теперь в PSWA есть три правила. Взглянем на них.

[chi-web01]: PS C:\> get-PswaAuthorizationRule 

Вывод можно посмотреть на скриншоте ниже.

Тестируем правила в PowerShell Web Access

Когда вы создали новое правило, PSWA не пожалуется, что вы использовали дублирующиеся имена, равно как и не проверит любую информацию вы “понаписали”, разве что имя пользователя или группы в Active Directory. Также отсутствует какой-либо командлет для того, чтобы модифицировать имеющиеся правила (например, если вы допустили ошибку), так что используйте Remove-PswaAuthorizationRule для удаления, а затем заново создавайте правило.
Чтобы проверить правила, можно использовать Test-PswaAuthorizationRule. Уточните имя пользователя или группу и опционально имя конфигурации конечной точки.

[chi-web01]: PS C:\> Test-PswaAuthorizationRule -username "globomantics\jeff" -computer chi-dc02 

Если будет найдено валидное правило, вывод будет следующим:

Первые два правила проверены. Но вот последнее для ограниченной конечной точки (то, что мы создали для нужд Help Desk) не было проверено, так как ничего в ответ не вернулось. Но я могу попробовать заново, только в этот раз я уточню имя конфигурации.

[chi-web01]: PS C:\> Test-PswaAuthorizationRule -username "globomantics\adeco" -computer * -configuration * 

На скриншоте ниже показано это правило.

Однако позвольте прояснить: все, что мы делали сейчас, это проверяли существование правила для заданного пользователя или группы. Оно не проверяет корректность ввода конкретной точки, доступность сервера или наличие достаточных прав у учетной записи. Вам необходимо отдельно (и вручную) протестировать все это, используя командлет Enter-PSSession. Если это работает здесь, это должно работать в PowerShell Web Access.

PSWA: Что дальше?

Естественно, перед тем как полноценно работать с PowerShell Web Access необходимо какое-то время потренироваться и дополнительно что-нибудь почитать. Однако если Вы (или Ваши коллеги) уже используют PowerShell remoting, переключиться на PSWA оказывается не так сложно. Для компьютеров, входящих в домен, все должно просто работать. Для всего другого Вы должны разобраться со следующими задачами:

• Сконфигурировать файл с хостами (hosts file) на устройствах, не входящих в домен, например, на планшетах, чтобы разрешить использование имени сервера с PSWA.
• Установить доменный сертификат CA в качестве доверительного корневого центра сертификации на устройствах, не входящих в домен.
• Настроить общий доступ к PSWA, так что вы можете удаленно управлять серверами откуда угодно.
• Постоянно контролировать членство в группах, у которых есть права на удаленный доступ.

Но, естественно, действия, которые необходимо предпринять, зависят от конкретной ситуации в конкретной организации.
PowerShell Web Access может быть очень мощным инструментов управления, но для того, чтобы он таковым стал, необходимо потратить время на настройку доменных правил и процедур. Используйте Test-PswaAuthorization для разрешения проблем с доступом. А Enter-PSSession можно использовать для решения других проблем конфигурации.