Ограничение прав пользователя на запуск только 1 приложения

Ограничение прав пользователя Windows 8.1
Hi. Есть оснастка gpedit. Как ограничить права только определённых пользователей (например.

Ограничение прав пользователя с паролем администратора
Нужна помощь! Есть компьютер с двумя учетными записями (администратор и ученик(например)), не могу.

Ограничение прав пользователя, после входа через RDP
Доброго времени суток, проблема такая, не понимаю немного. Windows server 2008 r2 установлена AD .

Запуск только одного приложения в терминальной сесии
Можно ли сделать так, что бы пользователь подключившийся к серверу по РДП, у него сразу запустилась.

Тематические курсы и обучение профессиям онлайн Профессия Cпециалист по кибербезопасности (Skillbox) DevOps-инженер (Нетология) Профессия DevOps-инженер PRO (Skillbox)

Заказываю контрольные, курсовые, дипломные и любые другие студенческие работы здесь или здесь.

Ограничение прав приложения/пользователя
Здравствуйте, есть определённое приложение, запускается из под своего пользователя, возможно ли.

Ограничение прав пользователя
Доброго времени суток! В cPanel на хостинге, создал нового пользователя для доступа к базе данный.

Ограничение прав пользователя
Приветствую. Такая задача. Нужно создать пользователя с минимальными возмжностями для работы.

Ограничение прав доступа пользователя
Привет всем Есть вопрос Как ограничить права доступа пользователя (за пределы home директории.

Терминальный сервер #1 Ограничение прав пользователей

Терминальный сервер #1 Ограничение прав пользователей

В одном из прошлых видео мы рассматривали процесс поднятия роли сервера терминалов.

В этом же уроке предлагаю более детально рассмотреть процесс ограничения прав пользователя на терминальном сервере. Да, по умолчанию он лишен административных прав и много чего не может, однако, все равно к этому вопросу нужно отнестись более внимательно, так как пользователь все же находится на самом главном устройстве в вашей компании.

Регистрируйся на следующий вебинар по системному администрированию!

Так что стоит детально проанализировать, что пользователю делать можно, а что нет.

По сути тут может быть две ситуации, когда терминальный сервер реализован в рамках доменной сети, и все пользователи хранятся на контроллере домена. И в ситуации, когда сеть одноранговая и учетками, под которыми будут подключаться пользователи к терминальному серверу, мы управляем непосредственно на терминальном сервере.

Как правило такая схема подходит для небольших компаний, у которых какая-то служба реализована на терминальном сервере, допустим 1С.

Все это я более подробно рассказывал и показывал в видео по настройке терминального сервера! Для тех, кто его не видел, я оставлю ссылку к данному видео. И если вы не понимаете, о чем речь, то для начала посмотрите его.

И так, когда мы попадаем на сервер под учеткой обычного терминального пользователя, мы не можем установить софт, однако, нам доступно довольно много различных возможностей:

— доступ к системным дискам

— можно запускать приложения, которые могут не относиться к работе пользователя

— запустить диспетчер серверов

— доступ к элементам панели управления

— доступ к диспетчеру задач

— доступ к командной строке

Давайте приступим к устранению этих недостатков.

Скажу сразу, что все что я буду показывать, это скорее базовые ограничения пользователей, которые нужно выполнить в первую очередь. Однако, на практике бывает множество различных дополнительных ограничивающих политик, так что буду очень рад, если вы в комментариях также поделитесь своим опытом из разряда, что запретили, зачем и как. Таким образом можно будет составить более развернутую картину, ну и записать вторую, а может быть и третью часть данного видео.

Думаю, что нам это вполне по силам 😉 Так как тема действительно интересная и меня уже не один раз расспрашивали по поводу ограничивающих политик.

1) Доступ к жестким дискам сервера

Запретить доступ к данным системных дисков можно через групповую политику, но, если мы попытаемся её изменить через Выполнить \ gpedit.msc то мы изменим групповую политику для всех пользователей на данном сервере, так что изменения затронут как терминальных пользователей, так и административные учетные записи.

А нам нужно ограничить в правах именно учетные записи, которые не имеют административные права на сервере. Для этого запустим редактор групповой политики через консоль (Выполнить \ mmc \ Файл \ Добавить \ Редактор объектов групповой политики \ Обзор \ Пользователи \ Не администраторы \ ОК \ Готово \ ОК) При желании таким образом можно настроить политики для отдельных пользователей.

Конфигурация пользователя \ Административные шаблоны \ Компоненты Windows \ Проводник \ Запретить доступ к дискам через Мой компьютер \ Включена \ Выполнить \ cmd \ gpupdate /force

Входим на сервер под удаленным пользователем и при попытке получить доступ к диску выдается сообщение «Операция отменена из-за ограничений, действующих на этом компьютере»

Причем у вас не получится не просто получить доступ к корню диска, а к любой папке через проводник (Рабочий стол, Загрузки и т.д. Даже если на рабочем столе создать папку и зайти в неё) В общем, везде где есть путь к расположению файла.

Однако, через файловые менеджеры, например тотал коммандер получить доступ к файлам можно. Или через командную строку

Поэтому, более тонко можно настроить через редактирование NTFS прав на файлы и папки (Диск D \ ПКМ \ Свойства \ Безопасность \ Удалить Все и Пользователи \ Добавить к нужной папке пользователя в права, как правило это папка с базой данных и т.д.

Тут уже через файловый менеджер не получится открыть диск и файлы.

Если какая-то нужная папка, то можно разместить ярлык на рабочем столе, где будет фактический путь и поместить в папку для всех пользователей (C:\Users\Public\Desktop \ Разрешить отображение скрытых файлов и папок \ Копировать туда ярлык с папкой и у всех удаленных пользователей появится на рабочем столе эта папка)

Так же от сюда можно убрать различные приложения, которые могут мешать пользователю и засорять его рабочий стол.

2) Запрет запуска приложений (Административные шаблоны \ Система \ Не запускать указанные приложения Windows \ TOTALCMD.EXE)

3) Запретить элементы панели управления (Административные шаблоны \ Панель управления \ Запретить доступ к панели управления и параметрам компьютера)

4) Запретить диспетчер серверов (Административные шаблоны \ Система \ Не запускать указанные приложения Windows \ ServerManager.exe)

5) Запретить диспетчер задач (Административные шаблоны \ Система \ Варианты действий после нажатия CTRL+ALT+DEL \ Удалить диспетчер задач \ Включено)

6) Запрет командной строки (Административные шаблоны \ Система \ Запретить использование командной строки)

Удобная штука, чтобы убрать какие-то ограничения, можно не искать где вы их прописали, а перейти во все параметры, сортировка по состоянию и быстро узнать какие параметры включены.

Пишите в комментариях или мне в личку свои заметки по различным ограничениям, которые внедряете на практике. Как будет достаточно интересных дополнений, выпущу вторую часть 😉

Настройка управления доступом и разрешениями на уровне пользователей Configure User Access Control and Permissions

Применяется к: Windows Admin Center, ознакомительная версия Windows Admin Center Applies to: Windows Admin Center, Windows Admin Center Preview

В средах рабочей группы или в доменах, не являющихся доверенными, доступ на основе групп в Windows Admin Center не поддерживается. Group based access in Windows Admin Center is not supported in workgroup environments or across non-trusted domains.

Определения ролей доступа к шлюзу Gateway access role definitions

Существует две роли для доступа к службе шлюза Windows Admin Center. There are two roles for access to the Windows Admin Center gateway service:

Пользователи шлюза могут подключаться к службе шлюза Windows Admin Center, чтобы через него управлять серверами, но не могут изменять разрешения доступа и механизм проверки подлинности, используемый для аутентификации шлюза. Gateway users can connect to the Windows Admin Center gateway service to manage servers through that gateway, but they can’t change access permissions nor the authentication mechanism used to authenticate to the gateway.

Администраторы шлюза могут настраивать доступ, а также способ выполнения проверки подлинности для пользователей на шлюзе. Gateway administrators can configure who gets access as well as how users authenticate to the gateway. Просматривать и настраивать параметры доступа в Windows Admin Center могут только администраторы шлюза. Only gateway administrators can view and configure the Access settings in Windows Admin Center. Локальные администраторы на компьютере шлюза всегда являются администраторами службы шлюза Windows Admin Center. Local administrators on the gateway machine are always administrators of the Windows Admin Center gateway service.

Доступ к шлюзу не подразумевает доступ к управляемым серверам, отображаемым шлюзом. Access to the gateway doesn’t imply access to managed servers visible by the gateway. Для управления целевым сервером подключающийся пользователь должен использовать учетные данные (через переданные учетные данные Windows или учетные данные, предоставленные в сеансе Windows Admin Center с помощью действия Управлять как) с административным доступом к этому целевому серверу. To manage a target server, the connecting user must use credentials (either through their passed-through Windows credential or through credentials provided in the Windows Admin Center session using the Manage as action) that have administrative access to that target server.

Active Directory или группы локальных компьютеров Active Directory or local machine groups

По умолчанию для управления доступом к шлюзу используются Active Directory или группы локальных компьютеров. By default, Active Directory or local machine groups are used to control gateway access. При наличии домена Active Directory доступом пользователей и администраторов шлюза можно управлять из интерфейса Windows Admin Center. If you have an Active Directory domain, you can manage gateway user and administrator access from within the Windows Admin Center interface.

На вкладке Пользователи можно указать пользователя, которому нужно предоставить доступ к Windows Admin Center в качестве пользователя шлюза. On the Users tab you can control who can access Windows Admin Center as a gateway user. По умолчанию, и если не указать группу безопасности, доступ будет иметь любой пользователь, обращающийся к URL-адресу шлюза. By default, and if you don’t specify a security group, any user that accesses the gateway URL has access. После добавления одной или нескольких групп безопасности в список пользователей доступ будет ограничен членами этих групп. Once you add one or more security groups to the users list, access is restricted to the members of those groups.

Если в вашей среде не используется домен Active Directory, доступ контролируется локальными группами Users и Administrators на компьютере шлюза Windows Admin Center. If you don’t use an Active Directory domain in your environment, access is controlled by the Users and Administrators local groups on the Windows Admin Center gateway machine.

Проверка подлинности смарт-карты Smartcard authentication

Вы можете принудительно применить проверку подлинности смарт-карты, указав дополнительную необходимую группу для групп безопасности на основе смарт-карты. You can enforce smartcard authentication by specifying an additional required group for smartcard-based security groups. После добавления группы безопасности на основе смарт-карты пользователь может получить доступ к службе Windows Admin Center, только если он является членом любой группы безопасности и группы смарт-карты, включенной в список пользователей. Once you have added a smartcard-based security group, a user can only access the Windows Admin Center service if they are a member of any security group AND a smartcard group included in the users list.

На вкладке Администраторы можно указать пользователя, которому нужно предоставить доступ к Windows Admin Center в качестве администратора шлюза. On the Administrators tab you can control who can access Windows Admin Center as a gateway administrator. Локальная группа администраторов на компьютере всегда будет иметь полный доступ администратора и ее не можно удалить из списка. The local administrators group on the computer will always have full administrator access and cannot be removed from the list. Добавляя группы безопасности, вы даете членам этих групп разрешения на изменение параметров шлюза Windows Admin Center. By adding security groups, you give members of those groups privileges to change Windows Admin Center gateway settings. Список администраторов поддерживает проверку подлинности смарт-карты такую же, как и для списка пользователей: с условием AND и для группы безопасности и для группы смарт-карт. The administrators list supports smartcard authentication in the same way as the users list: with the AND condition for a security group and a smartcard group.

Azure Active Directory Azure Active Directory

Если ваша организация использует Azure Active Directory (Azure AD), вы можете добавить дополнительный уровень безопасности в Windows Admin Center, требуя для доступа к шлюзу проверку подлинности Azure AD. If your organization uses Azure Active Directory (Azure AD), you can choose to add an additional layer of security to Windows Admin Center by requiring Azure AD authentication to access the gateway. Чтобы обеспечить доступ к Windows Admin Center, учетной записи Windows пользователя также следует предоставить доступ к серверу шлюза (даже при использовании проверки подлинности Azure AD). In order to access Windows Admin Center, the user’s Windows account must also have access to gateway server (even if Azure AD authentication is used). При использовании Azure AD управление правами доступа пользователя и администратора Windows Admin Center осуществляется на портале Azure, а не из пользовательского интерфейса Windows Admin Center. When you use Azure AD, you’ll manage Windows Admin Center user and administrator access permissions from the Azure Portal, rather than from within the Windows Admin Center UI.

Доступ к Windows Admin Center при включенной проверке подлинности Azure AD Accessing Windows Admin Center when Azure AD authentication is enabled

В зависимости от используемого браузера некоторые пользователи, обращающиеся к Windows Admin Center с настроенной проверкой подлинности Azure AD, получат дополнительный запрос из браузера, в котором нужно будет указать данные учетной записи Windows для компьютера, на котором установлен Windows Admin Center. Depending on the browser used, some users accessing Windows Admin Center with Azure AD authentication configured will receive an additional prompt from the browser where they need to provide their Windows account credentials for the machine on which Windows Admin Center is installed. После ввода этих данных пользователи увидят дополнительный запрос на проверку подлинности Azure Active Directory, для которого требуются учетные данные учетной записи Azure, которой предоставлен доступ к приложению Azure AD в Azure. After entering that information, the users will get the additional Azure Active Directory authentication prompt, which requires the credentials of an Azure account that has been granted access in the Azure AD application in Azure.

Пользователи, учетная запись Windows которых имеет права администратора на компьютере шлюза, не будут получать запрос на проверку подлинности Azure AD. Users who’s Windows account has Administrator rights on the gateway machine will not be prompted for the Azure AD authentication.

Настройка проверки подлинности Azure Active Directory для Windows Admin Center (Предварительная версия) Configuring Azure Active Directory authentication for Windows Admin Center Preview

В Windows Admin Center последовательно выберите Параметры > Доступ и используйте выключатель, чтобы включить параметр «Use Azure Active Directory to add a layer of security to the gateway» (Использовать Azure Active Directory для добавления уровня безопасности в шлюз). Go to Windows Admin Center Settings > Access and use the toggle switch to turn on «Use Azure Active Directory to add a layer of security to the gateway». Если вы не зарегистрировали шлюз в Azure, вам будет предложено сделать это в данный момент. If you have not registered the gateway to Azure, you will be guided to do that at this time.

По умолчанию все участники клиента Azure AD имеют доступ пользователей к службе шлюза Windows Admin Center. By default, all members of the Azure AD tenant have user access to the Windows Admin Center gateway service. Доступ администратора к шлюзу Windows Admin Center имеют только локальные администраторы на компьютере шлюза. Only local administrators on the gateway machine have administrator access to the Windows Admin Center gateway. Обратите внимание, что права локальных администраторов на компьютере шлюза нельзя ограничить. Локальные администраторы могут выполнять любые действия независимо от того, используется ли Azure AD для проверки подлинности или нет. Note that the rights of local administrators on the gateway machine cannot be restricted — local admins can do anything regardless of whether Azure AD is used for authentication.

Если вы хотите предоставить доступ к службе Windows Admin Center определенным пользователям Azure AD, группам пользователей шлюза или администраторам шлюза, необходимо выполнить следующие действия. If you want to give specific Azure AD users or groups gateway user or gateway administrator access to the Windows Admin Center service, you must do the following:

1. Перейдите в приложение Azure AD Windows Admin Center на портале Azure, используя гиперссылку, указанную в Параметрах доступа. Go to your Windows Admin Center Azure AD application in the Azure portal by using the hyperlink provided in Access Settings. Примечание. Эта гиперссылка доступна, только если включена проверка подлинности Azure Active Directory. Note this hyperlink is only available when Azure Active Directory authentication is enabled.
   • Приложение также можно найти на портале Azure, перейдя в Azure Active Directory >Корпоративные приложения >Все приложения и выполнив поиск по фразе WindowsAdminCenter (приложение Azure AD будет называться WindowsAdminCenter-). You can also find your application in the Azure portal by going to Azure Active Directory >Enterprise applications >All applications and searching WindowsAdminCenter (the Azure AD app will be named WindowsAdminCenter-). Если поиск не дает результатов, убедитесь, что для Показать задано значение Все приложения, а для Состояние приложения, а — Любой и нажмите кнопку «Применить», а затем повторите поиск. If you don’t get any search results, ensure Show is set to all applications, application status is set to any and click Apply, then try your search. Найдя приложение, перейдите в раздел Пользователи и группы Once you’ve found the application, go to Users and groups
2. На вкладке «Свойства» задайте для параметра Требуется назначение пользователей значение «Да». In the Properties tab, set User assignment required to Yes. После этого доступ к шлюзу Windows Admin Center смогут получить только участники, перечисленные на вкладке Пользователи и группы. Once you’ve done this, only members listed in the Users and groups tab will be able to access the Windows Admin Center gateway.
3. На вкладке «Пользователи и группы» выберите Добавить пользователя. In the Users and groups tab, select Add user. Для каждого добавляемого пользователя или группы необходимо назначить роль пользователя или администратора шлюза. You must assign a gateway user or gateway administrator role for each user/group added.

После включения проверки подлинности Azure AD служба шлюза перезапустится и вам потребуется обновить браузер. Once you turn on Azure AD authentication, the gateway service restarts and you must refresh your browser. Вы можете в любое время обновить доступ пользователя к приложению SME Azure AD на портале Azure. You can update user access for the SME Azure AD application in the Azure portal at any time.

При попытке доступа к URL-адресу шлюза Windows Admin Center пользователям будет предложено войти, используя удостоверение Azure Active Directory. Users will be prompted to sign in using their Azure Active Directory identity when they attempt to access the Windows Admin Center gateway URL. Помните, что пользователи также должны быть членами локальных «Пользователей» на сервере шлюза для доступа к центру администрирования Windows Admin Center. Remember that users must also be a member of the local Users on the gateway server to access Windows Admin Center.

Пользователи и администраторы могут просматривать текущую учетную запись, с которой они совершили вход, а также выйти из этой учетной записи Azure AD с вкладки Учетная запись в параметрах Windows Admin Center. Users and administrators can view their currently logged-in account and as well as sign-out of this Azure AD account from the Account tab of Windows Admin Center Settings.

Настройка проверки подлинности Azure Active Directory для Windows Admin Center Configuring Azure Active Directory authentication for Windows Admin Center

Чтобы настроить проверку подлинности Azure AD, необходимо сначала зарегистрировать шлюз в Azure (это необходимо сделать только один раз для шлюза Windows Admin Center). To set up Azure AD authentication, you must first register your gateway with Azure (you only need to do this once for your Windows Admin Center gateway). На этом этапе создается приложение Azure AD, с помощью которого вы можете управлять доступом пользователей шлюза и администраторов шлюза. This step creates an Azure AD application from which you can manage gateway user and gateway administrator access.

Если вы хотите предоставить доступ к службе Windows Admin Center определенным пользователям Azure AD, группам пользователей шлюза или администраторам шлюза, необходимо выполнить следующие действия. If you want to give specific Azure AD users or groups gateway user or gateway administrator access to the Windows Admin Center service, you must do the following:

1. Перейдите к приложению SME Azure AD на портале Azure. Go to your SME Azure AD application in the Azure portal.
   • Если щелкнуть Изменить контроль доступа, а затем выбрать Azure Active Directory из раздела параметров доступа Windows Admin Center, можно использовать гиперссылку, предоставленную в пользовательском интерфейсе, для доступа к приложению Azure AD на портале Azure. When you click Change access control and then select Azure Active Directory from the Windows Admin Center Access settings, you can use the hyperlink provided in the UI to access your Azure AD application in the Azure portal. Эта гиперссылка также доступна в параметрах доступа после нажатия кнопки «Сохранить» и выбора Azure AD в качестве поставщика удостоверений управления доступом. This hyperlink is also available in the Access settings after you click save and have selected Azure AD as your access control identity provider.
   • Приложение также можно найти на портале Azure, перейдя в Azure Active Directory >Корпоративные приложения >Все приложения и выполнив поиск по фразе SME (приложение Azure AD будет называться SME-). You can also find your application in the Azure portal by going to Azure Active Directory >Enterprise applications >All applications and searching SME (the Azure AD app will be named SME-). Если поиск не дает результатов, убедитесь, что для Показать задано значение Все приложения, а для Состояние приложения, а — Любой и нажмите кнопку «Применить», а затем повторите поиск. If you don’t get any search results, ensure Show is set to all applications, application status is set to any and click Apply, then try your search. Найдя приложение, перейдите в раздел Пользователи и группы Once you’ve found the application, go to Users and groups
2. На вкладке «Свойства» задайте для параметра Требуется назначение пользователей значение «Да». In the Properties tab, set User assignment required to Yes. После этого доступ к шлюзу Windows Admin Center смогут получить только участники, перечисленные на вкладке Пользователи и группы. Once you’ve done this, only members listed in the Users and groups tab will be able to access the Windows Admin Center gateway.
3. На вкладке «Пользователи и группы» выберите Добавить пользователя. In the Users and groups tab, select Add user. Для каждого добавляемого пользователя или группы необходимо назначить роль пользователя или администратора шлюза. You must assign a gateway user or gateway administrator role for each user/group added.

Как только вы сохраните контроль доступа Azure AD в панели Изменить контроль доступа, служба шлюза перезапустится и вам потребуется обновить свой браузер. Once you save the Azure AD access control in the Change access control pane, the gateway service restarts and you must refresh your browser. Вы можете в любое время обновить доступ пользователя к приложению Windows Admin Center Azure AD на портале Azure. You can update user access for the Windows Admin Center Azure AD application in the Azure portal at any time.

При попытке доступа к URL-адресу шлюза Windows Admin Center пользователям будет предложено войти, используя удостоверение Azure Active Directory. Users will be prompted to sign in using their Azure Active Directory identity when they attempt to access the Windows Admin Center gateway URL. Помните, что пользователи также должны быть членами локальных «Пользователей» на сервере шлюза для доступа к центру администрирования Windows Admin Center. Remember that users must also be a member of the local Users on the gateway server to access Windows Admin Center.

Используя вкладку Azure в общих параметрах Windows Admin Center, пользователи и администраторы могут просматривать текущую учетную запись, с которой они совершили вход, а также выйти из этой учетной записи Azure AD. Using the Azure tab of Windows Admin Center general settings, users and administrators can view their currently logged-in account and as well as sign-out of this Azure AD account.

Условный доступ и многофакторная проверка подлинности Conditional access and multi-factor authentication

Одним из преимуществ использования Azure AD в качестве дополнительного уровня безопасности для контроля доступа к шлюзу Windows Admin Center является то, что вы можете использовать эффективные функции безопасности Azure AD, такие как условный доступ и многофакторная проверка подлинности. One of the benefits of using Azure AD as an additional layer of security to control access to the Windows Admin Center gateway is that you can leverage Azure AD’s powerful security features like conditional access and multi-factor authentication.

Настройте единый вход Configure single sign-on

Единый вход при развертывании в качестве службы в Windows Server Single sign-on when deployed as a Service on Windows Server

После установки Windows Admin Center в Windows 10 все готово к использованию единого входа. When you install Windows Admin Center on Windows 10, it’s ready to use single sign-on. Однако если вы собираетесь использовать Windows Admin Center в Windows Server, то перед использованием единого входа необходимо настроить в среде некоторую форму делегирования Kerberos. If you’re going to use Windows Admin Center on Windows Server, however, you need to set up some form of Kerberos delegation in your environment before you can use single sign-on. Делегирование настраивает компьютер шлюза как доверенный для делегирования к целевому узлу. The delegation configures the gateway computer as trusted to delegate to the target node.

Используйте следующий пример PowerShell, чтобы настроить ограниченное делегирование на основе ресурсов в вашей среде. To configure Resource-based constrained delegation in your environment, use the following PowerShell example. В этом примере показано, как настроить Windows Server [node01.contoso.com] для принятия делегирования из шлюза Windows Admin Center [wac.contoso.com] в домене contoso.com. This example shows how you would configure a Windows Server [node01.contoso.com] to accept delegation from your Windows Admin Center gateway [wac.contoso.com] in the contoso.com domain.

Чтобы удалить эту связь, выполните следующий командлет: To remove this relationship, run the following cmdlet:

Управление доступом на основе ролей Role-based access control

Управление доступом на основе ролей позволяет предоставлять пользователям ограниченный доступ к компьютеру, не делая их полными локальными администраторами. Role-based access control enables you to provide users with limited access to the machine instead of making them full local administrators. Role-based access control (Управление доступом на основе ролей) Read more about role-based access control and the available roles.

Настройка RBAC состоит из 2 шагов: включения поддержки на целевых компьютерах и назначения пользователям соответствующих ролей. Setting up RBAC consists of 2 steps: enabling support on the target computer(s) and assigning users to the relevant roles.

Убедитесь, что у вас есть права локального администратора на компьютерах, для которых вы настраиваете поддержку управления доступом на основе ролей. Make sure you have local administrator privileges on the machines where you are configuring support for role-based access control.

Применение управления доступом на основе ролей к одному компьютеру Apply role-based access control to a single machine

Модель развертывания на одном компьютере идеально подходит для простых сред, в которых управление нужно представить только нескольким компьютерам. The single machine deployment model is ideal for simple environments with only a few computers to manage. Настройка компьютера с поддержкой управления доступом на основе ролей приведет к следующим изменениям: Configuring a machine with support for role-based access control will result in the following changes:

• Модули PowerShell с функциями, необходимыми для Windows Admin Center, будут установлены на системный диск в C:\Program Files\WindowsPowerShell\Modules . PowerShell modules with functions required by Windows Admin Center will be installed on your system drive, under C:\Program Files\WindowsPowerShell\Modules . Все модули будут начинаться с Microsoft.Sme All modules will start with Microsoft.Sme
• Desired State Configuration выполняет одноразовую настройку для конфигурации конечной точки профиля «Достаточно для администрирования» на компьютере с именем Microsoft.Sme.PowerShell. Desired State Configuration will run a one-time configuration to configure a Just Enough Administration endpoint on the machine, named Microsoft.Sme.PowerShell. Эта конечная точка определяет 3 роли, используемые Windows Admin Center, и при подключении к нему пользователя будет запускаться как временный локальный администратор. This endpoint defines the 3 roles used by Windows Admin Center and will run as a temporary local administrator when a user connects to it.
• Чтобы управлять, каким пользователям назначен доступ к каким ролям, будут созданы 3 новые локальные группы: 3 new local groups will be created to control which users are assigned access to which roles:
  • Администраторы Windows Admin Center Windows Admin Center Administrators
  • Администраторы Hyper-V Windows Admin Center Windows Admin Center Hyper-V Administrators
  • Читатели Windows Admin Center Windows Admin Center Readers

Чтобы включить поддержку управления доступом на основе ролей на одном компьютере, выполните следующие действия. To enable support for role-based access control on a single machine, follow these steps:

1. Откройте Windows Admin Center и подключитесь к компьютеру, который нужно настроить для управления доступом на основе ролей, используя на целевом компьютере учетную запись с правами локального администратора. Open Windows Admin Center and connect to the machine you wish to configure with role-based access control using an account with local administrator privileges on the target machine.
2. В инструменте Обзор щелкните Настройки >Контроль доступа на основе ролей. On the Overview tool, click Settings >Role-based access control.
3. Щелкните Применить в нижней части страницы, чтобы включить на целевом компьютере поддержку управления доступом на основе ролей. Click Apply at the bottom of the page to enable support for role-based access control on the target computer. Процесс приложения включает копирование скриптов PowerShell и вызов конфигурации (с помощью Desired State Configuration PowerShell) на целевом компьютере. The application process involves copying PowerShell scripts and invoking a configuration (using PowerShell Desired State Configuration) on the target machine. Выполнение может занять до 10 минут, и приведет к перезапуску WinRM. It may take up to 10 minutes to complete, and will result in WinRM restarting. Это приведет к временному отключению пользователей Windows Admin Center, PowerShell и WMI. This will temporarily disconnect Windows Admin Center, PowerShell, and WMI users.
4. Обновите страницу, чтобы проверить состояние управления доступом на основе ролей. Refresh the page to check the status of role-based access control. Когда оно будет готово к использованию, состояние изменится на Применено. When it is ready for use, the status will change to Applied.

После применения конфигурации вы можете назначить пользователям приведенные ниже роли. Once the configuration is applied, you can assign users to the roles:

1. Откройте средство Локальные пользователи и группы и перейдите на вкладку Группы. Open the Local Users and Groups tool and navigate to the Groups tab.
2. Выберите группу Читатели Windows Admin Center. Select the Windows Admin Center Readers group.
3. В нижней части панели Детали нажмите Добавить пользователя и введите имя пользователя или группы безопасности, для которых следует настроить доступ к серверу через Windows Admin Center только для чтения. In the Details pane at the bottom, click Add User and enter the name of a user or security group which should have read-only access to the server through Windows Admin Center. Пользователи и группы могут поступать с локального компьютера или домена Active Directory. The users and groups can come from the local machine or your Active Directory domain.
4. Повторите шаги 2-3 для групп Администраторы Hyper-V Windows Admin Center и Администраторы Windows Admin Center. Repeat steps 2-3 for the Windows Admin Center Hyper-V Administrators and Windows Admin Center Administrators groups.

Вы также можете последовательно заполнять эти группы по всему домену, настраивая объект групповой политики с помощью параметра Restricted Groups Policy Setting (Настройка политики групп с ограниченным доступом). You can also fill these groups consistently across your domain by configuring a Group Policy Object with the Restricted Groups Policy Setting.

Применение управления доступом на основе ролей к нескольким компьютерам Apply role-based access control to multiple machines

При развертывании на крупном предприятии вы можете использовать существующие средства автоматизации для распространения функции управления доступом на основе ролей на компьютеры, скачав пакет конфигурации со шлюза Windows Admin Center. In a large enterprise deployment, you can use your existing automation tools to push out the role-based access control feature to your computers by downloading the configuration package from the Windows Admin Center gateway. Пакет конфигурации предназначен для использования с Desired State Configuration PowerShell, но его можно адаптировать для работы с предпочтительным решением для автоматизации. The configuration package is designed to be used with PowerShell Desired State Configuration, but you can adapt it to work with your preferred automation solution.

Скачивание конфигурации управления доступом на основе ролей Download the role-based access control configuration

Чтобы загрузить пакет конфигурации управления доступом на основе ролей, необходимо иметь доступ к Windows Admin Center и командной строке PowerShell. To download the role-based access control configuration package, you’ll need to have access to Windows Admin Center and a PowerShell prompt.

Если вы используете шлюз Windows Admin Center в Windows Server в режиме службы, используйте следующую команду, чтобы скачать пакет конфигурации. If you’re running the Windows Admin Center gateway in service mode on Windows Server, use the following command to download the configuration package. Не забудьте обновить адрес шлюза, указав подходящий для своей среды. Be sure to update the gateway address with the correct one for your environment.

Если вы используете шлюз Windows Admin Center на компьютере с Windows 10, выполните следующую команду: If you’re running the Windows Admin Center gateway on your Windows 10 machine, run the following command instead:

При развертывании ZIP-архива вы увидите следующую структуру папок: When you expand the zip archive, you’ll see the following folder structure:

• InstallJeaFeatures.ps1 InstallJeaFeatures.ps1
• JustEnoughAdministration (каталог) JustEnoughAdministration (directory)
• Модули (каталог) Modules (directory)
  • Microsoft.SME.* (каталоги) Microsoft.SME.* (directories)
  • WindowsAdminCenter.Jea (каталог) WindowsAdminCenter.Jea (directory)

Чтобы настроить поддержку управления доступом на основе ролей на узле, необходимо выполнить следующие действия. To configure support for role-based access control on a node, you need to perform the following actions:

1. Скопируйте JustEnoughAdministration, Microsoft.SME.* и модули WindowsAdminCenter.Jea в каталог модуля PowerShell на целевом компьютере. Copy the JustEnoughAdministration, Microsoft.SME.*, and WindowsAdminCenter.Jea modules to the PowerShell module directory on the target machine. Как правило, они расположены в C:\Program Files\WindowsPowerShell\Modules . Typically, this is located at C:\Program Files\WindowsPowerShell\Modules .
2. Обновите файл InstallJeaFeature.ps1 в соответствии с требуемой конфигурацией для конечной точки RBAC. Update InstallJeaFeature.ps1 file to match your desired configuration for the RBAC endpoint.
3. Запустите InstallJeaFeature.ps1, чтобы скомпилировать ресурс DSC. Run InstallJeaFeature.ps1 to compile the DSC resource.
4. Разверните конфигурацию DSC на всех компьютерах, чтобы применить ее. Deploy your DSC configuration to all of your machines to apply the configuration.

В следующем разделе объясняется, как это сделать с помощью удаленного взаимодействия PowerShell. The following section explains how to do this using PowerShell Remoting.

Развертывание на нескольких компьютерах Deploy on multiple machines

Чтобы развернуть конфигурацию, загруженную на несколько компьютеров, необходимо обновить скрипт InstallJeaFeatures.ps1, чтобы включить соответствующие группы безопасности для среды, скопировать файлы на каждый из компьютеров и вызвать скрипты конфигурации. To deploy the configuration you downloaded onto multiple machines, you’ll need to update the InstallJeaFeatures.ps1 script to include the appropriate security groups for your environment, copy the files to each of your computers, and invoke the configuration scripts. Для этого можно использовать предпочтительные средства автоматизации, однако в этой статье основное внимание уделяется чистому подходу на основе PowerShell. You can use your preferred automation tooling to accomplish this, however this article will focus on a pure PowerShell-based approach.

По умолчанию скрипт конфигурации будет создавать локальные группы безопасности на компьютере, чтобы управлять доступом к каждой из ролей. By default, the configuration script will create local security groups on the machine to control access to each of the roles. Это подходит для компьютеров, присоединенных к рабочей группе и доменам, но если развертывание выполняется в среде только для домена, вам может потребоваться напрямую связать группу безопасности домена с каждой ролью. This is suitable for workgroup and domain joined machines, but if you’re deploying in a domain-only environment you may wish to directly associate a domain security group with each role. Чтобы обновить конфигурацию для использования групп безопасности домена, откройте InstallJeaFeatures.ps1 и внесите следующие изменения: To update the configuration to use domain security groups, open InstallJeaFeatures.ps1 and make the following changes:

1. Удалите из файла 3 ресурсы группы: Remove the 3 Group resources from the file:
   1. «Группа MS-Readers-Group» «Group MS-Readers-Group»
   2. «Группа MS-Hyper-V-Administrators-Group» «Group MS-Hyper-V-Administrators-Group»
   3. «Группа MS-Administrators-Group» «Group MS-Administrators-Group»
2. Удалите 3 ресурса группы из свойства JeaEndpoint DependsOn Remove the 3 Group resources from the JeaEndpoint DependsOn property
   1. «[Group]MS-Readers-Group» «[Group]MS-Readers-Group»
   2. «[Group]MS-Hyper-V-Administrators-Group» «[Group]MS-Hyper-V-Administrators-Group»
   3. «[Group]MS-Administrators-Group» «[Group]MS-Administrators-Group»
3. Измените имена групп в свойстве JeaEndpoint RoleDefinitions на нужные группы безопасности. Change the group names in the JeaEndpoint RoleDefinitions property to your desired security groups. Например, если у вас есть группа безопасности CONTOSO\MyTrustedAdmins, которой нужно назначить доступ с ролью администраторов Windows Admin Center, измените ‘$env:COMPUTERNAME\Windows Admin Center Administrators’ на ‘CONTOSO\MyTrustedAdmins’ . For example, if you have a security group CONTOSO\MyTrustedAdmins that should be assigned access to the Windows Admin Center Administrators role, change ‘$env:COMPUTERNAME\Windows Admin Center Administrators’ to ‘CONTOSO\MyTrustedAdmins’ . Ниже перечислены три строки, которые необходимо обновить. The three strings you need to update are:
   1. ‘$env:COMPUTERNAME\Windows Admin Center Administrators’ ‘$env:COMPUTERNAME\Windows Admin Center Administrators’
   2. ‘$env:COMPUTERNAME\Windows Admin Center Hyper-V Administrators’ ‘$env:COMPUTERNAME\Windows Admin Center Hyper-V Administrators’
   3. ‘$env:COMPUTERNAME\Windows Admin Center Readers’ ‘$env:COMPUTERNAME\Windows Admin Center Readers’

Обязательно используйте уникальные группы безопасности для каждой роли. Be sure to use unique security groups for each role. Если одна и та же группа безопасности назначена нескольким ролям, настройка завершится ошибкой. Configuration will fail if the same security group is assigned to multiple roles.