Puuttuuko ryhmäkäytäntö VPN:ssä? Tarkista laajuus ennen tunnelia

Jokin, joka toimi toimistoverkossa, lakkaa toimimasta viikolla, jolloin käyttäjä alkaa työskennellä VPN:n yli, ja tunneli saa syyn ennen kuin kukaan avaa raportin. Ryhmäkäytäntö päättää, mitkä asetukset päätyvät Windows-käyttäjälle ja -tietokoneelle, hakee materiaalin toimialueelta ja suorittaa asiakaspään käsittelyn, ja nämä kolme vaihetta epäonnistuvat kolmella eri tavalla. Tunneli muuttaa vain sitä, mikä polku asiakkaalla on. Tarkistusten järjestyksessä läpikäyminen estää tiedostojen käyttöoikeusongelman jahtaamisen reititysongelmana.

Aloita asetuksesta, älä tunnelista

Kirjoita yksi odotettu GPO ja yksi konkreettinen asetus siinä, ja päätä sitten, kuuluuko asetus käyttäjän vai tietokoneen kokoonpanoon. Tämä edellyttää valtuutettua, toimialueeseen liitettyä Windows-asiakasta hyväksytyssä VPN:ssä, ei hallitsematonta tai vain pilvessä olevaa laitetta, josta tehdään toimialueen jäsen. Laajuuden vastaus ratkaisee, kuka saa lukea tuloksen ja tarvitaanko oikeuksien korotusta, joten selvitä se ennen kuin suoritat mitään.

Kysy toimialueen ylläpitäjältä, minkä linkin, objektin sijainnin, suodattimien ja WMI-suodattimien pitäisi olla käytössä. Näiden hallintojen muuttaminen testin läpäisemiseksi on toinen projekti, jolla on toinen omistaja.

Lue raportti sillä tilillä, jolle asetus kuuluu

Suorita kohdekäyttäjän omassa istunnossa whoami /user ja sitten gpresult /scope user /r. Tili, joka todensi VPN:n, ei ole automaattisesti se Windows-tili, jonka käytäntöä luet, ja ylläpitotililtä tehty tarkistus vastaa eri kysymykseen. Tallenna lähtötaso uudella tiedostonimellä, esimerkiksi %TEMP%\vpn-policy-user-before.html. gpresult-viite kuvaa laajuus- ja tulostekytkimet, ja on syytä tietää, että raportin luominen ei päivitä mitään.

Tietokonekäytännöllä on oma laajuutensa ja käyttöoikeuskontekstinsa, joten tarkastele sitä erikseen tarvittavalla oikeuksien korotuksella. Molempien laajuuksien kokoaminen yhteen raporttiin on tapa, jolla käyttäjän asetus julistetaan puuttuvaksi, vaikka se ei koskaan ollut siinä laajuudessa.

Löytäminen ei ole pääsy: ensin SRV-tietueet, sitten SMB

Kun hyväksytty VPN on yhdistetty, varmista, että asiakas ratkaisee toimialueen ohjaimet aiottua DNS-polkua pitkin; latautuva julkinen verkkosivusto ei kerro ohjainten löytämisestä mitään. Esimerkkitoimialueelle corp.example nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.example vastaa kysymykseen, joka sinulla todella on. Palautettu palvelutietue on vain löytämistodiste, koska valitun ohjaimen osoitteen on edelleen oltava tavoitettavissa vaaditulla todentamisella ja sallituilla hakemistopalveluilla. Käytäntömateriaali saapuu sitten SYSVOLista, mikä on SMB-luku juuri sitä ohjainta vastaan eikä ICMP-testi.

Heikompi todiste sekoitetaan helposti todisteeksi. Ohjaimen ICMP-vastaus käytäntömallin hylätyn luvun vieressä tuottaa raportin, joka näyttää tyhjältä syystä, jota kukaan ei ole vielä yhdistänyt.

Pidä käyttöönoton AD-palvelun käyttöoikeudet, paluupolut ja aikasynkronointi yhtenäisinä sen sijaan, että korvaisit ne yleisellä palomuurin avauksella tai julkisella DNS-palvelimella. Käytäntötiedot, jotka eroavat ohjainten välillä, ovat hakemiston omistajan replikointikysymys.

Yksi päivitys, kaksi raporttia, yksi vertailu

Kun polku on todistettu, pyydä asiaankuuluva päivitys komennolla gpupdate /target:user ja lue tulos sen sijaan että olettaisit sen. Oletuspäivitys soveltaa muuttunutta käytäntöä, kun taas /force pyytää uudelleensoveltamista; kumpikaan ei korjaa DNS:ää, tiedostojen käyttöoikeuksia tai suodatusta. Jotkin laajennukset valmistuvat vasta myöhemmässä kirjautumisessa tai toisessa etualan tapahtumassa, joten yksi ajo ei ole tuomio. Uloskirjautumis- tai uudelleenkäynnistyskytkimien lisääminen etäkäyttäjän istuntoon rutiinidiagnostiikkana heittää pois sen, mitä hänellä oli auki.

Luo toinen raportti eri tiedostonimellä ja vertaa käsittelyaikaa, odotettua GPO:ta, sen sovellettua tai evättyä tilaa ja itse asetusta. Aiemman onnistuneen istunnon raportti ei todista tästä päivityksestä mitään. Suodatettu käytäntö viittaa soveltuvuuteen eikä siirtoon, mikä muuttaa sitä, kenelle seuraava vaihe kuuluu.

Sido epäonnistuminen yhteen toimintoon

Tapahtumien valvonnassa aloita järjestelmälokin ryhmäkäytäntövaroituksesta tai -virheestä ja siirry sitten Sovellusten ja palvelujen lokit -kohdan alla olevaan toiminnalliseen GroupPolicy-lokiin. Suodata tämä toiminnallinen loki juuri suorittamasi päivityksen toimintotunnuksella, koska uusi päivitys saa uuden tunnuksen ja sen sekoittaminen eilisiin tapahtumiin tuottaa itsevarman ja väärän johtopäätöksen. Kirjaa aika, käyttäjä- tai tietokonekonteksti, valittu ohjain, GPO, virhekoodi ja epäonnistunut riippuvuus.

Tämä kirjaus on se, mihin verkon tai hakemiston omistaja voi reagoida. VPN:ään yhdistettynä oleminen ja gpupdaten useasti suorittaminen eivät ole todisteita, eikä kumpikaan selviä luovutuksesta.

Pidä HTML-raportit yksityisinä, sillä ne paljastavat sisäisiä nimiä, ryhmäjäsenyyksiä ja tietoturvakokoonpanon. Kun asetus on vahvistettu, poista lisäämäsi väliaikaiset käyttöoikeudet sen sijaan että jättäisit ne paikoilleen.