Заметка
Доступ к этой странице требует авторизации. Вы можете попробовать войти в систему или изменить каталог.
Доступ к этой странице требует авторизации. Вы можете попробовать сменить директорию.
Обновлено: 24 июня 2013 года
Применимо к: Windows Server 2012 R2, Windows Server 2012
Windows PowerShell Web Access в Windows Server 2012 R2 и Windows Server 2012 имеет ограниченную модель безопасности. Пользователям должен быть явно предоставлен доступ, прежде чем они смогут войти в шлюз Windows PowerShell Web Access и использовать веб-консоль Windows PowerShell.
Настройка правил авторизации и безопасности сайта
После установки Windows PowerShell Web Access и настройки шлюза пользователи могут открыть страницу входа в браузере, но не могут войти, пока администратор Windows PowerShell Web Access не предоставит им доступ явно. Контроль доступа к 'Windows PowerShell Web Access' управляется с помощью набора команд Windows PowerShell, описанных в следующей таблице. Не существует сопоставимого графического интерфейса для добавления или управления правилами авторизации. См. Cmdlet-модули веб-доступа Windows PowerShell.
Администраторы могут определять {0-n} правила аутентификации для Windows PowerShell Web Access. Стандартная безопасность является ограничительной, а не разрешительной; Отсутствие правил аутентификации означает, что ни один пользователь не имеет доступа ни к чему.
Add-PswaAuthorizationRule и Test-PswaAuthorizationRule в Windows Server 2012 R2 содержат параметр учетных данных, позволяющий добавлять и тестировать правила авторизации Windows PowerShell Web Access с удалённого компьютера или внутри активной сессии Windows PowerShell Web Access. Как и в других cmdlet Windows PowerShell с параметром Credential, вы можете указать объект PSCredential в качестве значения этого параметра. Чтобы создать объект PSCredential, содержащий учетные данные, которые вы хотите передать удалённому компьютеру, запустите cmdlet Get-Credential .
Правила аутентификации Windows PowerShell Web Access — это разрешённые правила. Каждое правило — это определение разрешённого соединения между пользователями, целевыми компьютерами и конкретными конфигурациями сессий Windows PowerShell (также называемыми конечными точками или runspaces) на заданных целевых компьютерах. Для объяснения о runspaces см. Начало использования PowerShell Runspaces
Это важно
Пользователю достаточно одного правила, чтобы получить доступ. Если пользователю предоставляется доступ к одному компьютеру с полным языковым доступом или только к удалённым командорам управления Windows PowerShell из веб-консоли, он может войти (или переключиться) на другие компьютеры, подключённые к первому целевому компьютеру. Самый безопасный способ настройки Windows PowerShell Web Access — это разрешить пользователям доступ только к ограниченным сессиям, которые позволяют выполнять конкретные задачи, которые обычно необходимы для удаления.
Cmdlet, на которые ссылаются в Windows PowerShell Web Access Cmdlet , позволяют создавать набор правил доступа, которые используются для авторизации пользователя на шлюзе Windows PowerShell Web Access. Правила отличаются от списков контроля доступа (ACL) на целевом компьютере и обеспечивают дополнительный уровень безопасности для веб-доступа. Более подробная информация о безопасности описана в следующем разделе.
Если пользователи не могут пройти ни один из предыдущих уровней безопасности, они получают общее сообщение «в доступе отказано» в окнах браузера. Хотя данные безопасности ведутся на сервере шлюза, конечным пользователям не показывают информацию о том, сколько уровней безопасности они прошли, а также о том, на каком уровне произошёл сбой входа или аутентификации.
Для получения дополнительной информации о настройке правил авторизации см. раздел «Настройка правил авторизации » в этой теме.
Безопасность
Модель безопасности Windows PowerShell Web Access включает четыре уровня между конечным пользователем веб-консоли и целевым компьютером. Администраторы Windows PowerShell Web Access могут добавлять уровни безопасности через дополнительную конфигурацию в консоли IIS Manager. Для получения дополнительной информации о защите веб-сайтов в консоли IIS Manager см. раздел Configure Web Server Security (IIS7).
Для получения дополнительной информации о лучших практиках IIS и предотвращении атак типа типа отказ в обслуживании см. раздел «Лучшие практики предотвращения атак с использованием DoS/отказа в обслуживании». Администратор также может приобрести и установить дополнительное программное обеспечение для аутентификации в розничной торговле.
В следующей таблице описаны четыре уровня безопасности между конечными пользователями и целевой компьютерами.
Подробную информацию о каждом слое можно найти в следующих заголовках:
Функции безопасности веб-сервера IIS
Пользователи Windows PowerShell Web Access всегда должны указывать имя пользователя и пароль для аутентификации своих аккаунтов на шлюзе. Однако администраторы Windows PowerShell Web Access также могут включать или выключать опциональную аутентификацию сертификатов клиента, смотреть «установить» и использовать Windows PowerShell Web Access для запуска тестового сертификата, а позже — как настроить подлинный сертификат.
Опциональная функция клиентского сертификата требует, чтобы конечные пользователи имели действительный сертификат клиента, помимо имён пользователей и паролей, и является частью конфигурации веб-сервера (IIS). Когда уровень клиентских сертификатов активирован, страница входа в Windows PowerShell Web Access предлагает пользователям предоставить действительные сертификаты перед оценкой их учетных данных входа. Аутентификация сертификатов клиента автоматически проверяет наличие сертификата клиента. Если действительный сертификат не найден, Windows PowerShell Web Access информирует пользователей, чтобы они могли предоставить сертификат. Если обнаруживается действующий сертификат клиента, Windows PowerShell Web Access открывает страницу входа, чтобы пользователи могли ввести свои имена пользователей и пароли.
Это один из примеров дополнительных настроек безопасности, которые предлагает IIS Web Server. Для получения дополнительной информации о других функциях безопасности IIS см. раздел Configure Web Server Security (IIS 7).
Аутентификация шлюзов на основе форм Windows PowerShell Web Access
Страница входа в Windows PowerShell Web Access требует набора учетных данных (имя пользователя и пароль) и предлагает пользователям возможность предоставить разные учетные данные для целевого компьютера. Если пользователь не предоставляет альтернативные учетные данные, основное имя пользователя и пароль, используемые для подключения к шлюзу, также используются для подключения к целевому компьютеру.
Необходимые учетные данные аутентифицируются на шлюзе Windows PowerShell Web Access. Эти учетные данные должны быть действительными пользовательскими учётными записями либо на локальном сервере шлюза Windows PowerShell Web Access, либо в Active Directory.
Правила авторизации веб-доступа Windows PowerShell
После аутентификации пользователя на шлюзе Windows PowerShell Web Access проверяет правила авторизации, чтобы проверить, имеет ли пользователь доступ к запрашиваемому целевому компьютеру. После успешной авторизации учетные данные пользователя передаются целевому компьютеру.
Эти правила оцениваются только после аутентификации пользователя шлюзом и до того, как пользователь может быть аутентифицирован на целевом компьютере.
Правила аутентификации и авторизации целей
Последним уровнем безопасности Windows PowerShell Web Access является собственная конфигурация безопасности целевой компьютера. Пользователи должны иметь соответствующие права доступа, настроенные на целевом компьютере, а также в правилах авторизации Windows PowerShell Web Access, чтобы запускать веб-консоль Windows PowerShell, которая влияет на целевой компьютер через Windows PowerShell Web Access.
Этот слой предлагает те же механизмы безопасности, которые оценивают попытки подключения, если пользователи пытаются создать удалённую сессию Windows PowerShell с целевым компьютером из Windows PowerShell, запустив команды Enter-PSSession или New-PSSession .
По умолчанию Windows PowerShell Web Access использует основное имя пользователя и пароль для аутентификации как на шлюзе, так и на целевом компьютере. Веб-страница входа в разделе «Опциональные настройки подключения» предлагает пользователям возможность предоставить разные учетные данные для целевого компьютера, если это необходимо. Если пользователь не предоставляет альтернативные учетные данные, основное имя пользователя и пароль, используемые для подключения к шлюзу, также используются для подключения к целевому компьютеру.
Правила авторизации могут использоваться для предоставления пользователям доступа к определённой конфигурации сессии. Вы можете создавать ограниченные runspaces или сессионные конфигурации для Windows PowerShell Web Access, а также позволять определённым пользователям подключаться только к определённым сессиям при входе в Windows PowerShell Web Access. Вы можете использовать списки контроля доступа (ACL), чтобы определить, какие пользователи имеют доступ к конкретным конечным точкам, а также дополнительно ограничить доступ к конечной точке для определённого набора пользователей, используя правила авторизации, описанные в этом разделе. Для получения дополнительной информации о ограниченных пространствах см. раздел «Создание ограниченного пространства выполнения».
Настройка правил авторизации
Администраторы, вероятно, хотят использовать то же правило авторизации для пользователей Windows PowerShell Web Access, которое уже определено в их среде для удалённого управления Windows PowerShell. Первая процедура в этом разделе описывает, как добавить правило защищённой авторизации, предоставляющее доступ одному пользователю, входу в систему для управления одним компьютером и внутри одной сессионной конфигурации. Вторая процедура описывает, как убрать правило авторизации, которое больше не требуется.
Если вы планируете использовать пользовательские сессионные конфигурации, позволяющие конкретным пользователям работать только в ограниченных пространствах выполнения Windows PowerShell Web Access, создайте свои собственные сессионные конфигурации перед добавлением правил авторизации, которые к ним ссылаются. Нельзя использовать cmdlets Windows PowerShell Web Access для создания пользовательских конфигураций сессий. Для получения дополнительной информации о создании пользовательских конфигураций сессий см. about_Session_Configuration_Files.
Cmdlets Windows PowerShell Web Access поддерживают один дикий символ — звездочку ( * ). Джокер-символы внутри строк не поддерживаются; Используйте одну звездочку для каждого свойства (пользователи, компьютеры или конфигурации сессий).
Замечание
Для получения дополнительных способов использования правил авторизации для предоставления доступа пользователям и защиты среды Windows PowerShell Web Access см. другие примеры сценариев правил авторизации в этой теме.
Добавить ограничительное правило авторизации
Выполните одно из следующих действий, чтобы открыть сеанс Windows PowerShell с повышенными правами.
На рабочем столе Windows щелкните правой кнопкой мыши Windows PowerShell на панели задач и нажмите кнопку "Запуск от имени администратора".
На экране «Пуск » Windows кликните правой кнопкой мыши по Windows PowerShell, а затем нажмите «Запустить как администратор».
Необязательный шаг Для ограничения доступа пользователей с помощью конфигураций сессий:
Проверьте, что конфигурации сессий, которые вы хотите использовать, уже существуют в ваших правилах.
Если они ещё не созданы, используйте инструкции для создания конфигураций сессий в about_Session_Configuration_Files.
Это правило авторизации позволяет конкретному пользователю получить доступ к одному компьютеру в сети, к которому он обычно имеет доступ, с доступом к конкретной конфигурации сессии, соответствующей типичным потребностям пользователя в скриптах и cmdlet. Введите следующее, а затем нажмите клавишу ВВОД.
Add-PswaAuthorizationRule -UserName <domain\user | computer\user> ` -ComputerName <computer_name> -ConfigurationName <session_configuration_name>- В следующем примере пользователь с именем JSmith в домене Contoso получает доступ к управлению компьютерным Contoso_214 и использует конфигурацию сессии под названием NewAdminsOnly.
Add-PswaAuthorizationRule -UserName 'Contoso\JSmith' ` -ComputerName Contoso_214 -ConfigurationName NewAdminsOnlyПроверьте, что правило создано, запустив либо cmdlet Get-PswaAuthorizationRule , либо
Test-PswaAuthorizationRule -UserName <domain\user | computer\user> -ComputerName** <computer_name>. Например:Test-PswaAuthorizationRule -UserName Contoso\\JSmith -ComputerName Contoso_214.
Чтобы удалить правило авторизации
Если сессия Windows PowerShell ещё не открыта, см. шаг 1 , чтобы добавить ограничительное правило авторизации в этом разделе.
Введите следующее, затем нажмите Enter, где ID правила представляет уникальный номер нужного вами правила.
Remove-PswaAuthorizationRule -ID <rule ID>Или, если вы не знаете ID-номер, но знаете дружелюбное название нужного правила для удаления, вы можете получить название правила и отправить его в
Remove-PswaAuthorizationRulecmdlet, чтобы удалить правило, как показано в следующем примере:Get-PswaAuthorizationRule ` -RuleName <rule-name> | Remove-PswaAuthorizationRule
Замечание
Вас не просят подтвердить, хотите ли вы удалить указанное правило авторизации; правило удаляется при нажатии Enter. Убедитесь, что вы хотите удалить правило авторизации перед запуском Remove-PswaAuthorizationRule cmdlet.
Другие примеры сценариев правил авторизации
Каждая сессия Windows PowerShell использует конфигурацию сессии; если сессия не указана, Windows PowerShell использует встроенную сессионную конфигурацию Windows PowerShell по умолчанию, называемую Microsoft.PowerShell. Настройка сессии по умолчанию включает все cmdlet, доступные на компьютере. Администраторы могут ограничивать доступ ко всем компьютерам, определяя конфигурацию сессии с ограниченным пространством выполнения (ограниченным набором cmdlet и задач, которые могут выполнять конечные пользователи). Пользователь, которому предоставлен доступ к одному компьютеру с полным языковым доступом или только с удалёнными командами управления Windows PowerShell, может подключаться к другим компьютерам, подключённым к первому компьютеру. Определение ограниченного пространства выполнения может предотвратить доступ пользователей к другим компьютерам из разрешённого пространства Windows PowerShell и повысить безопасность вашей среды Windows PowerShell Web Access. Конфигурацию сессии можно распределить (с помощью Group Policy) на все компьютеры, которые администраторы хотят сделать доступными через Windows PowerShell Web Access. Дополнительные сведения о конфигурациях сеансов см. в about_Session_Configurations. Ниже приведены некоторые примеры такого сценария.
Администратор создаёт конечную точку, называемую PswaEndpoint, с ограниченным пространством выполнения. Затем администратор создаёт правило
*,*,PswaEndpointи распределяет конечную точку на другие компьютеры. Это правило позволяет всем пользователям получить доступ ко всем компьютерам с конечной точкой PswaEndpoint. Если это единственное правило авторизации, определённое в наборе правил, компьютеры без этой конечной точки будут недоступны.Администратор создал конечную точку с ограниченным пространством под названием PswaEndpoint и хочет ограничить доступ для конкретных пользователей. Администратор создаёт группу пользователей под названием Level1Support и определяет следующее правило: Level1Support,*,PswaEndpoint. Правило предоставляет всем пользователям группы Level1Support доступ ко всем компьютерам с конфигурацией PswaEndpoint . Аналогично, доступ может быть ограничен определённым набором компьютеров.
Некоторые администраторы предоставляют определённым пользователям больше доступа, чем другим. Например, администратор создаёт две группы пользователей — Admins и BasicSupport. Администратор также создаёт конечную точку с ограниченным пространством под названием PswaEndpoint и определяет следующие два правила: Admins,*,* и BasicSupport,*,PswaEndpoint. Первое правило предоставляет всем пользователям админ-группы доступ ко всем компьютерам, а второе — всем пользователям группы BasicSupport доступ только к тем компьютерам с PswaEndpoint.
Администратор создал приватную тестовую среду и хочет предоставить всем авторизованным пользователям сети доступ ко всем компьютерам в сети, к которым они обычно имеют доступ, а также ко всем конфигурациям сессий, к которым они обычно имеют доступ. Поскольку это приватная тестовая среда, администратор создаёт правило авторизации, которое не является безопасным. - Администратор запускает cmdlet
Add-PswaAuthorizationRule * * *, который использует символ * wildcard для представления всех пользователей, всех компьютеров и всех конфигураций. - Это правило эквивалентно следующему:Add-PswaAuthorizationRule -UserName * -ComputerName * -ConfigurationName *.Замечание
Это правило не рекомендуется в безопасной среде и обходит уровень безопасности авторизации, предоставляемый Windows PowerShell Web Access.
Администратор должен позволять пользователям подключаться к целевых компьютерам в среде, включающей как рабочие группы, так и домены, где компьютеры рабочих групп иногда используются для подключения к целевых компьютерам в доменах, а компьютеры в доменах — для подключения к целевых компьютерам в рабочих группах. Администратор имеет шлюзовый сервер PswaServer в рабочей группе; и srv1.contoso.com целевого компьютера находится в домене. Пользователь Крис является авторизованным локальным пользователем как на сервере шлюза рабочей группы, так и на целевом компьютере. Его имя пользователя на сервере рабочей группы — chrisLocal; А его имя пользователя на целевом компьютере — Contoso\chris. Чтобы разрешить доступ к srv1.contoso.com для Криса, администратор добавляет следующее правило.
Add-PswaAuthorizationRule -userName PswaServer\chrisLocal `
-computerName srv1.contoso.com -configurationName Microsoft.PowerShell
Приведённый пример правил аутентификация Криса на сервере шлюза, а затем авторизирует ему доступ к srv1. На странице входа Крис должен предоставить второй набор учетных данных в разделе опциональных настроек соединения (contoso\chris). Сервер шлюза использует дополнительный набор учетных данных для аутентификации на целевом компьютере, srv1.contoso.com.
В предыдущем сценарии Windows PowerShell Web Access устанавливает успешное соединение с целевым компьютером только после того, как следующие условия были успешны и разрешены хотя бы одним правилом авторизации.
Аутентификация на сервере шлюза рабочей группы путём добавления имени пользователя в формате server_name\user_name к правилу авторизации
Аутентификация на целевом компьютере с использованием альтернативных учетных данных, указанных на странице входа в разделе «Опциональные настройки соединения »
Замечание
Если шлюзовые и целевые компьютеры находятся в разных рабочих группах или доменах, необходимо установить доверительные отношения между двумя компьютерами рабочей группы — двумя доменами или между рабочей группой и доменом. Это отношение нельзя настроить с помощью cmdlet-систем авторизации правил веб-доступа Windows PowerShell. Правила авторизации не определяют доверительные отношения между компьютерами; Они могут разрешать пользователям только подключаться к конкретным целевым компьютерам и конфигурациям сессий. Для получения дополнительной информации о том, как настраивать доверительные отношения между разными доменами, см . раздел «Создание доменных и лесных доверительных фондов». Для получения дополнительной информации о том, как добавить компьютеры рабочих групп в список доверенных хостов, см. раздел «Удалённое управление с Server Manager».
Использование единого набора правил авторизации для нескольких сайтов
Правила авторизации хранятся в XML-файле. По умолчанию имя пути XML-файла — $env:windir\Web\PowershellWebAccess\data\AuthorizationRules.xml.
Путь к XML-файлу правил авторизации хранится в файлеpowwa.config , который находится в $env:windir\Web\PowershellWebAccess\data. Администратор имеет гибкость изменить ссылку на стандартный путь в powwa.config в соответствии с предпочтениями или требованиями. Позволяя администратору менять местоположение файла, несколько шлюзов Windows PowerShell Web Access используют одни и те же правила авторизации, если такая конфигурация необходима.
Управление сеансами
По умолчанию Windows PowerShell Web Access ограничивает пользователя тремя сессиями одновременно. Вы можете редактировать web.config файл веб-приложения в IIS Manager, чтобы поддерживать разное количество сессий на пользователя. Путь к файлуweb.config — это $env:windir\Web\PowerShellWebAccess\wwwroot\Web.config.
По умолчанию IIS Web Server настроен на перезапуск пула приложений при изменении любых настроек. Например, пул приложений перезагружается, если в файлweb.config внесены изменения. >Поскольку Windows PowerShell Web Access использует состояния сессий в памяти, >пользователи, войдшие в сессии Windows PowerShell Web Access, теряют свои сессии при перезагрузке пула приложений.
Настройка стандартных параметров на странице входа
Если ваш шлюз Windows PowerShell Web Access работает на Windows Server 2012 R2, вы можете настроить значения по умолчанию для настроек, отображаемых на странице входа в Windows PowerShell Web Access. Вы можете настроить значения в web.config файле, описанном в предыдущем абзаце. Значения по умолчанию для настроек страницы входа находятся в разделе appSettings файла web.config; ниже приведён пример раздела appSettings . Действительные значения для многих из этих настроек совпадают с значениями соответствующих параметров cmdlet New-PSSession в Windows PowerShell.
Например, defaultApplicationName ключ, как показано в следующем блоке кода, — это значение переменной предпочтения $PSSessionApplicationName на целевом компьютере.
<appSettings>
<add key="maxSessionsAllowedPerUser" value="3"/>
<add key="defaultPortNumber" value="5985"/>
<add key="defaultSSLPortNumber" value="5986"/>
<add key="defaultApplicationName" value="WSMAN"/>
<add key="defaultUseSslSelection" value="0"/>
<add key="defaultAuthenticationType" value="0"/>
<add key="defaultAllowRedirection" value="0"/>
<add key="defaultConfigurationName" value="Microsoft.PowerShell"/>
</appSettings>
Тайм-ауты и незапланированные отключения
Тайм-аут сессий Windows PowerShell Web Access. В Windows PowerShell Web Access, работающей на Windows Server 2012, после 15 минут бездействия сессии отображается сообщение о тайм-ауте для авторизованных пользователей. Если пользователь не отвечает в течение пяти минут после отображения сообщения о тайм-ауте, сессия заканчивается, и пользователь выходит из системы. Вы можете менять периоды тайм-аута для сессий в настройках сайта в IIS Manager.
В Windows PowerShell Web Access, работающей на Windows Server 2012 R2, по умолчанию время сессий заканчивается после 20 минут бездействия. Если пользователи отключаются от сессий в веб-консоли из-за сетевых ошибок или других незапланированных выключений или сбоев, а не потому, что сами закрыли сессии, сессии Windows PowerShell Web Access продолжают выполняться, подключённые к целевой компьютерам, до истечения тайм-аута на стороне клиента. Сессия отключается либо после стандартных 20 минут, либо после указанного администратором шлюза тайм-аута — в зависимости от того, что короче.
Если сервер шлюза работает на Windows Server 2012 R2, Windows PowerShell Web Access позволяет пользователям подключаться к сохранённым сессиям позже, но когда сетевые ошибки, незапланированные выключения или другие сбои отключают сессии, пользователи не могут видеть или подключаться к сохранённым сессиям до истечения тайм-аута, указанного администратором шлюза.