OpenVPN dropper en OTP-session senere: hvad genautentificering kræver

Fra klientens side ser det ud som en tilfældig afbrydelse en time inde i en fungerende session. Tray-ikonet forsvinder, tunnelen genopbygges, og loggen viser en godkendelsesfejl snarere end en netværksfejl. Det, der faktisk skete, var, at sessionen genforhandlede, og det andet håndtryk havde brug for legitimationsoplysninger, som klienten ikke længere havde en gyldig kopi af. En engangskode, der virkede ved login, kan ikke virke igen, så nøglefornyelsen fejler præcis som designet.

Rettelsen er en beslutning om, hvad det andet håndtryk skal fremvise, ikke en længere genforsøgstimer.

Følg udvekslingen fra klientens synspunkt

Ved login sender klienten brugernavnet, adgangskoden og en kode fra tokenenheden, og serveren accepterer kombinationen. Derefter kører sessionen, indtil en genforhandlingsudløser aktiveres, hvilket starter et nyt TLS-håndtryk inde i den eksisterende tunnel. Det håndtryk beder om godkendelse igen. Hvis serverens godkendelsesvej forventer en adgangskode plus en aktuel engangskode, har klienten ingen ny kode at tilbyde, medmindre brugeren er til stede for at indtaste en.

De fleste klienter åbner ikke en prompt midt i sessionen, så håndtrykket udløber, og tunnelen falder. Brugeren ser en genopkobling, ikke en godkendelsesprompt, og derfor giver den første rapport normalt netværket skylden.

auth-gen-token ændrer, hvem der besvarer det andet spørgsmål

auth-gen-token er den indstilling, der lader serveren udstede et token efter et vellykket login, og senere genforhandlinger fremviser dette token i stedet for at gentage adgangskoden og koden. Manualen dokumenterer dets levetid og fornyelsesadfærd, og tokenet skal behandles som en legitimationsoplysning med sin egen udløbsdato. I standardvejen validerer serveren selv tokenet i stedet for at kalde den eksterne adgangskodeautentifikator igen.

Med en ekstern godkendelsesintegration ændres den opdeling. Pluginnet skal forstå tokentilstand og anvende sine egne kontroller, fordi serveren ikke længere er den eneste komponent, der afgør, om sessionen fortsætter. At behandle tokenet som endnu en numerisk engangskode er ikke en implementering af funktionen.

Beslut, hvad der sker med kontostatus

Et token, der overlever en kontos adgang, er et hul i politikken. Beslut, hvordan en deaktiveret konto, et fjernet gruppemedlemskab eller en tilbagekaldt enhed slår igennem, mens tokenet stadig er gyldigt. Korte tokenlevetider gør vinduet mindre; en eksplicit tilbagekaldelsesvej gør det bevidst. Skriv svaret ned, før du aktiverer indstillingen, fordi standardvejen ikke konsulterer den eksterne autentifikator ved hver genforhandling.

I en udrulning med flere servere skal hemmeligheden til tokensignering deles, ellers kan klienten sendes til en node, der ikke kan validere dens token.

Test udløb og genopkobling, ikke kun login

Sænk genforhandlingsintervallet i en testprofil, så det andet håndtryk sker, mens du ser på, og følg derefter begge logs. Bekræft, at tokenet udstedes ved login, fremvises ved nøglefornyelse og opdateres eller genudstedes i henhold til den konfigurerede levetid. Tving derefter et tokenudløb og en fuld genopkobling, fordi en klient, der genopkobler rent, stadig kan fejle på nøglefornyelsesvejen.

Test fjernelse af konto til sidst. Det tilfælde fortæller dig, om den politik, du skrev, håndhæves eller blot er dokumenteret.

Ret det ikke ved at slå fornyelse fra

At sætte genforhandlingsintervallet til nul på begge parter fjerner symptomet og nøglerotationen med det. Det skjuler et problem med genbrug af legitimationsoplysninger bag en politikændring, som ingen har gennemgået. Behold fornyelsen, og vælg mellem et token udstedt af serveren og en frisk interaktiv udfordring ud fra, om en bruger er til stede.

En længere genforsøgstimer gør ikke en brugt kode gyldig igen. Den udsætter kun afbrydelsen og gør loggen sværere at læse.