Migri VPN-aŭtentikigan backend sen reuzi malnovajn haŝojn
Transloki VPN-identecojn estas tranĉo, ne kopio: mapu la aŭtentigan ĉenon, transloku pilaran grupon, provu ŝanĝojn de akreditiloj kaj planu rekuperon, kiun restarigo ne malfaras.
Uzantnomoj aperas en la nova dosierujo, la migrado estas deklarita finita, kaj ensalutoj tamen malsukcesas. La enirejo ankoraŭ bezonas subtenatan aŭtentigan vojon kaj ĝustan rajtigan rezulton, kaj neniu el la du sekvas el dosierujo, kiu nun enhavas la kontojn. Translokigo de backend estas tranĉo kun vivciklo, ne kopia tasko. La suba simptomo estas tiu, kiu kutime malkaŝas la diferencon.
La simptomo: kontoj ekzistas, sesioj ne
La nova dosierujo enhavas ĉiun uzantnomon, testa bind sukcesas, kaj la VPN-kliento tamen redonas aŭtentigan malsukceson. Tiu kombino signifas, ke la identeco ekzistas, sed la kontrolvojo uzata de la enirejo ne atingas ĝin, aŭ atingas ĝin per metodo, kiun ĝi ne povas plenumi. Ambaŭ estas agordo, kaj ili estas malsamaj problemoj.
La unua estas tubaro: la enirejo montras al backend, kiu ne respondas, uzas komunan sekreton, kiun la alia flanko ne atendas, aŭ petas atributon, kiun la nova servo ne redonas. La dua estas kriptografia: la metodo postulas la originan sekreton, kaj la nova konservejo tenas nur ĝian haŝon. La erarteksto aspektas simila en ambaŭ kazoj, kaj tial la du estas traktataj kiel unu problemo.
Apartigi tiujn du antaŭ ol tuŝi kontojn ŝparas semajnon. Unu estas demando pri enkursigo kaj fido, la alia estas decido pri restarigo de akreditiloj, kaj miksi ilin produktas ŝanĝojn, kiujn neniu povas atribui.
Mapu la ĉenon antaŭ ol iu translokiĝas
Notu ses aferojn por ĉiu klienta profilo: la eksteran aŭtentigan metodon, eblan internan metodon, la servan identecon, kiun la kliento atendas, la interfacon inter enirejo kaj backend, la atributon, kiun la enirejo mapas al grupa membreco, kaj la rezultan rimedan politikon. Legi ilin laŭorde montras, kiun ligilon neniu posedas. Ĉiu ero havas posedanton, kaj la tranĉo malsukcesas ĉe tiu, kiun neniu kontrolis.
| 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 |
Ordinara ensaluto en la dosierujon trapasas preskaŭ nenion de tiu ĉeno. Ĝi pruvas, ke la konto ekzistas kaj ke la pasvorto funkcias, do ĝuste tiun parton, pri kiu neniam estis dubo.
Haŝoj ne vojaĝas inter metodoj
La kongrueco de akreditiloj devas esti kontrolita unufoje, antaŭ ol iu grupo translokiĝas. FreeRADIUS klare dokumentas la dividon: CHAP-kontrolo, kiun la servilo mem faras, bezonas la realan pasvorton, kaj MS-CHAP akceptas tiun pasvorton aŭ taŭgan NT-materialon. Haŝo farita por alia celo kongruas kun neniu el la du kazoj, kiom ajn forta ĝi estas.
La diferenco temas pri tio, kiu kalkulas la pruvon. Metodo, kiu kontrolas per ligado al la dosierujo, lasas la dosierujon kontroli tion, kion ĝi povas kontroli. Metodo, kiu kontrolas per rekalkulado de defia respondo, bezonas la sekreton mem, ĉar la servilo devas fari la saman kalkulon.
Kie la materialo mankas, la honestaj opcioj estas subtenata restarigo, realiĝo, ekstera kontrola servo aŭ ŝanĝo de metodo. Provizora eksporto de rekupereblaj pasvortoj ne estas sur tiu listo. Ĝi kreas konservejon de akreditiloj en klara teksto dum la plej ĥaosa semajno de la projekto, kaj ĝi kutime postvivas la migradon.
Pilara grupo, poste vivciklaj ŝanĝoj
Transloku malgrandan grupon de aprobitaj identecoj kun la reala kliento, kaj provu kvar aferojn: freŝan ensaluton, intence malĝustan akreditilon, la rimedojn, kiujn la sesio rajtas atingi, kaj la rimedojn, kiujn ĝi ne rajtas atingi. Kontrolu ankaŭ la servan identecon, kiun la kliento akceptis, ĉar malkongruo de atestila nomo estas nevidebla ĝis iu legas la klientan protokolon.
Poste praktiku la ŝanĝojn, de kiuj la efektivigo vere dependas. Ŝanĝu pasvorton, renovigu aŭ realigu atestilon, kaj forigu aliron de unu pilara konto. Post ĉiu, konfirmu, kiu kontrolilo traktis la provon, ĉar sesio kreita antaŭ la tranĉo povas daŭre funkcii kaj pruvas nenion pri la sekva ensaluto.
Apartigu la liveradon de profilo de la identeca ŝanĝo. Ĉiu grupo bezonas sian celatan profilon, sian staton de akreditilo aŭ realiĝo, la aŭtentigan servon, kiun ĝi uzu, kaj subtenan kontakton, kaj neniu el tiuj rikordoj rajtas enhavi sekreton.
Se malnova kaj nova vojoj kunekzistas, limigu ilin per findato. Aŭtomata retrofalo povas enlasi konton per malnova akreditilo post kiam la nova posedanto forigis aliron, kaj tio estas sekureca regreso kaŝita kiel disponebleco.
Rolundo ne povas restarigi akreditilon
Malfari la tranĉon lasas la dosierujon precize tia, kia ĝi estas nun. Restarigita pasvorto restas restarigita, revokita atestilo restas revokita, kaj ŝanĝita formato de akreditilo restas ŝanĝita. Tiuj estas eventoj en la dosierujo, kaj la enirejo neniam estis ilia fonto. Rekupero devas esti difinita por ĉiu evento, kaj nenio el tio rajtas dependi de rekonstruado de sekreto el nekompatibla haŝo.
Tenu administran vojon, kiu ne uzas la konekton migrata. Kiam la nova aŭtentigo malsukcesas, paŭzu la grupon kaj uzu ĝian dokumentitan rekuperan vojon anstataŭ malfortigi la aŭtentigon por ĉiuj por plenumi limdaton.
Post kiam la grupoj estas kovritaj, retiru la malnovajn backend-akreditilojn, profilon kaj fido-rilatojn tra iliaj posedantoj. Konfirmu, ke la malnova vojo ne plu enlasas uzantojn, kaj tenu la senskretan mapadon de identeco al politiko, kiun subteno ankoraŭ bezonas. Migrado finiĝas, kiam la nova vivciklo funkcias kaj neniu plu eniras per la malnova vojo, ne kiam la kontolisto aspektas kompleta.