Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
Cet article fait partie d'une série d'articles qui expliquent comment dépanner systématiquement le chemin de données sur les systèmes Firepower pour déterminer si les composants de Firepower peuvent affecter le trafic. Reportez-vous à l'article Présentation pour obtenir des informations sur l'architecture des plates-formes Firepower et des liens vers les autres articles de dépannage du chemin de données.
Cet article couvre la sixième étape du dépannage du chemin de données Firepower, la fonctionnalité d'authentification active.
Lorsque vous essayez de déterminer si un problème est causé par l'identité, il est important de comprendre quel trafic cette fonctionnalité peut avoir un impact. Les seules fonctionnalités de l'identité qui peuvent provoquer des interruptions de trafic sont celles liées à l'authentification active. L'authentification passive ne peut pas entraîner l'abandon inattendu du trafic. Il est important de comprendre que seul le trafic HTTP(S) est affecté par l'authentification active. Si un autre trafic est affecté parce que l'identité ne fonctionne pas, cela est plus probable car la stratégie utilise des utilisateurs/groupes pour autoriser/bloquer le trafic, de sorte que lorsque la fonctionnalité d'identité ne peut pas identifier les utilisateurs, des choses inattendues peuvent se produire, mais cela dépend de la stratégie de contrôle d'accès du périphérique et de la stratégie d'identité. Le dépannage de cette section passe en revue les problèmes liés à l'authentification active uniquement.
Les fonctions d'authentification actives impliquent que le périphérique Firepower exécute un serveur HTTP. Lorsque le trafic correspond à une règle de stratégie d'identité qui contient une action d'authentification active, Firepower envoie un paquet 307 (redirection temporaire) dans la session, afin de rediriger les clients vers son serveur portail captif.
Il existe actuellement cinq types différents d'authentification active. Deux redirigent vers un nom d'hôte qui se compose du nom d'hôte du capteur et du domaine principal Active Directory lié au domaine, et trois redirigent vers l'adresse IP de l'interface sur le périphérique Firepower qui effectue la redirection captive du portail.
Si un problème survient dans le processus de redirection, la session peut se rompre car le site n'est pas disponible. C'est pourquoi il est important de comprendre comment la redirection fonctionne dans la configuration en cours. Le tableau ci-dessous vous aide à comprendre cet aspect de configuration.
Si l'authentification active redirige vers le nom d'hôte, elle redirige les clients vers ciscoasa.my-ad.domain : <port_used_for_captive_portal>
La collecte de captures de paquets est la partie la plus importante du dépannage des problèmes d'authentification active. Les captures de paquets ont lieu sur deux interfaces :
Les deux captures sont initiées, le trafic intéressant est exécuté via le périphérique Firepower, puis les captures sont arrêtées.
Notez que le fichier de capture de paquets de l'interface interne, « ins_ntlm », est copié dans le répertoire /mnt/disk0. Il peut ensuite être copié dans le répertoire /var/common afin d'être téléchargé hors du périphérique (/ngfw/var/common sur toutes les plates-formes FTD) :
> expert
# copy /mnt/disk0/<pcap_file> /var/common/
Les fichiers de capture de paquets peuvent ensuite être copiés hors du périphérique Firepower à partir de l'invite > en suivant les instructions de cet article.
Vous pouvez également choisir Firepower Management Center (FMC) dans Firepower version 6.2.0 et ultérieure. Pour accéder à cet utilitaire sur le FMC, accédez à Périphériques > Gestion des périphériques. Cliquez ensuite sur le bouton en regard du périphérique en question, puis Dépannage avancé > Téléchargement de fichier. Vous pouvez ensuite entrer le nom d'un fichier en question et cliquer sur Télécharger.
L'analyse PCAP dans Wireshark peut être effectuée pour aider à identifier le problème dans les opérations d'authentification actives. Comme un port non standard est utilisé dans la configuration du portail captif (885 par défaut), Wireshark doit être configuré pour décoder le trafic comme SSL.
La capture d'interface interne et la capture d'interface de tunnel doivent être comparées. La meilleure façon d'identifier la session en question dans les deux fichiers PCAP est de localiser le port source unique car les adresses IP sont différentes.
Dans l'exemple ci-dessus, notez que le paquet Hello du serveur est manquant dans la capture d'interface interne. Cela signifie qu'il n'a jamais été rendu au client. Il est possible que le paquet ait été abandonné par snort, ou peut-être en raison d'un défaut ou d'une mauvaise configuration.
Note: Snort inspecte son propre trafic de portail captif afin d'empêcher toute exploitation HTTP.
Si le problème ne se trouve pas dans la pile SSL, il peut être utile de déchiffrer les données dans le fichier PCAP afin de voir le flux HTTP. Il existe deux méthodes pour y parvenir.
Attention : Si la méthode 2 est utilisée, ne fournissez pas votre clé privée au centre d'assistance technique Cisco (TAC). Un certificat et une clé de test temporaires peuvent toutefois être utilisés. Un utilisateur de test doit également être utilisé dans le test.
Dans l'exemple ci-dessous, un fichier PCAP a été décrypté. Il montre que NTLM est utilisé comme méthode d'authentification active.
Une fois l'autorisation NTLM effectuée, le client est redirigé vers la session d'origine, afin d'atteindre sa destination prévue, à savoir http://www.cisco.com.
Lorsqu'elle est utilisée dans une stratégie d'identité, l'authentification active a la possibilité d'abandonner le trafic autorisé (trafic HTTP(s) uniquement), en cas de problème dans le processus de redirection. Une étape de réduction rapide consiste à désactiver toute règle dans la stratégie d'identité avec l'action d'Authentification active.
Assurez-vous également que l'option Utiliser l'authentification active si l'authentification passive ne permet pas d'identifier l'utilisateur n'est pas activée pour toutes les règles avec l'action 'Authentification passive'.
Données | Instructions |
Dépannage du fichier à partir du Centre de gestion de Firepower (FMC) | https://www.cisco.com/c/en/us/support/docs/security/sourcefire-defense-center/117663-technote-SourceFire-00.html |
Dépannage du fichier à partir du périphérique Firepower inspectant le trafic | https://www.cisco.com/c/en/us/support/docs/security/sourcefire-defense-center/117663-technote-SourceFire-00.html |
Captures de paquets de session complète | Reportez-vous à cet article pour obtenir des instructions. |
S'il a été déterminé que le composant Authentification active n'est pas la cause du problème, l'étape suivante consiste à dépanner la fonctionnalité Stratégie d'intrusion.
Cliquez ici pour passer à l'article suivant.