FortiGate VPN MFA: lokaler Token, RADIUS oder SAML?

Das Gateway, ein RADIUS-Backend oder ein SAML-Anbieter können den Faktor prüfen, und jeder scheitert anders. Dienst, Client und Wiederherstellungsweg zusammenbringen.

Jedes FortiGate-VPN-MFA-Design beantwortet zuerst eine Frage: Wer prüft den zweiten Faktor? Das Gateway selbst kann es mit einem lokalen Token oder einem per E-Mail gesendeten Code tun, ein RADIUS-Backend kann ihn erzwingen und eine Challenge zurückgeben, oder ein SAML-Identitätsanbieter kann die gesamte Zeremonie im Browser übernehmen. Jede dieser Varianten erzeugt eine andere Anmeldesequenz, eine andere Fehlersignatur und ein anderes Wiederherstellungsverfahren, und einen Befehlsblock zwischen ihnen zu kopieren erzeugt eine Konfiguration, die plausibel aussieht und niemanden authentifiziert. Dies ist ein Mechanismus-Artikel: Was jedes Design bei einer Anmeldung tatsächlich tut und wo es bricht.

Die Anmeldezeremonie entscheidet, wem der Faktor gehört

In den ersten beiden Designs ist das FortiGate die vertrauende Partei. Es sammelt die Anmeldedaten, entscheidet, ob ein zweiter Faktor nötig ist, und prüft ihn lokal oder über eine Challenge. Im dritten Design hört das Gateway auf, Prüfer zu sein, und wird zum Vermittler: Es leitet den Client zum Identitätsanbieter um, empfängt eine Assertion und ordnet die bestätigte Identität einem Benutzer und einer Gruppe zu. Im RADIUS-Design liegt es dazwischen und treibt einen Anforderungs-Antwort-Austausch mit einem Backend, das die Richtlinie hält.

Dieser Unterschied entscheidet, welche Beweise Sie sammeln können. Wenn das Gateway prüft, sagt Ihnen seine eigene Debug-Ausgabe, was passiert ist. Wenn ein Identitätsanbieter prüft, weiß das Gateway nur, dass eine Assertion angekommen ist, und die Antwort auf die Frage „war MFA tatsächlich erforderlich“ liegt in den Protokollen des Anbieters, nicht in denen der Firewall. Das falsche Protokoll zu lesen ist der häufigste Weg, ein Rollout falsch zu diagnostizieren, das sich genau wie entworfen verhält. Auch der Dienst begrenzt die Zeremonie: FortiOS 7.6.3 entfernt den SSL-VPN-Tunnelmodus zugunsten von IPsec, während der Webmodus als Agentless VPN auf unterstützten Modellen weiterläuft, sodass eine auf einem Dienst bewiesene Zeremonie nicht automatisch auf einem anderen verfügbar ist.

Lokale Prüfung: Token und E-Mail-Codes

Von FortiGate verwaltete Faktoren hängen am Benutzerobjekt. Ein FortiToken oder eine dokumentierte Token-Integration benötigt Registrierung, die unterstützte Prüfzeremonie, Lizenzierung wo zutreffend und ein Ersetzungsverfahren. Ein per E-Mail gesendeter Code benötigt einen funktionierenden SMTP-Pfad und ein Postfach, das der Benutzer erreichen kann, bevor der Tunnel existiert – eine Abhängigkeit, die nichts mit Kryptografie und alles damit zu tun hat, ob sich jemand anmelden kann.

config user local
    edit "jdoe"
        set type password
        set two-factor fortitoken
        set fortitoken FTKMOB1234567890
    next
end

Die E-Mail-Zustellung ist Teil der Verfügbarkeit der Authentifizierung. Ein nur über das VPN erreichbares Postfach erzeugt eine Schleife, die sich für niemanden von selbst auflöst, und Zustellverzögerung, Codegültigkeit und der Timeout der entfernten Authentifizierung sind drei getrennte Einschränkungen. Eine davon zu erhöhen repariert kein unerreichbares Postfach, und ein Design, das die Schleife nie getestet hat, wird sie beim ersten Passwort-Reset nach einem Feiertag entdecken.

Auch Vertrauensanforderungen gehören hierher, vor der Produktwahl. NIST SP 800-63B betrachtet E-Mail für die Out-of-Band-Authentifizierung als unzulässig, sodass ein Deployment, das Konformität beansprucht, einen E-Mail-Code nicht als zweiten Faktor verwenden kann, so bequem er auch ist. Dass eine Funktion auf dem Gerät existiert, ist keine Aussage darüber, dass sie einen bestimmten Standard erfüllt.

RADIUS: Das Gateway fragt, das Backend entscheidet

Mit RADIUS sendet das FortiGate die Anmeldedaten an ein Backend, das die Faktorrichtlinie besitzt. Der Austausch kann eine einfache Annahme oder Ablehnung sein, oder er kann eine Challenge umfassen, die der Client beantworten muss, was bedeutet, dass sowohl der VPN-Dienst als auch der Client diese Challenge-Form unterstützen müssen. Ein Backend, das eine Push-Freigabe erzwingt, und ein Client, der nur einen sechsstelligen Code an ein Passwort anhängen kann, werden sich nicht in der Mitte treffen.

config user radius
    edit "corp-radius"
        set server "10.10.20.15"
        set secret ENCXXXXXXXX
        set secondary-server "10.10.20.16"
    next
end
diagnose test authserver radius corp-radius pap jdoe <password>

Testen Sie das Backend unabhängig, bevor Sie den Tunnel beschuldigen. Wenn der authserver-Test gelingt und eine VPN-Anmeldung nicht, liegt der Unterschied in der Challenge-Behandlung und nicht in den Anmeldedaten, und das Debug des Authentifizierungs-Daemons des Gateways ist der Ort, an dem das sichtbar wird:

diagnose debug application fnbamd -1
diagnose debug enable

SAML: Der Browser verlässt das Gateway

In einem SAML-Design wird der Client zum Identitätsanbieter umgeleitet, authentifiziert sich dort und kehrt mit einer Assertion zurück, die das Gateway gegen eine Vertrauensbeziehung und ein Gruppenmapping prüft. Das Gateway sieht weder das Passwort noch den zweiten Faktor, was zugleich eine Sicherheitsverbesserung und eine betriebliche Komplikation ist: Der Fehler passiert jetzt in einer Browsersitzung, die die Firewall nicht einsehen kann.

Eine Assertion zu akzeptieren beweist nicht, dass der Anbieter für diese Anmeldung MFA verlangt hat. Eine Anbieterrichtlinie, die MFA auf einige Anwendungen anwendet und auf andere nicht, erzeugt genau die Anmeldung, die Sie angefordert haben, und nichts von der Sicherheit, die Sie angenommen haben. Prüfen Sie die Richtlinie des Anbieters für diese konkrete Anwendung und prüfen Sie, ob das Mapping der Gruppenaussagen auf FortiGate-Gruppen nach einer Umbenennung auf einer der beiden Seiten noch übereinstimmt.

Client-Unterstützung ist hier wichtiger als irgendwo sonst. Manche VPN-Clients übernehmen die Übergabe an den Browser nativ, manche öffnen den Systembrowser, und headless oder kommandozeilenbasierte Clients schließen den Ablauf möglicherweise gar nicht ab. Testen Sie mit dem Client, den die Benutzer wirklich verwenden, auf den Plattformen, die sie wirklich nutzen, bevor Sie das Profil veröffentlichen.

Wiederherstellung ist Teil des Mechanismus

Jedes der obigen Designs hat eine Abhängigkeit, die für jeweils einen Benutzer ausfallen kann: ein unerreichbares Postfach, ein verlorener Token, ein Backend, das eine Challenge ablehnt, ein gesperrtes Konto beim Identitätsanbieter. Entscheiden Sie jetzt, wer den Zugang wiederherstellen kann, über welches unterstützte Verfahren und mit welcher Prüfung der anfragenden Person. Ein Notfall-Lokalkonto eines Administrators, getrennt vom VPN-Weg gehalten, ist eine Kontrolle; eine unerklärte Umgehung nur mit Passwort ist ein Vorfall, der darauf wartet, entdeckt zu werden.

Testen Sie dann drei Anmeldungen vor dem Rollout: die normale, einen abgelehnten oder abgelaufenen Faktor und die genehmigte Wiederherstellung eines verlorenen Authenticators. Halten Sie fest, in welchem Protokoll jede erscheint. Dieser Nachweis verwandelt „MFA ist aktiviert“ in ein Design, das jemand anderes betreiben kann.

Ähnliche Artikel