Как делегировать контроль над ou в active directory

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

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

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

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

Ограничения доверительных отношений

Когда вы устанавливаете доверительные отношения между доменами в одном лесу, между лесами или с внешней областью, информация об этих доверительных отношениях сохраняется в Active Directory. Каждое доверительное отношение в домене представлено объектом, известным как объект доверенного домена (Trusted domain objects-TDO). TDO хранит информацию о доверии, такую как транзитивность доверия и тип доверия. Всякий раз, когда вы создаете траст, новый TDO создается и сохраняется в системном контейнере в домене траста. Ограничения доверия возникают из-за количества объектов доверенного домена (TDO), длины путей доверия и способности клиентов обнаруживать доступные доверительные отношения. Применяемые ограничения включают следующее:

Клиенты Kerberos могут пройти не более 10 доверительных ссылок, чтобы найти запрошенный ресурс в другом домене. Если путь доверия между доменами превышает это ограничение, попытка доступа к домену завершается неудачно.
Когда клиент ищет маршрут доверительных отношений, поиск ограничивается доверием, которые устанавливаются непосредственно с доменом, и доверительными отношениями, которые являются транзитивными в лесу.
Тестирование показало, что увеличение времени на выполнение связанных с TDO операций, таких как проверка подлинности между доменами, заметно ухудшает производительность, если реализация Active Directory в организации содержит более 2400 TDO.

Возможности режимов работы и требования

для Windows Server 2016 требуется функциональный уровень леса Windows Server 2003. это значит, что перед добавлением контроллера домена, выполняющего Windows Server 2016 к существующему Active Directory лесу, режим работы леса должен быть Windows Server 2003 или более поздней версии. Если в лесу есть контроллеры домена под управлением Windows Server 2003 или новее, но режим работы леса соответствует Windows 2000, то установка также блокируется.

перед добавлением контроллеров домена Windows Server 2016 в лес необходимо удалить контроллеры домена Windows 2000. В этом случае порядок действий будет следующим.

Установите контроллеры домена под управлением Windows Server 2003 или более поздней версии. Эти контроллеры домена можно развертывать в ознакомительной версии Windows Server. Для этого шага нужно также запустить программу adprep.exe для соответствующей операционной системы.
Удалите контроллеры домена под управлением Windows 2000. В частности, надлежащим образом понизьте уровень контроллеров домена под управлением Windows Server 2000 или принудительно удалите их из домена и при помощи компонента «Пользователи и компьютеры Active Directory» удалите учетные записи для всех удаленных контроллеров домена.
Повысьте режим работы леса до Windows Server 2003 или выше.
Установите контроллеры домена, на которых выполняется Windows Server 2016.
Удалите контроллеры домена под управлением более ранних версий Windows Server.

Откат функциональных уровней

После настройки режима работы леса (FFL) на определенное значение невозможно выполнить откат или понижение режима работы леса, за исключением следующих:

при обновлении с Windows Server 2012 R2 FFL можно уменьшить до Windows Server 2012 R2.
при обновлении с Windows server 2008 R2 FFL можно уменьшить его до Windows Server 2008 R2.

После того как для режима работы домена задано определенное значение, откат или понижение режима работы домена невозможно, за исключением следующих:

при повышении режима работы домена до Windows Server 2016 а также в том случае, если режим работы леса Windows Server 2012 или ниже, вы можете вернуть функциональный уровень домена к Windows Server 2012 или Windows Server 2012 R2.

Дополнительные сведения о возможностях, доступных при более низких режимах работы, см. в разделе Общее представление о режимах работы доменных служб Active Directory (AD DS).

Создание доменного пользователя и ввод компьютера в домен

4 минуты чтения

В прошлой статье мы создали и настроили контроллер домена (DC), настало время наполнить наш домен пользователями и рабочими станциями.

Конфигурация

Открываем Server Manager и выбираем опцию Roles.

Из доступных ролей выбираем недавно установленную — Active Directory Domain Services, далее Active Directory Users and Computers и находим созданный нами домен (в нашем случае — merionet.loc). В выпадающем списке объектов находим Users и кликаем по данной опции правой кнопкой мыши и выбираем New → User.

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

Далее, нас просят ввести пароль для новой учетной записи и выбрать дополнительные опции:

User must change password at next logon — при включении данной опции, пользователя попросят сменить пароль при следующем логине;
User cannot change password — пользователь не сможет самостоятельно изменить свой пароль;
Password never expires — срок действия пароля пользователя никогда не истечет;
Account is disabled — учетная запись пользователя будем отключена и он не сможет залогиниться с доменными учетными данными, даже если они будут введены верно.

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

Отлично, новый пользователь домена создан. Теперь нам нужно зайти на компьютер пользователя и ввести его в домен. Для этого логинимся на компьютер пользователя с локальными учетными данными и открываем Свойства компьютера. Как видите, наш компьютер пока еще не стал частью домена, он ещё является частью рабочей группы WORKGROUP/. Убедитесь, что компьютер пользователя имеет версию Windows не ниже Professional. Чтобы ввести его в домен выбираем Change Settings

Важно! Поддержка доменной инфраструктуры начинается только с версии Windows Professional. На версиях Starter, Home Basic, Home Premium подключиться к домену не получится!

Далее напротив опции «To rename this computer or change its domain or workgroup, click Change» нажимаем собственно Change

Далее в открывшемся окне в опции «Member of» вместо Workgroup выбираем Domain и вводим имя нашего домена (в нашем случае – merionet.loc)

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

Если все было сделано корректно, то мы увидим сообщение, свидетельствующее о том, что наш компьютер теперь является частью домена (в нашем случае — merionet.loc)

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

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

Теперь, если мы откроем свойства компьютера, то увидим, что наш компьютер принадлежит домену (в нашем случае – merionet.loc)

Настройка DNS

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

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

На DNS домена primary.local

Открываем Диспетчер серверов — кликаем по Средства — DNS:

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

В «DNS-домен» пишем второй домен (в нашем случае, secondary.local), затем задаем его IP-адрес, ставим галочку Сохранять условный сервер пересылки в Active Directory и реплицировать ее следующим образом — выбираем Все DNS-серверы в этом домене:

Открываем командную строку и вводим команду:

nslookup secondary.local

Мы должны получить ответ на подобие:

Server: localhost
Address: 127.0.0.1
Non-authoritative answer:
Name: secondary.local
Address: 192.168.0.16

На DNS домена secondary.local

Действия, которые делаем на втором сервере DNS, во многом, аналогичны.

Открываем Диспетчер серверов — Средства — DNS:

Раскрываем сервер — Серверы условной пересылки — Создать сервер условной пересылки:

На данном шаге небольшие изменения. В «DNS-домен» пишем первый домен (primary.local), затем задаем его IP-адрес (192.168.0.15), ставим галочку Сохранять условный сервер пересылки в Active Directory и реплицивовать ее следующим образом — выбираем Все DNS-серверы в этом домене:

В командной строке второго сервера проверяем настройку:

nslookup primary.local

Мы должны получить ответ на подобие:

Server: localhost
Address: 127.0.0.1
Non-authoritative answer:
Name: primary.local
Address: 192.168.0.15

Active Directory — что это простыми словами

Active Directory — это очень удобный способ системного управления. С помощью Active Directory можно эффективно управлять данными.

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

В него включаются все объекты — компьютеры, принтеры, факсы, учётные записи пользователей и прочее. Сумма доменов, на которых расположены данные, именуется «лесом». База Active Directory — это доменная среда, где количество объектов может составлять до 2 миллиардов. Представляете эти масштабы?

То есть, при помощи такого «леса» или базы данных можно соединить большое количество сотрудников и оборудования в офисе, причём без привязки к месту — в службах могут быть соединены и другие юзеры, например, из офиса компании в другом городе.

Кроме того, в рамках служб Active Directory создаются и объединяются несколько доменов — чем больше компания, тем больше средств необходимо для контроля её техники в рамках базы данных.

Далее, при создании такой сети определяется один контролирующий домен, и даже при последующем наличии других доменов первоначальный по-прежнему остаётся «родительским» — то есть только он имеет полный доступ к управлению информацией.

Где хранятся эти данные, и чем обеспечивается существование доменов? Чтобы создать Active Directory, используются контроллеры. Обычно их ставится два — если с одним что-то произойдёт, информация будет сохранена на втором контроллере.

Ещё один вариант использования базы — если, например, ваша компания сотрудничает с другой, и вам предстоит выполнить общий проект. В таком случае может потребоваться доступ посторонних личностей к файлам домена, и здесь можно настроить своего рода «отношения» между двумя разными «лесами», открыть доступ к требуемой информации, не рискуя безопасностью остальных данных.

В общем, Active Directory является средством для создания базы данных в рамках определённой структуры, независимо от её размеров. Пользователи и вся техника объединяются в один «лес», создаются домены, которые размещаются на контроллерах.

Ещё целесообразно уточнить — работа служб возможна исключительно на устройствах с серверными системами Windows. Помимо этого, на контроллерах создаётся 3-4 сервера DNS. Они обслуживают основную зону домена, а в случае, когда один из них выходит из строя, его заменяют прочие серверы.

После краткого обзора Active Directory для чайников, вас закономерно интересует вопрос — зачем менять локальную группу на целую базу данных? Естественно, здесь поле возможностей в разы шире, а чтобы выяснить другие отличия данных служб для системного управления, давайте детальнее рассмотрим их преимущества.

Таблица 20.4. Задачи, которые могут быть делегированы на уровне организационных единиц

Задача	Описание
Create, delete, and manage user account	Полномочия на создание, удаление и управление учетными записями пользователей
Reset user passwords and force password change at next logon	Полномочия на изменение паролей учетных записей пользователей, а также установка требования на изменение пароля самим пользователем при следующей регистрации в системе
Read all user information	Полномочия на просмотр любой информации о пользователях
Create, delete, and manage groups	Полномочия на создание, удаление и управление группами пользователей
Modify the membership of a group	Полномочия на изменение членства в группе
Manage Group Policy links	Полномочия на управление ссылками групповой политики
Generate Resultant Set of Policy (Planning)	Полномочия, необходимые для генерации результирующих политик в режиме планирования
Generate Resultant Set of Policy (Logging)	Полномочия, необходимые для генерации результирующих политик в режиме ведения журнала
Create, delete and manage inetOrgPerson accounts	Полномочия на создание, удаление и управление объектами класса inetOrgPerson
Reset inetOrgPerson passwords and force password change at next logon	Полномочия на изменение паролей, сопоставленных объектам класса inetOrgPerson, а также установка требования на изменение пароля самим субъектом подсистемы безопасности при следующей регистрации в системе
Read all inetOrgPerson information	Полномочия на просмотр любой информации об объекте класса inetOrgPerson

Процесс делегирования полномочий выполняется следующим образом. Запустите оснастку
Active Directory Users and Computers. Выберите контейнер, для которого вы хотите делегировать полномочия и вызовите его контекстное меню. Выберите в меню пункт
Delegate Control (Делегировать управление), чтобы запустить мастер Delegation of Control Wizard (Мастер делегирования полномочий). На странице Users or Groups необходимо определить пользователей, которым будут делегированы полномочия (рис. 20.7).

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

Назначение встроенных ролей администратора приложения

В Azure AD есть набор встроенных ролей администратора, позволяющий предоставить доступ к управлению конфигурацией в Azure AD для всех приложений. Эти роли являются рекомендуемым способом предоставления ИТ-специалистам доступа к управлению широким набором разрешений на конфигурацию приложений без предоставления доступа к управлению другими частями Azure AD, не связанными с конфигурацией приложений.

Администратор приложения: пользователи с этой ролью могут создавать и контролировать все аспекты корпоративных приложений, регистрации приложений, а также параметры прокси приложения. Кроме того, эта роль позволяет предоставлять согласие на делегированные разрешения и разрешения приложений, за исключением Microsoft Graph. Пользователи, которым назначена эта роль, не добавляются в качестве владельцев при создании регистраций приложений или корпоративных приложений.
Администратор облачных приложений: пользователи с этой ролью имеют те же разрешения, что и для роли администратора приложений, за исключением возможности управления прокси приложения. Пользователи, которым назначена эта роль, не добавляются в качестве владельцев при создании регистраций приложений или корпоративных приложений.

Дополнительные сведения и описание этих ролей см. в статье Встроенные роли Azure Active Directory.

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

Важно!

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

Пример делегата

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

Как ИТ-администратор, Хана взаимодействует с каждым отделом — Мамта в отделе маркетинга, Марк в финансовом отделе и Джо в юридическом отделе, которые отвечают за ресурсы отдела и критически важное для бизнеса содержание. С помощью управления правами можно делегировать управление доступом этим пользователям, не являющимся администраторами, которые знают, какой доступ нужен каждому пользователю, сколько времени и какие ресурсы необходимы

Делегирование пользователям, не являющимся администраторами, позволяет сотрудникам управлять доступом в пределах своего отдела

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

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

Хана создает новую группу безопасности Azure AD и добавляет в нее Мамту, Марка и Джо.
Хана добавляет эту группу к роли создателей каталога.

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

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

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

Пользователь	Роль организации	Роль Azure AD	Роль управления правами
Хана	ИТ-администратор	Глобальный администратор или администратор управления удостоверениями
Мамта	Руководитель отдела маркетинга	Пользователь	Создатель и владелец каталогов
Bob	Потенциальный клиент отдела маркетинга	Пользователь	Владелец каталогов
Джесика	Руководитель проекта отдела маркетинга	Пользователь	Диспетчер пакетов для доступа

Кому можно делегировать права?

Только после получения администрирующего статуса руководитель может дополнительно делегировать право на внесение информации персоналом УК от одного человека к другому. Сотруднику система присвоит второстепенный статус «Уполномоченного специалиста ГИС ЖКХ».

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

Назначая «Администратора», руководитель компании должен через ЕСИА предоставить лицу право осуществлять те или иные операции. Человек, не имеющий права на вход в базу, может увидеть данные по фирме только через портал «Госуслуги», где размещена общая информация и нет доступа к ее корректировке.

Настройка множественных доменов¶

Конфигурация Keystone

Отредактируйте конфигурационный файл службы Keystone – .
Добавьте указанные ниже параметры в секцию :


driver = keystone.identity.backends.sql.Identity

domain_specific_drivers_enabled = True
domain_config_dir = /etc/keystone/domains

Создайте каталог :

mkdir etckeystonedomains

Создайте конфигурационный файл с именем ,
где DOMAIN_NAME – имя домена (в OpenStack).

Пропишите владельца директории и файла:

chown  -R keystonekeystone etckeystonedomains

Пример конфигурации домена

Если домен планируется назвать как «CHD», то директория будет выглядеть так:

Отредактировать конфигурационный файл и указать следующие параметры:


driver = keystone.identity.backends.ldap.Identity



url = ldap://LDAP_IP
user = cn=admin,cn=Users,dc=example,dc=com
password = openstack
suffix = dc=example,dc=com
use_dumb_member = False
allow_subtree_delete = False

user_tree_dn = cn=Users,dc=example,dc=com
user_objectclass = InetOrgPerson

group_tree_dn = cn=Groups,dc=example,dc=com
group_objectclass = groupOfNames

user_allow_create = False
user_allow_update = False
user_allow_delete = False

group_allow_create = False
group_allow_update = False
group_allow_delete = False

В и используются другие объектные классы
для пользователя и группы:

...
user_objectclass = person
group_objectclass = group

Потребуется указать маппинг атрибутов LDAP и видов данных Keystone:

user_id_attribute = sAMAccountName
user_name_attribute = sAMAccountName
user_mail_attribute = mail
user_pass_attribute = userPassword

group_id_attribute = sAMAccountName
group_name_attribute = sAMAccountName
group_member_attribute =

group_desc_attribute = description
group_filter =

Перезапуск службы веб-сервера

Для вступления изменений в силу перезапустите службу веб-сервера.
На контроллере (УУ) выполните команду:

systemctl restart httpd