Authentification client P2S Azure : Entra, certificat ou RADIUS

Le programme d'installation s'exécute, le profil s'importe et la connexion échoue à l'étape de connexion. La plupart de ces tickets ne sont pas un défaut du client : une application compatible OpenVPN peut transporter le tunnel sans savoir effectuer une connexion Microsoft Entra. L'ordre qui évite la boucle est méthode, puis client, puis profil. Choisissez la méthode d'authentification pour laquelle la passerelle est configurée, choisissez un client que Microsoft documente pour cette méthode, et seulement ensuite générez le profil que ce client attend. Tout ce qui suit respecte cet ordre.

Partez de la méthode, pas du programme d'installation

La passerelle est configurée avec un ou plusieurs types de tunnel et méthodes d'authentification. C'est ce couple, et non l'extension du fichier sur votre bureau, qui décide quels clients sont pris en charge.

Notez le couple avant de télécharger quoi que ce soit, car la matrice de prise en charge est étroite et un mauvais départ coûte un après-midi.

Voici la correspondance que je garde dans les notes de déploiement :

Lisez ce tableau comme une contrainte, pas comme un menu. Chaque ligne est une combinaison documentée, et mélanger un client d'une ligne avec la méthode d'une autre est exactement l'erreur que cet article vise à éviter.

Entra ID signifie OpenVPN plus Azure VPN Client

Pour l'authentification Entra en point à site, la disposition prise en charge utilise le type de tunnel OpenVPN et le client Azure VPN. Une boîte de dialogue générique nom d'utilisateur et mot de passe ne remplace pas cette intégration, et l'IKEv2 natif de Windows n'est pas un moyen interchangeable d'effectuer la même connexion. Si un client tiers propose une option Entra ou Azure AD, vérifiez-la dans la documentation actuelle de Microsoft plutôt que sur l'étiquette. L'étiquette relève du marketing, tandis que la combinaison documentée fait office de contrat.

Sur macOS, le client Azure VPN est également le chemin documenté pour cette méthode.

Les certificats exigent un identifiant client, pas seulement une racine

L'authentification par certificat est un modèle pris en charge distinct, et elle fonctionne avec les clients OpenVPN documentés par Microsoft ainsi qu'avec le client Azure VPN sur les plateformes prises en charge. Sous Windows, le client Azure VPN n'est pas réservé à Entra : il dispose aussi d'un flux de certificat documenté. Ce qu'il lui faut, c'est le certificat client prévu avec une clé privée utilisable, approuvé par la passerelle. La racine de confiance de la passerelle n'est pas un identifiant client, et la clé de signature de l'émetteur n'appartient jamais à un paquet client.

Vérifiez la chaîne avant de déboguer le profil. Un certificat émis par une racine à laquelle la passerelle ne fait pas confiance produit une panne qui ressemble à un mauvais profil et qui est en réalité un problème de confiance.

Gardez la clé privée non exportable lorsque la plateforme le permet, et testez avec le certificat réellement installé pour l'utilisateur actuel.

RADIUS est un choix de backend avec ses propres combinaisons

RADIUS déplace la décision d'identification vers un serveur que vous exploitez, et il est documenté avec des types de tunnel et des clients précis. Ce n'est pas automatiquement la bonne réponse parce que le parc compte plusieurs systèmes d'exploitation. Déterminez ce que le client réel peut présenter avant de modifier la stratégie d'authentification de la passerelle, car basculer la passerelle vers RADIUS n'adapte pas chaque profil existant. Le client doit toujours pouvoir demander ou fournir ces identifiants.

Si le parc mixte est la cause, résolvez-le plateforme par plateforme au lieu d'affaiblir la stratégie de la passerelle pour tout le monde.

Linux après le retrait de l'aperçu en 2026

Les conseils de Microsoft sur le retrait de Linux fixent au 31 août 2026 la date de retrait de l'aperçu du client Azure VPN pour Linux, donc depuis novembre 2026 cet aperçu est derrière vous. Les installations existantes peuvent continuer de fonctionner, mais elles ne reçoivent plus de support, de mises à jour ni de correctifs de sécurité. Ne distribuez pas un ancien programme d'installation Linux comme un nouveau déploiement pris en charge. C'est le retrait d'un client, pas celui d'Azure VPN Gateway ni des clients Windows et macOS.

Les alternatives Linux documentées sont un client OpenVPN avec authentification par certificat, ou strongSwan avec IKEv2 et authentification par certificat ou RADIUS. Ce sont deux configurations différentes qui nécessitent une approbation organisationnelle, et non une conversion obtenue en renommant l'ancien profil Entra.

Si la connexion Entra est obligatoire pour des raisons de stratégie, le propriétaire doit choisir une plateforme prise en charge ou une conception alternative approuvée. C'est une décision, pas un contournement.

Générez le profil et effectuez quatre vérifications

Générez la configuration client depuis la passerelle prévue une fois la combinaison arrêtée, et importez la représentation documentée pour ce client et cette méthode. Le dossier OpenVPN générique et le profil XML du client Azure VPN ne sont pas interchangeables. Si la passerelle active délibérément plusieurs types d'authentification, choisissez le profil et le chemin d'identification correspondants au lieu de compter sur une seule connexion pour tous les satisfaire. Effectuez ensuite les vérifications dans cet ordre :

• Le client pris en charge importe le profil généré sans le modifier.
• L'identité prévue s'authentifie avec la méthode attendue par ce profil.
• La stratégie de routes et de résolveur requise apparaît sur le client.
• L'application autorisée atteint sa ressource privée.

Une importation réussie ne prouve ni la compatibilité d'authentification ni l'autorisation d'accès à la ressource privée, c'est pourquoi ces quatre vérifications restent distinctes.