OpenVPN släpper en OTP-session senare: vad omautentisering kräver

Från klientens sida ser det ut som en slumpmässig frånkoppling en timme in i en arbetssession. Ikonen i aktivitetsfältet försvinner, tunneln byggs upp igen och loggen visar ett autentiseringsfel i stället för ett nätverksfel. Det som faktiskt hände var att sessionen förhandlade om och att den andra handskakningen behövde uppgifter som klienten inte längre hade en giltig kopia av. En engångskod som fungerade vid inloggningen kan inte fungera igen, så nyckelbytet misslyckas precis som det är tänkt.

Lösningen är ett beslut om vad den andra handskakningen ska presentera, inte en längre timer för nya försök.

Gå igenom utbytet ur klientens perspektiv

Vid inloggningen skickar klienten användarnamnet, lösenordet och en kod från tokenenheten, och servern accepterar kombinationen. Sedan kör sessionen tills en utlösare för omförhandling aktiveras, vilket startar en ny TLS-handskakning inne i den befintliga tunneln. Den handskakningen begär autentisering igen. Om serverns autentiseringsväg förväntar sig ett lösenord plus en aktuell engångskod har klienten ingen ny kod att erbjuda om inte användaren är närvarande och skriver in en.

De flesta klienter öppnar ingen fråga mitt i sessionen, så handskakningen tar slut på tid och tunneln faller. Användaren ser en återanslutning, inte en autentiseringsfråga, och därför skyller den första rapporten oftast på nätverket.

auth-gen-token ändrar vem som svarar på den andra frågan

Alternativet auth-gen-token låter servern utfärda en token efter en lyckad inloggning, och senare omförhandlingar presenterar den tokenen i stället för att upprepa lösenordet och koden. Handboken dokumenterar dess livslängd och förnyelsebeteende, och tokenen måste behandlas som en uppgift med egen utgångstid. På standardvägen validerar servern tokenen själv i stället för att anropa den externa lösenordsautentiseraren igen.

Med en extern autentiseringsintegration ändras den uppdelningen. Insticksprogrammet måste förstå tokenens tillstånd och tillämpa egna kontroller, eftersom servern inte längre är den enda komponenten som avgör om sessionen fortsätter. Att behandla tokenen som ännu en numerisk engångskod är inte en implementering av funktionen.

Bestäm vad som händer med kontostatusen

En token som lever längre än ett kontos åtkomst är ett hål i policyn. Bestäm hur ett inaktiverat konto, ett borttaget gruppmedlemskap eller en återkallad enhet får verkan medan en token fortfarande är giltig. Korta tokenlivslängder minskar fönstret; en uttrycklig återkallningsväg gör det avsiktligt. Skriv ned svaret innan du aktiverar alternativet, eftersom standardvägen inte rådfrågar den externa autentiseraren vid varje omförhandling.

I en distribution med flera servrar måste hemligheten för tokensignering delas, annars kan klienten skickas till en nod som inte kan validera dess token.

Testa utgång och återanslutning, inte bara inloggning

Sänk omförhandlingsintervallet i en testprofil så att den andra handskakningen sker medan du tittar, och följ sedan båda loggarna. Bekräfta att tokenen utfärdas vid inloggning, presenteras vid nyckelbytet och förnyas eller utfärdas på nytt enligt den konfigurerade livslängden. Tvinga sedan fram en tokenutgång och en full återanslutning, eftersom en klient som återansluter rent fortfarande kan misslyckas på nyckelbytesvägen.

Testa borttagning av konto sist. Det fallet berättar om policyn du skrev verkställs eller bara dokumenteras.

Fixa det inte genom att stänga av förnyelsen

Att sätta omförhandlingsintervallet till noll på båda parter tar bort symtomet och därmed även nyckelrotationen. Det döljer ett problem med återanvändning av uppgifter bakom en policyändring som ingen har granskat. Behåll förnyelsen och välj mellan en token som servern utfärdar och en ny interaktiv utmaning utifrån om en användare är närvarande.

En längre timer för nya försök gör inte en förbrukad kod giltig igen. Den skjuter bara upp frånkopplingen och gör loggen svårare att läsa.