RouterOS OpenVPN und NPS: user-auth-method setzen, nicht auth

Unter RouterOS wählt auth den Tunnel-Digest, während user-auth-method entscheidet, wie die RADIUS-Anfrage geprüft wird. Passe das Zweite an die NPS-Richtlinie an.

RouterOS kann NPS mit einer OpenVPN-Anmeldung erreichen und trotzdem abgelehnt werden; die übliche Ursache sind zwei Einstellungen, deren Namen beide nach Authentifizierung klingen. Die eine wählt einen kryptografischen Digest für den Tunnel; die andere entscheidet, wie die Anmeldedaten des Benutzers an RADIUS übergeben werden. Eine Änderung des Digests macht aus einer PAP-Anfrage niemals MS-CHAPv2, egal wie oft der Dienst neu startet. Die folgende Checkliste trennt beides und verfolgt dann eine einzelne fehlgeschlagene Anmeldung durch die NPS-Richtlinie, die sie beurteilt hat.

Schritt 1: beide Einstellungen lesen, bevor eine geändert wird

Drucke die effektive OpenVPN-Serverkonfiguration auf dem Router aus, der den Tunnel beendet – nicht aus einem Backup oder einem kopierten Forenbeitrag. Die beiden Felder, um die es geht, stehen meist im selben Menü und lesen sich, als wären sie Alternativen. Sie sind es nicht: Das eine betrifft den Datenkanal, das andere den Austausch der Anmeldedaten.

/interface ovpn-server server print
/interface ovpn-server server export

Das Feld auth listet Digests wie sha1 und sha256 und steuert den HMAC, der Tunnelpakete authentifiziert. Das Feld user-auth-method wählt pap oder mschap2 und entscheidet, wie der Router die Anmeldedaten des Benutzers an RADIUS übergibt. Eine Änderung des Digests kann das zweite Verhalten nicht ändern; deshalb überlebt dieselbe Ablehnung jede Anpassung am ersten.

Höre hier auf, wenn deine Version user-auth-method überhaupt nicht anbietet. Ältere RouterOS-Builds bieten es auf dem OpenVPN-Server möglicherweise nicht an, und die Lösung gehört in eine Version, die du unterstützen kannst, nicht in einen Befehl aus einer neueren.

Schritt 2: die Richtlinie finden, die die Anmeldung tatsächlich abgelehnt hat

Auf der NPS-Seite wird eine Verbindungsanforderung gegen Netzwerkrichtlinien geprüft, und die in der passenden Richtlinie genannte Authentifizierungsmethode muss eine sein, die der Client tatsächlich angeboten hat. Ordne eine fehlgeschlagene Anmeldung nach Zeit und Benutzer zu, statt eine Summenzahl zu lesen. Das Sicherheitsprotokoll zeichnet gewährte und verweigerte Anforderungen mit einem Ursachencode auf, was dir weit mehr sagt als die allgemeine Fehlerzeile des Routers.

Get-WinEvent -LogName Security -MaxEvents 200 |
  Where-Object { $_.Id -in 6272,6273 } |
  Format-List TimeCreated,Id,Message

Lies drei Dinge im Ereignis: den Namen der passenden Richtlinie, die Authentifizierungsmethode und den Ursachencode. Eine Richtlinie, die MS-CHAPv2 verlangt, weist eine PAP-Anfrage auch bei korrektem Passwort ab, und eine Richtlinie, die ein Domänenkonto verlangt, weist ein lokales Konto ab. Der RADIUS-Client-Eintrag muss außerdem zur Quelladresse des Routers passen, sonst wird die Anfrage verworfen, bevor eine Richtlinie befragt wird. Nichts davon erscheint im OpenVPN-Protokoll.

Höre hier auf, wenn die Anfrage NPS nie erreicht. Das ist ein Problem mit dem gemeinsamen Geheimnis, der Client-Adresse oder UDP 1812, und eine Änderung der Authentifizierungsmethoden behebt es nicht.

Schritt 3: eine Methode ändern, auf beiden Seiten

Wenn das genehmigte Design MS-CHAPv2 ist, stelle es auf dem Router ein und bestätige, dass die passende Richtlinie es akzeptiert. Ändere eine Seite, teste erneut und ändere dann die andere; beide gleichzeitig zu ändern lässt dich nicht mehr sagen, welche wichtig war.

/interface ovpn-server server set user-auth-method=mschap2
/interface ovpn-server server print
/log print where topics~"radius"

Aktiviere nicht jede schwächere Methode auf NPS, damit der Fehler verschwindet. Das Backend muss Material besitzen, das die gewählte Methode prüfen kann: MS-CHAPv2 braucht Zugriff auf das Passwort oder die Domäne, und eine Richtlinie kann dieses Material nicht erfinden. Eine Richtlinie zu öffnen öffnet auch, was ein Angreifer gegen dasselbe Konto versuchen kann. Halte Methode, Richtlinienname und Änderungsreferenz zusammen fest, damit die nächste Person eine Entscheidung erbt statt einer Vermutung.

Lass die Zertifikatsprüfung des Tunnels genau so, wie sie war. Eine Anmeldedatenmethode ersetzt nicht die Serveridentität, und TLS-Prüfungen zu senken, damit ein Test besteht, tauscht ein Problem gegen ein schlimmeres.

Schritt 4: drei Anmeldungen und eine Berechtigung testen

Teste einen erlaubten Benutzer, ein falsches Passwort und einen ausgeschlossenen Benutzer, jeweils in einer frischen Sitzung. Der erste beweist den Pfad, der zweite beweist, dass die Anmeldedatenprüfung echt ist, und der dritte beweist, dass die Richtlinie weiterhin ausschließt, wen sie soll. Eine zwischengespeicherte Sitzung kann alle drei verbergen, also trenne die Versuche.

/log print where topics~"ovpn"
/radius monitor 0

Erfolgreiche Authentifizierung ist nicht das Ende der Checkliste. Prüfe die Adresse, die der Client erhalten hat, und die Ressourcen, die diese Adresse erreichen kann, denn ein Benutzer kann sich korrekt authentifizieren und trotzdem im falschen Pool landen. Ist die zugewiesene Adresse falsch, liegt das Problem im Profil oder in den RADIUS-Antwortattributen, nicht in der Methode. Bestätige beides, bevor du das Ticket schließt.

Die Checkliste ist fertig, wenn Routereinstellung und NPS-Richtlinie dieselbe Methode nennen, ein erlaubter Benutzer sich mit einer frischen Sitzung verbindet, ein falsches Passwort abgelehnt wird, ein ausgeschlossener Benutzer weiterhin ausgeschlossen ist und die zugewiesene Adresse zum vorgesehenen Pool passt. Alles darunter überlässt die nächste Anmeldung dem Zufall.

Ähnliche Artikel