OpenVPN verwirft eine OTP-Sitzung später: Was die erneute Authentifizierung braucht

Aus Sicht des Clients sieht es wie eine zufällige Trennung eine Stunde nach Beginn einer funktionierenden Sitzung aus. Das Taskleistensymbol verschwindet, der Tunnel wird neu aufgebaut, und das Protokoll zeigt einen Authentifizierungsfehler statt eines Netzwerkfehlers. Tatsächlich hat die Sitzung neu verhandelt, und der zweite Handshake brauchte Anmeldedaten, von denen der Client keine gültige Kopie mehr besaß. Ein Einmalcode, der beim Anmelden funktionierte, kann nicht erneut funktionieren, daher schlägt die Schlüsselerneuerung genau wie vorgesehen fehl.

Die Lösung ist eine Entscheidung darüber, was der zweite Handshake vorlegen soll, kein längerer Wiederholungs-Timer.

Verfolgen Sie den Austausch aus Sicht des Clients

Beim Anmelden sendet der Client den Benutzernamen, das Passwort und einen Code vom Token-Gerät, und der Server akzeptiert die Kombination. Dann läuft die Sitzung, bis ein Auslöser für die Neuverhandlung greift, der einen neuen TLS-Handshake innerhalb des bestehenden Tunnels startet. Dieser Handshake verlangt erneut eine Authentifizierung. Wenn der Authentifizierungspfad des Servers ein Passwort plus einen aktuellen Einmalcode erwartet, hat der Client keinen neuen Code anzubieten, es sei denn, der Benutzer ist anwesend, um einen einzugeben.

Die meisten Clients öffnen mitten in der Sitzung keine Abfrage, daher läuft der Handshake ab und der Tunnel fällt. Der Benutzer sieht eine Wiederverbindung, keine Authentifizierungsabfrage, und deshalb beschuldigt der erste Bericht meist das Netzwerk.

auth-gen-token ändert, wer die zweite Frage beantwortet

auth-gen-token ist die Option, mit der der Server nach einer erfolgreichen Anmeldung ein Token ausstellt, und spätere Neuverhandlungen legen dieses Token vor, statt Passwort und Code zu wiederholen. Das Handbuch dokumentiert seine Lebensdauer und sein Erneuerungsverhalten, und das Token muss als Anmeldedatum mit eigenem Ablauf behandelt werden. Im Standardpfad validiert der Server das Token selbst, statt den externen Passwort-Authenticator erneut aufzurufen.

Mit einer externen Authentifizierungsintegration ändert sich diese Aufteilung. Das Plugin muss den Token-Zustand verstehen und eigene Prüfungen anwenden, denn der Server ist nicht mehr die einzige Komponente, die entscheidet, ob die Sitzung fortgesetzt wird. Das Token als weiteren numerischen Einmalcode zu behandeln ist keine Umsetzung der Funktion.

Entscheiden Sie, was mit dem Kontostatus geschieht

Ein Token, das den Zugriff eines Kontos überlebt, ist ein Politikerloch. Entscheiden Sie, wie ein deaktiviertes Konto, eine entfernte Gruppenmitgliedschaft oder ein widerrufenes Gerät wirksam werden, während das Token noch gültig ist. Kurze Token-Lebensdauern verkleinern das Fenster; ein ausdrücklicher Widerrufspfad macht es beabsichtigt. Schreiben Sie die Antwort auf, bevor Sie die Option aktivieren, denn der Standardpfad fragt den externen Authenticator nicht bei jeder Neuverhandlung.

Bei einer Bereitstellung mit mehreren Servern muss das Token-Signaturgeheimnis geteilt werden, sonst kann der Client an einen Knoten geschickt werden, der sein Token nicht validieren kann.

Testen Sie Ablauf und Wiederverbindung, nicht nur die Anmeldung

Senken Sie das Neuverhandlungsintervall in einem Testprofil, damit der zweite Handshake erfolgt, während Sie zusehen, und verfolgen Sie dann beide Protokolle. Bestätigen Sie, dass das Token beim Anmelden ausgestellt, bei der Schlüsselerneuerung vorgelegt und gemäß der konfigurierten Lebensdauer erneuert oder neu ausgestellt wird. Erzwingen Sie dann einen Token-Ablauf und eine vollständige Wiederverbindung, denn ein Client, der sich sauber wiederverbindet, kann auf dem Pfad der Schlüsselerneuerung immer noch scheitern.

Testen Sie die Kontenentfernung zuletzt. Dieser Fall zeigt Ihnen, ob die von Ihnen geschriebene Politik durchgesetzt oder nur dokumentiert wird.

Beheben Sie es nicht durch Deaktivieren der Erneuerung

Das Neuverhandlungsintervall auf beiden Seiten auf null zu setzen beseitigt das Symptom und damit die Schlüsselrotation. Das versteckt ein Problem der Wiederverwendung von Anmeldedaten hinter einer Politikänderung, die niemand geprüft hat. Behalten Sie die Erneuerung bei und wählen Sie zwischen einem serverausgestellten Token und einer frischen interaktiven Aufforderung, je nachdem, ob ein Benutzer anwesend ist.

Ein längerer Wiederholungs-Timer macht einen verbrauchten Code nicht wieder gültig. Er verzögert nur die Trennung und macht das Protokoll schwerer lesbar.