Migrimi i backend-it të vërtetimit të VPN pa ripërdorur hash-et e vjetra

Emrat e përdoruesve shfaqen në drejtorinë e re, migrimi shpallet i përfunduar dhe hyrjet vazhdojnë të dështojnë. Porta ende ka nevojë për një rrugë të vërtetimi të mbështetur dhe një rezultat të saktë autorizimi, dhe asnjëra nuk rrjedh nga një drejtori që tani përmban llogaritë. Zhvendosja e backend-it është një prerje me cikël jete, jo një punë kopjimi. Simptoma më poshtë është ajo që zakonisht zbulon ndryshimin.

Simptoma: llogaritë ekzistojnë, sesionet jo

Drejtoria e re përmban çdo emër përdoruesi, një lidhje prove funksionon dhe klienti VPN vazhdon të kthejë një dështim vërtetimi. Ky kombinim do të thotë se identiteti ekziston, por rruga e verifikimit që përdor porta nuk e arrin atë, ose e arrin me një metodë që nuk mund ta përmbushë. Të dyja janë konfigurim, dhe janë probleme të ndryshme.

E para është instalimi: porta tregon një backend që nuk përgjigjet, përdor një sekret të përbashkët që pala tjetër nuk e pret, ose kërkon një atribut që shërbimi i ri nuk e kthen. E dyta është kriptografike: metoda kërkon sekretin origjinal, dhe ruajtja e re mban vetëm hash-in e tij. Teksti i gabimit duket i ngjashëm në të dyja rastet, prandaj të dyja trajtohen si një problem.

Ndarja e këtyre dyve para se të preken llogaritë kursen një javë. Njëra është çështje rrugëzimi dhe besimi, tjetra është vendim për rivendosjen e kredencialeve, dhe përzierja e tyre prodhon ndryshime që askush nuk mund t'i atribuojë.

Hartoni zinxhirin para se të zhvendoset dikush

Shkruani gjashtë gjëra për çdo profil klienti: metodën e jashtme të vërtetimit, çdo metodë të brendshme, identitetin e serverit që klienti pret, ndërfaqen midis portës dhe backend-it, atributin që porta harton në anëtarësimin në grup, dhe politikën e burimeve që rrjedh. Leximi sipas radhës tregon cila hallkë nuk ka pronar. Çdo artikull ka një përgjegjës, dhe prerja dështon në atë që askush nuk e kontrolloi.

Një hyrje e zakonshme në drejtori pothuajse nuk kalon asgjë nga ai zinxhir. Vërteton se llogaria ekziston dhe fjalëkalimi funksionon, pikërisht pjesa që nuk ishte kurrë në dyshim.

Hash-et nuk udhëtojnë midis metodave

Përputhshmëria e kredencialeve duhet kontrolluar një herë, para se të zhvendoset çdo grup. FreeRADIUS e dokumenton ndarjen qartë: kontrolli CHAP që serveri bën vetë kërkon fjalëkalimin e vërtetë, dhe MS-CHAP pranon atë fjalëkalim ose material NT të përshtatshëm. Një hash i krijuar për një qëllim tjetër nuk përshtatet me asnjërin rast, sado i fortë qoftë.

Ndryshimi është se kush e llogarit provën. Një metodë që verifikon duke u lidhur me drejtorinë e lë drejtorinë të kontrollojë çfarë mundet. Një metodë që verifikon duke rillogaritur përgjigjen ndaj sfidës kërkon vetë sekretin, sepse serveri duhet të kryejë të njëjtin llogaritje.

Aty ku mungon materiali, opsionet e ndershme janë rivendosje e mbështetur, riregjistrim, shërbim i jashtëm verifikimi ose ndryshim metode. Eksportimi i përkohshëm i fjalëkalimeve të rikuperueshme nuk është në atë listë. Krijon një depo kredencialesh në tekst të thjeshtë në javën më kaotike të projektit, dhe zakonisht i mbijeton migrimit.

Grup pilot, pastaj ndryshime të ciklit të jetës

Zhvendosni një grup të vogël identitetesh të miratuara me klientin e vërtetë, dhe provoni katër gjëra: hyrje të re, kredencial të gabuar qëllimisht, burimet që sesioni mund të arrijë, dhe burimet që nuk duhet t'i arrijë. Kontrolloni edhe identitetin e serverit që klienti pranoi, sepse mospërputhja e emrit të certifikatës është e padukshme derisa dikush të lexojë regjistrin e klientit.

Pastaj ushtroni ndryshimet nga të cilat varet vërtet vendosja. Ndryshoni një fjalëkalim, rinovoni ose riregjistroni një certifikatë, dhe hiqni aksesin nga një llogari pilot. Pas secilit, konfirmoni cili verifikues e trajtoi përpjekjen, sepse një sesion i krijuar para prerjes mund të vazhdojë të punojë dhe nuk provon asgjë për hyrjen e radhës.

Ndarja e shpërndarjes së profilit nga ndryshimi i identitetit. Çdo grup ka nevojë për profilin e synuar, gjendjen e kredencialit ose regjistrimit, shërbimin e vërtetimit që duhet të përdorë dhe një kontakt mbështetjeje, dhe asnjë nga këto të dhëna nuk duhet të përmbajë sekret.

Nëse rrugët e vjetra dhe të reja bashkëjetojnë, kufizojini me një datë përfundimi. Një kthim automatik mund të lejojë një llogari të hyjë me kredencial të vjetër pasi pronari i ri ka hequr aksesin, dhe kjo është një regres sigurie i maskuar si disponueshmëri.

Kthimi nuk mund të rikthejë një kredencial

Përmbysja e prerjes e lë drejtorinë pikërisht ashtu siç është tani. Një fjalëkalim i rivendosur mbetet i rivendosur, një certifikatë e revokuar mbetet e revokuar, dhe një format kredenciali i ndryshuar mbetet i ndryshuar. Këto janë ngjarje në drejtori, dhe porta nuk ishte kurrë burimi i tyre. Rikuperimi duhet përcaktuar për çdo ngjarje, dhe asnjë pjesë e tij nuk mund të varet nga rindërtimi i një sekreti prej një hash-i të papajtueshëm.

Mbani një rrugë administrative që nuk përdor lidhjen që po migrohet. Kur vërtetimi i ri dështon, ndaloni grupin dhe përdorni rrugën e tij të dokumentuar të rikuperimit, në vend që të dobësoni vërtetimin për të gjithë për të mbajtur një afat.

Pasi grupet mbulohen, tërhiqni kredencialet, profilet dhe marrëdhëniet e besimit të vjetra të backend-it përmes pronarëve të tyre. Konfirmoni që rruga e vjetër nuk pranon më përdorues, dhe mbani hartëzimin identitet-politikë pa sekrete që mbështetja ende ka nevojë. Një migrim përfundon kur cikli i ri i jetës punon dhe askush nuk hyn më nga rruga e vjetër, jo kur lista e llogarive duket e plotë.