OpenVPN username-as-common-name: Warum Ihre CN-Prüfung leer ist

Sie fügen ein client-connect-Skript hinzu, das jede Verbindung ablehnt, in der common_name von username abweicht, und es sieht aus wie eine Bindung zwischen einem Zertifikat und einem Konto. Auf einem Server mit username-as-common-name hat dieser Vergleich bereits seine Bedeutung verloren, wenn das Skript läuft. Beide Werte sind dieselbe Zeichenkette, also besteht die Prüfung für ein Zertifikat, das an eine völlig andere Person ausgestellt wurde.

Die Prüfung ist nicht falsch, weil das Skript schlecht geschrieben ist. Sie ist falsch, weil der Wert, den es liest, früher in derselben Verbindung ersetzt wurde.

Was der Vergleich zu beweisen scheint

Zertifikatsauthentifizierung und Passwortauthentifizierung sind getrennte Nachweise, und ein Server kann beide verlangen, ohne zu verlangen, dass sie zu derselben Person gehören. Die Lücke ist real: ein gültiges Gerätezertifikat plus ein beliebiges gültiges Konto ist eine andere Aussage als dasselbe Gerätezertifikat plus ein namentlich genanntes Konto. Ein Skript, das common_name mit username vergleicht, liest sich wie das fehlende Glied zwischen beiden. Und es wäre eines, wenn common_name noch bedeutete, was das Zertifikat sagte.

Ob das der Fall ist, hängt von einer Serveroption ab, und diese Option wird meist aus einem unabhängigen Grund eingeschaltet, etwa um die Benennung von Konfigurationsdateien pro Benutzer zu erleichtern.

Was username-as-common-name mit dem Namen macht

Mit aktiviertem username-as-common-name ersetzt OpenVPN den gemeinsamen Namen des Zertifikats durch den authentifizierten Benutzernamen, sobald Benutzername und Passwort geprüft sind. Der Prüf-Hook, der während dieser Kontrolle läuft, erhält weiterhin den gemeinsamen Namen des Zertifikats, weil die Ersetzung noch nicht stattgefunden hat. Alles danach, client-connect eingeschlossen, sieht den Benutzernamen. Der spätere Callback erhält also eine Identität zweimal und kann sie nicht mit dem vorgelegten Zertifikat vergleichen.

Verfolgen Sie eine beispielhafte Verbindung: ein für bob-device ausgestelltes Zertifikat, eine erfolgreiche Verzeichnisanmeldung als alice und die aktivierte Option. Die Prüfphase kann noch zwei verschiedene Zeichenketten sehen. Die Verbindungsphase sieht alice und alice.

Dieses Beispiel zeigt, warum der Vergleich leer ist. Es zeigt nicht, dass die Verbindung sonst akzeptiert würde, denn Zertifikatsprüfung und Passwortprüfung laufen weiterhin für sich.

Setzen Sie die Bindung dorthin, wo beide Identitäten noch existieren

Die Regel muss in einer Phase durchgesetzt werden, die die Zertifikatsidentität und das Konto gleichzeitig sieht, was praktisch den Prüf-Hook für Benutzername und Passwort oder ein dort geladenes Plugin bedeutet. Ein unterstütztes Plugin, das bereits die Passwortprüfung durchführt, ist meist der richtige Ort, um eine Zuordnungsregel hinzuzufügen, denn ein Ersatz durch einen Namensvergleich würde die Passwortprüfung ganz fallen lassen.

Definieren Sie die Zuordnung, bevor Sie Code schreiben, denn Gleichheit ist selten die eigentliche Richtlinie. Ein Zertifikat identifiziert oft ein Gerät, während die Anmeldung eine Person identifiziert, und ein Gerät kann rechtmäßig mehreren Personen dienen. Speichern Sie die Beziehung in einer Form, deren Ausstellung Sie kontrollieren, und entscheiden Sie, was bei Umbenennung, bei Neuausstellung und bei domänenqualifizierten Namen geschieht. Ein Domänenpräfix kleinzuschreiben oder zu entfernen, ohne das Verzeichnis zu verstehen, kann zwei Konten zusammenführen, die getrennt bleiben sollten.

Denken Sie daran, dass die Option auch ändert, welche Konfiguration pro Client gilt, weil client-config-dir über den gemeinsamen Namen adressiert wird.

Testen Sie die Zuordnung mit zwei gültigen Anmeldedaten

Beginnen Sie mit dem Paar, das Ihre Richtlinie zulässt, und bestätigen Sie, dass es sich verbindet. Legen Sie dann dasselbe gültige Zertifikat mit einem anderen, aber ansonsten gültigen Konto vor: Dieser Versuch muss scheitern, und er muss wegen der Zuordnungsregel scheitern, nicht wegen eines falsch getippten Passworts. Ein falsches Passwort beweist, dass die Passwortprüfung funktioniert, und sagt nichts über die Regel zwischen Zertifikat und Konto.

Prüfen Sie auch die Pfade für fehlendes und ungültiges Zertifikat und bestätigen Sie, welche Identität der Server für Einstellungen pro Client verwendet. Wenn der einzige Weg, den Vergleich zum Laufen zu bringen, darin besteht, username-as-common-name zu deaktivieren, kalkulieren Sie diese Änderung zuerst, denn sie verschiebt die Konfigurationssuche jedes Clients zurück auf den Zertifikatsnamen.