Falta la directiva de grup a la VPN? Comproveu l’abast abans del túnel

Una cosa que s’aplicava a la xarxa de l’oficina deixa d’aplicar-se la setmana que un usuari comença a treballar per VPN, i el túnel rep la culpa abans que ningú obri un informe. La directiva de grup decideix quines configuracions arriben a l’usuari i a l’equip de Windows, recull el material del domini i executa el processament al costat del client, i aquests tres passos fallen de tres maneres diferents. El túnel només canvia quin camí té el client. Recórrer les comprovacions en ordre evita que un problema de permisos de fitxers es persegueixi com un problema d’encaminament.

Comenceu per la configuració, no pel túnel

Anoteu una GPO esperada i una configuració concreta dins seu, i després decidiu si aquesta configuració viu a Configuració d’usuari o a Configuració d’equip. Això suposa un client Windows autoritzat i unit al domini en una VPN aprovada, no un dispositiu no gestionat o només al núvol que es converteix en membre del domini. La resposta sobre l’abast decideix qui pot llegir el resultat i si cal elevació, així que resoleu-ho abans d’executar res.

Pregunteu a l’administrador del domini quins enllaços, ubicacions d’objecte, filtres de seguretat i filtres WMI haurien d’estar en joc. Canviar aquests controls perquè una prova passi és un altre projecte amb un altre propietari.

Llegiu l’informe amb el compte a qui pertany la configuració

A la sessió pròpia de l’usuari afectat, executeu whoami /user i després gpresult /scope user /r. El compte que ha autenticat la VPN no és automàticament el compte de Windows la directiva del qual llegiu, i una comprovació feta des d’un compte d’administrador respon una altra pregunta. Deseu la línia base amb un nom de fitxer nou, com ara %TEMP%\vpn-policy-user-before.html. La referència de gpresult documenta els commutadors d’abast i de sortida, i val la pena saber que generar un informe no actualitza res.

La directiva d’equip té el seu propi abast i context de permisos, així que inspeccioneu-la per separat amb l’elevació que necessita. Ajuntar els dos abasts en un sol informe és com una configuració d’usuari es declara absent quan mai no era en aquell abast.

El descobriment no és accés: primer els registres SRV, després SMB

Amb la VPN aprovada connectada, confirmeu que el client resol els controladors de domini pel camí DNS previst; un lloc web públic que es carrega no diu res sobre el descobriment de controladors. Per al domini il·lustratiu corp.example, nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.example respon la pregunta que realment teniu. Un registre de servei retornat només és una prova de descobriment, perquè l’adreça del controlador seleccionat encara ha de ser abastable amb l’autenticació requerida i els serveis de directori permesos. El material de directiva arriba després des de SYSVOL, que és una lectura SMB contra aquell controlador concret i no una prova ICMP.

Les proves més febles es confonen fàcilment amb una prova. Una resposta ICMP d’un controlador, al costat d’una lectura denegada d’una plantilla de directiva, produeix un informe que sembla buit per una raó que encara ningú no ha connectat.

Manteniu coherents els permisos del servei AD, els camins de retorn i la sincronització horària del desplegament, en lloc de substituir-los per una obertura de tallafoc general o un servidor DNS públic. Les dades de directiva que difereixen entre controladors són una qüestió de rèplica per al propietari del directori.

Una actualització, dos informes, una comparació

Amb el camí provat, demaneu l’actualització pertinent amb gpupdate /target:user i llegiu el resultat en lloc de suposar-lo. L’actualització per defecte aplica la directiva canviada mentre que /force demana una reaplicació; cap de les dues no repara DNS, permisos de fitxers ni filtratge. Algunes extensions només es completen en un inici de sessió posterior o en un altre esdeveniment en primer pla, així que una sola execució no és un veredicte. Afegir commutadors de tancament de sessió o reinici a la sessió d’un usuari remot com a diagnòstic rutinari llença el que tenia obert.

Genereu un segon informe amb un nom de fitxer diferent i compareu el temps de processament, la GPO esperada, el seu estat aplicat o denegat i la configuració mateixa. Un informe d’una sessió anterior amb èxit no demostra res sobre aquesta actualització. Una directiva filtrada apunta a l’aplicabilitat més que al transport, cosa que canvia qui posseeix el pas següent.

Lligueu la fallada a una sola activitat

Al Visor d’esdeveniments, comenceu per l’avís o l’error de directiva de grup al registre del sistema, i després passeu al registre operatiu GroupPolicy a Registres d’aplicacions i serveis. Filtreu aquest registre operatiu per l’identificador d’activitat de l’actualització que acabeu d’executar, perquè una actualització nova obté un identificador nou i barrejar-lo amb els esdeveniments d’ahir produeix una conclusió confiada i errònia. Anoteu l’hora, el context d’usuari o d’equip, el controlador seleccionat, la GPO, el codi d’error i la dependència fallida.

Aquesta anotació és el que el propietari de la xarxa o del directori pot fer servir. Estar connectat a la VPN i haver executat gpupdate diverses vegades no són proves, i cap de les dues coses no sobreviu a un traspàs.

Manteniu els informes HTML privats, perquè exposen noms interns, pertinença a grups i configuració de seguretat. Un cop confirmada la configuració, traieu els permisos temporals que heu afegit en lloc de deixar-los al seu lloc.