Quel client peut terminer une connexion SAML sur AWS Client VPN

Deux personnes posent la même question sur AWS Client VPN et SAML et obtiennent des réponses opposées. L’une se connecte depuis un portable Ubuntu chaque matin ; l’autre a un téléphone, un profil téléchargé et un client qui rejette une ligne de ce profil. La différence n’est ni la chance ni un commutateur caché dans le tableau de bord. Tout se ramène à trois conditions : que la plateforme soit l’une de celles qu’AWS prend en charge pour son propre client, que l’outil entre vos mains puisse effectuer l’échange fédéré dans le navigateur, et que le point de terminaison soit configuré pour SAML. Qu’une des trois manque et la connexion bloque ailleurs.

Trois conditions décident si la connexion peut aboutir

La plateforme vient en premier. AWS fournit son propre client Client VPN pour Windows, macOS et Ubuntu sur AMD64, et fin octobre 2026 la page des exigences Linux cite Ubuntu 22.04, 24.04 et 26.04. Une compilation reconditionnée, un paquet converti ou une autre distribution peuvent fonctionner, mais ce n’est pas une plateforme prise en charge, et quand cela casse, c’est vous la ligne de support.

Le client vient en deuxième. La connexion fédérée n’est pas une option de profil que toutes les applications compatibles OpenVPN analysent. Le client fourni ouvre votre fournisseur d’identité dans un navigateur, reçoit la réponse d’authentification signée et transmet cette réponse au point de terminaison. Une application qui se contente de lire le profil et de monter un tunnel n’effectue pas cette étape, aussi propre que paraisse son journal de connexion.

Le point de terminaison vient en troisième. Un point de terminaison utilisant des identifiants Active Directory ou des certificats mutuels a une tout autre organisation, et changer de client ne la modifiera pas. Confirmez le mode d’authentification auprès de celui qui a émis le profil avant de déboguer quoi que ce soit d’autre.

Prises ensemble, les trois conditions donnent un court tableau de décision :

Pourquoi un import OpenVPN s’arrête sur auth-federate

Un profil AWS Client VPN exporté porte une directive qui indique au client que l’authentification a lieu hors du tunnel, par fédération. Un client OpenVPN générique soit rejette la ligne d’emblée, soit l’ignore et n’a alors aucun identifiant à présenter. C’est là que s’arrêtent la plupart des tentatives sous Android : le profil s’importe, l’application proteste, ou la connexion meurt sur une erreur de configuration avant qu’un seul paquet ne quitte l’appareil.

Supprimer auth-federate est le geste suivant tentant, et il transforme un échec clair en échec confus. Retirer une directive ne convertit pas un point de terminaison SAML en authentification par nom d’utilisateur et mot de passe. Le point de terminaison attend toujours une réponse SAML signée et rejette ce que le client envoie à la place. Le mot de passe de votre compte, le profil téléchargé et une assertion copiée ne sont pas des identifiants interchangeables.

Se connecter au fournisseur d’identité dans Chrome sur le téléphone prouve seulement que le fournisseur d’identité a accepté l’utilisateur. Cela ne dit rien de l’arrivée de la réponse à un client capable de la renvoyer au point de terminaison. Les exigences d’authentification fédérée font du client fourni une partie du flux précisément pour cette raison : l’étape dans le navigateur est nécessaire et non suffisante.

À quoi ressemble le parcours de bureau Linux pris en charge

Installez le paquet publié par AWS pour Ubuntu AMD64 avec le gestionnaire de paquets de votre système, puis ouvrez la connexion depuis ce client plutôt que d’importer le profil dans une application VPN généraliste. Utilisez le profil que votre administrateur a exporté pour ce point de terminaison ; ne remplacez ni une URL de retour ni un identifiant client provenant d’un ancien guide, même si le client l’accepte.

Lancez la connexion, terminez la connexion et toute demande MFA dans le navigateur qui s’ouvre, et laissez le flux de retour du navigateur vers le client s’achever. Demandez ensuite l’adresse privée dont vous avez réellement besoin, de nouveau. Une page annonçant une connexion réussie ne prouve pas que le tunnel est monté.

Le client Linux réserve les ports TCP locaux 8096 à 8115 pour les réponses SAML. Quand la passation se bloque après que le fournisseur d’identité vous a accepté, regardez ce qui écoute déjà dans cette plage :

ss -ltnp | grep -E ":809[6-9]|:81(0[0-9]|1[0-5])"

Un port occupé, ou un logiciel de sécurité de point de terminaison qui bloque l’écouteur de bouclage, produit une connexion qui semble aboutir puis ne se connecte jamais. Gardez cette plage locale. C’est un chemin de retour côté client, pas quelque chose à ouvrir dans un groupe de sécurité EC2 ou une règle de pare-feu de passerelle, et l’ouvrir sur internet ajoute de l’exposition sans rien corriger.

Lisez l’étape qui échoue avant de changer quoi que ce soit

Blâmer le client est le réflexe habituel, mais chaque point de défaillance appartient à un propriétaire différent. Déterminez d’abord où vous en êtes réellement.

• Aucune fenêtre de navigateur ne s’ouvre. Vérifiez le mode d’authentification du profil, la connexion choisie et l’intégration avec le navigateur par défaut du bureau.
• Le fournisseur d’identité rejette le compte. Affectation du compte, enrôlement MFA ou configuration de l’application SAML, tout cela relève de l’administrateur.
• Le navigateur se termine mais le client ne se connecte jamais. Une réponse d’authentification expirée ou inutilisable, un port de retour bloqué ou une passation échouée.
• Le tunnel est monté mais l’application est injoignable. Routes du point de terminaison, règles d’autorisation, groupes de sécurité, DNS. Répéter la connexion dans le navigateur ne peut pas ajouter une autorisation réseau manquante.

Conservez le texte d’erreur du client et l’heure de la tentative lorsque vous escaladez. L’affirmation que SAML est cassé et celle que le client n’a jamais reçu de réponse d’authentification valide envoient les gens à des endroits complètement différents.

Quand l’exigence est Android malgré tout

Android n’est pas une plateforme pour laquelle AWS publie son client, donc la réponse honnête est qu’il n’existe aucun client mobile pris en charge à installer. C’est une contrainte de conception, pas un casse-tête à résoudre sur le téléphone en modifiant le profil jusqu’à ce que quelque chose se connecte.

Ce qui peut changer, c’est la conception d’accès derrière, et cette décision revient à l’administrateur : un chemin d’accès applicatif approuvé vers l’unique service interne dont le téléphone a besoin, un produit VPN compatible mobile que l’organisation exploite déjà, ou un poste de travail pris en charge pour le point de terminaison qui n’utilise que SAML. Chaque option apporte sa propre configuration de point de terminaison, son enrôlement d’identité et ses règles d’autorisation, et l’utilisateur ne peut en créer aucune à partir d’un profil téléchargé.

Les outils tiers qui prétendent combler l’écart exigent une revue explicite du support et de la sécurité couvrant MFA, le traitement des réponses, la politique d’appareil et le rythme des mises à jour. Leur existence n’en fait pas un client Android fourni par AWS, et vous ne devriez pas déplacer du matériel d’authentification réutilisable sur un téléphone pour en faire fonctionner un.

Donnez à l’administrateur trois faits plutôt qu’un long fil sur les directives : le mode d’authentification du point de terminaison, la ressource privée que le téléphone doit atteindre et l’échéance. C’est assez pour choisir entre un bureau, un chemin d’accès applicatif et un nouveau produit VPN.

Vérifiez les conditions dans l’ordre avant d’ouvrir un autre ticket : plateforme sur la liste des clients fournis, un outil capable de terminer l’échange dans le navigateur, un point de terminaison réellement configuré pour la fédération et, sous Linux, la plage de ports de bouclage. Le premier élément qui échoue est celui à corriger. Tout ce qui suit est conjecture.