Active Directory разграничение прав

Как делегировать контроль над OU в Active Directory

В крупных организациях существует несколько команд ИТ-администраторов и специалистов службы поддержки и в этом случае необходимо делегирование полномочий. Например, специалисты службы поддержки или руководители групп могут сбрасывать пароли, системные администраторы могут изменять членство в группах, а управлять OU могут только ИТ-архитекторы.

Такое разделение обязанностей действительно полезно для оптимизации операций и безопасности.

rocket img

cta

Чтобы выполнить делегирование управления, администраторы домена должны иметь разрешения или полные привилегии управления над OU. Это можно сделать несколькими способами: через Active Directory Users and Computers, командную строку, группы и пр.

Делегирование через Active Directory Users and Computers

Для того чтобы делегировать управление через Active Directory Users and Computers (dsa.msc). Выполните следующие действия:

Запустите Active Directory Users and Computers. Щелкните правой кнопкой мыши на OU, которому вы хотите делегировать управление, и выберите Delegate Control.

dc1

Появится мастер делегирования контроля, где вам нужно нажать «Next«.

В появившемся окне нужно нажать «Add. » и выбрать пользователей или группы, которым вы хотите делегировать управление, и нажать «Next«.

В окне «Tasks to Delegate» выберите задачи, которые вы хотите делегировать, вы также можете создать пользовательскую задачу с нуля.

dc2

Нажмите Next и Finish

Разрешения на делегирование можно просмотреть в свойствах OU на вкладке Security.

Делегирование через командную строку

Для делегирования прав доступа компания Microsoft разработала сервис dsacls.exe. Он хорошо подходит для назначения делегирования посредством скриптов. Он также хорошо подходит для отображения текущих прав доступа. Вы можете использовать параметр /a для отображения всех прав доступа у OU, например:

dsacls.exe «OU=Employees,DC=office,dc=local» /a

dc4

Здесь мы видим права доступа KJenkins, которые мы делегировали в нашем предыдущем примере.

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

Наиболее популярные расширенные права:

Давайте делегируем нашему пользователю KJenkins права на удаление OU Employees:

dsacls.exe «OU=Employees,DC=office,DC=local» /G OFFICE\KJenkins:SD;

Делегирование через встроенные группы

По умолчанию существуют встроенные группы, такие как Account Operators и Server Operators, которые выполняют административные задачи в Active Directory.

Вы можете включить любого пользователя в эти группы и получить дополнительные полномочия в домене без необходимости предоставления полного доступа к управлению. Но имейте в виду, что встроенная группа Account Operators предоставляет больше разрешений, чем требуется на самом деле. Они могут создавать, изменять и удалять все объекты, кроме членов группы Domain Admins, во всех OU, кроме OU Domain Controllers.

Лучшие практики по делегированию прав в OU

— Постройте матрицу управления делегированием, чтобы документировать все права доступа к AD

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

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

— Попробуйте протестировать настройки делегирования на предмет нежелательных эффектов.

Источник

Группы безопасности Active Directory

Область применения

Эта справочная тема для ИТ-специалистов описывает группы безопасности Active Directory по умолчанию.

В Active Directory существуют две формы общих принципов безопасности: учетные записи пользователей и учетные записи компьютеров. Эти учетные записи представляют физическое лицо (лицо или компьютер). Учетные записи пользователей также можно использовать в качестве специальных учетных записей служб для некоторых приложений. Группы безопасности используются для сбора учетных записей пользователей, учетных записей компьютеров и других групп в управляемые подразделения.

В операционной Windows Server существует несколько встроенных учетных записей и групп безопасности, которые предварительно сконфигурировали соответствующие права и разрешения для выполнения определенных задач. Для Active Directory существуют два типа административных обязанностей:

Администраторы служб Отвечает за обслуживание и доставку служб домена Active Directory (AD DS), включая управление контроллерами домена и настройку AD DS.

Администраторы данных Отвечает за ведение данных, хранимых в AD DS и на серверах членов домена и рабочих станциях.

О группах Active Directory

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

В Active Directory существует два типа групп:

Группы рассылки Используется для создания списков рассылки электронной почты.

Группы безопасности Используется для назначения разрешений общим ресурсам.

Группы рассылки

Группы рассылки можно использовать только в приложениях электронной почты (например, Exchange Server) для отправки электронной почты в коллекции пользователей. Группы рассылки не включены в службу безопасности, что означает, что они не могут быть указаны в списках управления дискреционным доступом (DACLs).

Группы безопасности

Группы безопасности могут эффективно назначать доступ к ресурсам в сети. С помощью групп безопасности можно:

Назначьте права пользователей группам безопасности в Active Directory.

Права пользователей назначены группе безопасности для определения того, что члены этой группы могут делать в области домена или леса. Права пользователей автоматически назначены некоторым группам безопасности при установке Active Directory, чтобы помочь администраторам определить административную роль человека в домене.

Например, пользователь, добавленный в группу операторов резервного копирования в Active Directory, имеет возможность резервного копирования и восстановления файлов и каталогов, расположенных на каждом контроллере домена в домене. Это возможно, так как по **** умолчанию файлы и **** каталоги резервного копирования прав пользователей и файлы и каталоги восстановления автоматически назначены группе операторов резервного копирования. Поэтому члены этой группы наследуют права пользователей, которые назначены этой группе.

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

Назначение разрешений группам безопасности для ресурсов.

Разрешения отличаются от прав пользователей. Разрешения назначены группе безопасности для общего ресурса. Разрешения определяют, кто может получить доступ к ресурсу и уровню доступа, например Full Control. Некоторые разрешения, установленные на объектах домена, автоматически назначены, чтобы разрешить различные уровни доступа к группам безопасности по умолчанию, таким как группа операторов учетных записей или группа администраторов домена.

Группы безопасности перечислены в DACLs, определяя разрешения на ресурсы и объекты. При назначении разрешений для ресурсов (файловых акций, принтеров и так далее) администраторы должны назначать эти разрешения группе безопасности, а не отдельным пользователям. Разрешения назначены группе один раз, а не несколько раз каждому отдельному пользователю. Каждая учетная запись, добавляемая в группу, получает права, которые назначены этой группе в Active Directory, а пользователь получает разрешения, определенные для этой группы.

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

Область групповой

Группы характеризуются областью, определяемой степенью применения группы в дереве домена или лесу. Область группы определяет, где группе могут быть предоставлены разрешения. В Active Directory определяются следующие три групповых области:

Помимо этих трех областей, группы по умолчанию в контейнере Builtin имеют групповую область Builtin Local. Этот групповой и групповой тип не могут быть изменены.

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

Области группы

Учетные записи из любого домена в одном лесу

Глобальные группы из любого домена в одном лесу

Другие универсальные группы из любого домена в том же лесу

Можно преобразовать в область Domain Local, если группа не является членом каких-либо других универсальных групп.

Можно преобразовать в глобальную область, если группа не содержит других универсальных групп

На любом домене в одном лесу или доверчивых лесах

Другие универсальные группы в том же лесу

Локальные группы домена в одном лесу или доверчивых лесах

Локальные группы на компьютерах в одном лесу или доверчивых лесах

Учетные записи из того же домена

Другие глобальные группы из того же домена

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

На любом домене в одном лесу или доверчивых доменах или лесах

Универсальные группы из любого домена в одном лесу

Другие глобальные группы из того же домена

Локальные группы домена из любого домена в том же лесу или из любого доверчивых доменов

Учетные записи из любого домена или любого доверенного домена

Глобальные группы из любого домена или любого доверенного домена

Универсальные группы из любого домена в одном лесу

Другие локальные группы домена из того же домена

Учетные записи, глобальные группы и универсальные группы из других лесов и из внешних доменов

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

Другие локальные группы домена из того же домена

Локальные группы на компьютерах в том же домене, за исключением встроенных групп с хорошо известными SID-данными

Специальные группы удостоверений

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

Сведения обо всех специальных группах удостоверений см. в special Identitys.

Группы безопасности по умолчанию

Группы по умолчанию, такие как группа администраторов домена, являются группами безопасности, которые создаются автоматически при создании домена Active Directory. Эти заранее определенные группы можно использовать для управления доступом к общим ресурсам и делегирования определенных административных ролей в домене.

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

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

Группы по умолчанию находятся в контейнере Builtin и в контейнере Users в Active Directory Users and Computers. Контейнер Builtin включает группы, определяемые областью Domain Local. Пользователи включают в себя группы, определяемые с глобальной областью, и группы, определяемые с локальной областью домена. Группы, расположенные в этих контейнерах, можно переместить в другие группы или организационные подразделения (OU) в домен, но их нельзя переместить в другие домены.

Некоторые административные группы, перечисленные в этой теме, и все члены этих групп защищены фоновой процедурой, которая периодически проверяет и применяет определенный дескриптор безопасности. Этот дескриптор — это структура данных, которая содержит сведения о безопасности, связанные с защищенным объектом. Этот процесс гарантирует, что любая успешная несанкционированная попытка изменить дескриптор безопасности в одной из административных учетных записей или групп будет перезаписана с защищенными настройками.

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

Группы безопасности active Directory по умолчанию по версии операционной системы

В следующих таблицах описаны группы по умолчанию, расположенные в контейнерах Builtin и Users в каждой операционной системе.

Источник

Делегирование административных полномочий в Active Directory

В этой статье мы рассмотрим особенности делегирования административных полномочий в домене Active Directory. Делегирование позволяет предоставить право на выполнение некоторых задач управления в AD обычным пользователям домена, не включая их в привилегированные доменные группы, такие как Domain Admins, Account Operators и т.д.. Например, с помощью делегирования вы можете предоставить определённой группе пользователей (допустим, Helpdesk) право на добавление пользователей в группы, заведение новых пользователей в AD и сброс пароля.

Особенности делегирования прав в AD

Для делегации полномочий в AD используется мастер Delegation of Control Wizard в графической оснастке Active Directory Users and Computers (DSA.msc).

Административные права в AD можно делегировать на довольно детальном уровне. Одной группе можно предоставить право на сброс пароля в OU, другой – на создание и удаление аккаунтов, третье на сброс пароля. Можно настроить наследование разрешений на вложенные OU. Вы можете делегировать полномочия на уровне:

Обычно не рекомендуется делегировать разрешения непосредственно для пользователя. Вместо этого создайте в AD новую группу безопасности, добавьте в нее пользователя и делегируйте полномочия на OU для группы. Если вам понадобится предоставить такие же права в домене еще одному пользователю, вам будет достаточно добавить его в группу безопасности.

Делегирование полномочий на сброс паролей и разблокировку учетных записей

Представим, наша задача – предоставить группе HelpDesk право на сброс пароля и разблокировку аккаунтов пользователей в домене. Итак, создадим новую группу в AD с помощью PowerShell:

Добавьте в группу нужных пользователей:

Запустите консоль Active Directory Users and Computers (ADUC), щелкните ПКМ по OU с пользователями (в нашем примере это ‘OU=Users,OU=Moscow,DC=corp,dc=winitpro,DC=ru’) и выберите пункт меню Delegate Control.

delegate control

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

vybrat gruppu dlya delegirovaniya polnomochij

Выберите из списка один из преднастроенных наборов привилегий (Delegate the following common tasks):

Либо создайте собственное задание делегирования (Create a custom task to delegate). Я выберу второй вариант.

create a custom task to delegate

Выберите тип объектов AD, на которые нужно предоставить права. Т.к. нам нужно предоставить права на учетные записи пользователей, выберите пункт User Object. Если вы хотите предоставить право на создание и удаление пользователей в этом OU, выберите опции Create/Delete selected objects in this folder. В нашем примере мы не предоставляем таких полномочий.

user object

В списке разрешений нужно выбрать те привилегий, которые вы хотите делегировать. В нашем примере мы выберем право на разблокировку (Read lockoutTime и Write lockoutTime) и сброс пароля (Reset password).

read lockouttime i write lockouttime

Нажмите Next и на последнем экране подтвердите назначение выбранных полномочий.

master delegirovaniya polnomochij v active directory

Теперь под учетной записью пользователя из группы HelpDesk попробуйте из PowerShell сбросить пароль пользователя из OU Users, например из PowerShell:

Пароль должен сброситься успешно (если он соответствует доменной политике паролей).

Теперь попробуйте создать пользователя в данной OU с помомью командлета New-ADUser:

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

Для контроля пользователям, которым вы делегированными привилегии, вы можете использовать журналы контроллеров домена. Например, вы можете отследить кто сбросил пароль пользователя в домене, узнать кто создал учетную запись пользователя в AD или отследить изменения в определённых группах AD.

Делегация полномочий на присоединение компьютеров в домен AD

По умолчанию любой пользователь домена может присоединить в домен 10 компьютеров. При добавлении в домен 11-го компьютера появляется сообщение об ошибке.

you have exceeded the maximum number of computer a

Вы можете изменить это ограничение на уровне всего домена, увеличив значение в атрибуте ms-DS-MachineAccountQuota (ссылка). Либо (гораздо правильнее и безопаснее), делегировав право на присоединение компьютеров к домену в определенной OU конкретной группе пользователей (helpdesk). Для этого нужно предоставить право создавать объекты типа (Computer objects). В мастере делегирования выберите Create selected objects in this folder.

create selected objects in this folder

А в секции Permissions выберите Create All Child Objects.

delegirovat pravo na sozdanie obuektov v ad

Отключаем делегирование прав в домене AD

Чтобы лишить группу делегированных ранее прав на OU, откройте свойства OU в консоли ADUC и перейдите на вкладку Security.

rasshirennye nastrojki delegirovaniya v ad

В списке разрешений найдите группу, который вы делегировали права и нажмите Remove. Список предоставленных полномочий можно посмотреть на вкладке Advanced. Как вы видите для группы HelpDesk разрешен сброс паролей.

Источник

Настройка управления доступом и разрешениями на уровне пользователей

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

В средах рабочей группы или в доменах, не являющихся доверенными, доступ на основе групп в Windows Admin Center не поддерживается.

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

Существует две роли для доступа к службе шлюза Windows Admin Center.

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

Администраторы шлюза могут настраивать доступ, а также способ выполнения проверки подлинности для пользователей на шлюзе. Просматривать и настраивать параметры доступа в Windows Admin Center могут только администраторы шлюза. Локальные администраторы на компьютере шлюза всегда являются администраторами службы шлюза Windows Admin Center.

Доступ к шлюзу не подразумевает доступ к управляемым серверам, отображаемым шлюзом. Для управления целевым сервером подключающийся пользователь должен использовать учетные данные (через переданные учетные данные Windows или учетные данные, предоставленные в сеансе Windows Admin Center с помощью действия Управлять как) с административным доступом к этому целевому серверу.

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

По умолчанию для управления доступом к шлюзу используются Active Directory или группы локальных компьютеров. При наличии домена Active Directory доступом пользователей и администраторов шлюза можно управлять из интерфейса Windows Admin Center.

На вкладке Пользователи можно указать пользователя, которому нужно предоставить доступ к Windows Admin Center в качестве пользователя шлюза. По умолчанию, и если не указать группу безопасности, доступ будет иметь любой пользователь, обращающийся к URL-адресу шлюза. После добавления одной или нескольких групп безопасности в список пользователей доступ будет ограничен членами этих групп.

Если в вашей среде не используется домен Active Directory, доступ контролируется локальными группами Users и Administrators на компьютере шлюза Windows Admin Center.

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

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

На вкладке Администраторы можно указать пользователя, которому нужно предоставить доступ к Windows Admin Center в качестве администратора шлюза. Локальная группа администраторов на компьютере всегда будет иметь полный доступ администратора и ее не можно удалить из списка. Добавляя группы безопасности, вы даете членам этих групп разрешения на изменение параметров шлюза Windows Admin Center. Список администраторов поддерживает проверку подлинности смарт-карты такую же, как и для списка пользователей: с условием AND и для группы безопасности и для группы смарт-карт.

Azure Active Directory

Если ваша организация использует Azure Active Directory (Azure AD), вы можете добавить дополнительный уровень безопасности в Windows Admin Center, требуя для доступа к шлюзу проверку подлинности Azure AD. Чтобы обеспечить доступ к Windows Admin Center, учетной записи Windows пользователя также следует предоставить доступ к серверу шлюза (даже при использовании проверки подлинности Azure AD). При использовании Azure AD управление правами доступа пользователя и администратора Windows Admin Center осуществляется на портале Azure, а не из пользовательского интерфейса Windows Admin Center.

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

В зависимости от используемого браузера некоторые пользователи, обращающиеся к Windows Admin Center с настроенной проверкой подлинности Azure AD, получат дополнительный запрос из браузера, в котором нужно будет указать данные учетной записи Windows для компьютера, на котором установлен Windows Admin Center. После ввода этих данных пользователи увидят дополнительный запрос на проверку подлинности Azure Active Directory, для которого требуются учетные данные учетной записи Azure, которой предоставлен доступ к приложению Azure AD в Azure.

Пользователи, учетная запись Windows которых имеет права администратора на компьютере шлюза, не будут получать запрос на проверку подлинности Azure AD.

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

В Windows Admin Center последовательно выберите Параметры > Доступ и используйте выключатель, чтобы включить параметр «Use Azure Active Directory to add a layer of security to the gateway» (Использовать Azure Active Directory для добавления уровня безопасности в шлюз). Если вы не зарегистрировали шлюз в Azure, вам будет предложено сделать это в данный момент.

По умолчанию все участники клиента Azure AD имеют доступ пользователей к службе шлюза Windows Admin Center. Доступ администратора к шлюзу Windows Admin Center имеют только локальные администраторы на компьютере шлюза. Обратите внимание, что права локальных администраторов на компьютере шлюза нельзя ограничить. Локальные администраторы могут выполнять любые действия независимо от того, используется ли Azure AD для проверки подлинности или нет.

Если вы хотите предоставить доступ к службе Windows Admin Center определенным пользователям Azure AD, группам пользователей шлюза или администраторам шлюза, необходимо выполнить следующие действия.

После включения проверки подлинности Azure AD служба шлюза перезапустится и вам потребуется обновить браузер. Вы можете в любое время обновить доступ пользователя к приложению SME Azure AD на портале Azure.

При попытке доступа к URL-адресу шлюза Windows Admin Center пользователям будет предложено войти, используя удостоверение Azure Active Directory. Помните, что пользователи также должны быть членами локальных «Пользователей» на сервере шлюза для доступа к центру администрирования Windows Admin Center.

Пользователи и администраторы могут просматривать текущую учетную запись, с которой они совершили вход, а также выйти из этой учетной записи Azure AD с вкладки Учетная запись в параметрах Windows Admin Center.

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

Чтобы настроить проверку подлинности Azure AD, необходимо сначала зарегистрировать шлюз в Azure (это необходимо сделать только один раз для шлюза Windows Admin Center). На этом этапе создается приложение Azure AD, с помощью которого вы можете управлять доступом пользователей шлюза и администраторов шлюза.

Как только вы сохраните контроль доступа Azure AD в панели Изменить контроль доступа, служба шлюза перезапустится и вам потребуется обновить свой браузер. Вы можете в любое время обновить доступ пользователя к приложению Windows Admin Center Azure AD на портале Azure.

Используя вкладку Azure в общих параметрах Windows Admin Center, пользователи и администраторы могут просматривать текущую учетную запись, с которой они совершили вход, а также выйти из этой учетной записи Azure AD.

Условный доступ и многофакторная проверка подлинности

Одним из преимуществ использования Azure AD в качестве дополнительного уровня безопасности для контроля доступа к шлюзу Windows Admin Center является то, что вы можете использовать эффективные функции безопасности Azure AD, такие как условный доступ и многофакторная проверка подлинности.

Настройте единый вход

Единый вход при развертывании в качестве службы в Windows Server

После установки Windows Admin Center в Windows 10 все готово к использованию единого входа. Однако если вы собираетесь использовать Windows Admin Center в Windows Server, то перед использованием единого входа необходимо настроить в среде некоторую форму делегирования Kerberos. Делегирование настраивает компьютер шлюза как доверенный для делегирования к целевому узлу.

Используйте следующий пример PowerShell, чтобы настроить ограниченное делегирование на основе ресурсов в вашей среде. В этом примере показано, как настроить Windows Server [node01.contoso.com] для принятия делегирования из шлюза Windows Admin Center [wac.contoso.com] в домене contoso.com.

Чтобы удалить эту связь, выполните следующий командлет:

Управление доступом на основе ролей

Управление доступом на основе ролей позволяет предоставлять пользователям ограниченный доступ к компьютеру, не делая их полными локальными администраторами. Role-based access control (Управление доступом на основе ролей)

Настройка RBAC состоит из 2 шагов: включения поддержки на целевых компьютерах и назначения пользователям соответствующих ролей.

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

Применение управления доступом на основе ролей к одному компьютеру

Модель развертывания на одном компьютере идеально подходит для простых сред, в которых управление нужно представить только нескольким компьютерам. Настройка компьютера с поддержкой управления доступом на основе ролей приведет к следующим изменениям:

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

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

Вы также можете последовательно заполнять эти группы по всему домену, настраивая объект групповой политики с помощью параметра Restricted Groups Policy Setting (Настройка политики групп с ограниченным доступом).

Применение управления доступом на основе ролей к нескольким компьютерам

При развертывании на крупном предприятии вы можете использовать существующие средства автоматизации для распространения функции управления доступом на основе ролей на компьютеры, скачав пакет конфигурации со шлюза Windows Admin Center. Пакет конфигурации предназначен для использования с Desired State Configuration PowerShell, но его можно адаптировать для работы с предпочтительным решением для автоматизации.

Скачивание конфигурации управления доступом на основе ролей

Чтобы загрузить пакет конфигурации управления доступом на основе ролей, необходимо иметь доступ к Windows Admin Center и командной строке PowerShell.

Если вы используете шлюз Windows Admin Center в Windows Server в режиме службы, используйте следующую команду, чтобы скачать пакет конфигурации. Не забудьте обновить адрес шлюза, указав подходящий для своей среды.

Если вы используете шлюз Windows Admin Center на компьютере с Windows 10, выполните следующую команду:

При развертывании ZIP-архива вы увидите следующую структуру папок:

Чтобы настроить поддержку управления доступом на основе ролей на узле, необходимо выполнить следующие действия.

В следующем разделе объясняется, как это сделать с помощью удаленного взаимодействия PowerShell.

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

Чтобы развернуть конфигурацию, загруженную на несколько компьютеров, необходимо обновить скрипт InstallJeaFeatures.ps1, чтобы включить соответствующие группы безопасности для среды, скопировать файлы на каждый из компьютеров и вызвать скрипты конфигурации. Для этого можно использовать предпочтительные средства автоматизации, однако в этой статье основное внимание уделяется чистому подходу на основе PowerShell.

По умолчанию скрипт конфигурации будет создавать локальные группы безопасности на компьютере, чтобы управлять доступом к каждой из ролей. Это подходит для компьютеров, присоединенных к рабочей группе и доменам, но если развертывание выполняется в среде только для домена, вам может потребоваться напрямую связать группу безопасности домена с каждой ролью. Чтобы обновить конфигурацию для использования групп безопасности домена, откройте InstallJeaFeatures.ps1 и внесите следующие изменения:

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

Источник

бланки договора документы заполнение документов оформление документов формы