Alias de groupe ASA ou URL de groupe : comment le profil est sélectionné

Un profil de connexion ne régit une session qu'après que l'ASA l'a sélectionné. Cette phrase est tout le modèle de diagnostic pour un portail ancien sans client. Un profil inutilisé peut contenir des règles d'accès parfaites et ne s'appliquer à personne. Suivez le point d'entrée de connexion avant de modifier la moindre politique.

Les distinctions ci-dessous suivent la documentation 9.16 ; le SSL VPN sans client a été supprimé en 9.17(1) et au-delà.

L'alias est une entrée de liste, pas une URL

group-alias fournit un libellé que l'utilisateur choisit dans la liste des groupes sur la page de connexion. Afficher cette liste est un réglage distinct, tunnel-group-list enable. L'alias n'est qu'un nom de sélection et rien de plus. Configurer un alias nommé staff ne crée pas d'URL /staff qui sélectionnerait le profil.

On attend de l'alias qu'il fasse double emploi parce que, depuis le navigateur, la liste et l'URL ressemblent au même choix.

Ce que group-url fait réellement correspondre

group-url lie une URL entrante à un profil de connexion. Lorsque cette URL activée correspond, l'ASA sélectionne le profil sans demander à l'utilisateur de choisir dans la liste. L'URL doit être l'URL complète voulue, dans la syntaxe prise en charge par votre version. Son enregistrement DNS et son certificat doivent concorder avec ce que les utilisateurs saisissent, sinon la correspondance n'a jamais lieu.

Un suffixe d'URL copié ne prouve rien sur la configuration. Vérifiez le profil, pas la barre d'adresse.

Suivez la sélection jusqu'à la politique qui s'exécute

Une fois un groupe de tunnel sélectionné, l'équipement résout la méthode d'authentification et la politique de groupe par défaut qui y est rattachée. Ensuite, les attributs propres à l'utilisateur, les valeurs renvoyées par l'authentification et l'autorisation dynamique peuvent remplacer des parties de cette base. Inspectez ce que la session a réellement reçu. Lire la politique nommée seule vous donne la base, pas le résultat.

L'écart entre les deux est à l'origine de la plupart des signalements « la règle est correcte mais l'accès est faux ».

L'héritage n'est pas l'isolement

Les attributs que vous laissez non spécifiés peuvent hériter de la politique de groupe par défaut. Une nouvelle politique nommée n'est donc pas isolée des valeurs par défaut partagées, et modifier celles-ci atteint chaque profil qui en hérite. Comparez l'accès effectif aux ressources, les paramètres DNS et les restrictions de session par profil. Faites-le avant de changer quoi que ce soit de partagé.

Gardez aussi l'application de l'accès séparée de la sélection.

Pour une session sans client, le filtre applicable est l'ACL webtype. Un filtre VPN pour client tunnelé ne le remplace pas simplement parce que les deux se trouvent près du même bloc de politique dans la configuration.

Tranchez le cas sans correspondance, puis testez chaque chemin

Déterminez ce qui doit se produire sur l'URL générique du portail et sur les autres points d'entrée sans correspondance. Regardez le vrai chemin du profil par défaut et son autorisation au lieu de modifier une valeur par défaut partagée pour qu'un seul compte de test passe. Ouvrez ensuite trois sessions neuves : l'URL explicite, l'entrée de liste activée et le point d'entrée générique. Notez le profil sélectionné et la politique effective pour chacune.

Réutiliser un onglet de navigateur d'une connexion antérieure fausse la comparaison, car cette session est déjà liée à un profil.

Ce relevé transforme « le portail s'ouvre » en une table de correspondance connexion-politique que vous pouvez auditer plus tard, et c'est la seule réponse durable quand un profil semble correct et ne régit personne.