Groepbeleid ontbreek op VPN? Kyk eers na die omvang voor die tonnel

Iets wat op die kantoornetwerk gegeld het, hou op geld die week wanneer ’n gebruiker oor VPN begin werk, en die tonnel kry die skuld voordat iemand ’n verslag oopmaak. Groepbeleid bepaal watter instellings op die Windows-gebruiker en -rekenaar beland, haal die materiaal by die domein en voer die kliëntkant-verwerking uit, en dié drie stappe faal op drie verskillende maniere. Die tonnel verander net watter pad die kliënt het. Om die kontroles in volgorde te loop, keer dat ’n lêertoestemmingsprobleem as ’n routeringsprobleem nagejaag word.

Begin by die instelling, nie by die tonnel nie

Skryf een verwagte GPO en een konkrete instelling daarin neer en besluit dan of daardie instelling onder Gebruikerkonfigurasie of Rekenaarkonfigurasie val. Dit veronderstel ’n gemagtigde, domeingekoppelde Windows-kliënt op ’n goedgekeurde VPN, nie ’n onbestuurde of suiwer wolktoestel wat in ’n domeinlid omskep word nie. Die antwoord oor die omvang bepaal wie die uitslag mag lees en of verhoging nodig is, so maak dit eers klaar voordat jy enigiets uitvoer.

Vra die domeinadministrateur watter skakel, objekligging, sekuriteitsfilters en WMI-filters veronderstel is om in spel te wees. Om daardie beheermaatreëls te verander sodat ’n toets slaag, is ’n ander projek met ’n ander eienaar.

Lees die verslag met die rekening aan wie die instelling behoort

Voer in die betrokke gebruiker se eie sessie whoami /user en dan gpresult /scope user /r uit. Die rekening wat die VPN gemagtig het, is nie outomaties die Windows-rekening wie se beleid jy lees nie, en ’n kontrole vanuit ’n administrateur-rekening beantwoord ’n ander vraag. Stoor die basislyn onder ’n nuwe lêernaam soos %TEMP%\vpn-policy-user-before.html. Die gpresult-verwysing dokumenteer die skakelaars vir omvang en uitvoer, en dit is die moeite werd om te weet dat om ’n verslag te skep niks ververs nie.

Rekenaarbeleid het sy eie omvang en toestemmingskonteks, ondersoek dit dus afsonderlik met die verhoging wat dit nodig het. Om albei omvange in een verslag saam te voeg, is hoe ’n gebruikerinstelling as ontbrekend verklaar word terwyl dit nooit in daardie omvang was nie.

Ontdekking is nie toegang nie: eers SRV-rekords, dan SMB

Bevestig, met die goedgekeurde VPN gekoppel, dat die kliënt domeinbeheerders deur die beoogde DNS-pad oplos; ’n openbare webwerf wat laai, sê niks oor die ontdekking van beheerders nie. Vir die voorbeelddomein corp.example beantwoord nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.example die vraag wat jy werklik het. ’n Teruggegee diensrekord is net ontdekkingsbewys, want die gekose beheerder se adres moet steeds bereikbaar wees met die vereiste verifikasiemiddels en toegelate gidsdienste. Beleidsmateriaal kom dan uit SYSVOL, wat ’n SMB-lesing teen daardie spesifieke beheerder is en nie ’n ICMP-toets nie.

Swakker bewyse word maklik vir ’n bewys aangesien. ’n ICMP-antwoord van ’n beheerder, langs ’n geweierde lesing van ’n beleidsjabloon, lewer ’n verslag wat leeg lyk om ’n rede wat nog niemand gekoppel het nie.

Hou die ontplooiing se AD-diensregte, terugpaaie en tydsinkronisasie samehangend eerder as om dit met ’n bree firewall-opening of ’n openbare DNS-bediener te vervang. Beleidsdata wat tussen beheerders verskil, is ’n replikasievraag vir die gidseienaar.

Een verversing, twee verslae, een vergelyking

Vra met die pad bewys die tersaaklike verversing met gpupdate /target:user en lees die uitslag in plaas daarvan om dit te veronderstel. Die standaardverversing pas veranderde beleid toe, terwyl /force hertoepassing versoek; nie een van die twee herstel DNS, lêertoestemmings of filtering nie. Sekere uitbreidings voltooi eers by ’n latere aanmelding of ’n ander voorgrondgebeurtenis, so ’n enkele loop is nie ’n uitspraak nie. Om aflok- of herlaai-skakelaars as roetinediagnose by ’n afgeleë gebruiker se sessie te voeg, gooi weg wat hulle oopgehad het.

Skep ’n tweede verslag onder ’n ander lêernaam en vergelyk die verwerkingstyd, die verwagte GPO, sy toegepaste of geweierde status en die instelling self. ’n Verslag uit ’n vroeëre suksesvolle sessie bewys niks oor hierdie verversing nie. ’n Beleid wat uitgefilter is, dui op toepaslikheid eerder as op vervoer, wat verander wie die volgende stap besit.

Bind die faling aan een enkele aktiwiteit

Begin in Gebeureverkyker met die Groepbeleid-waarskuwing of -fout in die Stelsel-log, en gaan dan na die Groepbeleid-bedryfslog onder Toepassing- en Dienslogboeke. Filter daardie bedryfslog volgens die aktiwiteitsidentifiseerder van die verversing wat jy pas uitgevoer het, want ’n nuwe verversing kry ’n nuwe identifiseerder en om dit met gister se gebeure te meng, lewer ’n selfversekerde, verkeerde gevolgtrekking. Teken die tyd, die gebruiker- of rekenaarkonteks, die gekose beheerder, die GPO, die foutkode en die mislukte afhanklikheid aan.

Dié aantekening is waarop die netwerk- of gidseienaar kan reageer. Om aan die VPN gekoppel te wees en gpupdate verskeie kere te hardloop, is nie bewyse nie, en nie een van die twee oorleef ’n oorhandiging nie.

Hou die HTML-verslae privaat, want hulle lê interne name, groeplidmaatskap en sekuriteitskonfigurasie bloot. Sodra die instelling bevestig is, verwyder die tydelike toestemmings wat jy bygevoeg het in plaas daarvan om dit te laat staan.