Migrera en VPN-authbackend utan att återanvända gamla hashar

Användarnamn dyker upp i den nya katalogen, migreringen förklaras klar, och inloggningarna misslyckas ändå. Gatewayen behöver fortfarande en autentiseringsväg som stöds och ett korrekt auktoriseringsresultat, och inget av dem följer av en katalog som nu innehåller kontona. En backendflytt är en övergång med livscykel, inte ett kopieringsjobb. Symtomet nedan är det som oftast avslöjar skillnaden.

Symtomet: konton finns, sessioner gör det inte

Den nya katalogen innehåller varje användarnamn, en testbind lyckas, och VPN-klienten returnerar fortfarande ett autentiseringsfel. Kombinationen betyder att identiteten finns, men att den verifieringsväg som gatewayen använder inte når den, eller når den med en metod som den inte kan uppfylla. Båda är konfiguration, och de är olika problem.

Det första är kabeldragning: gatewayen pekar på en backend som inte svarar, använder en delad hemlighet som andra sidan inte förväntar sig, eller frågar efter en attribut som den nya tjänsten inte lämnar. Det andra är kryptografiskt: metoden kräver den ursprungliga hemligheten, och det nya lagret innehåller bara en hash av den. Feltexten ser likadan ut i båda fallen, och därför behandlas de två som ett problem.

Att skilja de två åt innan konton rörs sparar en vecka. Det ena är en fråga om routing och tillit, det andra ett beslut om att återställa inloggningsuppgifter, och att blanda dem ger ändringar som ingen kan härleda.

Kartlägg kedjan innan någon flyttas

Skriv ned sex saker för varje klientprofil: den yttre autentiseringsmetoden, en eventuell inre metod, den serveridentitet klienten förväntar sig, gränssnittet mellan gateway och backend, det attribut gatewayen mappar till gruppmedlemskap och den resursprincip som följer. Att läsa dem i ordning visar vilken länk ingen äger. Varje punkt har en ägare, och övergången misslyckas vid den som ingen kontrollerade.

En vanlig kataloginloggning prövar nästan inget av den kedjan. Den bevisar att kontot finns och att lösenordet fungerar, vilket är den del som aldrig var tveksam.

Hashar färdas inte mellan metoder

Kompatibiliteten hos inloggningsuppgifterna måste kontrolleras en gång, innan någon grupp flyttas. FreeRADIUS dokumenterar uppdelningen tydligt: en CHAP-kontroll som servern själv utför kräver det faktiska lösenordet, och MS-CHAP accepterar det lösenordet eller lämpligt NT-material. En hash som tagits fram för något annat ändamål passar i inget av fallen, hur stark den än är.

Skillnaden handlar om vem som beräknar beviset. En metod som verifierar genom att binda till katalogen låter katalogen kontrollera det den kan kontrollera. En metod som verifierar genom att räkna om ett utmaningssvar behöver själva hemligheten, eftersom servern måste utföra samma beräkning.

Där materialet saknas är de ärliga alternativen en återställning som stöds, en ny registrering, en extern verifieringstjänst eller ett metodbyte. En tillfällig export av återställbara lösenord står inte på den listan. Den skapar ett lager av inloggningsuppgifter i klartext under projektets mest kaotiska vecka, och den överlever oftast migreringen.

Pilotgrupp, sedan livscykeländringar

Flytta en liten grupp godkända identiteter med den riktiga klienten och testa fyra saker: en färsk inloggning, en medvetet felaktig inloggningsuppgift, de resurser sessionen får nå och de resurser den inte får nå. Kontrollera också den serveridentitet som klienten accepterade, eftersom en avvikande certifikatbeteckning är osynlig tills någon läser klientloggen.

Prova sedan de ändringar som driftsättningen faktiskt beror på. Byt ett lösenord, förnya eller registrera om ett certifikat och ta bort åtkomsten för ett pilotkonto. Bekräfta efter varje vilken verifierare som hanterade försöket, eftersom en session som skapades före övergången kan fortsätta fungera och inte bevisar något om nästa inloggning.

Skilj profilleveransen från identitetsbytet. Varje grupp behöver sin avsedda profil, sin status för inloggningsuppgifter eller registrering, den autentiseringstjänst den ska använda och en supportkontakt, och ingen av dessa uppgifter får innehålla en hemlighet.

Om gamla och nya vägar finns samtidigt ska de avgränsas med ett slutdatum. En automatisk återgång kan släppa in ett konto via en gammal inloggningsuppgift efter att den nya ägaren tagit bort åtkomsten, och det är en säkerhetsregression förklädd till tillgänglighet.

En återställning kan inte återställa en inloggningsuppgift

Att vända övergången lämnar katalogen precis som den står nu. Ett återställt lösenord förblir återställt, ett återkallat certifikat förblir återkallat och ett ändrat format för inloggningsuppgifter förblir ändrat. Det är händelser i katalogen, och gatewayen var aldrig deras källa. Återhämtning måste definieras per händelse, och inget av det får bero på att rekonstruera en hemlighet ur en inkompatibel hash.

Behåll en administrativ väg som inte använder anslutningen som migreras. När den nya autentiseringen misslyckas, pausa gruppen och använd dess dokumenterade återhämtningsväg i stället för att försvaga autentiseringen för alla för att hålla en deadline.

När grupperna är täckta ska de gamla backenduppgifterna, profilerna och tillitsförhållandena avvecklas genom sina ägare. Bekräfta att den gamla vägen inte längre släpper in användare, och behåll den icke-hemliga mappningen från identitet till princip som supporten fortfarande behöver. En migrering är klar när den nya livscykeln fungerar och ingen längre kan komma in via den gamla vägen, inte när kontolistan ser komplett ut.