Fehlende TOTP-Abfrage in OpenConnect unter NetworkManager: vier Prüfungen

Das Gateway akzeptiert das Passwort, verlangt einen Code, und der Dialog bietet kein Feld dafür. Es wurde nichts falsch eingetippt: Das NetworkManager-Plugin hat den Secret-Austausch abgeschlossen, ohne den sechsstelligen Wert anzufordern. Gehen Sie die vier Prüfungen unten der Reihe nach durch, denn nur eine davon ändert den Client. Der Rest der Liste schließt das Gateway, das Konto und den Plugin-Build aus.

Erste Prüfung: Lesen Sie, wo die Authentifizierung stehen blieb

Ein falsches Passwort schlägt sofort fehl. Ein fehlender zweiter Faktor schlägt nach dem Anmeldedatenschritt fehl, meist mit einer wiederholten Aufforderung oder einem Timeout auf der Gateway-Seite. Der Zeitpunkt und das Gateway-Log zeigen, welche Runde unbeantwortet blieb.

Lesen Sie das Verbindungslog, bevor Sie das Profil anfassen. Meldet das Gateway eine unvollständige Authentifizierung oder eine abgelaufene Challenge, hat der Client den Code nie gesendet. Meldet es ungültige Anmeldedaten, ist das Passwort das Problem, und keine TOTP-Einstellung behebt es.

Notieren Sie die genaue Reihenfolge der Aufforderungen, die das Gateway erwartet: Benutzername, Passwort, dann Code, oder Benutzername, Code, dann Passwort. Manche Gateways ordnen die Runden um, und ein Client, der nur die erste Reihenfolge kennt, bleibt bei der zweiten hängen.

Zweite Prüfung: Verwenden Sie den Client, dem die Challenge gehört

OpenConnect selbst implementiert die gesamte Unterhaltung einschließlich der Challenge-Runde. Der direkte Aufruf ist der berechenbarste Weg zu bestätigen, dass Konto und Gateway funktionieren:

sudo openconnect --protocol=anyconnect --useragent=AnyConnect vpn.example.net

Der Client fragt in der Reihenfolge, in der das Gateway fragt. Der User-Agent zählt, weil manche Gateways den Anmeldeablauf auf einen bekannten Client zuschneiden, und eine generische Zeichenfolge kann einen kürzeren Ablauf erzeugen, der nie nach dem Code fragt. Führen Sie ihn einmal im Vordergrund aus, bevor Sie einen Hintergrunddienst einrichten.

Fragt die Kommandozeile korrekt, sind Konto, Gateway und zweiter Faktor in Ordnung. Das verbleibende Problem ist der Dialog des Plugins, nicht der Authentifizierungsdienst. Das grenzt die fehlerhafte Komponente ein, ohne den Server anzufassen. Bewahren Sie die Befehlsausgabe beim Incident-Datensatz auf.

Überspringt auch die Kommandozeile die Aufforderung, halten Sie an und prüfen Sie die Gateway-Konfiguration mit ihrem Verantwortlichen. Kein Desktop-Client kann eine Challenge beantworten, die der Server nie sendet.

Dritte Prüfung: Sehen Sie nach, ob Ihr Plugin einen TOTP-Modus anbietet

Manche NetworkManager-OpenConnect-Builds bieten einen Token-Modus und ein User-Agent-Feld im Identity-Tab der Verbindung. Setzen Sie den User-Agent auf den Wert, den das Gateway erwartet, wählen Sie die manuelle TOTP-Eingabe und speichern Sie die Verbindung.

Ob es diese Felder gibt, hängt von der Plugin-Version und davon ab, welchen Verbindungseditor der Desktop verwendet. Ein eigenständiger Editor kann Optionen zeigen, die das GNOME-Panel verbirgt, oder umgekehrt. Prüfen Sie die Version des installierten Pakets, bevor Sie eine versteckte Einstellung suchen.

Ist der Token-Modus vorhanden und erscheint die Aufforderung dennoch nicht, fehlt dem Build die Challenge-Übergabe zwischen Plugin und generischem Secret-Dialog. Das Passwort erneut zu tippen, dasselbe Paket neu zu installieren oder den Schlüsselbund zu leeren erzeugt kein Feld, das der Build nicht implementiert.

Vierte Prüfung: Behandeln Sie einen generierten Code als Kompromiss

Ein Skript kann oathtool für den aktuellen Code aufrufen und Benutzername, Passwort und Code in nmcli connection up --ask einspeisen. Die Sequenz funktioniert, aber das gemeinsame Secret landet an einer Stelle, die jeder lesen kann, der das Skript öffnen kann, und dieser Leser kann für immer Codes erzeugen. Das ist eine dauerhafte Erweiterung der Angriffsfläche für Anmeldedaten, keine Client-Korrektur.

Wer das wählt, sollte die Secret-Datei auf root beschränken, generierte Werte aus der Shell-Historie heraushalten und das Skript als Anmeldedatenmaterial behandeln. Ein Wrapper, der den Code ins Terminal spiegelt, wirft den zweiten Faktor weg. Testen Sie den Wrapper zuerst mit einem Wegwerfkonto.

Das Skript muss auch die Aufforderungsreihenfolge des Gateways einhalten. Verlangt der Server den Code vor dem Passwort, sendet eine feste Eingabesequenz den falschen Wert an die falsche Aufforderung und erzeugt dieselbe unvollständige Authentifizierung. Üben Sie das mit einem Testkonto, bevor Sie es an einen Login-Job hängen.

Bestätigen Sie dasselbe Gateway und dasselbe Konto

Testen Sie jede Umgehung gegen dasselbe Gateway, dasselbe Konto und dieselbe Tunnelgruppe. Ein Gateway, das zusätzlich ein Gerätezertifikat verlangt, kann den Kommandozeilen-Client aus einem Grund ablehnen, der nichts mit TOTP zu tun hat, und die Aufforderungsreihenfolge kann von der geübten abweichen.

Notieren Sie den Client, seine Version, den User-Agent und die Aufforderungsreihenfolge, die funktioniert hat. Dieser Datensatz sagt der nächsten Person, ob das Problem im Plugin-Build, im Gateway-Ablauf oder in der Kontorichtlinie liegt, ohne eine weitere Runde Passwortzurücksetzungen.

Schließen Sie ab, indem Sie sich nach einer vollständigen Abmeldung einmal neu verbinden. Ein zwischengespeichertes Secret kann einen defekten Ablauf bis zur nächsten Sitzung behoben aussehen lassen, und beim zweiten Verbinden kehrt die fehlende Aufforderung gewöhnlich zurück.