Wohin der Code der statischen Abfrage bei einer OpenVPN-Anmeldung gehört

Der Client zeigt ein zweites Feld nach dem Passwortfeld, Sie tippen den Code vom Hardware-Token ein, und die Anmeldung schlägt weiterhin mit einem Authentifizierungsfehler fehl. Dieses Feld existiert, also hat das Profil es angefordert. Ob der Server den Wert jemals in einer Form erhalten hat, die er versteht, ist eine andere Frage, und sie ist es wert, zuerst beantwortet zu werden.

Beginnen Sie bei der Eingabeaufforderung, die Ihr Client tatsächlich anzeigt

Ein Profil kann eine Direktive für eine statische Abfrage mit einem Aufforderungstext und einem Flag tragen, das steuert, ob die Antwort beim Tippen angezeigt wird. Die Aufforderung ist das, was Sie im Dialog sehen; das Flag ist eine Anzeigeeinstellung für dieselbe Eingabe. Keines von beiden sagt dem Server, wie er etwas prüfen soll.

Zählen Sie die Felder, die Sie tatsächlich bekommen haben. Ein Feld für einen Benutzernamen plus ein maskiertes Feld ist eine normale Passwortanmeldung ganz ohne Abfrage. Ein zweites Feld, das nach dem Passwort mit eigener Beschriftung erscheint, ist der Client, der die Abfrage-Interaktion umsetzt.

Wenn das zweite Feld im verwendeten Client nie erscheint, setzt dieser Client die Interaktion möglicherweise nicht um, oder nur über eine andere Oberfläche wie eine Verwaltungsschnittstelle. Den Client zu prüfen ist billiger, als das Profil neu zu schreiben, und dort liegt die Diskrepanz meist tatsächlich.

Was der Server bereits unterstützen muss

Das Profil beschreibt, was der Client erfassen soll. Es aktiviert keine Prüfung auf dem Server, und ein Server ohne die passende Authentifizierungsintegration erhält einfach ein Passwort, das er nicht kennt. Deshalb zeigen manche Installationen die Aufforderung und lehnen jeden Code ab, und deshalb ist die Antwort des Betreibers, welcher Mechanismus die Prüfung durchführt, die entscheidende.

Fragen Sie den Betreiber, welcher Mechanismus die Prüfung durchführt. Es kann ein Plugin sein, das mit PAM spricht, ein Skript-Hook, der die Antwort gegen einen Token-Dienst prüft, oder eine verwaltungsbasierte Integration, die den gepackten Wert selbst zerlegt. Jeder davon erwartet eine etwas andere Eingabe.

Hier müssen auch die Erwartungen kalibriert werden. Eine zweite Aufforderung ist ein Eingabemechanismus, kein Beweis dafür, dass ein zweiter Faktor erzwungen wird, denn die Durchsetzung geschieht serverseitig und zeigt sich erst, wenn Sie einen falschen Code testen.

Das kodierte Feld, das die Verwaltungsschnittstelle sendet

Wenn eine Oberfläche die Verbindung über die Verwaltungsschnittstelle steuert, werden Passwort und Abfrage-Antwort vor dem Absenden in einen einzigen Wert gepackt. Die Referenz zur Verwaltungsschnittstelle dokumentiert das Format: ein Präfix, dann das Passwort und die Antwort als getrennte Base64-Komponenten.

Base64 ist eine Kodierung, kein Schutz. Es verbirgt nichts vor jemandem, der das Feld lesen kann, und es macht aus einem Einmalcode nichts Wiederverwendbares. Der gepackte Wert verdient dieselbe Behandlung wie ein Passwort: raus aus geteilten Profilen, raus aus Kommandozeilen und raus aus Diagnoseprotokollen.

Diese Kodierung ist auch die häufigste Verwechslungsquelle, denn es gibt jetzt drei Formen, die ähnlich aussehen und nicht austauschbar sind. Eine einfache Anmeldedatendatei enthält ein Passwort. Eine wörtliche Verkettung von Passwort und Code enthält eine andere Zeichenfolge. Die gepackte Antwort eines Verwaltungsclients enthält eine dritte. Bestätigen Sie, welche Ihr Prüfpfad erwartet, bevor Sie ein Feld ändern, nur weil ein Fehler verschwunden ist.

Statisch gegen dynamisch: unterschiedliches Timing

Eine statische Abfrage ist bekannt, bevor die erste Anmeldeinformation gesendet wird, sodass der Client sie vorab abfragen kann. Eine dynamische Abfrage kommt später, gesendet vom Authentifizierungsablauf, nachdem ein Austausch bereits begonnen hat, und sie braucht einen Client, der eine Anfrage mitten im Gespräch verarbeiten kann.

Die Unterstützung des einen liefert nicht das andere. Eine Profildirektive, die eine statische Aufforderung konfiguriert, implementiert keine serverinitiierte Abfrage, und eine Oberfläche, die dynamische Anfragen verarbeitet, zeigt vielleicht trotzdem keine statische an. Zu lesen, welche Seite die Anfrage gestartet hat, ist der schnellste Weg, sie zu unterscheiden.

Unbeaufsichtigter Betrieb ist der Punkt, an dem daraus eine Design- statt einer UI-Frage wird. Ein gespeicherter Code ist keine dauerhafte Anmeldeinformation für den Start, und eine Wiederverbindung Stunden später braucht eine frische Eingabe, es sei denn, die Installation unterstützt eine Token-Regelung, die der Betreiber bewusst aktiviert hat.

Testen Sie Erfolg und Fehlschlag, nicht nur den Dialog

Führen Sie beide Hälften des Tests durch. Korrekte Anmeldeinformationen mit gültiger Antwort sollten erfolgreich sein; korrekte Anmeldeinformationen mit absichtlich falscher Antwort sollten abgelehnt werden. Wenn beides erfolgreich ist, sammelt der Client eine Eingabe, die nichts prüft, und der Dialog wurde für eine Kontrolle gehalten. Dieser eine Test erfasst mehr Installationen als jede Profilprüfung.

Wiederholen Sie dann die Verbindung nach einer Wiederverbindung, mit einem Konto, das nicht registriert ist, und über welchen Client Ihre Nutzer tatsächlich verwenden. Dass die Aufforderung erscheint, ist Clientverhalten; dass ein falscher Code abgelehnt wird, ist der Server, der etwas durchsetzt.