Делегирование прав в Active Directory
Опубликовал(а): Иван Иван
в: 09.02.2012
Привет, сегодня, с позволения своего коллеги Дружкова Дмитрия (автора данной инструкции), поделюсь с Вами опытом делегирования административных полномочий для работы в Active Directory. Изначально задача заключается в том что бы предоставить ограниченные права рядовому сисадмину для администрирования Organization Unit (OU) отдельного филиала компании. Работать будем в WIndows Server 2008 R2.
Административные полномочия включают в себя полный доступ и распространяются на следующие объекты: Группа , Компьютер , Контакт , Общая папка , Подразделение , Пользователь , Принтер . Данные права доступа не распространяются на объект, на который непосредственно производится делегирование (например, права доступа на удаление контейнера отсутствуют).
Для делегирования полномочий на объект Active Directory необходимо иметь права доступа администратора на него.
1. Выделить требуемый объект и нажатием правой кнопкой мыши вызвать меню свойств (для этого в консоли «Active Directory – Пользователи и компьютеры» в меню «Вид» должен быть выбран пункт «Дополнительные компоненты» ). Выбрать пункт меню «Делегирование управления…»(рисунок 1).
Рисунок 1
2. В появившемся приветственном окне «Мастера делегирования управления» меню нажать кнопку «Далее» (рисунок 2).
Рисунок 2
3. В окне «Пользователи или группы» нажать кнопку «Добавить» и в появившемся меню выбрать требуемую группу безопасности или учётную запись (делегирование прав доступа на контейнер предпочтительно производить для доменной группы безопасности). После выбора всех требуемых учётных записей нажать «ОК» и «Далее» (рисунок 3).
Рисунок 3
4. В окне «Делегируемые задачи» выбрать «Создать особую задачу для делегирования» и нажать «Далее» (рисунок 4).
Рисунок 4
5. В окне «Тип объекта Active Directory» выбрать пункт меню «Только следующими объектами в этой папке:» и далее отметить следующие объекты: · Группа объектов · Компьютер объектов · Контакт объектов · Общая папка объектов · Подразделение объектов · Пользователь объектов · Принтер объектов
Отметить пункты «Создать в этой папке выбранные объекты» и «Удалить из этой папки объекты».
Нажать кнопку «Далее» (рисунок 5).
Рисунок 5
6. В окне «Разрешения» оставить пункт меню «Общие» и выбрать «Полный доступ». Нажать «Далее» (рисунок 6).
Рисунок 6
7. В окне «Завершение мастера делегирования управления» нажать «Готово» (рисунок 7).
Рисунок 7
Спасибо за внимание!!!
Мастер настройки доменных служб Active Directory
Начиная с Windows Server 2012, мастер настройки доменных служб Active Directory заменяет устаревший мастер установки доменных служб Active Directory в качестве параметра пользовательского интерфейса, чтобы указать параметры при установке контроллера домена. Мастер настройки доменных служб Active Directory запускается после завершения работы мастера добавления ролей.
Предупреждение
Устаревший мастер установки доменных служб Active Directory (dcpromo.exe) является устаревшим, начиная с Windows Server 2012.
В разделе «Установка доменных служб Active Directory (уровень 100)» процедуры пользовательского интерфейса показывают, как запустить мастер добавления ролей для установки двоичных файлов ролей сервера AD DS, а затем запустить мастер настройки доменных служб Active Directory, чтобы завершить установку контроллера домена. В примерах Windows PowerShell показано, как выполнить оба этапа с помощью командлета развертывания AD DS.
Назначение встроенных ролей администратора приложения
В Azure AD есть набор встроенных ролей администратора, позволяющий предоставить доступ к управлению конфигурацией в Azure AD для всех приложений. Эти роли являются рекомендуемым способом предоставления ИТ-специалистам доступа к управлению широким набором разрешений на конфигурацию приложений без предоставления доступа к управлению другими частями Azure AD, не связанными с конфигурацией приложений.
- Администратор приложения: пользователи с этой ролью могут создавать и контролировать все аспекты корпоративных приложений, регистрации приложений, а также параметры прокси приложения. Кроме того, эта роль позволяет предоставлять согласие на делегированные разрешения и разрешения приложений, за исключением Microsoft Graph. Пользователи, которым назначена эта роль, не добавляются в качестве владельцев при создании регистраций приложений или корпоративных приложений.
- Администратор облачных приложений: пользователи с этой ролью имеют те же разрешения, что и для роли администратора приложений, за исключением возможности управления прокси приложения. Пользователи, которым назначена эта роль, не добавляются в качестве владельцев при создании регистраций приложений или корпоративных приложений.
Дополнительные сведения и описание этих ролей см. в статье Встроенные роли Azure Active Directory.
Следуйте инструкциям в руководстве Назначение ролей пользователям с помощью Azure Active Directory, чтобы назначить роли администратора приложений или администратора облачных приложений.
Важно!
Администраторы приложений и администраторы облачных приложений могут добавлять учетные данные в приложение и использовать их для олицетворения удостоверения приложения. У приложения могут быть разрешения, которые дают повышение привилегий по сравнению с разрешениями роли администратора. У администратора с этой ролью есть потенциальная возможность создавать или обновлять пользователей или другие объекты при олицетворении приложения в зависимости от разрешений приложения.
Ни одна из ролей не предоставляет возможность управления параметрами условного доступа.
Параметры удаления и предупреждения AD DS
Чтобы получить справку об использовании страницы «Просмотреть параметры», см. главу «Просмотр параметров»
Если на контроллере домена размещены дополнительные роли, такие как роль DNS-сервера или сервера глобального каталога, появляется следующая страница с предупреждением:
Чтобы подтвердить, что дополнительные роли более не будут доступны, сперва нужно нажать кнопку Продолжить удаление, а затем Далее.
При принудительном удалении контроллера домена все изменения объектов Active Directory, которые не были реплицированы на другие контроллеры в домене, будут утеряны. Помимо этого, если на контроллере домена размещены роли хозяина операций, глобального каталога или роль DNS-сервера, критические операции в домене и лесе могут быть изменены следующим образом. Перед удалением контроллера домена, на котором размещена роль хозяина операций, необходимо попытаться переместить роль на другой контроллер домена. Если передать эту роль невозможно, сначала удалите AD DS с этого компьютера, а затем воспользуйтесь служебной программой Ntdsutil.exe для захвата роли. Используйте программу Ntdsutil на контроллере домена, для которого планируется захватить роль; по возможности используйте последний партнер репликации на том же сайте, что и данный контроллер домена. Дополнительные сведения о переносе и захвате ролей хозяина операций см. в статье 255504 базы знаний Майкрософт. Если мастер не может определить, размещена ли на контроллере домена роль хозяина операций, необходимо запустить команду run netdom.exe, чтобы проверить, выполняет ли данный контроллер домена роли хозяина операций.
-
Глобальный каталог: пользователи могут испытывать проблемы со входом в домены леса. Перед удалением сервера глобального каталога необходимо убедиться, что в этом лесу и на сайте достаточно серверов глобального каталога для обслуживания входа пользователей в систему. При необходимости следует назначить другой сервер глобального каталога и обновить информацию клиентов и приложений.
-
DNS-сервер: все данные DNS, хранящиеся в интегрированных зонах Active Directory, будут утеряны. После удаления AD DS этот DNS-сервер не сможет выполнять разрешение имен для зон DNS, которые были интегрированы в Active Directory. Следовательно, рекомендуется обновить DNS-конфигурацию всех компьютеров, которые в настоящий момент обращаются к IP-адресу этого DNS-сервера для разрешения имен с IP-адресом нового DNS-сервера.
-
Хозяин инфраструктуры: клиенты в домене могут испытывать трудности с определением местоположения объектов в других доменах. Перед продолжением перенесите роль хозяина инфраструктуры на контроллер домена, не являющийся сервером глобального каталога.
-
Хозяин RID: возможны проблемы при создании новых учетных записей пользователей, компьютеров и групп безопасности. Перед продолжением перенесите роль хозяина RID на другой контроллер домена в том же домене.
-
Эмулятор основного контроллера домена (PDC): операции эмулятора PDC, например обновление групповых политик и смена пароля для учетных записей, отличных от учетных записей AD DS, будут осуществляться неправильно. Перед продолжением перенесите роль хозяина эмулятора PDC на другой контроллер домена в том же домене.
-
Хозяин схемы больше не сможет изменять схему этого леса. Перед продолжением перенесите роль хозяина схемы на контроллер домена в корневом домене леса.
-
Хозяин именования доменов: добавлять или удалять домены в этом лесу будет уже невозможно. Перед продолжением перенесите роль хозяина именования доменов на контроллер домена в корневом домене леса.
-
Все разделы каталога приложений на этом контроллере домена Active Directory будут удалены. Если контроллер домена содержит последний репликат одного или нескольких разделов каталога приложений, по завершении операции удаления эти разделы перестанут существовать.
Обратите внимание, что домен прекратит существование после удаления доменных служб Active Directory с последнего контроллера домена в домене. Если контроллер домена является DNS-сервером, которому делегированы права на размещение зоны DNS, на следующей странице можно будет удалить DNS-сервер из делегирования зоны DNS
Если контроллер домена является DNS-сервером, которому делегированы права на размещение зоны DNS, на следующей странице можно будет удалить DNS-сервер из делегирования зоны DNS.
Дополнительные сведения об удалении доменных служб Active Directory см. в разделах Удаление доменных служб Active Directory (уровень 100) и Понижение уровня контроллеров домена и доменов (уровень 200).
Создание правила для разрешения пользователей на основе входящего утверждения на Windows Server 2016
-
В диспетчере сервера щелкните Средства и выберите Управление AD FS.
-
В дереве консоли в разделе AD FS щелкните контроль доступа Политики.
-
Щелкните правой кнопкой мыши и выберите «Добавить политику контроль доступа».
-
В поле имени введите имя политики, описание и нажмите кнопку «Добавить».
-
В редакторе правил в разделе «Пользователи» установите флажок с определенными утверждениями в запросе и щелкните подчеркнутую конкретную часть внизу.
-
На экране «Выбор утверждений » нажмите переключатель «Утверждения «, выберите тип утверждения, оператор и значение утверждения и нажмите кнопку «ОК».
-
В редакторе правил нажмите кнопку «ОК». На экране добавления политики контроль доступа нажмите кнопку «ОК».
-
-
В дереве консоли управления AD FS в разделе AD FS щелкните «Отношения доверия проверяющей стороны».
-
Щелкните правой кнопкой мыши доверие проверяющей стороны, к которому требуется разрешить доступ, и выберите «Изменить контроль доступа политику».
-
В политике управления доступом выберите политику, а затем нажмите кнопку «Применить » и » ОК».
Назначение пользователей группам
Группы в Azure AD можно использовать для назначения лицензий или развернутых корпоративных приложений большому количеству пользователей. Группы также можно использовать для назначения всех ролей администратора, кроме Azure AD глобального администратора, или предоставить доступ к внешним ресурсам, таким как приложения SaaS или сайты SharePoint.
Динамические группы можно использовать в Azure AD для автоматического расширения членства в группах и заключения контрактов. Динамические группы обеспечивают большую гибкость и сокращают работу по управлению членством в группах. Вам понадобится лицензия Azure AD Premium P1 для каждого уникального пользователя, добавленного хотя бы в одну из динамических групп.
Определения ролей доступа к шлюзу
Существует две роли для доступа к службе шлюза Windows Admin Center.
Пользователи шлюза могут подключаться к службе шлюза Windows Admin Center, чтобы через него управлять серверами, но не могут изменять разрешения доступа и механизм проверки подлинности, используемый для аутентификации шлюза.
Администраторы шлюза могут настраивать доступ, а также способ выполнения проверки подлинности для пользователей на шлюзе. Просматривать и настраивать параметры доступа в Windows Admin Center могут только администраторы шлюза. Локальные администраторы на компьютере шлюза всегда являются администраторами службы шлюза Windows Admin Center.
Примечание
Доступ к шлюзу не подразумевает доступ к управляемым серверам, отображаемым шлюзом. Для управления целевым сервером подключающийся пользователь должен использовать учетные данные (через переданные учетные данные Windows или учетные данные, предоставленные в сеансе Windows Admin Center с помощью действия Управлять как) с административным доступом к этому целевому серверу.
Роли управления правами
Управление правами имеет следующие роли с разрешениями на администрирование самого управления правами, которые применяются во всех каталогах.
| Роль управления правами | Идентификатор определения роли | Описание |
|---|---|---|
| Создатель каталогов | Создает каталоги и управляет ими. Как правило, это ИТ-администратор, не являющийся глобальным администратором, или владельцем ресурса для коллекции ресурсов. Пользователь, который создает каталог, автоматически становится первым владельцем каталога и может добавлять дополнительных владельцев. Создатель каталога не может управлять каталогами, которыми он не владеет, и добавлять ресурсы, не принадлежащие каталогу. Если создателю каталога необходимо управлять другим каталогом или добавить ресурсы, которыми он не владеет, он может запросить совладельца этого каталога или ресурса. |
Управление правами имеет следующие роли, определенные для каждого конкретного каталога для администрирования пакетов доступа и другой конфигурации в каталоге. Администратор или владелец каталога может добавлять пользователей, группы пользователей или субъекты-службы к этим ролям.
| Роль управления правами | Идентификатор определения роли | Описание |
|---|---|---|
| Владелец каталогов | Изменение пакетов доступа и других ресурсов в каталоге, а также управление ими. Как правило, это ИТ-администратор, или владельцы ресурсов, или пользователь, которого выбрал владелец каталога. | |
| Средство чтения каталога | Просмотр существующих пакетов для доступа в каталоге. | |
| Диспетчер пакетов для доступа | Изменяет любые существующие пакеты для доступа в каталоге и для управляет пакетами. | |
| Диспетчер назначения пакетов для доступа | Изменяет любые назначения существующих пакетов для доступа и для управляет назначениями. |
Кроме того, выбранному пользователю, утверждающему и запрашивающему пакет для доступа, назначены права, которые не являются ролями.
| Правый | Описание |
|---|---|
| Утверждающий | Пользователь, которому политикой предоставлены полномочия для разрешения или запрета запросов на пакеты для доступа, однако он не может изменять определения пакетов для доступа. |
| Requestor | Пользователь, которому политикой предоставлены полномочия на запросы пакетов для доступа. |
В следующей таблице перечислены задачи, которые роли управления правами могут выполнять в рамках управления правами.
| Задача | Административный | Создатель каталогов | Владелец каталогов | Диспетчер пакетов для доступа | Диспетчер назначения пакетов для доступа |
|---|---|---|---|---|---|
| Делегировать создателю каталогов | ️ | ||||
| Добавление подключенной организации | ️ | ||||
| Создать новый каталог | ️ | ️ | |||
| ️ | ️ | ||||
| ️ | ️ | ||||
| ️ | ️ | ||||
| ️ | ️ | ||||
| Делегировать диспетчеру пакетов для доступа | ️ | ️ | |||
| ️ | ️ | ||||
| Создать в каталоге новый пакет для доступа | ️ | ️ | ️ | ||
| Изменить роли ресурсов в пакете для доступа | ️ | ️ | ️ | ||
| Создать и редактировать политики | ️ | ️ | ️ | ||
| ️ | ️ | ️ | ️ | ||
| ️ | ️ | ️ | ️ | ||
| ️ | ️ | ️ | ️ | ||
| ️ | ️ | ️ | ️ | ||
| ️ | ️ | ️ | ️ | ||
| ️ | ️ | ️ | ️ | ||
| ️ | ️ | ️ | ️ | ||
| ️ | ️ | ️ | |||
| ️ | ️ | ️ |
Параметры DNS
При установке DNS-сервера отображается следующая страница Параметров DNS:
При установке DNS-сервера записи делегирования, которые указывают на DNS-сервер в качестве разрешенного для зоны, должны создаваться в зоне службы доменных имен родительского домена. Записи делегирования передают орган разрешения имен и обеспечивают правильные ссылки на другие DNS-серверы и на клиентов новых серверов, которые были сделаны полномочными для новой зоны. Эти записи ресурсов содержат следующие сведения:
-
Запись ресурса сервера имен (NS) для реализации делегирования. Эта запись ресурса сообщает, что сервер с именем ns1.na.example.microsoft.com является полномочным сервером для делегированного субдомена.
-
Запись ресурса узла (A или AAAA), также известная как запись приклеивания, должна присутствовать для разрешения имени сервера, указанного в записи ресурса сервера имен (NS) в ip-адрес. Процесс разрешения имени узла в этой записи ресурса в делегированный DNS-сервер в записи ресурса сервера имен (NS) иногда называется «связывающим преследованием».
Мастер настройки доменных служб Active Directory может создавать эти записи автоматически. После нажатия кнопки Далее на странице Параметры контроллера домена Мастер проверяет наличие соответствующих записей в родительской зоне DNS. Если мастер не может проверить, существуют ли эти записи в родительском домене, программа предоставляет возможность создать новое делегирование DNS для нового домена (или обновить существующее делегирование) автоматически и продолжить установку нового контроллера домена.
Можно также создать эти записи нового делегирования перед установкой DNS-сервера. Чтобы создать делегирование зоны, откройте Диспетчер DNS, щелкните правой кнопкой мыши родительский домен, а затем выберите Новое делегирование. Для создания делегирования выполните последовательность действий, предлагаемую мастером создания делегирования.
Процесс установки пытается создать делегирование, чтобы компьютеры, входящие в другие домены, могли разрешать DNS-запросы для узлов в субдомене DNS, включая контроллеры домена и компьютеры-члены домена
Обратите внимание, что записи делегирования могут создаваться автоматически только на DNS-серверах Майкрософт. Если зона родительского DNS-домена расположена на DNS-серверах стороннего производителя, например BIND, на странице проверки предварительных требований отображается предупреждение о неудачной попытке создания записей DNS-делегирования
Дополнительные сведения об этом предупреждении см. в разделе Известные проблемы установки AD DS.
Делегирование между родительским доменом и субдоменом, уровень которого нужно повысить, можно создать и проверить как до, так и после установки. Не следует откладывать установку нового контроллера домена из-за того, что невозможно создать или обновить делегирование DNS.
Дополнительные сведения о делегировании см. в разделе «Основные сведения о делегировании зоны » (https://go.microsoft.com/fwlink/?LinkId=164773). Если делегирование зоны не представляется возможным, можно рассмотреть другие способы обеспечения разрешения имен узлов в вашем домене из других доменов. Например, администратор DNS другого домена может настроить условную пересылку, зоны заглушки или дополнительные зоны для разрешения имен узлов в вашем домене. Дополнительные сведения см. в следующих разделах:
-
Основные сведения о типах зон (https://go.microsoft.com/fwlink/?LinkID=157399)
-
Общие сведения о зонах заглушки (https://go.microsoft.com/fwlink/?LinkId=164776)
-
Основные сведения о серверах пересылки (https://go.microsoft.com/fwlink/?LinkId=164778)
Администрирование в Active Directory
По умолчанию в Windows Server консоль Active Directory Users and Computers работает с доменом, к которому относится компьютер. Можно получить доступ к объектам компьютеров и пользователей в этом домене через дерево консоли или подключиться к другому контроллеру.
Средства этой же консоли позволяют просматривать дополнительные параметры объектов и осуществлять их поиск, можно создавать новых пользователей, группы и изменять из разрешения.
К слову, существует 2 типа групп в Актив Директори – безопасности и распространения. Группы безопасности отвечают за разграничение прав доступа к объектам, они могут использоваться, как группы распространения.
Группы распространения не могут разграничивать права, а используются в основном для рассылки сообщений в сети.
Управление назначениями ролей для ролей управления правами программным способом (предварительная версия)
Вы также можете просматривать и обновлять назначения ролей создателей каталога и ролей управления правами в каталоге, используя Microsoft Graph. Пользователь с соответствующей ролью в приложении с делегированным разрешением может вызвать API Graph, чтобы получить список определений ролей управления правами и список назначений ролей для этих определений ролей.
Например, чтобы просмотреть роли управления правами, назначенные определенному пользователю или группе, используйте запрос Graph для перечисления назначений ролей и укажите идентификатор пользователя или группы в качестве значения фильтра запроса, как в
Для роли, относящейся к каталогу, в ответе указывает каталог, в котором пользователю назначена роль
Обратите внимание, что в этом ответе возвращаются только явные назначения роли управления правами субъекту. Права, полученные пользователем посредством роли каталога или членства в группе с ролью, не возвращаются
Создание и назначение настраиваемой роли (предварительная версия)
Создание пользовательских ролей и назначение пользовательских ролей — это отдельные шаги.
- Создайте настраиваемое определение роли и добавьте к нему разрешения из предустановленного списка. Это те же разрешения, которые используются во встроенных ролях.
- Создайте назначение роли, чтобы назначить настраиваемую роль.
Это разделение позволяет создать одно определение роли и назначить его несколько раз для разных областей. Настраиваемая роль может быть назначена в области всей организации или в области одного объекта Azure Active Directory. Примером области одного объекта является регистрация одного приложения. С помощью разных областей одно и то же определение роли можно назначить Светлане для всех регистраций приложений в организации, а затем Владимиру только для регистрации приложения «Отчеты о расходах Contoso».
Советы при создании и использовании пользовательских ролей для делегирования управления приложениями
- Пользовательские роли предоставляют доступ только в самых актуальных областях регистрации приложений на портале Azure. Они не предоставляют доступ в областях устаревших регистраций приложений.
- Настраиваемые роли не предоставляют доступ к порталу Azure, если для параметра «Ограничить доступ к порталу администрирования Azure AD» задано значение «Да».
- Регистрация приложений, к которым пользователь имеет доступ, с помощью назначения ролей, отображается только на вкладке «Все приложения» страницы регистрации приложений. Регистрации не отображаются на вкладке «Собственные приложения».
Дополнительные сведения об основах настраиваемых ролей, а также о том, как создать настраиваемую роль и назначить роль, см. в разделе Обзор настраиваемых ролей.
Делегирование ролей администратора
Многие крупные организации хотят предоставить своим пользователям необходимые разрешения для рабочих задач, не назначая роль глобального администратора со множеством возможностей, к примеру, пользователям, которым необходимо регистрировать приложения. Вот пример новых ролей администратора Azure AD, которые помогают распределить задачи управления приложениями более точно:
| Имя роли | Сводка разрешений |
|---|---|
| Администратор приложений | Может добавлять корпоративные приложения и регистрации приложений, а также управлять ими и настраивать параметры приложения прокси-сервера. Администраторы приложений могут просматривать политики условного доступа и устройства, но не управлять ими. |
| Администратор облачных приложений | Может добавлять корпоративные приложения и регистрации корпоративных приложений, а также управлять ими. У этой роли есть все разрешения администратора приложений за исключением разрешений на управление параметрами прокси-сервера приложения. |
| Разработчик приложений | Может добавлять и обновлять регистрации приложений, но не может управлять корпоративными приложениями или настраивать прокси приложения. |
Новые роли администратора Azure AD добавляются. Чтобы узнать, какие роли сейчас доступны, просмотрите портал Azure или справочник разрешений для роли администратора.
Право собственности на объекты Active Directory
Каждый объект в Active Directory должен иметь владельца. По умолчанию пользователь, создавший объект, является его владельцем. Владелец объекта имеет право изменить разрешения на доступ к объекту, что означает, что даже если владелец не имеет полного управления объектом, он всегда может изменить разрешения на доступ к объекту. В большинстве случаев владельцем объекта является определенная учетная запись пользователя, а не учетная запись группы. Единственное исключение — это когда объект создан членом группы Domain Admins. В этом случае владельцем объекта назначается группа Domain Admins. Если владелец объекта является членом локальной группы Administrators, a не членом группы Domain Admins, то владельцем объекта назначается группа Administrators.
Чтобы определить владельца объекта Active Directory, обратитесь к свойствам объекта, используя соответствующий инструмент Active Directory. Выберите вкладку Security (Безопасность), щелкните на Advanced (Дополнительно), а затем выберите вкладку Owner (Владелец). На рисунке 9-8 показано окно инструмента Active Directory Users And Computers.
Рис. 9-8. Просмотр владельца объекта Active Directory
Если вы имеете разрешение Modify Owner (Модификация владельца) для объекта, вы можете использовать это окно для изменения владельца объекта. Вы можете назначить владельцем свою собственную учетную запись, учетную запись другого пользователя или группу. Эта последняя возможность уникальна для Active Directory Windows Server 2003. В Active Directory системы Microsoft Windows 2000 вы сами можете стать владельцем или назначать владельцем другого участника безопасности.
