FortiGate-VPN landet in der falschen Gruppe: RADIUS-Zuordnung

Die Anmeldung gelingt, der Tunnel kommt hoch, und der Benutzer landet in der falschen oder in gar keiner Richtlinie. Nichts im FortiGate-Protokoll meldet, dass die Gruppe fehlte, denn aus seiner Sicht hat die Authentifizierung funktioniert, und der Gruppenabgleich wurde schlicht nicht ausgelöst. Die Kette, die Sie prüfen müssen, enthält drei getrennte Namen, und sie sind normalerweise nicht dieselbe Zeichenfolge.

Drei Namen mit drei Aufgaben

Schreiben Sie alle drei auf, bevor Sie irgendeine Konfiguration anfassen, denn zwei davon leben in unterschiedlichen Systemen.

Die Verzeichnisgruppe ist das, was Ihre RADIUS-Richtlinie auswertet. Das zurückgegebene Attribut ist ein Wert innerhalb der Access-Accept-Antwort. Die lokale FortiGate-Gruppe ist ein Container, auf den die Richtlinie namentlich verweist. Verwechselt man zwei davon, entsteht eine Anmeldung, die funktioniert, und eine Autorisierung, die es nicht tut.

Wo der Abgleich tatsächlich stattfindet

Fortinets Erläuterung der RADIUS-Gruppenzuordnung nennt Fortinet-Group-Name als Standard-Gruppenattribut. FortiGate vergleicht den konfigurierten Remote-Server und den Gruppennamenwert mit dem, was die Antwort enthält; der Vergleich erfolgt also gegen die zurückgegebene Zeichenfolge und nicht gegen die Anzeigebezeichnung Ihrer lokalen Gruppe.

Deshalb kann eine lokale Gruppe namens VPN-Engineering neben einem zurückgegebenen Wert vpn-engineering stehen und überhaupt nichts treffen. Groß- und Kleinschreibung sowie Schreibweise sind bei diesem Vergleich keine Kosmetik. Wählen Sie eine Zeichenfolge, verwenden Sie sie in der Antwort, und verweisen Sie auf dieselbe Zeichenfolge in der Zuordnungsregel des Gateways.

Auf FortiAuthenticator muss die Gruppe dem Attribut zugeordnet und in die passende RADIUS-Dienstrichtlinie aufgenommen werden, wobei die Steuerung zur Rückgabe des Gruppenattributs aktiviert ist, wo dies zutrifft.

Die Antwort kann auch ohne das Attribut gelingen

Erzwingen Sie für NPS oder einen anderen RADIUS-Server die Verzeichnisgruppenbedingung in der Richtlinie und konfigurieren Sie dann das unterstützte Antwortattribut. Eine erfolgreiche Passwortprüfung erzeugt von sich aus ein Access-Accept, und ein Access-Accept ohne Gruppenzeichenfolge ist eine vollkommen gültige Antwort, die auf der FortiGate-Seite nichts autorisiert. Das ist die häufigste Form des Problems.

Eine Gruppe zu definieren ist nicht dasselbe, wie sie zu senden. Das sind zwei Konfigurationsschritte auf zwei verschiedenen Bildschirmen, und normalerweise wird nur einer davon erledigt.

Warum die Zuordnung auf Any eine Falle ist

Ein Any-Remote-Gruppenabgleich ist ein legitimes Design, wenn der RADIUS-Server bereits genau die Population zulässt, die Sie wollen. Wählen Sie diese Delegation bewusst. Erweitert man den Abgleich, damit ein fehlendes Attribut verschwindet, lässt man jedes Konto zu, das der RADIUS-Server zufällig akzeptiert, auch solche, die nie VPN-Zugang haben sollten. Das Symptom verschwindet, und die Zugangskontrolle hört still auf zu existieren.

Wenn Sie nicht benennen können, wen der RADIUS-Server zulassen soll, sind Sie nicht bereit für einen Any-Abgleich.

Bewahren Sie vier Aufzeichnungen für den Support auf

Wenn es weiterhin nicht funktioniert, sammeln Sie vier Dinge: die ausgewählte RADIUS-Richtlinie, das tatsächlich zurückgegebene Gruppenattribut, den FortiGate-Server und den Wert, gegen den abgeglichen wurde, und die resultierende lokale Gruppe. Diese vier Aufzeichnungen lokalisieren den Bruch, ohne Passwörter offenzulegen oder die Gruppenmitgliedschaft zu ändern, um zu sehen, was passiert.

Testen Sie ein autorisiertes und ein außerhalb des Geltungsbereichs liegendes Konto unter der echten Regel und prüfen Sie die resultierende Richtlinie und den Ressourcenzugriff ebenso wie das Authentifizierungsergebnis. Nur das Paar sagt Ihnen, ob der Abgleich das tut, was Sie denken.