Налаштування Group Policy для компанії

Групові політики дають змогу централізовано керувати параметрами комп’ютерів і користувачів у домені Active Directory. Через Group Policy можна встановити вимоги до паролів, налаштувати Windows Defender і брандмауер, обмежити запуск небажаних програм, підключити мережеві ресурси, розгорнути сертифікати та стандартизувати робоче середовище.

Проблеми починаються тоді, коли GPO створюють без узгодженої структури: параметри дублюються, політики конфліктують, фільтрація стає непрозорою, а кожна зміна впливає одразу на весь домен. Правильний підхід полягає не в максимальній кількості обмежень, а в передбачуваній архітектурі, поетапному тестуванні та можливості швидко визначити джерело кожного застосованого параметра.

Перед початком роботи контролери домену, DNS і реплікація Active Directory мають функціонувати без помилок. Якщо домен ще не підготовлений, спочатку варто виконати встановлення Active Directory на Windows Server 2022, перевірити SYSVOL і лише після цього переходити до централізованих політик.

Проєктування структури OU та набору політик

Group Policy Object не слід прив’язувати безпосередньо до окремих користувачів або комп’ютерів. GPO пов’язується із сайтом Active Directory, доменом або організаційним підрозділом — OU. Тому якість структури OU безпосередньо визначає, наскільки зручно буде керувати політиками.

Практична структура може виглядати так:

Company
├── Users
│   ├── Office
│   ├── Remote
│   └── Administrators
├── Workstations
│   ├── Pilot
│   ├── Office
│   └── Remote
└── Servers
    ├── Member Servers
    ├── RDS
    └── Management

OU потрібно формувати за способом керування об’єктами, а не просто копіювати організаційну схему. Наприклад, бухгалтер і системний адміністратор можуть працювати в одному відділі, але вимагати різних наборів обмежень. Сервери, робочі станції та облікові записи привілейованих користувачів також необхідно розділяти.

Для кожної функції краще створювати окрему політику. Замість одного великого об’єкта `Company Policy` доцільно використовувати зрозумілий набір:

- `SEC-Workstations-Baseline` — базові параметри безпеки робочих станцій; - `SEC-Servers-Baseline` — окремі вимоги для серверів; - `CFG-Windows-Update` — налаштування оновлень; - `CFG-Defender` — Microsoft Defender Antivirus; - `USR-Office-Restrictions` — користувацькі обмеження; - `USR-Network-Drives` — підключення мережевих дисків; - `CFG-Windows-LAPS` — керування локальними паролями адміністраторів.

Таке розділення спрощує аудит і відкат змін. Якщо проблема виникла після налаштування оновлень, адміністратору не доведеться аналізувати сотні параметрів в одному монолітному GPO.

Не варто без необхідності змінювати `Default Domain Policy` і `Default Domain Controllers Policy`. У першій зазвичай залишають тільки доменні параметри облікових записів, зокрема базову парольну політику та Kerberos. Інші налаштування потрібно виносити в окремі GPO. Такий підхід також полегшує подальше системне адміністрування та зменшує ризик випадково змінити весь домен.

Створення Central Store і базових GPO

Адміністративні шаблони ADMX визначають, які параметри доступні в редакторі Group Policy Management. Якщо редагувати політики з різних адміністративних станцій без Central Store, набір шаблонів може відрізнятися. Через це один адміністратор бачитиме параметр, а інший — ні.

Центральне сховище створюється в SYSVOL домену. Команди потрібно запускати з підвищеними правами на адміністративній станції або контролері домену:

$Domain = $env:USERDNSDOMAIN
$CentralStore = "\\$Domain\SYSVOL\$Domain\Policies\PolicyDefinitions"

New-Item -Path $CentralStore -ItemType Directory -Force
robocopy "$env:WINDIR\PolicyDefinitions" $CentralStore /E

Після копіювання потрібно відкрити Group Policy Management Editor і переконатися, що редактор повідомляє про використання шаблонів із Central Store. Перед оновленням ADMX бажано створити копію поточного каталогу: нова версія шаблонів може змінити назви або підтримувані значення окремих параметрів.

Новий GPO можна створити через консоль `gpmc.msc` або PowerShell. Наприклад, базова політика робочих станцій створюється і прив’язується до пілотного OU так:

Import-Module GroupPolicy

$GpoName = "SEC-Workstations-Baseline"
$TargetOU = "OU=Pilot,OU=Workstations,OU=Company,DC=corp,DC=example,DC=ua"

New-GPO -Name $GpoName -Comment "Базові параметри безпеки робочих станцій"
New-GPLink -Name $GpoName -Target $TargetOU -LinkEnabled Yes

На першому етапі політику слід прив’язувати тільки до тестового OU. До нього переміщують кілька комп’ютерів із різними версіями Windows і типовим набором програм. Розгортати неперевірений GPO на всі робочі станції небезпечно: одна помилка в правилах брандмауера, сценарії запуску або AppLocker може заблокувати доступ до критичних ресурсів.

Базовий набір для робочих станцій зазвичай включає:

- увімкнений Microsoft Defender Antivirus і захист у реальному часі; - активний Windows Defender Firewall для всіх профілів; - обмеження локальних адміністративних прав; - Windows LAPS для унікальних паролів локального адміністратора; - блокування екрана після визначеного періоду бездіяльності; - аудит входів, змін політик і керування обліковими записами; - контроль макросів Office та вкладень із зовнішніх джерел; - заборону застарілих протоколів, якщо вони не потрібні застосункам.

Налаштування необхідно порівнювати з реальною конфігурацією програм. Наприклад, вимкнення NTLM або SMBv1 є правильним напрямом, але спочатку потрібно знайти застарілі пристрої й сервіси, які ще залежать від цих протоколів.

Фільтрація, пріоритети та безпечне розгортання

Порядок обробки групових політик описують як LSDOU: Local, Site, Domain, Organizational Unit. Пізніше застосований параметр зазвичай має вищий пріоритет. Якщо об’єкт розміщений у вкладеному OU, спочатку обробляються політики батьківського OU, а потім дочірнього.

Параметр `Enforced` не варто використовувати як універсальний спосіб виправлення конфліктів. Він ускладнює успадкування та може неочікувано вплинути на вкладені OU. `Block Inheritance` також слід застосовувати тільки за документованої потреби. У більшості випадків проблему краще вирішити правильною структурою OU та чітким поділом політик.

Security Filtering визначає, які користувачі або комп’ютери мають право прочитати й застосувати GPO. Для пілотного розгортання можна створити групу `GG-GPO-Workstations-Pilot`, додати до неї тестові комп’ютери та надати групі дозволи `Read` і `Apply group policy`.

Важливий нюанс: комп’ютерна конфігурація оцінюється від імені облікового запису комп’ютера, а не користувача. Якщо GPO містить параметри `Computer Configuration`, до групи фільтрації потрібно додавати саме комп’ютери.

WMI-фільтри корисні, коли політика має застосовуватися лише до певної версії Windows. Приклад запиту для клієнтських операційних систем:

SELECT * FROM Win32_OperatingSystem
WHERE ProductType = 1

Однак велика кількість складних WMI-запитів збільшує час входу та запуску комп’ютера. Якщо умову можна реалізувати через OU або групу безпеки, такий варіант зазвичай простіший і швидший.

Для RDS, навчальних класів і спільних робочих станцій може знадобитися loopback processing. Режим `Merge` доповнює користувацькі параметри політиками комп’ютера, а `Replace` повністю замінює звичайний набір користувацьких GPO. Loopback слід вмикати тільки на OU з відповідними комп’ютерами, інакше результат входу користувача буде складно прогнозувати.

Рекомендована послідовність розгортання виглядає так:

1. Створити GPO без зв’язку з робочим OU. 2. Задокументувати всі ввімкнені параметри та очікуваний результат. 3. Прив’язати політику до пілотного OU. 4. Перевірити її на кількох типових комп’ютерах. 5. Проаналізувати журнали подій і звіт Resultant Set of Policy. 6. Розширити охоплення на одну групу пристроїв. 7. Лише після стабільної роботи прив’язати GPO до основного OU.

У великих середовищах зміни варто проводити через погоджене вікно, а супровід серверних політик включати до процесу адміністрування серверів Windows і Linux. Це забезпечує контроль залежностей між доменними параметрами, мережевими службами та прикладними системами.

Перевірка застосування, аудит і резервне копіювання

Після внесення змін політику можна оновити на тестовому комп’ютері:

gpupdate /force

Команда не гарантує миттєвого застосування кожного параметра. Частина налаштувань потребує виходу користувача, повторного входу або перезавантаження. Результат потрібно перевіряти, а не робити висновок лише за повідомленням `gpupdate`.

Стислий звіт про застосовані GPO виводиться командою:

gpresult /r

Для детального аналізу зручніше створити HTML-звіт:

gpresult /h C:\Temp\gpresult.html /f
Start-Process C:\Temp\gpresult.html

У звіті видно успішно застосовані й відхилені політики, причини фільтрації, групи користувача та комп’ютера, а також підсумкові значення параметрів. Для віддаленої діагностики можна використати `Get-GPResultantSetOfPolicy`:

Get-GPResultantSetOfPolicy `
  -Computer "PC-017.corp.example.ua" `
  -ReportType Html `
  -Path "C:\Temp\PC-017-RSoP.html"

Події обробки GPO розміщені в журналі:

Applications and Services Logs
└── Microsoft
    └── Windows
        └── GroupPolicy
            └── Operational

Там можна побачити проблеми з DNS, недоступність SYSVOL, помилки сценаріїв і перевищення часу обробки. Якщо політика застосовується на одному контролері домену, але відсутня на іншому, потрібно перевірити реплікацію Active Directory та стан SYSVOL.

Кожен важливий GPO необхідно резервувати перед змінами. Окрему політику можна зберегти так:

$BackupPath = "D:\GPO-Backups\$(Get-Date -Format yyyy-MM-dd)"
New-Item -Path $BackupPath -ItemType Directory -Force

Backup-GPO -Name "SEC-Workstations-Baseline" -Path $BackupPath

Для резервного копіювання всіх політик використовується:

Backup-GPO -All -Path $BackupPath

Резервна копія GPO не замінює системне резервування контролерів домену. Її призначення — швидко відновити конкретну політику або порівняти конфігурації після невдалої зміни. Копії потрібно зберігати поза контролером домену та перевіряти процедуру відновлення.

Типові помилки

**Одна політика для всіх параметрів.** Монолітний GPO складно тестувати, делегувати й відновлювати. Розділяйте налаштування за функціями та класами пристроїв.

**Редагування стандартних доменних політик без потреби.** Це ускладнює діагностику та відновлення. Використовуйте окремі GPO, крім параметрів, які дійсно повинні бути визначені на рівні домену.

**Розгортання одразу на весь домен.** Навіть коректний параметр може конфліктувати з драйвером, агентом захисту або старою програмою. Спочатку потрібні Pilot OU і тестова група.

**Надмірне використання Enforced та Block Inheritance.** Такі прапорці приховують проблеми архітектури й роблять результуючу конфігурацію менш передбачуваною.

**Неправильна Security Filtering.** Видалення `Authenticated Users` без надання іншій групі дозволів на читання може призвести до того, що GPO взагалі не оброблятиметься. Потрібно окремо перевіряти `Read` та `Apply group policy`.

**Плутанина між користувацькими й комп’ютерними параметрами.** Переміщення користувача до іншого OU не змінить застосування налаштувань із секції `Computer Configuration`. Завжди перевіряйте, до якого типу об’єкта належить параметр.

**Відсутність описів і журналу змін.** Назва GPO не пояснює, чому параметр було ввімкнено. Поле Comment, дата, відповідальна особа, номер заявки та очікуваний результат суттєво скорочують час майбутнього аудиту.

**Ігнорування реплікації.** GPO складається з об’єкта в Active Directory та файлів у SYSVOL. Пошкодження або затримка одного з компонентів створює непослідовну поведінку між контролерами домену.

Висновок

Надійне налаштування Group Policy починається зі структури OU, зрозумілих назв і розділення політик за функціями. Central Store забезпечує однакові адміністративні шаблони, Security Filtering дає контрольоване охоплення, а пілотне OU захищає основне середовище від неперевірених змін.

Кожну політику потрібно впроваджувати як керовану зміну: визначити мету, створити резервну копію, протестувати на обмеженій групі, перевірити `gpresult` і журнали подій, а потім поступово розширити область застосування. За такого підходу Group Policy стає не набором випадкових обмежень, а відтворюваним механізмом керування конфігурацією Windows-середовища.