Active Directory

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

Стратегия по типу объекта — наиболее стабильная: пользователи, рабочие станции, серверы, сервисные учётные записи получают разные GPO, владельцев. Географическая ветка оправдана, когда площадка имеет собственную поддержку, сетевые настройки или локальные политики. Оргструктура уместна только там, где начальники реально становятся делегатами и структура не меняется ежеквартально.

Проверка выбора:
Разные базовые GPO? → ветка по типу
Разные локальные владельцы? → ветка по географии
Нужна только отчётность? → атрибут Department, не OU

Гибрид допустим: верхний уровень — типы объектов, ниже для рабочих станций — площадки. Нельзя одновременно дублировать один компьютер в «OU=Москва» и «OU=Продажи»: объект имеет единственного родителя.

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

OU=SKL
-- OU=Accounts
| +-- OU=Standard
| +-- OU=Privileged
| +-- OU=Service
-- OU=Devices
| +-- OU=Workstations
| +-- OU=Servers
-- OU=Groups
| +-- OU=Role
| +-- OU=Resource
-- OU=Staging
-- OU=Disabled

Контейнеры по умолчанию CN=Users и CN=Computers не являются OU: на них нельзя нормальным образом линковать GPO и делегировать управление. Перенаправьте создание компьютеров и пользователей в проектные OU командой redircmp и redirusr, а существующие объекты мигрируйте планово.

AGDLP означает Accounts → Global groups → Domain Local groups → Permissions

1. Accounts — учётные записи
2. Global — роли в домене
3. Domain Local — права на ресурс
4. Permissions — ACL

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

alice → GG_Sales_Read
 → DL_FS_Contracts_Read → \fs01\Contracts (Read)

AGUDLP для нескольких доменов:
Accounts → Global → Universal → Domain Local → Permission

Universal-группа реплицируется через GC, поэтому применяйте AGUDLP только при реальной междоменной потребности. В одно-доменном лесу AGDLP проще и дешевле для понимания. Группа — это роль или ресурс, а не «папка пользователей отдела».

Область определяет, кого группа может содержать и где ей назначают разрешения. Тип (Security или Distribution) определяет, участвует ли она в авторизации. В современном дизайне Security-группы создают с понятным назначением и минимальным владельцем.

Делегирование строят от операции к OU: службе поддержки разрешают сброс пароля и разблокировку только стандартных пользователей; команде серверов — создание и управление компьютерными объектами в OU=Servers; владельцу ресурса — управлять конкретной группой. Используйте мастер Delegation of Control как старт, затем проверяйте ACL и наследование.

OU=Accounts\Standard
 Helpdesk: Reset password, unlock, read properties
OU=Devices\Servers
 ServerOps: Create/delete computer objects
Group DL_FS_Project_RW
 Owner: Project manager (только membership)

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

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

GG_<роль>_<доступ> GG_Sales_Contract_Read
DL_<ресурс>_<доступ> DL_FS_Contracts_Read
PC-- PC-MSK-0142
SVC_<система>_<задача> SVC_Backup_Agent

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

Слишком глубокое дерево OU создаёт непредсказуемое наследование GPO; блокировка наследования и Enforced как стандартный приём делают результат неаудируемым. Ещё хуже — OU по проекту для временных участников, когда членство в группе выражает это точнее. Не переносите объект между OU и чтобы выдать доступ к папке: меняйте группу роли.

GPO связывается с сайтом, доменом или OU, но объект получает итоговую политику по порядку LSDOU: Local, Site, Domain, OU. При вложенных OU более близкая политика обычно побеждает при конфликте. Это не повод строить глубокую иерархию: каждый уровень усложняет объяснение результата. Сначала создайте небольшое число базовых политик, затем отдельные политики для чётко определённых классов устройств или пользователей.

Domain: базовая безопасность
 OU=Devices: общие настройки устройств
 OU=Servers: серверное усиление
 OU=Tier0: политика DC/критичных систем

Наследование — часть дизайна, не случайный эффект.

Security filtering и WMI filter применяйте только когда OU не выражает целевой набор без искусственного перемещения объектов. Фильтрация должна быть документирована и минимальна: сложная WMI-проверка при каждом входе повышает время обработки, трудность диагностики. Если политика относится к устройству и не привязывайте её к OU пользователей из-за удобства.

gpresult /h C:\Temp\policy.html
Get-GPInheritance -Target "OU=Servers,DC=skl,DC=local"
Get-GPOReport -All -ReportType Html -Path C:\Temp\gpo.html

AGDLP работает только вместе с управлением жизненным циклом групп. У каждой группы должны быть технический владелец, бизнес-владелец, описание ресурса, тип доступа, срок следующего пересмотра и правило утверждения членства. Технический владелец понимает последствия изменения ACL; бизнес-владелец подтверждает, кому доступ действительно нужен. Один человек может выполнять обе роли лишь в небольшой среде и это должно быть явно зафиксировано.

При выдаче доступа создавайте или используйте роль, а не меняйте ресурс напрямую. Заявка должна отвечать: какая функция сотрудника требует права, к какому ресурсу, на какой срок, кто утвердил и какая группа реализует решение. При отзыве доступа удаляется членство в глобальной группе роли; доменная локальная группа и ACL остаются стабильными. Это предотвращает «дрейф разрешений», когда уход сотрудника оставляет неизвестные записи на файлах.

Бизнес-заявка → GG_Finance_Invoice_Approve
 → DL_APP_Invoice_Approve
 → роль приложения

Аудит идёт справа налево:
ресурс → DL → GG → учётная запись → владелец

Перестройка OU — это изменение области GPO, делегирования, поэтому её не проводят массовым перетаскиванием в рабочее время. Сначала инвентаризируйте объекты, текущие GPO links, ACL OU, группы, скрипты, приложения, которые используют distinguishedName. Затем создайте целевую структуру, назначьте базовые политики, проведите пилот на небольшой группе устройств и только после проверки перенесите следующую волну.

Инвентаризация → Целевая OU → Пилот 5 устройств
 ↓  ↓
 план отката gpresult + вход + приложение
 ↓  ↓
 поэтапный перенос → ревизия ACL

DN не является постоянным идентификатором объекта: перенос меняет DN, но сохраняет objectGUID, SID. Однако плохо написанные сценарии, интеграции часто хранят путь OU строкой. Найдите их до миграции. Если старую OU нужно оставить временно, сделайте её переходной, запретите создание новых объектов и назначьте дату удаления.

Get-ADComputer -SearchBase "OU=Legacy,DC=skl,DC=local" -Filter * |
 Move-ADObject -TargetPath "OU=Workstations,OU=Devices,OU=SKL,DC=skl,DC=local"
Get-ADOrganizationalUnit -Filter * |
 Select-Object Name,DistinguishedName

Проектирование структуры OU, групп, GPO и делегирования должно быть доказуемым. Сначала собирают факты: владельцев сервисов, перечень зависимых систем, сетевые ограничения, требования к доступности, срокам восстановления, аудиту. Затем формулируют несколько вариантов, выбирают минимально сложный, записывают измеримые критерии успеха. Формулировка «так исторически сложилось» не является требованием и не должна переживать пересмотр дизайна.

Полезный приём — отделить решение от реализации. Решение описывает границу, владельца, допустимый риск, ожидаемое поведение при отказе; реализация перечисляет конкретные OU, DNS-зоны, контроллеры, группы или команды. Тогда изменение имени сервера не превращает архитектурный документ в ложный а новый инженер может проверить намерение до изменения конфигурации.

Методика проверки

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

Требование → вариант → риск → владелец
 ↓ ↓ ↓
 тестовый проверка решение об
 сценарий отказа эксплуатации

Документация обновляется после проверки,
а не до того, как факт подтверждён.

Get-ADGroupMember 'Domain Admins' -Recursive
Get-GPInheritance -Target 'OU=Servers,DC=skl,DC=local'
gpresult /r