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

Показанное на этой странице делегирование прав основано на рекомендаций Microsoft, но выполнено так, как это удобно для работы у нас в организации. Это только один из вариантов, и каждый может настроить свое делегирование по этому примеру.

Microsoft рекомендует подход на основе ролей (RBAC) в рамках многоуровневой модели администрирования (Tiered Administration).

Tiered Administration Model (уровни Tiers 0,1,2) – это вертикальное разделение по степени доверия и критичности (домен >> серверы >> рабочие станции).

Role-Based Access Control (RBAC) – это горизонтальное разделение по задачам внутри уровня (учётные записи, серверы, политики и тп.).

В результате сначала определяется уровень доступа (Tier), затем внутри него назначаются роли (RBAC) по задачам.

В нашем случае выполнено разделение на три уровня (группы).

L3 – группа с прямым контролем над доменом (Domain Admins, Enterprise Admins, Administrators). Участники группы управляют контроллерами домена, схемой, довериями, делегированиями, серверами. Соответствует Tier 0.

L2 – группа с административным доступом к определенным OU (подразделениям). Полный контроль над своей OU, пользователи, компьютеры, под-OU, делегирование прав внутри своей OU, GPO внутри своей OU, некоторые сервера. Частично соответствует Tier 1 в нашем случае. Можно дополнительно использовать подгруппу L2,5 и раздать права на управление серверами отдельно.

L1 – группа с минимальными правами на рабочие станции и пользователей (HelpDesk, Support). Принимают заявки, проверяют данные, базовая поддержка, сброс пароля, блокировка/разблокировка учетных записей обычных пользователей, доступность сети и тп. Новые админы на испытательном сроке. Если организация не большая, можно совместить L1 с L2 и распределить роли.

 

Наилучшие практические рекомендации.

Минимизация числа учетных записей с Domain Admin (в небольшой сети один супер-админ).

Использовать принцип наименьших привилегий – дать администраторам нижних уровней права только там, где они реально нужны.

Логи и аудит действий администраторов нижних уровней.

Запрет доступа на контроллеры домена для всех, кроме Domain Admin. Всё администрирование выполняется через оснастку RSAT с рабочих мест администраторов.

Базовый смысл данной инструкции – делегировать права нужно на конкретные OU, а не на весь домен. Сделаем этому. Создадим OU, группу безопасности, добавим пользователей и делегируем полномочия. Настройки выполнены на примере Windows Server 2019.

 

OU для групп управления.

OU (Organizational Unit) – это контейнер в Active Directory (AD) для группировки объектов (пользователей, компьютеров, других OU) с целью делегирования управления и применения групповых политик (GPO). На русский язык это можно перевести как подразделение и, по соответствующей переводу логике, в OU принято располагать группы и работников в соответствии с их подразделением. В планируемом OU будут размещаться группы администрирования.

Переходим в оснастку AD «Пользователи и компьютеры» через ресурсы диспетчера серверов или через строку «Выполнить».

Win+R >>

Создаем OU.

 

Придумываем понятное удобное название.

Защитить контейнер от случайного удаления — предотвращает удаление OU через обычный интерфейс. Обязательна для ключевых OU.

Создание OU через CLI (PowerShell).

 

Проверка создания.

Кроме групп админов в данном контейнере можно хранить группы управления инфраструктурой (KSC, Backup, Zabbix, Firewall) или другие административные группы (SQL-Admins, Exchange-Admins). Нельзя хранить пользовательские учётки админов, рабочие OU пользователей и компьютеров.

В домене есть предустановленная папка Managed Service Accounts. Близкое и логичное название, почему бы не использовать эту папку?

Service Account – это учётная запись в Windows/AD, предназначенная не для человека, а для сервисов или приложений – gMSA (групповых управляемых учётных записей). То есть не кто-то входит на компьютер, а программа или сервис выполняет операции от имени этого аккаунта. Лучше не использовать эту папку для названных выше целей. Мастера делегирования ориентированы на OU, а MSA это не полноценная OU. Некоторые функции, например делегирование или наследование ACL, могут работать не так, как ожидается.

 

OU для учетных записей администраторов.

Создается аналогично.

Раздельное хранение групп и их участников упрощает администрирование и применение политик.

Через CLI.

Перемещаем существующие учетные записи в созданный OU MANAGEMENT-ADMINS или создаем новые в этом OU.

 

OU для пользователей.

Создаем подразделение для бухгалтерии с названием, например BUH.

Через CLI.

Перемещаем в это OU учетные записи бухгалтеров или создаем новые, если их еще нет.

 

OU для компьютеров пользователей.

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

Создаем под-OU в подразделении BUH.

 

Через CLI.

Переносим в созданное под-OU существующие уже компьютеры или добавляем новые.

 

OU для компьютеров администраторов.

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

Создаем отдельное OU в корне домена с понятным названием, например MANAGEMENT-COMPUTERS.

Через CLI.

Перемещаем компьютеры админов в это OU.

Далее необходимо делегировать полный доступ на это OU и распространить на него GPO, раздающее локальных администраторов на компьютеры. Без шага 1 – админ не добавит свой компьютер в домен. Без шага 2 – у него не будет прав локального администратора на своём ПК. То же самое относится к другим подразделениям, за которые админ будет отвечать.

 

Удаление OU.

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

Включаем «Дополнительные компоненты».

 

Открываем свойства нужного OU.

 

В свойствах появилась вкладка «Объект». Убираем галку «Защитить объект от случайного удаления».

После этих действий OU можно удалить.

 

Группа для администраторов OU.

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

 

Через CLI.

 

Проверка создания.

Name – читаемое имя, может содержать пробелы, может быть на русском. Часто Name и sAMAccountName  делают одинаковыми для простоты, но можно дать -Name= «Администраторы OU», а -SamAccountName= «OU-ADMINS-GROUP» –  тогда удобно в GUI читать, а скриптам удобен короткий логин. Если не менять вручную, при создании в GUI происходит автоматическое подставление sAMAccountName = Name.

sAMAccountName – короткое, уникальное название с ограничением 20 символов.

GroupScope Global – глобальная группа. Подходит для большинства задач. Такие группы могут включать пользователей и другие глобальные группы только из своего домена, но их можно добавлять в списки ACL (права доступа) на ресурсы любого домена в лесу.

GroupCategory Security – категория группы «Безопасность». Используется для предоставления прав и разрешений в домене: управление доступом к файлам, настройка политик (GPO), делегирование полномочий. Такая группа может также использоваться для рассылки почты, но её главная цель – авторизация.

Path – указывает расположение OU, где создаётся группа.

 

Учетная запись.

Создадим учетную запись администратора в предназначенной для этого OU MANAGEMENT-ADMINS.

 

Имя/Полное имя – отображаемое имя в AD. Логин не зависит от него. Можно писать на русском языке.

Имя входа (userPrincipalName) – основной логин для входа (формат email).

Имя входа (пред-Windows 2000, sAMAccountName) – устаревший, но обязательный логин (макс. 20 символов).

 

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

Требовать смены пароля – стандартный пункт при создании. Отмечаем. Это обычная учетная запись для человека, соответственно должен применяться общий парольный принцип политик домена.

Запретить смену пароля – для служебных учетных записей, чтобы пароль знал только администратор.

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

Отключить учетную запись – создать учётную запись в неактивном состоянии.

Проверяем введенные параметры и нажимаем «Готово».

 

Через CLI.

Path – расположение OU, куда создаём пользователя.

AccountPassword – начальный пароль.

Enabled $true – активировать учетную запись сразу.

PasswordNeverExpires $true – пароль не истекает.

 

Добавляем созданного пользователя в созданную ранее группу OU-ADMINS-GROUP.

Через CLI.

 

Проверка.

Таким же способом добавляем в эту группу все учетные записи планируемых OU-админов.

 

Делегирование управления.

Делегирование настраивается на конкретный OU. Предположим, что созданная группа админов будет управлять пользователями бухгалтерии. Выбираем бухгалтерский OU и в свойствах нажимаем на «Делегирование управления…». Запустится мастер настройки. Проходим его по шагам.

 

Пользователи и группы.

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

 

 

Делегируемые задачи.

Возможны два варианта делегируемых задач: предустановленные и собственные.

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

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

Нажимаем «Далее».

 

Тип объекта Active Directory.

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

В этом случае мы не выбираем конкретные объекты делегирования. Делегирование создается для всего, что в этом списке и в этом OU.

Далее.

 

Разрешения.

Выбираем разрешения, которые мы хотим делегировать.

Выбираем Полный доступ. Получается, что мы задаем полный доступ на OU для администратора-OU, то есть то, что нам и нужно.

В результате, технически  создается ACE «Полный доступ» на саму OU, которая: наследуется на все объекты внутри OU, распространяется на любые типы объектов, действует только в пределах этой OU. OU-admin получает полный контроль над своей OU и всем, что в ней находится.

Реально на практике это означает что:

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

OU-админ не может управлять объектами выше этой OU, трогать Domain Admins, Enterprise Admins, GPO вне OU, группы и объекты в других OU, изменить ACL домена. Потому что ACL физически ограничен этой OU.

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

Прямого аналога настройки делегирования через PowerShell нет. К тому же использование PowerShell приводит к многочисленным ошибкам. Лучше делегировать права GUI мастером. (на начальном этапе развертывания домена)

 

Просмотр и редактирование созданных делегирований выполняется через свойства OU >> Безопасность >> Дополнительно.

 

ACL (Access Control List) – список правил доступа для объекта в AD. Показывает, кто и какие права имеет на объект.

ACE (Access Control Entry) – одна запись в ACL. Определяет, какая группа или пользователь и какие конкретные права имеют на объект.

В случае перемещения объектов в разные OU, делегирование лучше делать после того, как OU сформирован и в нем лежат все нужные объекты и вложенные OU. При перемещении OU может принести с собой явно заданные ACL, иметь отключённое наследование и тп. Перемещение OU может перезаписать или изменить права.

 

Добавление ПК в домен.

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

Такое поведение является вполне нормальным. Добавление в домен – это локальная администраторская операция. Windows проверяет локальные группы, а не AD-делегирование. Поэтому кнопка «Инициализировать» неактивна и Windows сообщает что в домен могут добавлять только администраторы – локальные администраторы компьютера.

Проблема не возникает у Domain Admin, потому что роль Domain Admin автоматически даёт локальные администраторские права на всех компьютерах, скрывая необходимость правильной настройки делегирования и GPO. В нормальной инфраструктуре Domain Admin не используется в ежедневной работе. 90% задач решаются делегированием OU, GPO, группами доступа.

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

 

GPO «локальный администратор».

GPO (Group Policy Object) – объект групповой политики. Это набор правил и настроек для централизованного управления пользователями и компьютерами в домене Active Directory. Позволяет автоматически настраивать параметры безопасности, устанавливать ПО, назначать скрипты и контролировать среду. GPO логично назначать на группу. Сценарий следующий: создаем группу и с помощью GPO распространяем её на все компьютеры. Далее больше ничего распространять не нужно – добавляем или убираем участников в группе и это сразу распространяется на все компьютеры в сети.

Создаем группу LOCAL-ADMINS-GROUP в OU MANAGEMENT-GROUPS.

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

 

Заходим в редактор GPO через «Выполнить».

Win+R >>

или через диспетчер серверов.

 

Создаем GPO с привязкой к нужному OU.

 

Вводим понятное название, отражающее назначение этой политики.

 

Редактируем созданный объект GPO.

Далее существует два варианта в зависимости от зрелости системы. Пойдем по варианту №1, так как он подходит всем без исключений и с ним сложно что-то испортить. Вариант №2 более строгий и может поломать работу в домене. (рассмотрен ниже под спойлером)

 

Вариант №1.

Конфигурация компьютера >> Настройка >> Параметры панели управления >> Локальные пользователи и группы >> Создаем локальную группу.

 

Действие: Обновить.

Имя группы: Администраторы (встроенная учетная запись).

Члены группы: LOCAL-ADMINS-GROUP

 

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

Применяем. Закрываем настройку.

GPO распространяется на домен без дополнительных действий в этой оснастке после завершения редактирования.

​

Для отключения GPO достаточно выбрать состояние «Отключено». Это полностью останавливает применение политики, даже если она привязана к OU.

 

Объекты GPO хранятся в отдельной директории. Их можно связывать с любым OU.

Переходим на клиентский ПК.

Перезагружаем ПК или обновляем GPO.

 

Переходим в оснастку локальных пользователей и групп.

Win+R >>

В группе локальных пользователей наблюдаем то, что и требовалось – доменная группа LOCAL-ADMINS-GROUP теперь локальный администратор ПК.

 

Добавление ПК в домен.

Возвращаемся к добавлению ПК в домен. Кнопка «Идентификация» теперь активна.

 

Далее проходим по мастеру.

Идентификация – это только проверка логина и пароля. Если учетная запись не существует в домене, аутентификация не пройдёт. И соответственно учетку нужно создать в AD.

 

Далее может возникнуть ошибка.

Эта ошибка относится к учётной записи компьютера в Active Directory, а не к пользовательской учетной записи. Она возникает при попытке сбросить пароль компьютерной учётной записи при повторном присоединении. Если у администратора нет делегированного права «Reset password» на объекты компьютеров в целевом OU, эта операция блокируется. Удаление старого объекта в AD решает проблему.

Под спойлером в конце страницы два дополнительных варианта решения этой ошибки.

Нажимаем ОК и проходим далее.

 

На следующем шаге указываем учетные данные OU-админа.

 

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

 

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

 

После идентификации требуется обязательная перезагрузка компьютера. Выполняем.

Итог.

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

 

​

​