Нещо, което е действало в офис мрежата, спира да действа в седмицата, в която потребител започне да работи през 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 отчетите поверителни, защото те разкриват вътрешни имена, членства в групи и конфигурация за сигурност. След като настройката е потвърдена, премахнете временните права, които сте добавили, вместо да ги оставяте на място.

Подобни статии