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.
Ce document décrit des conseils afin de dépanner les problèmes d'authentification Web dans un environnement de contrôleur de réseau local sans fil (WLC).
Cisco vous recommande de prendre connaissance des rubriques suivantes :
Contrôle et mise en service des points d'accès sans fil (CAPWAP).
Comment configurer le point d'accès léger (LAP) et le WLC pour un fonctionnement de base.
Connaissance de base de l'authentification Web et de la configuration de l'authentification Web sur les WLC.
Pour plus d'informations sur la façon de configurer l'authentification Web sur les WLC, référez-vous à Exemple de configuration d'authentification Web du contrôleur LAN sans fil.
Les informations de ce document sont basées sur un WLC 5500 qui exécute la version 8.3.121 du microprogramme.
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. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.
Ce document peut également être utilisé avec ce matériel :
Contrôleurs sans fil Cisco 5500
Contrôleurs sans fil Cisco 2500
Contrôleur de réseau local sans fil de la gamme Cisco Airespace 3500
Contrôleur de réseau local sans fil de la gamme Cisco Airespace 4000
Contrôleurs sans fil Cisco Flex 7500
Module de services sans fil Cisco 2 (WiSM2)
L'authentification Web est une fonctionnalité de sécurité de couche 3 qui empêche le contrôleur d'autoriser le trafic IP, à l'exception des paquets DHCP et des paquets DNS (Domain Name System), à partir d'un client particulier jusqu'à ce que ce client ait correctement fourni un nom d'utilisateur et un mot de passe valides, à l'exception du trafic autorisé via une liste de contrôle d'accès (ACL) de pré-authentification. L'authentification Web est la seule stratégie de sécurité qui permet au client d'obtenir une adresse IP avant l'authentification. Il s'agit d'une méthode d'authentification simple qui ne requiert aucun utilitaire demandeur ou client. L'authentification Web peut être faite localement sur un WLC ou via un serveur RADIUS. L'authentification Web est généralement utilisée par les clients qui veulent déployer un réseau d'accès invité.
L'authentification Web démarre lorsque le contrôleur intercepte le premier paquet TCP HTTP (port 80) GET du client. Pour que le navigateur Web du client puisse atteindre ce niveau, il doit d’abord obtenir une adresse IP et traduire l’URL en adresse IP (résolution DNS) pour le navigateur Web. Cela permet au navigateur Web de savoir quelle adresse IP envoyer à HTTP GET.
Lorsque l'authentification Web est configurée sur le WLAN, le contrôleur bloque tout le trafic (jusqu'à ce que le processus d'authentification soit terminé) en provenance du client, à l'exception du trafic DHCP et DNS. Lorsque le client envoie le premier HTTP GET au port TCP 80, le contrôleur redirige le client vers https://192.0.2.1/login.html (s'il s'agit de l'adresse IP virtuelle configurée) pour traitement. Ce processus fait apparaître la page Web de connexion.
Remarque : lorsque vous utilisez un serveur Web externe pour l'authentification Web, les plates-formes WLC ont besoin d'une ACL de pré-authentification pour le serveur Web externe.
Cette section explique en détail le processus de redirection de l'authentification Web.
Vous ouvrez le navigateur Web et tapez une URL, par exemple, http://www.example.com. Le client envoie une demande DNS liée à cet URL afin d'obtenir l'IP pour la destination. WLC transmet la requête DNS au serveur DNS et le serveur DNS répond avec une réponse DNS, qui contient l'adresse IP de la destination www.example.com qui à son tour est transmise aux clients sans fil.
Le client tente alors d'établir une connexion TCP avec l'adresse IP de destination. Il envoie un paquet TCP SYN destiné à l'adresse IP de www.example.com.
Le WLC a configuré des règles pour le client, donc peut agir en tant que serveur mandataire pour www.example.com. Il renvoie un paquet TCP SYN-ACK au client, avec l'adresse IP de www.example.com comme source. Le client renvoie un paquet TCP ACK afin de terminer la connexion TCP en trois étapes et la connexion TCP est entièrement établie.
Le client envoie un paquet HTTP GET destiné à www.example.com. Le WLC intercepte ce paquet et l'envoie pour redirection. La passerelle d'application HTTP prépare un corps en HTML et le renvoie comme réponse au HTTP GET demandé par le client. Ce HTML incite le client à se rendre à l'URL de page Web par défaut du WLC, par exemple : http://<Virtual-Server-IP>/login.html.
Le client ferme la connexion TCP avec l'adresse IP, par exemple www.example.com.
Maintenant, le client veut aller à http://<virtualip>/login.html et donc il essaie d'ouvrir une connexion TCP avec l'adresse IP virtuelle du WLC. Il envoie un paquet SYN TCP pour 192.0.2.1 (qui est notre IP virtuelle ici) au WLC.
Le WLC répond par un TCP SYN-ACK, et le client renvoie un TCP ACK au WLC afin de terminer la liaison.
Le client envoie une requête HTTP GET pour /login.html destinée à 192.0.2.1 afin de demander la page de connexion.
Cette requête est autorisée jusqu'au serveur Web du WLC et le serveur répond avec la page de connexion par défaut. Le client reçoit la page de connexion dans la fenêtre du navigateur où l'utilisateur peut poursuivre et se connecter.
Dans cet exemple, l'adresse IP du client est 192.168.68.94. Le client a résolu l'URL vers le serveur Web auquel il a accédé, 10.1.0.13. Comme vous pouvez le voir, le client a effectué la connexion en trois étapes pour démarrer la connexion TCP, puis a envoyé un paquet HTTP GET qui a commencé par le paquet 96 (00 est le paquet HTTP). Cela n'a pas été déclenché par l'utilisateur, mais par les déclencheurs de détection du portail automatisé du système d'exploitation (comme nous pouvons le deviner à partir de l'URL demandée). Le contrôleur intercepte les paquets et répond avec le code 200. Le paquet code 200 contient une URL de redirection :
<HTML><HEAD>
<TITLE> Web Authentication Redirect</TITLE>
<META http-equiv="Cache-control" content="no-cache">
<META http-equiv="Pragma" content="no-cache">
<META http-equiv="Expires" content="-1">
<META http-equiv="refresh" content="1; URL=https://192.0.2.1/login.html?redirect=http://captive.apple.com/hotspot-detect.html">
</HEAD></HTML>
Il ferme ensuite la connexion TCP via la connexion en trois étapes.
Le client démarre alors la connexion HTTPS à l'URL de redirection qui l'envoie à 192.0.2.1, qui est l'adresse IP virtuelle du contrôleur. Le client doit valider le certificat du serveur ou l'ignorer pour activer le tunnel SSL. Dans ce cas, il s'agit d'un certificat auto-signé, donc le client l'a ignoré. La page Web de connexion est envoyée via ce tunnel SSL. Le paquet 112 commence les transactions.
Vous avez la possibilité de configurer le nom de domaine pour l'adresse IP virtuelle du WLC. Si vous configurez le nom de domaine pour l'adresse IP virtuelle, ce nom de domaine est retourné dans le paquet HTTP OK du contrôleur en réponse au paquet HTTP GET du client. Vous devez ensuite effectuer une résolution DNS pour ce nom de domaine. Une fois qu'il obtient une adresse IP à partir de la résolution DNS, il tente d'ouvrir une session TCP avec cette adresse IP, qui est une adresse IP configurée sur une interface virtuelle du contrôleur.
La page Web est ensuite transmise au client via le tunnel et l'utilisateur renvoie le nom d'utilisateur/mot de passe via le tunnel SSL (Secure Sockets Layer).
L'authentification Web est effectuée par l'une des trois méthodes suivantes :
Utiliser une page Web interne (par défaut).
Utilisez une page de connexion personnalisée.
Utilisez une page de connexion à partir d'un serveur Web externe.
Remarques :
- Le bundle d'authentification Web personnalisé peut contenir jusqu'à 30 caractères pour les noms de fichiers. Assurez-vous qu'aucun nom de fichier dans le bundle ne dépasse 30 caractères.
- À partir de la version 7.0 du WLC, si l'authentification Web est activée sur le WLAN et que vous avez également des règles de liste de contrôle d'accès du processeur, les règles d'authentification Web basées sur le client sont toujours prioritaires tant que le client n'est pas authentifié dans l'état WebAuth_Reqd. Une fois que le client passe à l'état EXÉCUTÉ, les règles ACL du processeur sont appliquées.
- Par conséquent, si les ACL de CPU sont activées dans le WLC, une règle d'autorisation pour l'IP d'interface virtuelle est requise (dans n'importe quelle direction) dans ces conditions :
- Lorsque la liste de contrôle d'accès du processeur n'a pas de règle d'autorisation ALL pour les deux directions.
- Lorsqu'il existe une règle d'autorisation ALL, mais qu'il existe également une règle de refus pour le port 443 ou 80 de priorité supérieure.
- La règle d'autorisation pour l'adresse IP virtuelle doit être pour le protocole TCP et le port 80 si secureweb est désactivé, ou le port 443 si secureweb est activé. Ceci est nécessaire afin de permettre l'accès du client à l'adresse IP de l'interface virtuelle après une authentification réussie lorsque les ACL du CPU sont en place.
Après avoir configuré l'authentification Web et si la fonctionnalité ne fonctionne pas comme prévu, procédez comme suit :
Dans Macs/Linux, ouvrez une fenêtre de terminal et faites une nslookup www.cisco.com et voyez si l'adresse IP revient.
Si vous pensez que le client n'obtient pas de résolution DNS, vous pouvez :
Lorsque vous entrez cette URL, la page Web s'affiche-t-elle ? Si oui, il s’agit très probablement d’un problème DNS. Il peut également s'agir d'un problème de certificat. Le contrôleur, par défaut, utilise un certificat auto-signé et la plupart des navigateurs Web mettent en garde contre leur utilisation.
Vous pouvez télécharger un exemple de script d'authentification Web à partir de Téléchargements de logiciels Cisco. Par exemple, pour les contrôleurs 5508, choisissez Products > Wireless > Wireless LAN Controller > Standalone Controllers > Cisco 5500 Series Wireless LAN Controllers > Cisco 5508 Wireless LAN Controller > Software on Chassis > Wireless Lan Controller Web Authentication Bundle et téléchargez le fichier webauth_bundle.zip.
Ces paramètres sont ajoutés à l'URL lorsque le navigateur Internet de l'utilisateur est redirigé vers la page de connexion personnalisée :
Voici les codes d'état disponibles :
Référez-vous à la section Directives pour l'authentification Web personnalisée de Exemple de configuration de l'authentification Web du contrôleur de réseau local sans fil pour plus d'informations sur la façon de créer une fenêtre d'authentification Web personnalisée.
Remarque : les fichiers volumineux et les fichiers dont le nom est long peuvent entraîner une erreur d'extraction. Il est recommandé que les images soient au format .jpg.
Remarque : accédez au menu Controller > Interfaces à partir de l'interface utilisateur graphique du WLC afin d'attribuer un nom d'hôte DNS à l'interface virtuelle.
Protocol | Port |
---|---|
Trafic HTTP/HTTPS | Port TCP 80/443 |
Trafic de données/contrôle CAPWAP | Port UDP 5247/5246 |
Trafic de données/contrôle LWAPP (antérieur à rel 5.0) | Port UDP 12222/12223 |
paquets EOIP | Protocole IP 97 |
Mobilité | Port UDP 16666 (non sécurisé) Port UDP 16667 (tunnel IPSEC sécurisé) |
netsh ras set tracing eapol enable netsh ras set tracing rastls enable
Afin de désactiver les journaux, exécutez la même commande mais remplacez enable par disable. Pour XP, tous les journaux se trouvent dans C:\Windows\tracing.
debug client <mac_address in format xx:xx:xx:xx:xx:xx> debug dhcp message enable debug aaa all enable debug dot1x aaa enable debug mobility handoff enable
debug pm ssh-appgw enable debug pm ssh-tcp enable debug pm rules enable debug emweb server enable debug pm ssh-engine enable packet <client ip>
Révision | Date de publication | Commentaires |
---|---|---|
3.0 |
20-Mar-2024 |
Recertification |
1.0 |
13-Nov-2008 |
Première publication |