Selitev zalednega sistema za preverjanje pristnosti VPN brez ponovne uporabe starih zgoščenih vrednosti
Selitev identitet VPN je preklop, ne kopija: preslikajte verigo preverjanja pristnosti, premaknite pilotno skupino, preizkusite spremembe poverilnic in načrtujte obnovitev, ki je ponastavitev ne more razveljaviti.
Uporabniška imena se pojavijo v novem imeniku, selitev je razglašena za končano, prijave pa še vedno ne uspejo. Prehod še vedno potrebuje podprto pot preverjanja pristnosti in pravilen rezultat pooblastitve, in nobeno od tega ne izhaja iz imenika, ki zdaj vsebuje račune. Selitev zaledja je preklop z življenjskim ciklom, ne kopiranje. Spodnji simptom je tisti, ki običajno razkrije razliko.
Simptom: računi obstajajo, seje ne
Novi imenik vsebuje vsako uporabniško ime, preizkusna vez uspe in odjemalec VPN še vedno vrne napako preverjanja pristnosti. Takšna kombinacija pomeni, da identiteta obstaja, vendar pot preverjanja, ki jo uporablja prehod, do nje ne pride, ali pa pride z metodo, ki ji ne more ugoditi. Oboje je konfiguracija in gre za različna problema.
Prvi je ožičenje: prehod kaže na zaledje, ki se ne odziva, uporablja skupno skrivnost, ki je druga stran ne pričakuje, ali zahteva atribut, ki ga nova storitev ne vrne. Drugi je kriptografski: metoda zahteva izvirno skrivnost, novi hram pa vsebuje le njeno zgoščeno vrednost. Besedilo napake je v obeh primerih podobno, zato se oba obravnavata kot en problem.
Ločevanje obeh, preden se dotaknemo računov, prihrani teden. Prvi je vprašanje usmerjanja in zaupanja, drugi je odločitev o ponastavitvi poverilnic, in mešanje obojega ustvari spremembe, ki jih nihče ne more pripisati.
Preslikajte verigo, preden koga premaknete
Za vsak profil odjemalca zapišite šest stvari: zunanjo metodo preverjanja pristnosti, morebitno notranjo metodo, identiteto strežnika, ki jo odjemalec pričakuje, vmesnik med prehodom in zaledjem, atribut, ki ga prehod preslika v članstvo v skupini, in izhajajočo politiko virov. Branje po vrsti pokaže, kateri člen nima lastnika. Vsaka postavka ima lastnika, preklop pa spodleti pri tisti, ki je nihče ni preveril.
| Link | Question it answers |
|---|---|
| Client profile | Which method and server name does the client use? |
| Inner method | Is there a second authentication step? |
| Server identity | Which certificate or name must the client accept? |
| Gateway to backend | Which protocol, port and shared secret? |
| Attribute mapping | Which returned value becomes group membership? |
| Resource policy | What the resulting session may reach |
Običajna prijava v imenik ne preizkusi skoraj ničesar od te verige. Dokaže, da račun obstaja in da geslo deluje, kar je prav tisti del, ki nikoli ni bil vprašljiv.
Zgoščene vrednosti ne potujejo med metodami
Združljivost poverilnic je treba preveriti enkrat, preden se premakne katera koli skupina. FreeRADIUS jasno opisuje delitev: preverjanje CHAP, ki ga izvede strežnik sam, potrebuje dejansko geslo, MS-CHAP pa sprejme to geslo ali ustrezno gradivo NT. Zgoščena vrednost, ustvarjena za drug namen, ne ustreza nobenemu od obeh primerov, ne glede na to, kako močna je.
Razlika je v tem, kdo izračuna dokaz. Metoda, ki preverja s povezovanjem na imenik, prepusti imeniku, da preveri, kar lahko preveri. Metoda, ki preverja s preračunom odgovora na izziv, potrebuje samo skrivnost, ker mora strežnik izvesti isti izračun.
Kjer gradiva ni, so poštene možnosti podprta ponastavitev, ponovna registracija, zunanja storitev preverjanja ali sprememba metode. Začasen izvoz obnovljivih gesel ni na tem seznamu. Ustvari hram poverilnic v golem besedilu v najbolj kaotičnem tednu projekta in običajno preživi selitev.
Pilotna skupina, nato spremembe življenjskega cikla
Premaknite majhno skupino odobrenih identitet z resničnim odjemalcem in preizkusite štiri stvari: svežo prijavo, namerno napačno poverilnico, vire, ki jih seja sme doseči, in vire, ki jih ne sme. Preverite tudi identiteto strežnika, ki jo je odjemalec sprejel, ker je neujemanje imena potrdila nevidno, dokler nekdo ne prebere dnevnika odjemalca.
Nato preizkusite spremembe, od katerih je uvedba res odvisna. Spremenite geslo, obnovite ali znova registrirajte potrdilo in enemu pilotnemu računu odvzemite dostop. Po vsaki potrdite, kateri preverjevalec je obravnaval poskus, ker lahko seja, ustvarjena pred preklopom, še naprej deluje in ne dokazuje ničesar o naslednji prijavi.
Ločite dostavo profila od preklopa identitete. Vsaka skupina potrebuje predvideni profil, svoje stanje poverilnic ali registracije, storitev preverjanja pristnosti, ki naj jo uporablja, in stik za podporo, noben od teh zapisov pa ne sme vsebovati skrivnosti.
Če stara in nova pot obstajata vzporedno, ju omejite z končnim datumom. Samodejni povratek lahko spusti račun skozi staro poverilnico potem, ko je novi lastnik odstranil dostop, in to je varnostna regresija, preoblečena v razpoložljivost.
Povrnitev ne more obnoviti poverilnice
Obrnitev preklopa pusti imenik točno v stanju, v kakršnem je zdaj. Ponastavljeno geslo ostane ponastavljeno, preklicano potrdilo ostane preklicano in spremenjena oblika poverilnic ostane spremenjena. To so dogodki v imeniku in prehod nikoli ni bil njihov vir. Obnovitev je treba določiti za vsak dogodek in nič od tega ne sme biti odvisno od rekonstrukcije skrivnosti iz nezdružljive zgoščene vrednosti.
Ohranite upravno pot, ki ne uporablja povezave, ki se seli. Ko novo preverjanje pristnosti spodleti, ustavite skupino in uporabite njeno dokumentirano pot obnovitve, namesto da bi oslabili preverjanje pristnosti za vse, da bi ujeli rok.
Ko so skupine pokrite, umaknite stare poverilnice zaledja, profile in razmerja zaupanja prek njihovih lastnikov. Potrdite, da stara pot ne spušča več uporabnikov, in obdržite preslikavo identitete v politiko brez skrivnosti, ki jo podpora še potrebuje. Selitev je končana, ko novi življenjski cikel deluje in nihče več ne vstopi po stari poti, ne ko je seznam računov videti popoln.