Групова політика не діє на VPN? Перевірте область дії до тунелю

Щось, що діяло в офісній мережі, перестає діяти того тижня, коли користувач починає працювати через VPN, і тунель отримує провину раніше, ніж хтось відкриє звіт. Групова політика вирішує, які налаштування потрапляють на користувача й комп'ютер Windows, тягне матеріал з домену та виконує обробку на боці клієнта, і ці три кроки зазнають невдачі трьома різними способами. Тунель змінює лише те, який шлях має клієнт. Послідовне проходження перевірок не дає ганятися за проблемою прав на файли як за проблемою маршрутизації.

Почніть з налаштування, а не з тунелю

Запишіть одну очікувану GPO і одне конкретне налаштування в ній, потім вирішіть, чи це налаштування в конфігурації користувача, чи в конфігурації комп'ютера. Це передбачає авторизований клієнт Windows, уведений у домен, у схваленому VPN, а не некерований пристрій або пристрій лише в хмарі, який роблять членом домену. Відповідь про область дії визначає, хто може читати результат і чи потрібне підвищення прав, тому з'ясуйте це до запуску чого-небудь.

Запитайте адміністратора домену, яке прив'язування, розташування об'єкта, фільтри безпеки та фільтри WMI мають бути задіяні. Змінювати ці засоби керування, щоб тест пройшов, — інший проєкт з іншим власником.

Читайте звіт під обліковим записом, якому належить налаштування

У власному сеансі постраждалого користувача виконайте whoami /user, а потім gpresult /scope user /r. Обліковий запис, який автентифікував VPN, не обов'язково є тим обліковим записом Windows, чию політику ви читаєте, і перевірка з адміністративного запису відповідає на інше питання. Збережіть базовий стан під новим іменем файлу, наприклад %TEMP%\vpn-policy-user-before.html. довідка з gpresult описує перемикачі області дії та виводу, і варто знати, що створення звіту нічого не оновлює.

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

Виявлення — не доступ: спочатку записи SRV, потім SMB

Коли схвалений VPN підключено, підтвердьте, що клієнт розв'язує контролери домену призначеним шляхом DNS; публічний сайт, що завантажується, нічого не каже про виявлення контролерів. Для прикладу домену corp.example на питання, яке ви справді маєте, відповідає nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.example. Повернутий запис служби — лише доказ виявлення, бо адреса вибраного контролера все ще має бути доступною з потрібною автентифікацією та дозволеними службами каталогу. Матеріал політики потім надходить із SYSVOL, а це читання SMB саме до того контролера, а не перевірка ICMP.

Слабший доказ легко прийняти за доказ. Відповідь ICMP від контролера поруч із відхиленим читанням шаблону політики дає звіт, який виглядає порожнім з причини, яку ще ніхто не пов'язав.

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

Одне оновлення, два звіти, одне порівняння

Коли шлях доведено, попросіть відповідне оновлення за допомогою gpupdate /target:user і прочитайте результат, а не припускайте його. Оновлення за замовчуванням застосовує змінену політику, тоді як /force просить повторне застосування; жодне з них не виправляє DNS, права на файли чи фільтрування. Деякі розширення завершуються лише під час наступного входу або іншої події на передньому плані, тож один запуск — не вирок. Додавати перемикачі виходу або перезавантаження в сеанс віддаленого користувача як рутинну діагностику — це викинути те, що в нього було відкрито.

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

Прив'яжіть збій до однієї єдиної операції

У засобі перегляду подій почніть із попередження або помилки групової політики в системному журналі, потім перейдіть до операційного журналу GroupPolicy у розділі Журнали програм і служб. Відфільтруйте цей операційний журнал за ідентифікатором операції того оновлення, яке ви щойно запустили, бо нове оновлення отримує новий ідентифікатор, і змішування його з учорашніми подіями дає впевнений і хибний висновок. Запишіть час, контекст користувача або комп'ютера, вибраний контролер, GPO, код помилки та невдалу залежність.

Цей запис — те, на що може спиратися власник мережі або каталогу. Бути підключеним до VPN і кілька разів запустити gpupdate — не докази, і ні те, ні інше не переживе передавання.

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