38 политик, из которых работали 11: как я перестраиваю GPO в небольшом домене

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

С чего начинать наводить порядок в GPO

GPO — это не файл с настройками и не «команда, которую сервер отправляет компьютерам». Объект групповой политики состоит из данных в Active Directory и файловой части в SYSVOL. Сам GPO ничего не делает, пока его не свяжут с сайтом, доменом или OU. Клиент получает доступные ему объекты, проверяет разрешения и фильтры, а затем применяет настройки. Поэтому неисправность может находиться в четырёх разных местах: настройке, связи, правах или репликации. Это важно понять до открытия редактора политик — и именно с этого я начинаю любой аудит Active Directory, даже если заказчик просит «просто поправить одну политику».

Порядок обработки — Local, Site, Domain, OU. Вложенные OU идут от родительской к дочерней, а более близкая политика обычно побеждает при конфликте. В консоли GPMC у связи с меньшим номером Link Order выше приоритет. Но я не проектирую домен как турнир конфликтующих настроек. Если администратору приходится каждый раз вычислять, какая из семи политик победила, архитектура уже плохая. Enforced и Block Inheritance применяю как исключение, а не как штатный способ навести порядок.

Для компании до 50 рабочих мест я предпочитаю один домен, два контроллера и простую структуру OU. Два контроллера нужны не ради производительности GPO, а чтобы поломка узла, обновление или восстановление не остановили вход пользователей и DNS. В типовой среде каждому виртуальному контроллеру у меня хватает 2 vCPU, 8 Гбайт памяти и 80–100 Гбайт быстрого диска — это практический ориентир, а не требование Microsoft. Контроллеры размещаю на разных физических узлах. Если домен только проектируется, логику OU удобно заложить сразу, как в разборе про развёртывание Active Directory с нуля, а не переделывать через три года.

• OU=Domain Controllers — только контроллеры домена
• OU=Servers — рядовые серверы
• OU=Workstations с дочерней OU=Pilot — рабочие станции
• OU=Users с отдельной OU=Admins — пользователи и административные учётные записи
• OU=Service Accounts — сервисные учётные записи, если они действительно нужны

Сколько GPO нужно небольшому домену и как их назвать

В небольшом домене мне обычно достаточно 8–12 рабочих политик. Я разделяю их по назначению и типу объектов: DOM-Account-Policy, DC-Security, SRV-Security, WS-Security, WS-Update, WS-LAPS, USR-Office, USR-Restrictions, GPP-Drives-Printers. Обновления рабочих станций при этом лучше отдавать одной политике, а не размазывать по трём. Цифры в начале имени допустимы, если команда действительно следует одной схеме приоритетов. Важнее, чтобы из названия сразу были понятны объект, задача и область применения.

Политику паролей и блокировки доменных учётных записей я оставляю в Default Domain Policy. В неё не добавляю принтеры, браузер, брандмауэр и десятки параметров интерфейса. Default Domain Controllers Policy тоже не превращаю в общий набор защиты серверов. Эти два стандартных объекта должны оставаться короткими и предсказуемыми: их восстановление и диагностика тогда намного проще.

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

В комментарии каждого GPO записываю цель, владельца, дату изменения и номер заявки. Если одна половина объекта не используется, отключаю её через GPO Status: у чисто компьютерной политики — User Configuration Settings Disabled. Это немного сокращает обработку и, что для меня важнее, исключает случайное появление пользовательских настроек там, где их никто не ждёт.

• Одна политика — одна понятная зона ответственности
• Никаких имён вроде New GPO или Test2
• Не редактировать рабочий GPO без резервной копии
• Не хранить отключённые эксперименты годами
• Не связывать один объект со всем доменом «на всякий случай»

Как ограничить область действия GPO: OU, группы, WMI

Основной инструмент назначения политики — правильная OU. Security Filtering использую, когда внутри одной OU действительно нужна ограниченная группа, например кассовые компьютеры или пилот обновления. Для дисков и принтеров удобны Group Policy Preferences с Item-level Targeting по группе безопасности или AD Site. Действие для обычного сетевого принтера выбираю Update: Replace удаляет и заново создаёт объект при обработке, из-за чего пользователи видят пропадающие подключения. Если принтеров больше десятка и драйверы разные, отдельно продумываю централизованную печать через GPO — это отдельный проект, а не одна строчка в Preferences.

Есть неприятная ловушка. После удаления Authenticated Users из Security Filtering компьютер может потерять право читать GPO, даже если объект содержит только пользовательские настройки. Современная обработка получает пользовательскую политику в контексте компьютера. Поэтому я либо оставляю Authenticated Users с правом Read без Apply Group Policy, либо явно даю Read группе Domain Computers. Пользовательской целевой группе выдаю Read и Apply Group Policy. Я регулярно встречаю домены, где эту ошибку неделями пытаются исправить командами gpupdate.

WMI-фильтр применяю только там, где условие нельзя нормально выразить через OU или группу: например, зависимость от редакции либо версии ОС. Фильтр вычисляется на клиенте, усложняет диагностику и способен задержать обработку при проблемах WMI. Loopback в режиме Merge или Replace оставляю для общих терминалов и специализированных рабочих мест, где пользовательское окружение должно зависеть от компьютера. На обычных ноутбуках он не нужен.

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

• OU — основной способ назначения
• Группа безопасности — исключение внутри OU
• Item-level Targeting — отдельные элементы Preferences
• WMI — только для свойств, которых нет в AD
• Deny Apply Group Policy — крайняя мера, потому что запрет имеет приоритет

Какие политики безопасности включать первыми

На 2026 год я беру за отправную точку Microsoft Security Compliance Toolkit: для клиентов есть baseline Windows 11 25H2 (вышел в конце сентября 2025 года), для серверов — пакеты Windows Server 2022 и Windows Server 2025 (последняя ревизия, которую я брал, — 2602 от февраля 2026 года). Но целиком импортировать baseline в рабочий домен за один вечер — плохая идея. Там сотни параметров, включая аудит, сетевую аутентификацию и ограничения старых протоколов. Они разумны с точки зрения защиты, но способны отключить старый сканер, кассовый агент или обмен с медицинской системой. Я сравниваю рекомендации через Policy Analyzer, выбираю применимые настройки и проверяю их на пилоте.

В первую очередь включаю брандмауэр на всех профилях, Microsoft Defender с облачной защитой, UAC, блокировку экрана, расширенный аудит входов и управления учётными записями. Затем ограничиваю локальных администраторов и внедряю Windows LAPS. На запрет панели управления, обоев и флешек можно временно забить, если бизнес не сформулировал такую задачу. Единый локальный пароль администратора на всех компьютерах опаснее неправильной заставки в сотни раз.

Для Windows LAPS в локальном AD один раз расширяю схему, разрешаю компьютерам записывать атрибуты в своей OU и отдельно делегирую чтение паролей. В GPO (Computer Configuration → Policies → Administrative Templates → System → LAPS) задаю: резервное копирование в Active Directory (BackupDirectory=2), длину 20 символов, срок 14 дней, сложность 4 (заглавные, строчные, цифры, спецсимволы), шифрование пароля в AD и действие после использования «сбросить пароль и завершить сеанс» с задержкой 8 часов вместо стандартных 24. Шифрование пароля в AD требует уровня функционирования домена Windows Server 2016 или выше. Расшифровку разрешаю отдельной группе поддержки через параметр ADPasswordEncryptionPrincipal — без него расшифровывать смогут только Domain Admins. Подробнее про сам механизм я писал в статье о Windows LAPS для паролей локальных администраторов.

Update-LapsADSchema
Set-LapsADComputerSelfPermission -Identity 'OU=Workstations,DC=corp,DC=example,DC=local'
Set-LapsADReadPasswordPermission -Identity 'OU=Workstations,DC=corp,DC=example,DC=local' -AllowedPrincipals 'CORP\GG-LAPS-Readers'

Перед изменением схемы обязательны проверка репликации и резервная копия состояния системы контроллера домена. И не забудьте вручную скопировать LAPS.admx в центральное хранилище: Windows Update туда его сам не положит.

Пароли доменных пользователей — отдельная тема. В Default Domain Policy я задаю осмысленную минимальную длину, историю, запрет обратимого шифрования и аккуратную блокировку учётной записи. Не заставляю сотрудников менять пароль каждые две недели только ради отчёта: это рождает предсказуемые пароли и стикеры. Для администраторов при необходимости применяю гранулированные политики паролей (FGPP) — через PSO на группу, а не отдельным GPO, который для доменных паролей просто не сработает. А пароли в Group Policy Preferences не храню вообще: старые значения cpassword в SYSVOL расшифровываются, и исправление MS14-025 не удаляло созданные ранее секреты.

• Сначала брандмауэр, Defender, аудит и LAPS
• Затем сетевое усиление и ограничения приложений
• После совместимости — Attack Surface Reduction и прочие жёсткие меры
• Косметические запреты — в последнюю очередь

Кейс: 43 рабочих места и вход по 9 минут

Разберу проект у условного клиента — трикотажного производства «Вязаная нить», 43 рабочих места. Офис с бухгалтерией, продажами и складом плюс цех, где у мастеров смен стоят 8 компьютеров и два общих ПК на участке раскроя. Все рабочие станции на Windows 11 Pro: 29 на 24H2 и 14 на 25H2. Домен обслуживали два контроллера Windows Server 2022 Standard, уровень функционирования леса и домена — Windows Server 2016. В GPMC мы нашли 38 GPO, из которых реально что-то полезное делали 11, семь связей с уже удалёнными OU и четыре WMI-фильтра. У всех ПК был одинаковый пароль локального администратора, и его знала половина бывших подрядчиков.

Жалобы были типичные: вход от 3 до 9 минут по утрам и пропадающие принтеры этикеток на складе. Причина оказалась не одна. Два сценария входа по очереди проверяли сетевые пути на давно выключенном файловом сервере и ждали тайм-аута. Для 9 принтеров в Preferences стояло действие Replace, поэтому подключения пересоздавались при каждом фоновом обновлении политики. Один WMI-фильтр опрашивал Win32_Product — этот класс запускает проверку согласованности всех установленных MSI-пакетов и на медленном диске съедал десятки секунд. Наконец, две пользовательские политики не читались компьютерами после удаления Authenticated Users из фильтрации. Вот почему я не верю в диагноз «GPO тормозит»: тормозит конкретная архитектура или конкретное расширение.

Работу уложили в три недели без остановки цеха. Выгрузили отчёты всех объектов, зафиксировали связи и сократили рабочий набор до 11 GPO. Создали OU Workstations, Pilot, Shopfloor, Servers, Users, Admins и Service Accounts. В пилот вошли четыре компьютера: бухгалтерия, склад, мастер смены и общий ПК раскроя. Для двух общих ПК цеха включили loopback в режиме Replace, чтобы у любого входящего был одинаковый минимальный рабочий стол. Принтеры и диски раздали по группам через Item-level Targeting с действием Update, запрос к Win32_Product убрали, мёртвые пути из сценариев удалили. Windows LAPS внедрили с 20-символьным паролем и ротацией раз в 14 дней. Baseline Windows 11 и Windows Server 2022 не импортировали вслепую: сравнили в Policy Analyzer и включали четырьмя волнами.

Результат измеряли, а не оценивали на глаз. На восьми контрольных ПК медиана обработки политик при входе снизилась со 148 до 43 секунд, худший вход — с 540 до 95 секунд (по событиям журнала Microsoft-Windows-GroupPolicy/Operational). За шесть недель после запуска не было ни одной заявки о пропавшем принтере; до изменений их было шесть в месяц. Общее число обращений по входу, дискам и политикам снизилось с 19 до 6 в месяц. Две старые программы — учёт раскроя и драйвер вязальной машины — потребовали исключений из жёстких настроек, и я считаю это нормальным итогом пилота. В массовое развёртывание не попало ни одной настройки, способной остановить смену.

• 4 пилотных ПК из разных участков
• 38 исходных GPO, 11 после упрощения
• 20 символов и 14 дней для Windows LAPS
• 4 волны включения защитных настроек
• 3 недели работ, 6 недель наблюдения

Как менять, проверять и восстанавливать GPO

Рабочий GPO я не редактирую напрямую ради быстрой проверки. Создаю копию, связываю её только с OU=Pilot, моделирую результат в GPMC и проверяю минимум на одном обычном пользователе и одном администраторе. После теста делаю резервную копию, фиксирую отчёт и переношу изменение в рабочий объект. Для опасной настройки заранее описываю откат: отключить связь, вернуть предыдущий backup или удалить конкретный параметр.

Перед изменениями и по расписанию сохраняю все объекты и HTML-отчёты. Сам backup содержит настройки, идентификатор и ACL объекта, но связи с OU находятся на стороне контейнеров AD. Поэтому отдельно выгружаю Get-GPInheritance для важных OU или документирую связи из GPMC. Копию держу вне контроллеров домена и периодически проверяю восстановление.

$path = 'C:\GPO-Backup\2026-09-08'
New-Item -ItemType Directory -Path $path -Force
Backup-GPO -All -Path $path -Comment 'Перед плановыми изменениями'
Get-GPO -All | ForEach-Object {
    Get-GPOReport -Guid $_.Id -ReportType Html -Path (Join-Path $path ($_.Id.ToString() + '.html'))
}

Простого копирования папки SYSVOL недостаточно для корректного резервного копирования GPO.

Когда политика не применяется, я сначала строю результирующий набор (пошагово этот разбор описан в статье про диагностику через gpresult и RSoP), а не нажимаю gpupdate /force десять раз. Проверяю правильный контроллер, время, DNS, OU, группы, права Read/Apply, WMI-фильтр и журнал Microsoft-Windows-GroupPolicy/Operational. Обычный клиент обновляет политики каждые 90 минут со случайным смещением до 30 минут; контроллеры домена проверяют изменения компьютерной политики каждые 5 минут. Кроме того, отдельные расширения требуют запуска или нового входа, поэтому принудительное обновление не гарантирует мгновенный эффект.

gpresult /h C:\Temp\gpresult.html
Get-GPResultantSetOfPolicy -Computer PC-017 -User 'CORP\ivanov' -ReportType Html -Path C:\Temp\rsop.html

Если на разных компьютерах получается разный результат, проверяю репликацию AD и SYSVOL. Объект политики хранится в двух местах, и рассинхронизация между ними — редкая, но вполне реальная причина странного поведения.

Раз в месяц просматриваю ошибки обработки и изменения GPO, раз в квартал — неиспользуемые объекты, фильтры, делегирование и восстановимость копий. На это небольшой компании достаточно нескольких часов. Не рекомендую еженедельно «оптимизировать» стабильные политики. Главный показатель зрелости здесь скучный: изменение можно объяснить, проверить на пилоте, отменить и восстановить без героизма администратора.

• Перед изменением: backup, отчёт и план отката
• После изменения: RSoP и журнал GroupPolicy/Operational
• Ежемесячно: ошибки и несанкционированные изменения
• Ежеквартально: связи, фильтры, делегирование и тест восстановления

Частые вопросы