Bonjour,
Il y a un très bon document décrivant la configuration GUEST wireless intégrée avec ISE ici : "ISE Guest Access Prescriptive Deployment Guide" https://community.cisco.com/t5/security-documents/ise-guest-access-prescriptive-deployment-guide/ta-p/3640475#toc-hId--522975287
Si tu utilises un controleur Airespace, il existe une option de configuration d'un SSID ouvert avec une authentification Layer3 de type "Web policy" : c'était la solution utilisée jusqu'à ce que ISE intègre toute la gestion du portail. Est ce que ce serait la configuration actuelle de ton SSID ? Dans ce cas, l'utilisateur est bien redirigé vers le portail d'ISE, il rentre sur son navigateur les données de son compte invité, mais ensuite il reste bloqué sur la page de succès.
Ce qui est recommandé aujourd'hui, c'est de déléguer complètement la gestion du processus d'authentification web à ISE en configurant le SSID avec un mode de sécurité type "Layer2" : None + Mac Filtering + AAA (ISE), et sans rien en Layer3.
Le mode de fonctionnement est le suivant :
1/ Un nouveau client Wifi apparait avec une nouvelle MAC@, le controleur envoie la demande en Radius à ISE en filtrant la MAC@
2/ Dans un premier temps, ISE ne connait pas la MAC@. L'authorization policy retournée au controleur est celle par "Défaut" (en bas de la liste des policies), avec un "autorisation template" qui force la redirection vers le portail ISE. En plus de la redirection, il faut spécifier une ACL Airespace qui laisse passer les protocoles minimum (DHCP, DNS, HTTPS vers ISE sur le port du portail guest ISE).
3/ L'utilisateur ouvre son navigateur (ou le client intégré de l'OS force l'ouverture automatiquement), il est redirigé vers le portail.
4/ Il rentre son identifiant ; ISE vérifie la validité (ou alors, on passe par l'étape de création de compte dans le flux du portail)
5/ ISE a vérifié la validité du compte, il ré-évalue la policy initiale pour la MAC@ de l'utilisateur qui vient d'être placée dans un groupe des MAC@ Guests valides. De ce fait, il doit y avoir dans la liste des policies une entrée qui vérifie que si la MAC@ appartient au groupe des guests valides, alors on retourne un "autorisation template" avec l'ACL qui laisse passer le trafic vers Internet.
En général, cette règle est faite avec une authentification qui se base sur une condition "Wireless_MAB", et ensuite pour l'autorisation, on teste que l'identity group inclut le groupe GuestEndPoints qui a été configuré dans le portail Guest (celui par défaut ou un rajouté spécifiquement).
Tant que la MAC@ de l'équipement n'est pas présente dans le groupe GuestEndPoints, c'est la policy par défaut qui est appliquée (et le controleur reçoit l'ordre par radius de rediriger le traffic web vers ISE) ; Dès que le portail valide l'identifiant de l'utilisateur, la MAC@ est placée dans le groupe GuestEndPoints, et le portail force la ré-évaluation de la policy. Au deuxième passage dans la policy, la MAC@ est connue, et la règle qui teste l'appartenance au groupe GuestEndPoints renvoie un accept, ainsi que l'ACL qui donne accès à Internet sur le controleur.
Qu'est ce qui peut bloquer dans ce processus ?
1/ Comme indiqué au début, on utilise un filtrage L3 sur le controleur. SI ISE n'a pas de session radius établie, il n'y a pas de réaction possible une fois que le portail a validé le compte.
2/ Le SSID est configuré en filtrage L2, avec Radius : il y a une session Radius ouverte dans ISE, et dès que l'utilisateur est redirigé vers le portail, on doit voir dans ISE (Live sessions) une entrée pour la MAC@ avec la policy par défaut qui est appliquée. S'il manque la partie AAA sur le controleur, pas de session, pas de réaction d'ISE possible non plus.
3/ Le portail doit etre configuré pour répondre au controleur en Radius (CoA). Sinon, pas de réponse non plus.
4/ Si toutes ces conditions sont remplies, on doit retrouver la MAC@ dans le groupe GuestEndPoints une fois l'utilisateur Guest authentifié sur le portail. Si ce n'est pas le cas, il y a un problème de configuration du portail Guest.
5/ Dans les "Live logs", on doit voir un deuxième évènement au moment ou l'utilisateur fournit son identifiant : c'est la policy qui est ré-évaluée : dans ce cas, on doit vérifier la condition sur le groupe GuestEndPoints, et sélectionner l'autorisation d'accès. Si on retombe dans la policy par défaut, c'est cette règle qui est mal construite.
6/ ISE ré-évalue correctement la policy, retourne la bonne autorisation, mais le controleur ne réagit pas correctement : c'est un problème sur le controleur. Le SSID n'est pas configuré (Advanced) avec l'option AAA Override, et NAC State ISE. Ou alors, il manque l'ACL permit ip any any, ou le nom est faux (on peut voir l'état du client dans le monitoring ...
Normalement, il doit y avoir un souci parmi ces points ... et sinon, il y a toujours le TAC pour aider.
Bon courage,
Jean-Francois
