VPN-i autentimise backend'i migreerimine vanu räsiväärtusi uuesti kasutamata
VPN-i identiteetide teisaldamine on üleminek, mitte koopia: kaardista autentimisahel, vii üle pilootrühm, katseta volituste muudatusi ja planeeri taastamine, mida lähtestamine ei tühista.
Kasutajanimed ilmuvad uude kataloogi, migratsioon kuulutatakse lõpetatuks ja sisselogimised ikka ebaõnnestuvad. Lüüs vajab endiselt toetatud autentimisteed ja õiget autoriseerimistulemust ning kumbki ei tulene kataloogist, mis nüüd kontosid sisaldab. Backendi teisaldamine on elutsükliga üleminek, mitte kopeerimistöö. Alljärgnev sümptom on see, mis tavaliselt erinevuse paljastab.
Sümptom: kontod on olemas, sessioone pole
Uus kataloog sisaldab iga kasutajanime, testseose loomine õnnestub ja VPN-klient tagastab endiselt autentimisvea. See kombinatsioon tähendab, et identiteet on olemas, kuid lüüsi kasutatav kontrolltee ei jõua selleni või jõuab selleni meetodiga, mida see ei suuda rahuldada. Mõlemad on konfiguratsioon ja need on erinevad probleemid.
Esimene on juhtmestik: lüüs osutab backendile, mis ei vasta, kasutab ühiskasutatavat saladust, mida teine pool ei oota, või küsib atribuuti, mida uus teenus ei tagasta. Teine on krüptograafiline: meetod nõuab algset saladust ja uus hoidla sisaldab ainult selle räsi. Veateade näeb mõlemal juhul sarnane välja, mistõttu käsitletakse neid kahte ühe probleemina.
Nende kahe eraldamine enne kontode puudutamist säästab nädala. Üks on marsruutimise ja usalduse küsimus, teine volituste lähtestamise otsus, ja nende segamine tekitab muudatusi, mida keegi ei suuda omistada.
Kaardista ahel enne, kui kedagi teisaldatakse
Kirjuta iga kliendiprofiili kohta kuus asja: välimine autentimismeetod, võimalik sisemine meetod, serveri identiteet, mida klient ootab, lüüsi ja backendi vaheline liides, atribuut, mille lüüs vastendab rühmaliikmelisusele, ja sellest tulenev ressursipoliitika. Nende järjekorras lugemine näitab, millisel lülil pole omanikku. Igal elemendil on omanik ja üleminek ebaõnnestub sellel, mida keegi ei kontrollinud.
| 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 |
Tavaline kataloogi sisselogimine ei läbi sellest ahelast peaaegu midagi. See tõestab, et konto on olemas ja parool töötab, mis on just see osa, milles kunagi kahtlust ei olnud.
Räsid ei liigu meetodite vahel
Volituste ühilduvust tuleb kontrollida üks kord, enne kui ükski rühm liigub. FreeRADIUS kirjeldab jaotust selgelt: CHAP-kontroll, mille server ise teeb, nõuab tegelikku parooli, ja MS-CHAP aktsepteerib seda parooli või sobivat NT-materjali. Muuks otstarbeks loodud räs ei sobi kummagi juhtumiga, ükskõik kui tugev see on.
Erinevus on selles, kes tõestuse arvutab. Meetod, mis kontrollib kataloogiga sidumise kaudu, laseb kataloogil kontrollida seda, mida see kontrollida suudab. Meetod, mis kontrollib väljakutsevastuse ümberarvutamise kaudu, vajab saladust ennast, sest server peab tegema sama arvutuse.
Kus materjal puudub, on ausad valikud toetatud lähtestamine, uuesti registreerimine, väline kontrolliteenus või meetodi vahetus. Taastatavate paroolide ajutine eksport ei ole selles loendis. See loob lihttekstilise volituste hoidla projekti kõige kaootilisemal nädalal ja jääb tavaliselt migratsioonist kauemaks.
Pilootrühm, seejärel elutsükli muudatused
Teisalda väike rühm heakskiidetud identiteete päris kliendiga ja katseta nelja asja: värsket sisselogimist, teadlikult vale volitust, ressursse, mida sessioon tohib saavutada, ja ressursse, mida see ei tohi saavutada. Kontrolli ka serveri identiteeti, mille klient vastu võttis, sest sertifikaadi nime lahknevus on nähtamatu, kuni keegi kliendi logi loeb.
Seejärel harjuta muudatusi, millest juurutamine tegelikult sõltub. Muuda parooli, uuenda või registreeri sertifikaat uuesti ja eemalda ühelt pilootkontolt juurdepääs. Pärast igaüht kinnita, milline kontrollija taotlust käsitles, sest enne üleminekut loodud sessioon võib edasi töötada ega tõesta midagi järgmise sisselogimise kohta.
Eralda profiili tarnimine identiteedi vahetusest. Iga rühm vajab oma kavandatud profiili, oma volituse või registreerimise olekut, autentimisteenust, mida ta peaks kasutama, ja tugikontakti, ning ükski neist kirjetest ei tohi sisaldada saladust.
Kui vana ja uus tee eksisteerivad kõrvuti, piira neid lõppkuupäevaga. Automaatne tagasipöördumine võib lasta konto vana volitusega sisse pärast seda, kui uus omanik on juurdepääsu eemaldanud, ja see on turvaregressioon, mis on maskeeritud kättesaadavuseks.
Tagasipööramine ei saa volitust taastada
Ülemineku tagasipööramine jätab kataloogi täpselt sellisena, nagu see praegu on. Lähtestatud parool jääb lähtestatuks, tühistatud sertifikaat jääb tühistatuks ja muudetud volituste formaat jääb muudetuks. Need on sündmused kataloogis ja lüüs ei olnud kunagi nende allikas. Taastamine tuleb määratleda sündmuse kaupa ja miski sellest ei tohi sõltuda saladuse rekonstrueerimisest ühildumatu räsiga.
Hoia administratiivne tee, mis ei kasuta migreeritavat ühendust. Kui uus autentimine ebaõnnestub, peata rühm ja kasuta selle dokumenteeritud taastamisteed, selle asemel et nõrgestada autentimist kõigi jaoks tähtaja hoidmiseks.
Kui rühmad on kaetud, võta vanad backendi volitused, profiilid ja usaldussuhted omanike kaudu kasutusest välja. Kinnita, et vana tee ei lase enam kasutajaid sisse, ja hoia mitte-saladuslik identiteedi ja poliitika vastendus, mida tugi veel vajab. Migratsioon on lõpetatud, kui uus elutsükkel töötab ja keegi ei pääse enam vana tee kaudu sisse, mitte siis, kui kontode loend tundub täielik.