Mungon politika e grupit në VPN? Kontrolloni shtrirjen para tunelit

Diçka që zbatohej në rrjetin e zyrës ndalon së zbatuari në javën kur një përdorues fillon të punojë përmes VPN-së, dhe tuneli fajësohet përpara se dikush të hapë një raport. Politika e grupit vendos cilat cilësime arrijnë te përdoruesi dhe kompjuteri Windows, i merr materialet nga domeni dhe ekzekuton përpunimin në anën e klientit, dhe këto tre hapa dështojnë në tre mënyra të ndryshme. Tuneli ndryshon vetëm cilën rrugë ka klienti. Kalimi i kontrolleve me radhë pengon që një problem i lejeve të skedarëve të ndiqet si problem rrugëtimi.

Filloni me cilësimin, jo me tunelin

Shkruani një GPO të pritur dhe një cilësim konkret brenda saj, pastaj vendosni nëse cilësimi është në Konfigurimin e përdoruesit apo në Konfigurimin e kompjuterit. Kjo supozon një klient Windows të autorizuar dhe të bashkuar me domenin në një VPN të miratuar, jo një pajisje e paadministruar ose vetëm në re që kthehet në anëtar të domenit. Përgjigja për shtrirjen vendos kush mund ta lexojë rezultatin dhe nëse nevojitet ngritje e privilegjeve, prandaj zgjidheni atë përpara se të ekzekutoni çdo gjë.

Pyetni administratorin e domenit cila lidhje, vendndodhje objekti, filtra sigurie dhe filtra WMI duhet të jenë në lojë. Ndryshimi i këtyre kontrolleve që një test të kalojë është një projekt tjetër me një pronar tjetër.

Lexoni raportin me llogarinë së cilës i përket cilësimi

Në sesionin e vetë përdoruesit të prekur, ekzekutoni whoami /user dhe më pas gpresult /scope user /r. Llogaria që vërtetoi VPN-në nuk është automatikisht ajo llogari Windows, politika e së cilës po lexohet, dhe një kontroll nga një llogari administratori përgjigjet një pyetjeje tjetër. Ruani vijën bazë me një emër të ri skedari, siç është %TEMP%\vpn-policy-user-before.html. referenca e gpresult dokumenton çelësat e shtrirjes dhe të daljes, dhe ia vlen të dihet se krijimi i një raporti nuk rifreskon asgjë.

Politika e kompjuterit ka shtrirjen dhe kontekstin e vet të lejeve, prandaj ekzaminoni atë veçmas me ngritjen e nevojshme të privilegjeve. Bashkimi i të dyja shtrirjeve në një raport të vetëm është mënyra se si një cilësim përdoruesi shpallet i munguar kur nuk ka qenë kurrë në atë shtrirje.

Zbulimi nuk është akses: së pari regjistrimet SRV, pastaj SMB

Me VPN-në e miratuar të lidhur, konfirmoni që klienti i zgjidh kontrolluesit e domenit përmes rrugës së synuar DNS; një faqe interneti publike që ngarkohet nuk thotë asgjë për zbulimin e kontrolluesve. Për domenin ilustrues corp.example, nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.example përgjigjet pyetjes që vërtet keni. Një regjistrim shërbimi i kthyer është vetëm provë zbulimi, sepse adresa e kontrolluesit të zgjedhur duhet ende të jetë e arritshme me vërtetimin e kërkuar dhe shërbimet e drejtorisë të lejuara. Materiali i politikës vjen më pas nga SYSVOL, që është një lexim SMB ndaj pikërisht atij kontrolluesi dhe jo një test ICMP.

Një provë më e dobët ngatërrohet lehtë me një provë. Një përgjigje ICMP nga një kontrollues, pranë një leximi të refuzuar të një modeli politike, prodhon një raport që duket bosh për një arsye që askush nuk e ka lidhur ende.

Mbani koherente lejet e shërbimit AD, rrugët e kthimit dhe sinkronizimin e kohës së vendosjes, në vend që t'i zëvendësoni me një hapje të përgjithshme të firewall-it ose me një server DNS publik. Të dhënat e politikës që ndryshojnë midis kontrolluesve janë çështje replikimi për pronarin e drejtorisë.

Një rifreskim, dy raporte, një krahasim

Kur rruga është vërtetuar, kërkoni rifreskimin përkatës me gpupdate /target:user dhe lexoni rezultatin në vend që ta supozoni. Rifreskimi i parazgjedhur zbaton politikën e ndryshuar, ndërsa /force kërkon rizbatim; asnjëri prej tyre nuk rregullon DNS, lejet e skedarëve ose filtrimin. Disa zgjerime përfundojnë vetëm në një hyrje të mëvonshme ose në një ngjarje tjetër në plan të parë, kështu që një ekzekutim i vetëm nuk është verdikt. Shtimi i çelësave të daljes ose të rinisjes në sesionin e një përdoruesi në distancë si diagnostikim rutinë hedh poshtë atë që kishte hapur.

Gjeneroni një raport të dytë me një emër tjetër skedari dhe krahasoni kohën e përpunimit, GPO-në e pritur, statusin e zbatuar ose të refuzuar dhe vetë cilësimin. Një raport nga një sesion i mëparshëm i suksesshëm nuk provon asgjë për këtë rifreskim. Një politikë e filtruar tregon zbatueshmërinë dhe jo transportin, gjë që ndryshon kush e zotëron hapin tjetër.

Lidhni dështimin me një aktivitet të vetëm

Në Shikuesin e ngjarjeve, filloni me paralajmërimin ose gabimin e politikës së grupit në regjistrin e sistemit, pastaj kaloni në regjistrin operacional GroupPolicy te Regjistrat e aplikacioneve dhe shërbimeve. Filtrojeni atë regjistër operacional sipas identifikuesit të aktivitetit të rifreskimit që sapo ekzekutuat, sepse një rifreskim i ri merr një identifikues të ri, dhe përzierja me ngjarjet e djeshme prodhon një përfundim të sigurt dhe të gabuar. Regjistroni kohën, kontekstin e përdoruesit ose të kompjuterit, kontrolluesin e zgjedhur, GPO-në, kodin e gabimit dhe varësinë e dështuar.

Ai regjistrim është ajo mbi të cilën pronari i rrjetit ose i drejtorisë mund të veprojë. Të qenit i lidhur me VPN-në dhe ekzekutimi i gpupdate disa herë nuk janë prova, dhe asnjëra nuk i mbijeton një dorëzimi.

Mbani raportet HTML private, sepse zbulojnë emra të brendshëm, anëtarësi grupesh dhe konfigurim sigurie. Pasi cilësimi të konfirmohet, hiqni lejet e përkohshme që shtuat në vend që t'i lini në vend.