Active Directory

Один GPO состоит из двух реплицируемых частей. Group Policy Container (GPC) хранится в Active Directory и содержит метаданные, ссылки и номера версий. Group Policy Template (GPT) лежит в SYSVOL каждого DC и содержит файлы настроек, сценарии и Administrative Templates.

Active Directory (GPC)  SYSVOL (GPT)
CN={GUID},CN=Policies,... \\domain\SYSVOL\domain\Policies\{GUID}
 displayName  Machine\
 versionNumber  User\
 gPCFileSysPath  GPT.INI (Version=...)
 \  /
 \---- один логический GPO ----/

Клиент применяет GPO только когда версии согласованы.

Get-GPO -All | Select-Object DisplayName, Id, GpoStatus, CreationTime, ModificationTime
Get-GPOReport -Name "Workstations - Baseline" -ReportType Html -Path .\baseline.html

Служба Group Policy Client получает список применимых GPO, а Client-Side Extensions (CSE) интерпретируют конкретные разделы: Security Settings, Registry, Group Policy Preferences, Scripts, Software Installation, Folder Redirection, другие. У каждой CSE собственные правила фонового обновления и повторного применения.

Загрузка / вход:
 GPSVC -> ищет DC -> читает GPC -> читает GPT
 -> определяет применимые GPO
 -> CSE Security Settings -> параметры безопасности
 -> CSE Registry -> политики реестра
 -> CSE Preferences -> предпочтения
 -> CSE Scripts -> сценарии

«GPO применён» не равно «каждая настройка успешно обработана».

При проектировании группируйте настройки по области владения и циклу изменений: базовая безопасность, браузер, инженерное ПО, киоск. Не объединяйте всё в один «главный GPO» — его невозможно безопасно тестировать и откатывать.

Стандартный порядок — Local, Site, Domain, Organizational Unit (LSDOU). Позднее применённая настройка обычно выигрывает при конфликте но конкретная CSE может иметь особые правила. Вложенные OU обрабатываются от родительской к дочерней.

Порядок обработки:
Local --> Site --> Domain --> OU=Workstations --> OU=Engineering
   ранее позднее

Конфликт «Screen lock timeout»:
Domain GPO: 900 sec
Engineering GPO: 300 sec <-- обычно итоговое значение

Компьютерная конфигурация определяется местом объекта компьютера в AD, пользовательская — местом объекта пользователя. Не переносите пользователя в OU компьютеров в надежде получить настройки рабочего места: это ломает модель и затрудняет делегирование.

Block Inheritance на OU блокирует обычные GPO, пришедшие сверху. Ссылка с флагом Enforced проходит через эту блокировку и получает приоритет над обычными наследуемыми ссылками. Оба механизма применяйте крайне редко: они усложняют предсказуемость и расследования.

Domain
 [GPO: Security Baseline, Enforced] -----------+
 [GPO: Standard Desktop]  |
 |   |
 v   v
OU=Kiosks (Block Inheritance) всё равно применяется
 [GPO: Kiosk Restrictions]

Итог: Security Baseline + Kiosk Restrictions
 Standard Desktop заблокирован

Сначала используйте отдельную OU с узко назначенными GPO. Block Inheritance оставляйте для документированных исключений; Enforced — для малого набора действительно обязательных базовых правил.

Ссылка GPO задаёт область видимости (site/domain/OU), а Security Filtering ограничивает применение ACL-правами Read и Apply group policy. Это основной механизм назначения небольшим устойчивым группам.

# Пример WMI-фильтра: только Windows 11
SELECT * FROM Win32_OperatingSystem
WHERE Version LIKE "10.0%" AND ProductType = "1"

# Сначала проверяйте запрос локально
Get-CimInstance Win32_OperatingSystem |
 Select-Object Caption, Version, ProductType

Loopback processing меняет способ выбора пользовательских GPO при входе на определённый компьютер. В режиме Merge сначала применяются обычные пользовательские GPO, затем пользовательские GPO из OU компьютера. В Replace применяются только пользовательские GPO из OU компьютера.

Пользователь Alice из OU=Sales входит на Kiosk-17:
обычный путь: User GPO из OU=Sales
Merge: User GPO Sales + User GPO OU=Kiosks (последние приоритетнее)
Replace: только User GPO OU=Kiosks

Сценарии: киоски, RDS/VDI, экзаменационные ПК.
Не сценарий: «хочу исправить плохую структуру OU пользователей».

На медленном канале Windows может не обрабатывать часть расширений в фоновом обновлении. Порог slow link и поведение зависят от политики и CSE. Сценарии запуска, перенаправление папок и установка ПО особенно чувствительны к WAN.

Начинайте с конкретного пользователя, конкретного компьютера и времени события. Отчёт RSoP показывает результирующий набор и причины отклонения:

• disabled link
• security filtering
• WMI filter
• недоступный DC или конфликт приоритета

# Запускать в контексте проверяемого пользователя/администратора
gpresult /r
gpresult /h C:\Temp\gpresult.html
gpresult /scope computer /v

# Перечитать политики; не заменяет поиск корня проблемы
gpupdate /force

# Журнал: Microsoft-Windows-GroupPolicy/Operational
Get-WinEvent -LogName "Microsoft-Windows-GroupPolicy/Operational" -MaxEvents 50

Порядок диагностики:
1. Объект находится в ожидаемой OU?
2. Включена ли часть Computer/User и сама link?
3. Проходит ли Security Filtering и WMI?
4. Есть ли SYSVOL/GPC на выбранном DC?
5. Что сообщает Operational log конкретной CSE?
6. Какая более приоритетная GPO задаёт конфликтующее значение?

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

# Резервная копия перед изменением
Backup-GPO -Name "COMP - Baseline - Windows 11" -Path "\\backup\GPO"

# Найти не связанные с OU/domain/site GPO для ревизии
Get-GPO -All | Where-Object { $_.GpoStatus -ne "AllSettingsDisabled" } |
 Select-Object DisplayName, Id, ModificationTime

Проектирование Group Policy — это управление изменениями конфигурации, а не коллекция галочек. У каждого GPO должна быть одна понятная ответственность: базовая защита компьютера, параметры браузера, настройка киоска, политика конкретного приложения. Когда в одном объекте смешаны парольная политика, принтеры, ярлыки, BitLocker, сценарии, невозможно ответить, кто владеет изменением, какой тест нужен и что именно надо откатить при регрессии.

Предсказуемая библиотека GPO

COMP - Baseline - Windows 11 -> все управляемые ПК
COMP - Security - Kiosk -> OU=Kiosks
USER - Browser - Finance -> группа Finance-Users
USER - RDS - Session Restrictions -> OU=RDS Hosts (loopback)

Неудачное имя:
GPO_new_final_2025_2 -> неизвестны цель, область и владелец

GPC и GPT нужно мыслить как одну версионируемую сущность, размещённую в двух репликационных системах. GPC сообщает клиенту, что политика существует и где искать шаблон; GPT хранит фактические файлы. Поэтому диагностика «политика не применяется» начинается не с бесконечного gpupdate /force, а с проверки выбранного DC, доступности SYSVOL, согласования версий и события конкретной CSE. Принудительное обновление полезно для теста после исправления, но не чинит DNS, DFSR или неверный scope.

Клиентская цепочка:
IP/DNS -> DC Locator -> LDAP: GPC -> SMB: GPT/SYSVOL -> CSE -> результат
  | |
  | +-- файлы, GPT.INI, scripts
  +-- link, ACL, версия, WMI filter

Сбой на любом звене может выглядеть как «GPO проигнорирован».

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

OU=Devices
 ├─ OU=Standard <- обычная базовая политика
 ├─ OU=Kiosks <- отдельный режим и явные исключения
 └─ OU=Servers
 └─ OU=RDS <- loopback Replace для общих сессий

Не создавайте OU «исключения-2» только для обхода старого Enforced.

Security filtering — основной способ сузить применение в пределах связанной OU. Группа должна выражать бизнес- или техническую роль, а не временную ручную подборку компьютеров. WMI-фильтр уместен, когда признак невозможно выразить OU или группой и он стабилен; его запрос выполняется на клиенте, поэтому сотни тяжёлых WMI-проверок ухудшают вход и затрудняют объяснение результата. Предпочтения с item-level targeting используют для точечной доставки настройки, но ими не маскируют плохую структуру объектов.

Block Inheritance и Enforced — исключения, потому что они скрывают контекст. Block Inheritance может быть оправдан для изолированной OU киосков, а Enforced — для малого числа базовых ссылок, которые должны пережить блокировку. Но если для обычной работы понадобились оба флага на многих уровнях, это сигнал переосмыслить OU, область ссылок. «Enforced исправил проблему» часто означает лишь, что конфликт перенесён в место и которое сложнее заметить.

Проверка замысла, а не только флагов:

Domain: [COMP Baseline] --------------------> наследуется
OU=Kiosks: Block Inheritance
OU=Kiosks: [COMP Kiosk] -------------------> применяется

Если Baseline обязан остаться:
Domain: [COMP Security Minimum, Enforced] -> применяется поверх блока

В документации: почему это именно исключение и кто его пересмотрит.

Loopback Replace и Merge описывают пользовательскую конфигурацию в контексте компьютера. Они полезны, когда машине требуется определённый пользовательский режим независимо от владельца аккаунта: RDS, VDI, киоск, экзаменационный ПК. Replace не означает «более сильный GPO для всех»; он исключает обычные пользовательские настройки, способен неожиданно лишить пользователя параметров диска, браузера или сертификата. Перед включением loopback составьте перечень обязательных user-политик, проверьте вход обычного и привилегированного пользователя.

gpresult /scope computer /h C:\Temp\computer-gpo.html
gpresult /scope user /h C:\Temp\user-gpo.html
Get-GPInheritance -Target "OU=Kiosks,DC=corp,DC=example"
Get-GPOReport -All -ReportType Xml -Path C:\Temp\all-gpo.xml

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

Жизненный цикл настройки AD

Потребность -> модель угроз/ограничений -> pilot
 |   |
 v   v
владелец <- документация <- измерение <- внедрение
 |   |
 +-------- пересмотр / удаление --------+

«Создано без ошибки» не является критерием качества.
Критерий: известны ожидаемый эффект, границы и способ доказать эффект.

Разделяйте плоскости управления. Идентичность отвечает за то, кто предъявляет учётную запись; аутентификация — как система проверяет это предъявление; авторизация — какие операции разрешены; сеть — куда может дойти трафик; журнал событий — как восстановить картину. Попытка заменить одну плоскость другой создаёт ложное чувство защиты. Например, группа AD не заменяет сегментацию сети, а firewall не заменяет разрешение на объект.

Для production-процесса полезна трёхступенчатая модель: лаборатория подтверждает синтаксис, pilot подтверждает совместимость с реальными образами, приложениями, а поэтапное развёртывание ограничивает радиус поражения. Нельзя считать результатом лаборатории доказательство того, что политика, репликация или доверие безопасны для всей организации: в лаборатории обычно нет её задержек, наследованных ACL, исключений DNS и старых клиентов.

# Полезный минимум перед и после изменения:
Get-Date
whoami /all
Get-ADDomainController -Filter * | Select-Object HostName, Site, IPv4Address

# Сохраняйте вывод с номером заявки, а не только в истории консоли.
New-Item -ItemType Directory -Force -Path C:\Temp\AD-Change |
 Out-Null

Качественная документация отделяет факт от предположения. Факт: команда показала конкретный DC, версию или ошибку в указанное время. Предположение: эта ошибка объясняет наблюдаемое поведение. Для предположения нужен следующий тест, который может как подтвердить, так, опровергнуть его. Такой подход особенно важен в AD: один пользователь может попасть на другой контроллер домена, другой site или иметь старый токен и поэтому единичный удачный тест не описывает состояние всей среды.

Минимальная запись в журнале изменений

Время: 2026-07-14 15:00 UTC+3
Объект: имя, GUID и область действия
Гипотеза: какую причину проверяем
До: сохранённый отчёт / экспорт
Действие: одна обратимая операция
После: тот же тест, другой пользователь/узел при необходимости
Откат: условие, команда и ответственный

Такую запись можно передать дежурной смене без устных пояснений.

Права на изменение AD должны быть минимальными и раздельными. Человек, который утверждает нужду в политике или trust, не обязательно должен быть тем, кто имеет право менять все GPO, связи sites или объекты безопасности. Делегируйте операции на конкретную OU, группу или набор объектов, используйте отдельную привилегированную учётную запись и проверяйте членство в группах администрирования так же регулярно, как и рабочие ACL. Широкое членство в Domain Admins ради одной административной операции почти всегда является признаком недоработанного процесса.

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