AnyConnect version 4.0 et l'agent de posture NAC ne s'affiche pas dans le guide de dépannage ISE
Table des matières
Introduction
Identity Services Engine (ISE) fournit des fonctionnalités d'affichage qui nécessitent l'utilisation de l'agent NAC (Network Admission Control) (pour Microsoft Windows, Macintosh ou via webagent) ou AnyConnect Version 4.0. Le module de posture ISE d'AnyConnect version 4.0 fonctionne exactement comme l'agent NAC et est donc désigné comme l'agent NAC dans ce document. Le symptôme le plus fréquent d'un échec de posture pour un client est que l'agent NAC ne s'affiche pas car un scénario de travail entraîne toujours l'affichage de la fenêtre de l'agent NAC et l'analyse de votre ordinateur. Ce document vous aide à réduire les nombreuses causes qui peuvent mener à l'échec de la posture, ce qui signifie que l'agent NAC ne s'affiche pas. Il n'est pas exhaustif car les journaux des agents NAC ne peuvent être décodés que par le Centre d'assistance technique Cisco (TAC) et les causes profondes possibles sont nombreuses. Cependant, il vise à clarifier la situation et à identifier le problème plus loin que simplement « l'agent n'apparaît pas avec l'analyse de posture » et vous aidera probablement à résoudre les causes les plus courantes.
Conditions préalables
Exigences
Les scénarios, symptômes et étapes répertoriés dans ce document sont conçus pour vous permettre de résoudre les problèmes une fois la configuration initiale terminée. Pour la configuration initiale, référez-vous à Posture Services sur le Guide de configuration de Cisco ISE sur Cisco.com.
Composants utilisés
Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :
- ISE version 1.2.x
- Agent NAC pour ISE version 4.9.x
- AnyConnect version 4.0
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Méthodologie de dépannage
Pourquoi l'agent apparaît-il ?
L'agent apparaît lorsqu'il détecte un noeud ISE. Si l'agent détecte qu'il ne dispose pas d'un accès réseau complet et qu'il est dans un scénario de redirection de posture, il recherche constamment un noeud ISE.
Il existe un document Cisco.com qui explique les détails du processus de découverte d'agent : Network Admission Control (NAC) Agent Discovery Process for Identity Services Engine. Afin d'éviter la duplication du contenu, ce document ne traite que du point clé.
Lorsqu'un client se connecte, il subit une authentification RADIUS (filtrage MAC ou 802.1x) à la fin de laquelle ISE renvoie la liste de contrôle d'accès (ACL) de redirection et l'URL de redirection vers le périphérique réseau (commutateur, ASA (Adaptive Security Appliance) ou contrôleur sans fil) afin de restreindre le trafic client pour lui permettre uniquement d'obtenir une adresse IP et des résolutions DNS (Domain Name Server). Tout le trafic HTTP(S) provenant du client est redirigé vers une URL unique sur ISE qui se termine par CPP (Client Posture and Provisioning), à l'exception du trafic destiné au portail ISE lui-même. L'agent NAC envoie un paquet GET HTTP régulier à la passerelle par défaut. Si l'agent ne reçoit aucune réponse ou toute autre réponse qu'une redirection CPP, il considère qu'il dispose d'une connectivité complète et ne procède pas à la posture. S'il reçoit une réponse HTTP qui est une redirection vers une URL CPP à la fin d'un noeud ISE spécifique, il poursuit le processus de posture et contacte ce noeud ISE. Il n'apparaît et démarre l'analyse que lorsqu'il reçoit avec succès les détails de position de ce noeud ISE.
L'agent NAC accède également à l'adresse IP de l'hôte de découverte configurée (il ne s'attend pas à ce que plusieurs adresses soient configurées). Il s'attend à être redirigé là aussi afin d'obtenir l'URL de redirection avec l'ID de session. Si l'adresse IP de détection est un noeud ISE, il ne poursuit pas car il attend d'être redirigé pour obtenir l'ID de session correct. L'hôte de découverte n'est donc généralement pas nécessaire, mais peut être utile lorsqu'il est défini comme n'importe quelle adresse IP dans la plage de la liste de contrôle d'accès de redirection afin de déclencher une redirection (comme dans les scénarios VPN, par exemple).
Causes possibles
La redirection n'a pas lieu
C'est de loin la cause la plus fréquente. Afin de valider ou d'invalider, ouvrez un navigateur sur le PC où l'agent ne s'affiche pas et voyez si vous êtes redirigé vers la page de téléchargement de l'agent de posture lorsque vous tapez une URL. Vous pouvez également taper une adresse IP aléatoire telle que http://1.2.3.4 afin d'éviter un problème DNS possible (si une adresse IP redirige mais pas un nom de site Web, vous pouvez regarder DNS).
Si vous êtes redirigé, vous devez collecter les journaux des agents et le bundle d'assistance ISE (avec la posture et le module suisse en mode de débogage) et contacter le TAC Cisco. Cela indique que l'agent découvre un noeud ISE mais que quelque chose échoue pendant le processus d'obtention des données de posture.
Si aucune redirection ne se produit, vous avez votre première cause, qui nécessite toujours une enquête plus approfondie de la cause racine. Un bon début consiste à vérifier la configuration sur le périphérique d'accès réseau (contrôleur de réseau local sans fil (WLC) ou commutateur) et passer à l'élément suivant dans ce document.
Les attributs ne sont pas installés sur le périphérique réseau
Ce problème est un sous-cas du scénario Redirection Does Not Happen. Si la redirection ne se produit pas, la première chose à faire est de vérifier (comme le problème se produit sur un client donné) que le client est correctement placé dans le bon état par le commutateur ou la couche d'accès sans fil.
Voici un exemple de sortie de la commande show access-session interface <numéro d'interface> detail (vous pourriez devoir ajouter detail à la fin sur certaines plates-formes) prise sur le commutateur où le client est connecté. Vous devez vérifier que l'état est « Authz success », que la liste de contrôle d'accès de redirection d'URL pointe correctement vers la liste de contrôle d'accès de redirection prévue et que la redirection d'URL pointe vers le noeud ISE prévu avec CPP à la fin de l'URL. Le champ ACS ACL n'est pas obligatoire, car il indique uniquement si vous avez configuré une liste d'accès téléchargeable sur le profil d'autorisation sur ISE. Il est toutefois important de l'examiner et de vérifier qu'il n'y a pas de conflit avec la liste de contrôle d'accès de redirection (voir les documents sur la configuration de la position en cas de doute).
01-SW3750-access#show access-sess gi1/0/12 det
Interface: GigabitEthernet1/0/12
MAC Address: 000f.b049.5c4b
IP Address: 192.168.33.201
User-Name: 00-0F-B0-49-5C-4B
Status: Authz Success
Domain: DATA
Security Policy: Should Secure
Security Status: Unsecure
Oper host mode: single-host
Oper control dir: both
Authorized By: Authentication Server
Vlan Policy: N/A
ACS ACL: xACSACLx-IP-myDACL-51519b43
URL Redirect ACL: redirect
URL Redirect: https://ISE2.wlaaan.com:8443/guestportal/gateway?
sessionId=C0A82102000002D8489E0E84&action=cpp
Session timeout: N/A
Idle timeout: N/A
Common Session ID: C0A82102000002D8489E0E84
Acct Session ID: 0x000002FA
Handle: 0xF60002D9
Runnable methods list:
Method State
mab Authc Success
Afin de dépanner un WLC qui exécute AireOS, entrez show wireless client detail <mac address> et entrez show wireless client mac-address <mac address> detail afin de dépanner un WLC qui exécute Cisco IOS-XE. Des données similaires s'affichent et vous devez vérifier l'URL de redirection et la liste de contrôle d'accès et si le client est à l'état "POSTURE_REQD" ou similaire (cela varie selon la version du logiciel).
Si les attributs ne sont pas présents, vous devez ouvrir les détails d'authentification dans l'ISE du client que vous avez dépanné (accédez à Opérations > Authentifications) et vérifier dans la section Résultat que les attributs de redirection ont été envoyés. S'ils n'ont pas été envoyés, vous devez revoir la stratégie d'autorisation afin de comprendre pourquoi les attributs n'ont pas été renvoyés pour ce client particulier. L'une des conditions ne correspond probablement pas, il est donc conseillé de les dépanner une par une.
Souvenez-vous que, en ce qui concerne la liste de contrôle d'accès de redirection, Cisco IOS® redirige sur les instructions d'autorisation (de sorte que les adresses IP ISE et DNS doivent être refusées) tandis qu'AireOS sur le WLC redirige sur les instructions de refus (de sorte qu'il est autorisé pour ISE et DNS).
Les attributs sont en place, mais le périphérique réseau ne redirige pas
La cause principale dans ce cas est un problème de configuration. Examinez la configuration du périphérique réseau par rapport au guide de configuration et aux exemples de configuration disponibles sur le site Cisco.com. Si tel est le cas, le problème se produit généralement sur tous les ports ou points d'accès du périphérique réseau. Si ce n'est pas le cas, le problème peut se produire uniquement sur certains ports de commutation ou certains points d'accès. Si c'est le cas, vous devriez comparer la configuration de ceux où le problème se produit par rapport aux ports ou AP où la posture fonctionne bien.
Les points d'accès FlexConnect sont sensibles car ils peuvent chacun avoir une configuration unique et il est facile de faire une erreur dans une liste de contrôle d'accès ou un VLAN dans certains points d'accès et pas d'autres.
Un autre problème courant est que le VLAN client n'a pas d'interface SVI. Ceci s'applique uniquement aux commutateurs et est traité en détail dans la section Redirection du trafic ISE sur le commutateur de la gamme Catalyst 3750. Tout peut sembler bon du point de vue des attributs.
Liste d'accès téléchargeable avec interférence (DACL)
Si, en même temps que les attributs de redirection, vous repoussez une DACL vers le commutateur (ou Airespace-ACL pour un contrôleur sans fil), alors il pourrait bloquer votre redirection. La DACL est appliquée en premier et détermine ce qui est complètement abandonné et ce qui est traité. La liste de contrôle d’accès de redirection est ensuite appliquée et détermine ce qui est redirigé.
Concrètement, cela signifie que la plupart du temps, vous voudrez autoriser tout le trafic HTTP et HTTPS dans votre DACL. Si vous le bloquez, il ne sera pas redirigé car il sera abandonné avant cela. Ce n'est pas un problème de sécurité, car ce trafic sera redirigé principalement sur la liste de contrôle d'accès de redirection après, donc il n'est pas vraiment autorisé sur le réseau ; cependant, vous devez autoriser ces deux types de trafic dans la liste de contrôle d'accès de redirection afin qu'ils aient une chance d'atteindre la liste de contrôle d'accès de redirection juste après.
Version d'agent NAC incorrecte
Il est facile d'oublier que des versions spécifiques d'agent NAC sont validées par rapport à des versions spécifiques d'ISE. De nombreux administrateurs mettent à niveau leur cluster ISE et oublient de télécharger la version de l'agent NAC associé dans la base de données des résultats du provisionnement client.
Si vous utilisez une version d'agent NAC obsolète pour votre code ISE, sachez qu'elle peut fonctionner, mais pas nécessairement. Il n'est donc pas surprenant que certains clients travaillent et d'autres non. Une façon de vérifier est d'aller à la section de téléchargement Cisco.com de votre version ISE et de vérifier quelles versions d'agent NAC sont là. En général, plusieurs versions d'ISE sont prises en charge. Cette page Web rassemble toutes les matrices : Informations de compatibilité Cisco ISE.
Le proxy Web HTTP est utilisé par les clients
Le concept d'un proxy Web HTTP est que les clients ne résolvent pas eux-mêmes les adresses IP DNS des sites Web et ne contactent pas directement les sites Web ; ils envoient simplement leur demande au serveur proxy, qui s'en occupe. Le problème typique avec une configuration habituelle est que le client résout un site web (tel que www.cisco.com) en envoyant directement le HTTP GET pour lui au proxy, qui est intercepté et correctement redirigé vers le portail ISE. Cependant, au lieu d'envoyer ensuite la requête HTTP GET suivante à l'adresse IP du portail ISE, le client continue d'envoyer cette requête au proxy.
Si vous décidez de ne pas rediriger le trafic HTTP destiné au proxy, vos utilisateurs ont un accès direct à l'ensemble d'Internet (puisque tout le trafic passe par le proxy) sans authentification ni posture. La solution consiste à modifier les paramètres du navigateur des clients et à ajouter une exception pour l'adresse IP ISE dans les paramètres du proxy. De cette façon, lorsque le client doit atteindre ISE, il envoie la requête directement à ISE et non au proxy. Cela évite la boucle infinie où le client est constamment redirigé mais ne voit jamais la page de connexion.
Notez que l'agent NAC n'est pas affecté par les paramètres proxy entrés dans le système et qu'il continue à agir normalement. Cela signifie que si vous utilisez un proxy Web, vous ne pouvez pas à la fois faire fonctionner la détection d'agent NAC (parce qu'elle utilise le port 80) et faire en sorte que les utilisateurs installent automatiquement l'agent une fois qu'ils sont redirigés vers la page de position lorsqu'ils naviguent (puisque cela utilise le port proxy et que les commutateurs classiques ne peuvent pas rediriger sur plusieurs ports).
Les hôtes de découverte sont configurés dans l'agent NAC
En particulier après la version 1.2 d'ISE, il est recommandé de ne pas configurer d'hôte de détection sur l'agent NAC à moins que vous ayez une expertise sur ce qu'il fait et ne fait pas. L'agent NAC est censé découvrir le noeud ISE qui a authentifié le périphérique client via la découverte HTTP. Si vous comptez sur des hôtes de détection, l'agent NAC peut contacter un autre noeud ISE que celui qui a authentifié le périphérique et qui ne fonctionne pas. ISE Version 1.2 rejette un agent qui découvre le noeud par le biais du processus hôte de découverte parce qu'il veut que l'agent NAC obtienne l'ID de session de l'URL de redirection, de sorte que cette méthode est déconseillée.
Dans certains cas, vous pouvez configurer un hôte de détection. Ensuite, il doit être configuré avec n'importe quelle adresse IP (même si elle n'existe pas) qui sera redirigée par la liste de contrôle d'accès de redirection, et idéalement, il ne doit pas se trouver dans le même sous-réseau que le client (sinon, le client utilisera le protocole ARP indéfiniment pour lui et n'enverra jamais le paquet de détection HTTP).
L'agent NAC ne s'affiche pas parfois
Lorsque le problème est plus intermittent et que des actions telles que le débranchement/rebranchement de la connectivité câble/Wi-Fi le font fonctionner, il s'agit d'un problème plus subtil. Cela peut être un problème avec les ID de session RADIUS où l'ID de session est supprimé sur l'ISE par la comptabilité RADIUS (désactivez la comptabilité pour voir si cela change quelque chose).
Si vous utilisez ISE Version1.2, une autre possibilité est que le client envoie de nombreux paquets HTTP de sorte qu'aucun ne vienne d'un navigateur ou de l'agent NAC. ISE version 1.2 analyse le champ d'agent utilisateur dans les paquets HTTP pour voir s'il provient de l'agent NAC ou d'un navigateur, mais de nombreuses autres applications envoient du trafic HTTP avec un champ d'agent utilisateur et ne mentionnent aucun système d'exploitation ni aucune information utile. ISE version 1.2 envoie ensuite une modification d'autorisation pour déconnecter le client. ISE Version 1.3 n'est pas affecté par ce problème, car il fonctionne d'une manière différente. La solution consiste soit à effectuer une mise à niveau vers la version 1.3, soit à autoriser toutes les applications détectées dans la liste de contrôle d’accès de redirection afin qu’elles ne soient pas redirigées vers ISE.
Problème inverse : l'agent apparaît plusieurs fois
Le problème inverse peut se produire lorsque l'agent apparaît, effectue l'analyse de la position, valide le client, puis redémarre peu de temps après au lieu d'autoriser la connectivité réseau et de rester silencieux. Cela se produit parce que, même après une posture réussie, le trafic HTTP est toujours redirigé vers le portail CPP sur ISE. Il est conseillé de passer ensuite par la stratégie d'autorisation ISE et de vérifier que vous disposez d'une règle qui envoie un accès autorisé (ou une règle similaire avec des ACL et des VLAN possibles) lorsqu'elle voit un client conforme et NON une redirection CPP à nouveau.
Informations connexes
Historique de révision
| Révision | Date de publication | Commentaires |
|---|---|---|
1.0 |
30-Jan-2015 |
Première publication |
CommentairesContacter Cisco
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)