Warum das Bearbeiten einer .ovpn-Datei MFA auf dem Server nicht einschalten kann

Sie fügen auth-user-pass zu einem Profil hinzu, verbinden sich neu, und der Client fragt nach Benutzername und Passwort. Es sieht aus, als wäre MFA aktiv. Dann geben Sie einen Code aus dem falschen Konto ein oder einen Code, der vor zehn Minuten abgelaufen ist, und der Tunnel kommt trotzdem hoch. Das ist das Symptom: Der Client hat sich geändert, der Server nicht. Ein Einmalpasswort ist nur dann ein Faktor, wenn ein Prüfer auf dem Server entscheidet, ob es für die Identität gültig ist, die es beansprucht.

Die Abfrage beweist nur, dass der Client gefragt hat, mehr nicht

Eine .ovpn-Datei ist ein Dokument auf der Clientseite. Sie kann dem Client sagen, dass er Anmeldedaten anfordern, zwischenspeichern oder nicht mehr zwischenspeichern soll. Sie kann keinen Benutzer registrieren, kein PAM-Modul installieren oder den Server dazu bringen, einen zweiten Faktor zu verlangen, den er derzeit nicht prüft.

Auch die Installation einer Authenticator-App auf einem Telefon schafft diese Beziehung nicht. Das Google-Authenticator-PAM-Projekt ist eine OTP-Prüfkomponente, die hinter OpenVPN sitzen kann; es ist kein Weg, die Google-Kontoanmeldung an ein importiertes Profil zu schrauben.

Die Registrierung ist der Teil, den ein Profil nicht leisten kann

TOTP braucht Registrierungsmaterial, das zwischen der Authenticator-App und ihrem Prüfer geteilt wird. Die sechs Ziffern auf dem Telefon sind die Ausgabe; der Seed dahinter ist das Geheimnis, und er gehört zu einer Identität.

Der Betreiber braucht also einen Registrierungsprozess, der den richtigen Seed an die richtige VPN-Identität bindet, plus einen verifizierten Ersatzweg für ein verlorenes Telefon. Wenn Benutzer eine nach ihnen benannte Datei hochladen dürfen, wird die Registrierung zur Gelegenheit für Kontoübernahme, und die Verschlüsselung des Uploads ändert daran nichts.

Ein PAM-basiertes Design muss nicht für jeden VPN-Benutzer ein separates Unix-Konto anlegen. Die Moduldokumentation unterstützt alternative Pfade für Geheimnisse und ein eigenes Konto für den Dateizugriff, also eine Dateisystem-Identität und nicht die Login-Identität, die geprüft wird.

Der häufige Fehler ist ein fester Geheimnispfad, der auf einen Benutzernamen endet, kopiert aus einem Ein-Benutzer-Beispiel. Das ist eine Demonstration für eine Identität, kein Nachschlagen pro Benutzer, und wer ihn für jede Anfrage nutzt, gibt niemandem eine unabhängig registrierte Authenticator-App. Schreiben Sie die Identitätszuordnung auf, schützen Sie die Seed-Dateien und halten Sie Passwort-, Zertifikats- und Kontoprüfungen im selben Authentifizierungs-Stack.

Lesen Sie den PAM-Stack daraufhin, was tatsächlich verlangt wird

Eine Zeile wie account required pam_permit.so implementiert keine Kontoberechtigung und fügt keinen Faktor hinzu. Sie erlaubt diese PAM-Kontoverwaltungsstufe, was eine Aussage über eine Stufe ist und nicht über Ihre Benutzer.

Dasselbe gilt für großzügige Registrierungsoptionen. Benutzer ohne registrierten Seed zu akzeptieren, kann eine bewusste Einführungsentscheidung sein, ist aber kein Beweis, dass MFA verpflichtend ist, und sollte als befristete Ausnahme mit Enddatum festgehalten werden.

Passen Sie die Interaktion des Clients an das Design des Servers an

auth-user-pass

Diese Direktive verlangt die Eingabe von Benutzername und Passwort. Sie konfiguriert kein PAM, legt keinen Registrierungseintrag an und sagt dem Server nicht, dass das Passwortfeld einen TOTP-Wert enthält. Server-Integration und Client müssen sich auf eine Interaktion einigen, die das Deployment tatsächlich unterstützt: eine Challenge, ein dokumentiertes kombiniertes Anmeldedatenformat oder ein produktspezifischer Ablauf.

Hängen Sie keinen Code an das Passwort, nur weil der Client ein Feld anzeigt. Das funktioniert nur dort, wo das Plugin des Servers genau dieses Format erwartet, und scheitert überall sonst verwirrend.

Halten Sie Seeds und QR-Material aus gemeinsam genutzten Profilen und routinemäßigen Diagnoseprotokollen heraus. Ein Code, der über den authentifizierten Login-Kanal übermittelt wird, ist nicht dasselbe Objekt wie der Seed, der bei kontrollierter Registrierung ausgegeben wurde, und beides in einem Support-Ticket zu mischen, ist der Weg, auf dem Geheimnisse entweichen.

Neuverbindungen, Token und der Test, der die Sache entscheidet

Planen Sie, was nach dem ersten erfolgreichen Login passiert. Ein zuvor akzeptierter Code kann bei der nächsten Authentifizierung abgelaufen oder als Wiederholung abgelehnt werden. auth-nocache steuert die Aufbewahrung von Anmeldedaten und installiert kein MFA, und reneg-sec 0 ist keine Definition von TOTP-Unterstützung, so oft es auch in Forenthreads auftaucht.

Manche Deployments geben nach der ersten Prüfung Authentifizierungs-Token aus, damit Neuverbindungen nicht erneut fragen. Das ist eine Designentscheidung mit eigenem Gültigkeitsfenster und eigener Widerrufsgeschichte, kein Standard, den Sie erben.

Testen Sie dann die Zulassungsrichtlinie mit dem Client, den die Leute tatsächlich benutzen. Ein registrierter Benutzer mit dem richtigen Passwort, Zertifikat und aktuellen Code sollte sich verbinden können. Ein falscher Code, ein Benutzer ohne Registrierung und ein gesperrtes Konto sollten jeweils scheitern, und der Grund sollte im Serverprotokoll sichtbar sein. Bis Sie diese Ablehnungen gesehen haben, haben Sie eine Abfrage, keine Richtlinie.