Shtimi i një përdoruesi në një grup VPN nuk jep akses më vete

E vendosët llogarinë në grupin e duhur, hyrja doli me sukses, dhe lidhja vazhdon të refuzohet — ose lidhet dhe nuk arrin asgjë të dobishme. Refleksi i zakonshëm është të shtohet përdoruesi në më shumë grupe derisa diçka të popusti, dhe kështu organizatat përfundojnë duke dhënë shumë më tepër sesa kërkonte kërkesa. Anëtarësimi në grup është një nga të dhënat për një vendim autorizimi, kurrë vetë vendimi: një gateway mbledh disa fakte për sesionin, i përputh me politikën e renditur dhe vetëm atëherë vendos çfarë mund të prekë ai sesion. Nëse dështoi një kusht tjetër, ndryshimi i grupit nuk ndryshon asgjë përveç ekspozimit tuaj. Ja si ndërtohet në të vërtetë vendimi, ku anëtarësimi nuk mjafton më, dhe kontrolli që ju tregon se cilën dështim po shihni.

Anëtarësimi në grup është kusht, jo leje

Në RADIUS grupi vjen si atribut autorizimi, dhe atributet përshkruajnë sesionin në vend që ta japin. Serveri përgjigjet me Access-Accept ose Access-Reject; në pranim mund të bashkëngjitë Filter-Id, Class ose atributet e tunelit nga RFC 2868, dhe pajisja e rrjetit në anën tjetër i interpreton ato siç ka vendosur furnizuesi i saj. Asgjë në protokoll nuk e lidh një grup me akses të plotë. Ky mapim shkruhet nga kushdo që konfiguroi politikën në gateway ose në serverin e aksesit të rrjetit, dhe mund të jetë aq i ngushtë sa një host i vetëm.

Kjo shpjegon pse i njëjti emër grupi sillet ndryshe në dy sisteme. Microsoft NPS ndërton politika rrjeti nga kushte, kufizime dhe cilësime dhe i vlerëson në një rend të konfiguruar. OpenVPN Access Server ka modelin e vet të grupeve dhe rregullave të aksesit, ndërsa një server OpenVPN i komunitetit shpesh e delegon të gjithë çështjen te një skript client-connect ose një skedar client-config-dir. Secili konsumon një grup; asnjë nuk ndan logjikën e përparësisë së tjetrit. Një grup rregullash i kopjuar mes tyre nuk provon asgjë për atë që po korrigjoni.

Rregulli që përputhet vendos, jo grupi që prisnit

Shumica e motorëve ndalen te politika e parë që përputhet, ose te ajo më specifike. Nëse politika 3 refuzon dhe politika 7 lejon, një sesion mund të dështojë pa arritur kurrë te rregulli që do ta kishte lënë të kalonte. Rendi është një cilësim real në NPS dhe në shumicën e produkteve të kontrollit të aksesit në rrjet, dhe ai zhvendoset kur politikat shtohen me kalimin e viteve. Dikush ngre një politikë refuzimi në krye për të frenuar një incident të palidhur, dhe një grup që punonte tremujorin e kaluar ndalon së punuari.

Kushtet që udhëtojnë bashkë me grupin janë gjysma tjetër e problemit. Gjendja e pajisjes, metoda e vërtetimit, përfundimi i MFA-së, rrjeti burimor, subjekti i certifikatës ose një dritare orare mund të qëndrojnë të gjitha në të njëjtën politikë. Kur njëri prej tyre nuk plotësohet, politika nuk përputhet, motori kalon më tej dhe zbatohet një refuzim i parazgjedhur. Nga këndvështrimi i përdoruesit kjo duket sikur grupi po injorohet; nga këndvështrimi i motorit grupi nuk u konsultua kurrë.

Detajet e drejtorisë prodhojnë të njëjtin iluzion. Një politikë që përputhet me anëtarësimin në grupin Windows lexon SID-të në tokenin e përdoruesit, dhe aty numërohen vetëm grupet e sigurisë — një grup shpërndarjeje nuk shfaqet kurrë. Grupi primar i një përdoruesi mbahet në fushën e vet në vend të listës së numëruar, kështu që një politikë e lidhur me atë grup mund të dështojë në heshtje. Grupet e riemërtuara dhe SID-të ndër-domen kanë hapa përkthimi që dështojnë në heshtje kur një besim është njëdrejtimësh.

Lexoni regjistrin e pranimit ose refuzimit përpara se të prekni një grup

Bëni një pyetje së pari: a arriti kërkesa fare në fazën e autorizimit? Në NPS përgjigjja është tashmë në regjistrin e ngjarjeve, ku 6272 shënon një akses të dhënë, 6273 një refuzim dhe 6274 një kërkesë që serveri e hodhi poshtë përpara se të vlerësonte politikën. Këto tre numra e ndajnë problemin në tre hetime të ndryshme, dhe vetëm njëri prej tyre ka të bëjë me grupet.

Kur regjistri është jashtë arritjes, pyesni serverin drejtpërdrejt dhe lexoni çfarë kthen. Një përgjigje që nuk mbart Filter-Id as atribute tuneli ju thotë se serveri e trajton sesionin si të zakonshëm dhe gateway-i po zbaton rregulla të vetat. Një përgjigje që mbart atribute që pika e zbatimit nuk i zbaton është një defekt tjetër: autorizimi kaloi dhe pajisja që duhej të vepronte sipas tij e injoroi rezultatin.

radtest alice 'password' 10.0.0.5 0 testing123

Krahasoni atributet e kthyera me ato që dokumenton gateway-i, jo me atë që sugjeron emri i grupit. Ky krahasim zakonisht e ndan një problem politike nga një problem zbatimi përpara se dikush të modifikojë një grup.

Ndryshimi i grupit nuk është retroaktiv

Atributet e autorizimit kthehen një herë, kur sesioni vërtetohet. Gateway-i i ruan ato në sesion dhe nuk e rilexon drejtorinë për çdo paketë, prandaj pikërisht një sesion i vendosur vazhdon të punojë pasi hiqni dikë nga një grup. Po ashtu, një sesion i ri mund të dështojë ndërsa një i vjetër vazhdon të funksionojë, dhe dy përdorues me lista grupesh identike mund të përfundojnë me rezultate të ndryshme.

Për ta bërë një ndryshim të marrë efekt, ju nevojitet një vendim i ri autorizimi, jo vetëm çelësa të rinj. Aty ku serveri mbështet autorizimin dinamik RFC 5176, një Disconnect-Request ose CoA-Request drejt UDP 3799 e detyron sesionin të rivlerësohet; përndryshe shkëputni klientin dhe lëreni të rilidhet. Rinegociimi i rifreskon çelësat e tunelit dhe normalisht e lë rezultatin e autorizimit të paprekur, kështu që trajtimi i tij si rifreskim lejesh prodhon rezultate testimi kontradiktore.

Rregulloni kushtin, jo grupin

Pasi të dini se cila politikë u aktivizua, rregullimi zakonisht është i vogël: rirenditni një refuzim që mbulon lejimin e synuar, shtoni kushtin e pajisjes ose të MFA-së që mungon te politika që kishit ndërmend të përputhni, ose shkruani një rregull të ngushtë për burimin e vetëm në vend që ta promovoni përdoruesin në një grup që mbart dhjetë të tjerë. Zgjerimi i anëtarësimit për të mbyllur një kërkesë është versioni i shtrenjtë i të njëjtit rregullim, dhe kështu një shkurtore e mbështetjes bëhet një përjashtim i përhershëm që askush nuk e rishikon.

Një cikël i shkurtër e mban ndryshimin të ndershëm:

• Riprodhoni refuzimin me llogarinë origjinale dhe shkruani ID-në e ngjarjes përpara se të ndryshoni diçka.
• Ndryshoni një objekt — një rend politike, një kusht të vetëm ose një grup — dhe shënoni cilin.
• Hapni një sesion të ri, konfirmoni se dhënia shfaqet në regjistër dhe konfirmoni se burimi hapet vërtet.
• Testoni një përdorues që duhet të vazhdojë të refuzohet, që rregullimi të mos e ketë zgjeruar politikën aksidentalisht.

Nëse dhënia është e saktë dhe burimi ende nuk hapet, problemi kaloi te rrugëtimi ose zgjidhja e emrave në momentin që autorizimi doli me sukses. Mbani të ndara këto dy dështime dhe kërkesa e radhës zgjat minuta në vend të një pasdite.