Недостаје групна политика на 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 извештаје приватним, јер откривају интерна имена, чланства у групама и безбедносну конфигурацију. Када се подешавање потврди, уклоните додате привремене дозволе уместо да их оставите на месту.