OpenVPN gooit later een OTP-sessie weg: wat herauthenticatie nodig heeft

Vanuit de client gezien lijkt het een willekeurige verbreking een uur na het begin van een werksessie. Het pictogram in het systeemvak verdwijnt, de tunnel wordt opnieuw opgebouwd en het log toont een authenticatiefout in plaats van een netwerkfout. Wat er werkelijk gebeurde, is dat de sessie opnieuw onderhandelde en dat de tweede handshake inloggegevens nodig had waarvan de client geen geldige kopie meer had. Een eenmalige code die bij het inloggen werkte, kan niet opnieuw werken, dus de rekey faalt precies zoals ontworpen.

De oplossing is een beslissing over wat de tweede handshake moet presenteren, niet een langere retry-timer.

Loop de uitwisseling door vanuit het perspectief van de client

Bij het inloggen stuurt de client de gebruikersnaam, het wachtwoord en een code van het tokenapparaat, en de server accepteert die combinatie. Daarna loopt de sessie tot een trigger voor opnieuw onderhandelen afgaat, die een nieuwe TLS-handshake in de bestaande tunnel start. Die handshake vraagt opnieuw om authenticatie. Als het authenticatiepad van de server een wachtwoord plus een actuele eenmalige code verwacht, heeft de client geen nieuwe code te bieden tenzij de gebruiker aanwezig is om er een te typen.

De meeste clients openen midden in een sessie geen prompt, dus de handshake loopt af en de tunnel valt weg. De gebruiker ziet een herverbinding, geen authenticatieprompt, en daarom geeft het eerste rapport meestal het netwerk de schuld.

auth-gen-token verandert wie de tweede vraag beantwoordt

De optie auth-gen-token laat de server na een geslaagde login een token uitgeven, en latere heronderhandelingen presenteren dat token in plaats van het wachtwoord en de code te herhalen. De handleiding documenteert de levensduur en het vernieuwingsgedrag, en het token moet als inloggegeven met een eigen vervaldatum worden behandeld. In het standaardpad valideert de server het token zelf in plaats van opnieuw de externe wachtwoordauthenticator aan te roepen.

Met een externe authenticatie-integratie verandert die verdeling. De plugin moet de tokenstatus begrijpen en zijn eigen controles toepassen, omdat de server niet langer het enige onderdeel is dat beslist of de sessie doorgaat. Het token behandelen als nog een numerieke eenmalige code is geen implementatie van de functie.

Bepaal wat er met de accountstatus gebeurt

Een token dat langer leeft dan de toegang van een account is een gat in het beleid. Bepaal hoe een uitgeschakeld account, een verwijderd groepslidmaatschap of een ingetrokken apparaat doorwerkt terwijl een token nog geldig is. Korte tokenlevensduren maken het venster kleiner; een expliciet intrekkingspad maakt het bewust. Schrijf het antwoord op voordat je de optie inschakelt, omdat het standaardpad de externe authenticator niet bij elke heronderhandeling raadpleegt.

In een implementatie met meerdere servers moet het geheim voor tokenondertekening worden gedeeld, anders kan de client naar een node worden gestuurd die zijn token niet kan valideren.

Test verval en herverbinding, niet alleen inloggen

Verlaag het heronderhandelingsinterval in een testprofiel zodat de tweede handshake gebeurt terwijl je kijkt, en volg daarna beide logs. Bevestig dat het token bij het inloggen wordt uitgegeven, bij de rekey wordt gepresenteerd en volgens de geconfigureerde levensduur wordt vernieuwd of opnieuw uitgegeven. Forceer daarna een tokenverval en een volledige herverbinding, omdat een client die schoon opnieuw verbindt nog steeds kan falen op het rekey-pad.

Test het verwijderen van een account als laatste. Dat geval vertelt je of het beleid dat je schreef wordt afgedwongen of alleen gedocumenteerd.

Los het niet op door vernieuwing uit te schakelen

Het heronderhandelingsinterval op beide peers op nul zetten haalt het symptoom weg en daarmee ook de sleutelrotatie. Dat verbergt een probleem met hergebruik van inloggegevens achter een beleidswijziging die niemand heeft beoordeeld. Houd de vernieuwing en kies tussen een door de server uitgegeven token en een nieuwe interactieve uitdaging op basis van of een gebruiker aanwezig is.

Een langere retry-timer maakt een verbruikte code niet opnieuw geldig. Hij stelt de verbreking alleen uit en maakt het log moeilijker leesbaar.