EAP oder Client-Zertifikate? IKEv2-Authentifizierung entscheiden

Ihr Gateway kann seine eigene Identität mit einem Zertifikat belegen und Ihre über EAP, und diese Kombination ist üblich statt widersprüchlich. Die beiden Mechanismen beantworten verschiedene Fragen: Ist dieser Endpunkt der erwartete, und ist dieser Benutzer oder dieses Gerät zugelassen. EAP in einem Profil zu sehen schaltet die Serverprüfung nicht ab. Das Profil als eine einzige Einstellung zu lesen, führt dazu, dass Menschen den falschen Nachweis zurücksetzen.

Stellen Sie fest, welche Behauptung fehlgeschlagen ist, bevor Sie eines der beiden Objekte anfassen. Die Fehlerstufe sagt es Ihnen, wenn Sie sie der Reihe nach lesen.

Zwei Nachweise, zwei Behauptungen

Ein Serverzertifikat bindet einen Namen an einen Schlüssel, und der Client prüft diese Bindung gegen seinen Trust Store. Ein Client-Zertifikat bindet eine Identität an einen Schlüssel, und das Gateway prüft, ob das vorgelegte Zertifikat zu etwas verkettet, dem es vertraut. EAP trägt einen Authentifizierungsaustausch, dessen Inhalt von der gewählten Methode abhängt. Das sind drei Strukturen mit unterschiedlichen Laufzeiten, unterschiedlichen Eigentümern und unterschiedlichen Fehlerarten.

Eine Passphrase, die einen privaten Schlüssel entsperrt, ist kein Kontopasswort, auch wenn beide Abfragen innerhalb von Sekunden nacheinander erscheinen. Die eine ist lokal im Schlüsselspeicher des Geräts, die andere wird von einem Authentifizierungsserver hinter dem Gateway geprüft.

EAP ist ein Container, keine Methode

EAP ist ein Rahmen: Gateway und Client handeln eine Methode aus, und die Methode entscheidet, ob ein Passwort, ein Token, ein getunnelter innerer Austausch oder ein Zertifikat beteiligt ist, wie die strongSwan-Dokumentation zu IKEv2 darlegt. Deshalb sieht EAP-TLS aus Client-Sicht völlig anders aus als EAP-MSCHAPv2, obwohl beide im Menü als EAP erscheinen. Ein Profil, das nur EAP nennt, hat Ihnen nicht gesagt, wonach der Benutzer gefragt wird.

Lesen Sie Methode und Backend zusammen. Das Backend bestimmt Kontoformat, Sperrverhalten und was ein Passwort-Reset tatsächlich ändert, und nichts davon ist im Clientprofil sichtbar.

Die gemischte Bereitstellung ist normal

Serverzertifikat plus EAP für den Benutzer ist die Form, die die meisten Fernzugriffs-Gateways bereitstellen, weil sie dem Client einen prüfbaren Endpunkt und dem Betreiber eine Identität pro Benutzer in einem zentralen Kontospeicher gibt. Bereitstellungen mit Client-Zertifikaten gibt es ebenfalls, meist dort, wo Geräteidentität wichtiger ist als ein Passwort. Beide sind legitim, und der Fehler ist anzunehmen, das von letzter Woche sei das vor Ihnen.

Fragen Sie den Betreiber nach der dokumentierten Methode und dem Kontoformat, statt beides aus Feldnamen in einem Client abzuleiten.

Entscheidung anhand der Fehlerstufe

Ordnen Sie die Beobachtungen. Ein Vertrauensfehler vor jeder Benutzerabfrage ist ein Serverzertifikatsproblem, und kein Passwort behebt ihn. Eine Abfrage, auf die eine Ablehnung folgt, ist ein Problem der Benutzerauthentifizierung, mit der EAP-Methode und dem Backend als Verdächtigen. Eine erfolgreiche Authentifizierung, auf die ein child-SA-Fehler folgt, ist keines von beiden.

Zwei weitere Unterscheidungen zählen. Ein Client, der das Serverzertifikat ablehnt, meldet meist eine Namensabweichung oder eine unbekannte Zertifizierungsstelle, was eine Frage des Trust Store ist. Ein Gateway, das den Benutzer ablehnt, protokolliert oft die EAP-Methode und eine Ursachenkategorie, was eine Frage von Konto oder Richtlinie ist.

Die beiden Modelle betreiben

Bei Zertifikaten besteht die Arbeit aus Ausstellung, Erneuerung, Widerruf und Entfernen verlorener Geräte, und sie erfolgt nach einem Zeitplan, den Sie steuern. Bei EAP besteht die Arbeit aus dem Kontolebenszyklus, der Methodenunterstützung auf jeder Clientplattform und dem zweiten Faktor, den das Backend verlangt. Keines der Modelle ist abstrakt billiger; sie belasten verschiedene Teams. Schreiben Sie auf, welches Ihre Bereitstellung tatsächlich nutzt, denn die Support-Skripte unterscheiden sich stärker als die Konfiguration.

Halten Sie beides in Ihren Notizen getrennt. Ein Zertifikatsablauf erzeugt einen Fehler zu einem Datum, eine Kontosperre erzeugt einen Fehler nach einer Passwortänderung, und eine Methodenabweichung erzeugt einen Fehler nur auf einer Plattform.

Nachdem die Identität akzeptiert ist

Authentifizierung ist ein Tor. Die untergeordnete Sicherheitsassoziation, die Traffic Selectors, DNS und die eigenen Berechtigungen der Anwendung sind spätere Tore, und jedes scheitert zu seinen eigenen Bedingungen. Eine akzeptierte Identität, die nichts erreicht, ist kein Authentifizierungsproblem.

Notieren Sie die Methode, das verwendete Konto oder Zertifikat und die fehlgeschlagene Stufe. Diese Notiz macht den nächsten Vorfall zu einem Nachschlagen statt zu einem Experiment.