Azure P2S-Clientauthentifizierung: Entra, Zertifikat oder RADIUS

Das Installationsprogramm läuft, das Profil wird importiert, und die Verbindung scheitert beim Anmeldeschritt. Die meisten dieser Tickets sind kein Fehler im Client: Eine OpenVPN-kompatible Anwendung kann den Tunnel tragen und trotzdem nicht wissen, wie eine Microsoft-Entra-Anmeldung durchzuführen ist. Die Reihenfolge, die die Schleife vermeidet, ist Methode, dann Client, dann Profil. Wählen Sie die Authentifizierungsmethode, für die das Gateway konfiguriert ist, wählen Sie einen Client, den Microsoft für diese Methode dokumentiert, und erzeugen Sie erst dann das Profil, das dieser Client erwartet. Alles Weitere folgt dieser Reihenfolge.

Beginnen Sie mit der Methode, nicht mit dem Installationsprogramm

Das Gateway ist mit einem oder mehreren Tunneltypen und Authentifizierungsmethoden konfiguriert. Dieses Paar, nicht die Dateiendung auf Ihrem Desktop, entscheidet, welche Clients unterstützt werden.

Notieren Sie das Paar, bevor Sie etwas herunterladen, denn die Unterstützungsmatrix ist schmal, und ein falscher Start kostet einen Nachmittag.

Hier ist die Zuordnung, die ich in den Bereitstellungsnotizen führe:

Lesen Sie diese Tabelle als Einschränkung, nicht als Menü. Jede Zeile ist eine dokumentierte Kombination, und einen Client aus einer Zeile mit der Methode aus einer anderen zu mischen, ist genau der Fehler, den dieser Artikel verhindern soll.

Entra ID bedeutet OpenVPN plus Azure VPN Client

Für die Entra-Authentifizierung bei Punkt-zu-Standort verwendet die unterstützte Anordnung den Tunneltyp OpenVPN und den Azure VPN Client. Ein allgemeiner Dialog für Benutzername und Kennwort ersetzt diese Integration nicht, und das native IKEv2 von Windows ist kein austauschbarer Weg für dieselbe Anmeldung. Wenn ein Client eines Drittanbieters eine Entra- oder Azure AD-Option anbietet, prüfen Sie sie anhand der aktuellen Microsoft-Dokumentation und nicht anhand des Etiketts. Das Etikett ist Marketing, die dokumentierte Kombination ist der Vertrag.

Unter macOS ist der Azure VPN Client ebenfalls der dokumentierte Weg für diese Methode.

Zertifikate brauchen eine Client-Anmeldeinformation, nicht nur eine Root

Die Zertifikatsauthentifizierung ist ein separates unterstütztes Modell und funktioniert mit OpenVPN-Clients, die Microsoft dokumentiert, und mit dem Azure VPN Client auf unterstützten Plattformen. Unter Windows ist der Azure VPN Client nicht nur für Entra da: Er hat auch einen dokumentierten Zertifikatsworkflow. Was er braucht, ist das vorgesehene Clientzertifikat mit einem nutzbaren privaten Schlüssel, dem das Gateway vertraut. Die vertrauenswürdige Root des Gateways ist keine Client-Anmeldeinformation, und der Signaturschlüssel des Ausstellers gehört niemals in ein Clientpaket.

Prüfen Sie die Kette, bevor Sie das Profil debuggen. Ein Zertifikat, das von einer Root ausgestellt wurde, der das Gateway nicht vertraut, erzeugt einen Fehler, der wie ein schlechtes Profil aussieht und in Wahrheit ein Vertrauensproblem ist.

Halten Sie den privaten Schlüssel nicht exportierbar, wo die Plattform es zulässt, und testen Sie mit dem Zertifikat, das tatsächlich für den aktuellen Benutzer installiert ist.

RADIUS ist eine Backend-Wahl mit eigenen Kombinationen

RADIUS verlagert die Entscheidung über Anmeldeinformationen auf einen Server, den Sie betreiben, und ist mit bestimmten Tunneltypen und Clients dokumentiert. Es ist nicht automatisch die richtige Antwort, nur weil die Umgebung mehrere Betriebssysteme umfasst. Stellen Sie fest, was der tatsächliche Client vorlegen kann, bevor Sie die Authentifizierungsrichtlinie des Gateways ändern, denn das Umschalten des Gateways auf RADIUS passt nicht jedes bestehende Profil an. Der Client muss diese Anmeldeinformationen weiterhin abfragen oder bereitstellen können.

Wenn eine gemischte Umgebung der Grund ist, lösen Sie es pro Plattform, statt die Gateway-Richtlinie für alle abzuschwächen.

Linux nach dem Ende der Vorschau 2026

Microsofts Hinweise zum Linux-Ende nennen den 31. August 2026 als Enddatum der Vorschau des Azure VPN Client für Linux, ab November 2026 liegt diese Vorschau also hinter Ihnen. Bestehende Installationen können weiter funktionieren, erhalten aber keine Unterstützung, Updates oder Sicherheitskorrekturen mehr. Geben Sie kein altes Linux-Installationsprogramm als unterstützte neue Bereitstellung aus. Dies ist das Ende eines Clients, nicht von Azure VPN Gateway oder der Windows- und macOS-Clients.

Die dokumentierten Linux-Alternativen sind ein OpenVPN-Client mit Zertifikatsauthentifizierung oder strongSwan mit IKEv2 und Zertifikats- oder RADIUS-Authentifizierung. Beides sind andere Konfigurationen, die eine organisatorische Freigabe brauchen, keine Umstellung, die man durch Umbenennen des alten Entra-Profils erhält.

Wenn die Entra-Anmeldung aus Richtliniengründen vorgeschrieben ist, muss der Verantwortliche eine unterstützte Plattform oder ein genehmigtes alternatives Design wählen. Das ist eine Entscheidung, kein Workaround.

Erzeugen Sie das Profil und führen Sie vier Prüfungen aus

Erzeugen Sie die Clientkonfiguration aus dem vorgesehenen Gateway, sobald die Kombination feststeht, und importieren Sie die für diesen Client und diese Methode dokumentierte Darstellung. Der allgemeine OpenVPN-Ordner und das XML-Profil des Azure VPN Client sind nicht austauschbar. Wenn das Gateway bewusst mehrere Authentifizierungstypen aktiviert, wählen Sie das passende Profil und den passenden Anmeldeinformationspfad, statt zu erwarten, dass eine Verbindung alle erfüllt. Führen Sie dann die Prüfungen in dieser Reihenfolge aus:

• Der unterstützte Client importiert das erzeugte Profil, ohne es zu bearbeiten.
• Die vorgesehene Identität authentifiziert sich mit der Methode, die das Profil erwartet.
• Die erforderliche Routen- und Resolver-Richtlinie erscheint auf dem Client.
• Die zugelassene Anwendung erreicht ihre private Ressource.

Ein erfolgreicher Import beweist weder die Authentifizierungskompatibilität noch die Autorisierung für private Ressourcen, deshalb bleiben diese vier Prüfungen getrennt.