Authentification Web sur le contrôleur WLAN

Introduction

Ce document explique les processus d'authentification Web sur un contrôleur de réseau local sans fil (WLC). 

Conditions préalables

Conditions requises

Cisco vous recommande d'avoir une connaissance de base de la configuration du WLC.

Components Used

Les informations de ce document sont basées sur tous les modèles matériels WLC.

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. 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.

Processus internes d'authentification Web

Position de l'authentification Web en tant que fonction de sécurité

L'authentification Web (WebAuth) est la sécurité de couche 3. Il permet une sécurité conviviale qui fonctionne sur n'importe quelle station qui exécute un navigateur. Il peut également être combiné avec n'importe quelle sécurité de clé prépartagée (PSK) (stratégie de sécurité de couche 2). Bien que la combinaison de WebAuth et de PSK réduise considérablement la partie conviviale et ne soit pas utilisée souvent, elle a l'avantage de chiffrer le trafic client. WebAuth est une méthode d'authentification sans chiffrement.

WebAuth ne peut pas être configuré avec 802.1x/RADIUS (Remote Authentication Dial-In User Service) tant que le logiciel WLC version 7.4 n'est pas installé où il peut être configuré en même temps. Cependant, sachez que les clients doivent passer par dot1x et l'authentification Web. Il n'est pas destiné aux invités, mais à l'ajout d'un portail Web pour les employés (qui utilisent 802.1x). Il n'existe pas de SSID (Service Set Identifier) tout-en-un pour dot1x pour les employés ou de portail Web pour les invités.

Fonctionnement de WebAuth

Le processus d'authentification 802.11 est ouvert, vous pouvez donc vous authentifier et vous associer sans problème. Après cela, vous êtes associé, mais pas dans l'état EXÉCUTION WLC. Lorsque l'authentification Web est activée, vous êtes maintenu dans WEBAUTH_REQD où vous ne pouvez pas accéder à une ressource réseau (aucune requête ping, etc.). Vous devez recevoir une adresse IP DHCP avec l'adresse du serveur DNS dans les options.

Vous devez taper une URL valide dans votre navigateur. Le client résout l'URL via le protocole DNS. Le client envoie ensuite sa requête HTTP à l'adresse IP du site Web. Le WLC intercepte cette demande et renvoie la page de connexion webauth, qui fausse l'adresse IP du site Web. Dans le cas d'une authentification Web externe, le WLC répond avec une réponse HTTP qui inclut votre adresse IP de site Web et indique que la page a été déplacée. La page a été déplacée vers le serveur Web externe utilisé par le WLC. Lorsque vous êtes authentifié, vous accédez à toutes les ressources réseau et êtes redirigé vers l'URL initialement demandée, par défaut (sauf si une redirection forcée a été configurée sur le WLC). En résumé, le WLC permet au client de résoudre le DNS et d'obtenir automatiquement une adresse IP à l'état WEBAUTH_REQD.

Astuce : Si vous voulez que le WLC regarde un autre port au lieu du port 80, vous pouvez utiliser config network web-auth-port <numéro de port> pour créer également une redirection sur ce port. Par exemple, l'interface Web Access Control Server (ACS), qui se trouve sur le port 2002 ou d'autres applications similaires.

Remarque à propos de la redirection HTTPS : Par défaut et dans les versions 7.x et antérieures, le WLC n'a pas redirigé le trafic HTTPS. Cela signifie que si vous ouvrez votre navigateur et tapez une adresse HTTPS, rien ne se passe. Vous devez taper une adresse HTTP afin d'être redirigé vers la page de connexion qui a été servie dans HTTPS.

Dans les versions 8.0 et ultérieures, vous pouvez activer la redirection du trafic HTTPS avec la commande CLI config network web-auth https-redirect enable.

Sachez que cela consomme des ressources pour le WLC au cas où de nombreuses requêtes HTTPS seraient envoyées. Il est conseillé de ne pas utiliser cette fonctionnalité avant la version 8.7 du WLC où l'évolutivité de cette fonctionnalité a été améliorée. Notez également qu'un avertissement de certificat est inévitable dans ce cas. En effet, si votre client demande une URL (telle que https://www.cisco.com), le WLC présente toujours son propre certificat émis pour l'adresse IP de l'interface virtuelle. Cela ne correspond évidemment jamais à l'adresse URL/IP demandée par le client et le certificat ne sera pas approuvé à moins que le client ne force l'exception dans son navigateur.

Débit de performance indicatif de la version du logiciel WLC avant 8.7 mesuré :

Webauth	Taux atteint
3 URL - HTTP	140/seconde
1ère URL - HTTP 2e et 3e URL - HTTPS	20/seconde
3 URL - HTTPS (déploiement important)	< 1/seconde
3 URL - HTTPS (maximum de 100 clients)	10/seconde

Dans ce tableau de performances, les 3 URL sont appelées :

• URL d'origine entrée par l'utilisateur final (le site Web auquel l'utilisateur souhaite accéder)
• URL vers laquelle le WLC redirige le navigateur
• Envoi final des informations d'identification

Le tableau des performances indique les performances du WLC dans le cas où les 3 URL sont HTTP, dans le cas où les 3 URL sont HTTPS, ou si le client passe de HTTP à HTTPS (scénario le plus courant).

Comment faire fonctionner une WebAuth interne (locale) avec une page interne

Si vous devez configurer un WLAN avec une interface dynamique opérationnelle, les clients doivent également recevoir une adresse IP de serveur DNS via DHCP. Avant de définir un webauth, vous devez tester le bon fonctionnement de votre WLAN, que vous pouvez résoudre des requêtes DNS (nslookup) et que vous pouvez parcourir des pages Web. Ensuite, vous pouvez définir l'authentification Web en tant que fonctions de sécurité de couche 3. Vous pouvez créer vos utilisateurs dans la base de données locale ou sur un serveur RADIUS externe, par exemple. Reportez-vous au document Exemple de configuration de l'authentification Web du contrôleur de réseau local sans fil.

Comment configurer une authentification Web locale personnalisée avec une page personnalisée

L'authentification Web personnalisée peut être configurée avec redirectUrl à partir de l'onglet Sécurité. Cela force une redirection vers une page Web spécifique que vous entrez. Lorsque l'utilisateur est authentifié, il remplace l'URL d'origine demandée par le client et affiche la page pour laquelle la redirection a été affectée.

La fonction personnalisée vous permet d'utiliser une page HTML personnalisée au lieu de la page de connexion par défaut. Téléchargez votre bundle de fichiers html et image sur le contrôleur. Dans la page de téléchargement, recherchez webauth bundle au format tar. Habituellement, PicoZip crée des goudrons qui fonctionnent de manière compatible avec le WLC. Pour obtenir un exemple de bundle WebAuth, reportez-vous à la page Download Software pour les bundles WebAuth du contrôleur sans fil. Veillez à sélectionner la version appropriée pour votre WLC. Il est recommandé de personnaliser un bundle existant ; ne créez pas un bundle à partir de zéro.

Il y a certaines limitations avec webauth personnalisé qui varient avec les versions et les bogues. Les éléments à surveiller sont les suivants :

• la taille du fichier .tar (pas plus de 5 Mo)
  
  
• Le nombre de fichiers dans le .tar
  
  
• La longueur du nom de fichier des fichiers (ne doit pas dépasser 30 caractères)
  
  

Si votre package client ne fonctionne pas, essayez avec un package personnalisé simple. Ajoutez ensuite des fichiers et de la complexité un par un pour atteindre le package que le client a essayé d'utiliser. Cela devrait vous aider à identifier le problème. Pour obtenir un exemple de configuration d'une page personnalisée, reportez-vous à Création d'une page de connexion d'authentification Web personnalisée, une section du Guide de configuration du contrôleur de réseau local sans fil Cisco, version 7.6.

Remplacer la technique de configuration globale

Pour chaque WLAN, vous devez configurer avec la commande override global config et définir un type WebAuth pour chaque WLAN. Cela signifie que vous pouvez disposer d'un WebAuth interne/par défaut avec un WebAuth interne/par défaut personnalisé pour un autre WLAN. Cela vous permet également de configurer différentes pages personnalisées pour chaque WLAN. Vous devez combiner toutes vos pages dans le même bundle et les télécharger sur le WLC. Vous pouvez ensuite définir votre page personnalisée à l'aide de la commande override global config sur chaque WLAN et sélectionner le fichier correspondant à la page de connexion de tous les fichiers du bundle. Vous pouvez choisir une page de connexion différente dans le bundle pour chaque WLAN.

Problème de redirection

Il y a une variable dans le bundle HTML qui permet la redirection. N'y mettez pas votre URL de redirection forcée. Pour tout problème de redirection dans WebAuth personnalisé, Cisco recommande de vérifier le bundle. Si vous entrez une URL de redirection avec += dans l'interface graphique du WLC, cela peut remplacer ou ajouter à l'URL définie dans le bundle. Par exemple, dans l'interface utilisateur graphique du WLC, le champ redirectURL est défini sur www.cisco.com ; cependant, dans l'offre groupée, on peut lire : redirectURL+= 'www.google.com'. Le += redirige les utilisateurs vers www.cisco.comwww.google.com, qui est une URL non valide.

Comment faire fonctionner une authentification Web externe (locale) avec une page externe

Comme expliqué brièvement, l'utilisation d'un serveur WebAuth externe n'est qu'un référentiel externe pour la page de connexion. Les informations d'identification de l'utilisateur sont toujours authentifiées par le WLC. Le serveur Web externe vous permet uniquement d'utiliser une page de connexion spéciale ou différente. Voici les étapes effectuées pour un WebAuth externe :

1. Le client (utilisateur final) ouvre un navigateur Web et entre une URL.
   
   
2. Si le client n'est pas authentifié et que l'authentification Web externe est utilisée, le WLC redirige l'utilisateur vers l'URL du serveur Web externe. En d'autres termes, le WLC envoie une redirection HTTP au client avec l'adresse IP usurpée du site Web et pointe vers l'adresse IP du serveur externe. L'URL de connexion d'authentification Web externe est ajoutée avec des paramètres tels que AP_Mac_Address, client_url (www.website.com) et action_URL dont le client a besoin pour contacter le serveur Web du commutateur.
   
   
3. L'URL du serveur Web externe envoie l'utilisateur à une page de connexion. Ensuite, l'utilisateur peut utiliser une liste de contrôle d'accès pré-authentification (ACL) afin d'accéder au serveur. La liste de contrôle d'accès est nécessaire pour tous les modèles de WLC, à l'exception de la gamme 4400 et de Wism1.
   
   
4. La page de connexion prend les informations d'identification de l'utilisateur et renvoie la demande à l'action_URL, telle que http://192.0.2.1/login.html, du serveur Web du WLC. Ceci est fourni comme paramètre d'entrée à l'URL de redirection du client, où 192.0.2.1 est l'adresse de l'interface virtuelle sur le commutateur.
   
   
5. Le serveur Web du WLC envoie le nom d'utilisateur et le mot de passe pour l'authentification.
   
   
6. Le WLC initie la demande de serveur RADIUS ou utilise la base de données locale sur le WLC, puis authentifie l'utilisateur.
   
   
7. Si l'authentification réussit, le serveur Web du WLC transfère l'utilisateur à l'URL de redirection configurée ou à l'URL entrée par le client.
   
   
8. Si l'authentification échoue, le serveur Web du WLC redirige l'utilisateur vers l'URL de connexion du client.

Remarque : nous utilisons 192.0.2.1 comme exemple d'adresse IP virtuelle dans ce document. La plage 192.0.2.x est recommandée pour l'adresse ip virtuelle car elle n'est pas routable. Une documentation plus ancienne peut faire référence à « 1.1.1.x » ou qui est peut-être encore ce qui est configuré dans votre WLC comme cela était le paramètre par défaut. Cependant, notez que cette adresse IP est maintenant une adresse IP routable valide et que le sous-réseau 192.0.2.x est donc conseillé à la place.

Remarque : Si les points d'accès (AP) sont en mode FlexConnect, une liste de contrôle d'accès prédéfinie n'est pas pertinente. Les listes de contrôle d’accès flexibles peuvent être utilisées pour autoriser l’accès au serveur Web pour les clients qui n’ont pas été authentifiés. Référez-vous à Exemple de configuration de l'authentification Web externe avec des contrôleurs de réseau local sans fil.

Passage Web

Il s'agit d'une variante de l'authentification Web interne. Il affiche une page avec un avertissement ou une instruction d'alerte, mais n'invite pas les informations d'identification. L'utilisateur doit cliquer sur ok. Vous pouvez activer l'entrée d'e-mail et l'utilisateur peut entrer son adresse e-mail, qui devient son nom d'utilisateur. Lorsque l'utilisateur est connecté, vérifiez la liste de vos clients actifs ; cet utilisateur est répertorié avec l'adresse e-mail qu'il a entrée en tant que nom d'utilisateur. Pour plus d'informations, référez-vous à l'exemple de configuration du passage Web du contrôleur LAN sans fil 5760/3850.

Redirection Web conditionnelle

Si vous activez une redirection Web conditionnelle, l'utilisateur est redirigé conditionnellement vers une page Web particulière après que l'authentification 802.1x a réussi. Vous pouvez spécifier la page de redirection et les conditions sous lesquelles celle-ci se produit sur votre serveur RADIUS. Les conditions peuvent inclure le mot de passe de l'utilisateur lorsqu'il atteint la date d'expiration ou lorsque l'utilisateur doit payer une facture pour une utilisation/accès continue. Si le serveur RADIUS retourne l'url-redirect de paire AV Cisco, l'utilisateur est redirigé vers l'URL spécifiée lorsqu'il ouvre un navigateur. Si le serveur renvoie également l'url-redirect-acl de paire AV Cisco, alors la liste de contrôle d'accès spécifiée est installée comme liste de contrôle d'accès pré-authentification pour ce client. Le client n’est pas considéré comme entièrement autorisé à ce stade et ne peut transmettre que le trafic autorisé par la liste de contrôle d’accès pré-authentification. Une fois que le client a terminé une opération particulière à l'URL spécifiée (par exemple, un changement de mot de passe ou un paiement de factures), le client doit se réauthentifier. Lorsque le serveur RADIUS ne retourne pas d'url-redirect, le client est considéré comme entièrement autorisé et autorisé à transmettre le trafic.

Remarque : La fonction de redirection Web conditionnelle est disponible uniquement pour les WLAN configurés pour la sécurité de couche 2 802.1x ou WPA+WPA2.

Après avoir configuré le serveur RADIUS, vous pouvez configurer la redirection Web conditionnelle sur le contrôleur à l'aide de l'interface utilisateur graphique ou de l'interface de ligne de commande du contrôleur. Reportez-vous aux guides pas à pas suivants : Configuration de Web Redirect (GUI) et Configuration de Web Redirect (CLI).

Redirection Web de la page de démarrage

Si vous activez la redirection Web de la page de démarrage, l'utilisateur est redirigé vers une page Web particulière après que l'authentification 802.1x a réussi. Après la redirection, l'utilisateur a un accès complet au réseau. Vous pouvez spécifier la page de redirection sur votre serveur RADIUS. Si le serveur RADIUS retourne l'url-redirect de paire AV Cisco, l'utilisateur est redirigé vers l'URL spécifiée lorsqu'il ouvre un navigateur. Le client est considéré comme entièrement autorisé à ce stade et est autorisé à passer le trafic, même si le serveur RADIUS ne retourne pas d'url-redirect.

Remarque : La fonction de redirection Web de la page de démarrage est disponible uniquement pour les réseaux locaux sans fil configurés pour la sécurité de couche 2 802.1x ou WPA+WPA2.

Après avoir configuré le serveur RADIUS, vous pouvez configurer la redirection Web de la page de démarrage sur le contrôleur à l'aide de l'interface graphique du contrôleur ou de l'interface de ligne de commande.

Échec de WebAuth sur le filtre MAC

Pour cela, vous devez configurer les filtres MAC dans le menu de sécurité de couche 2. Si les utilisateurs sont validés avec succès avec leurs adresses MAC, ils passent directement à l'état d'exécution. Si ce n'est pas le cas, ils passent à l'état WEBAUTH_REQD et l'authentification Web normale se produit.

Remarque: Ceci n'est pas pris en charge avec le passthrough Web. Pour plus d'informations, suivez l'activité sur la demande d'amélioration CSCtw73512.

Authentification Web centrale

L'authentification Web centrale fait référence à un scénario où le WLC n'héberge plus de services. La différence réside dans le fait que le client est directement envoyé au portail Web ISE et ne passe pas par 192.0.2.1 sur le WLC. La page de connexion et l'ensemble du portail sont externalisés.

L'authentification Web centrale a lieu lorsque le contrôle d'admission au réseau RADIUS (NAC) est activé dans les paramètres avancés des filtres WLAN et MAC activés.

Le concept global est que le WLC envoie une authentification RADIUS (généralement pour le filtre MAC) à ISE, qui répond avec la paire redirect-url attribute value (AV). L'utilisateur est alors placé dans l'état POSTURE_REQD jusqu'à ce que ISE donne l'autorisation avec une demande de changement d'autorisation (CoA). Le même scénario se produit dans Posture ou Central WebAuth. Le WebAuth central n'est pas compatible avec WPA-Enterprise/802.1x, car le portail invité ne peut pas retourner les clés de session pour le chiffrement comme il le fait avec le protocole EAP (Extensible Authentication Protocol).

Authentification utilisateur externe (RADIUS)

Ceci n'est valide que pour Local WebAuth lorsque WLC gère les informations d'identification ou lorsqu'une stratégie Web de couche 3 est activée. Vous pouvez ensuite authentifier les utilisateurs localement sur le WLC ou en externe via RADIUS.

Il existe un ordre dans lequel le WLC vérifie les informations d'identification de l'utilisateur.

1. Dans tous les cas, il regarde d'abord dans sa propre base de données.

2. S'il n'y trouve pas les utilisateurs, il se dirige vers le serveur RADIUS configuré dans le WLAN invité (s'il en existe un configuré).

3. Il vérifie ensuite la liste des serveurs RADIUS globaux par rapport aux serveurs RADIUS sur lesquels l'utilisateur réseau est coché.

Ce troisième point est très important et répond à la question de beaucoup de ceux qui ne configurent pas RADIUS pour ce WLAN, mais remarquez qu'il vérifie toujours contre RADIUS lorsque l'utilisateur n'est pas trouvé sur le contrôleur. Ceci est dû au fait que l'utilisateur réseau est contrôlé par rapport à vos serveurs RADIUS dans la liste globale.

WLC peut authentifier les utilisateurs sur le serveur RADIUS avec le protocole PAP (Password Authentication Protocol), le protocole CHAP (Challenge Handshake Authentication Protocol) ou EAP-MD5 (Message Digest5). Il s'agit d'un paramètre global qui peut être configuré à partir de l'interface utilisateur graphique ou de l'interface de ligne de commande :

À partir de l'interface utilisateur graphique : accédez à Controller > Web RADIUS Authentication

À partir de CLI : entrez config custom-web RADIUSauth <pap|chap|md5chap>

Remarque : le serveur invité NAC utilise uniquement le protocole PAP.

Comment configurer un WLAN invité câblé

Il est facile à configurer et très proche de la configuration des invités sans fil. Vous pouvez le configurer avec un ou deux contrôleurs (uniquement s'il s'agit d'une auto-ancrage).

Choisissez un VLAN comme VLAN dans lequel vous placez les utilisateurs invités câblés, par exemple, sur VLAN 50. Lorsqu'un invité filaire souhaite accéder à Internet, branchez l'ordinateur portable sur un port d'un commutateur configuré pour VLAN 50. Ce VLAN 50 doit être autorisé et présent sur le chemin via le port d'agrégation WLC. Dans le cas de deux WLC (une ancre et une étrangère), ce VLAN invité câblé doit conduire au WLC étranger (appelé WLC1) et non à l'ancre. WLC1 s'occupe ensuite de la transmission tunnel du trafic vers le WLC DMZ (l'ancrage, appelé WLC2), qui libère le trafic dans le réseau routé.

Voici les cinq étapes à suivre pour configurer l'accès invité filaire :

1. Configurez une interface dynamique (VLAN) pour l'accès utilisateur invité filaire.
   
   Sur WLC1, créez une interface dynamique VLAN50. Dans la page de configuration d'interface, cochez la case Guest LAN. Ensuite, les champs tels que adresse IP et passerelle disparaissent. La seule chose que votre WLC doit savoir sur cette interface est que le trafic est routé à partir du VLAN 50. Ces clients sont des invités câblés.
   
   
2. Créez un réseau local câblé pour l'accès des invités.
   
   Sur un contrôleur, une interface est utilisée lorsqu'elle est associée à un WLAN. La deuxième étape consiste à créer un WLAN sur les contrôleurs de votre bureau principal. Accédez à WLAN et cliquez sur New. Dans Type WLAN, sélectionnez Guest LAN.
   
   Dans Profile Name et WLAN SSID, saisissez un nom qui identifie ce WLAN. Ces noms peuvent être différents, mais ne peuvent pas contenir d'espaces. Le terme WLAN est utilisé, mais ce profil de réseau n'est pas lié au profil de réseau sans fil.
   
   L'onglet Général propose deux listes déroulantes : Entrée et Sortie. Entrée est le VLAN à partir duquel les utilisateurs viennent (VLAN 50); La sortie est le VLAN auquel vous voulez les envoyer.
   
   Pour Inbound, sélectionnez VLAN50.
   
   Pour Sortie, c'est différent. Si vous n'avez qu'un seul contrôleur, vous devez créer une autre interface dynamique, une standard cette fois (pas un LAN invité), et vous envoyez vos utilisateurs câblés à cette interface. Dans ce cas, envoyez-les au contrôleur DMZ. Par conséquent, pour l'interface de sortie, sélectionnez l'interface de gestion.
   
   Le mode de sécurité pour ce LAN invité « WLAN » est WebAuth, ce qui est acceptable. Cliquez sur OK pour valider.
   
   
3. Configurez le contrôleur étranger (siège).
   
   Dans la liste WLAN, cliquez sur Ancrage de mobilité à la fin de la ligne Guest LAN, puis sélectionnez votre contrôleur DMZ. On suppose ici que les deux contrôleurs se connaissent. S'ils ne se connaissent pas encore, accédez à Controller > Mobility Management > Mobility group, et ajoutez DMZWLC sur WLC1. Ajoutez ensuite WLC1 sur DMZ. Les deux contrôleurs ne doivent pas se trouver dans le même groupe de mobilité. Sinon, les règles de sécurité de base sont enfreintes.
   
   
4. Configurez le contrôleur d'ancrage (contrôleur DMZ).
   
   Votre contrôleur de bureau principal est prêt. Vous devez maintenant préparer votre contrôleur DMZ. Ouvrez une session de navigateur Web sur votre contrôleur DMZ et accédez aux WLAN. Créez un nouveau WLAN. Dans Type WLAN, sélectionnez Guest LAN.
   
   Dans Profile Name et WLAN SSID, saisissez un nom qui identifie ce WLAN. Utilisez les mêmes valeurs que celles entrées sur le contrôleur du bureau central.
   
   L'interface Inbound est None. En fait, cela n'a pas d'importance, car le trafic est reçu via le tunnel Ethernet sur IP (EoIP). C'est pourquoi vous n'avez pas besoin de spécifier d'interface d'entrée.
   
   L'interface de sortie est celle sur laquelle les clients sont censés être envoyés. Par exemple, le VLAN DMZ est le VLAN 9. Créez une interface dynamique standard pour VLAN 9 sur votre DMZWLC, puis choisissez VLAN 9 comme interface de sortie.
   
   Vous devez configurer la fin du tunnel de l'ancrage de mobilité. Dans la liste WLAN, sélectionnez Mobility Anchor for Guest LAN. Envoyez le trafic au contrôleur local, DMZWLC. Les deux extrémités sont maintenant prêtes.
   
   
5. Ajustez le réseau local invité.
   
   Vous pouvez également affiner les paramètres WLAN aux deux extrémités. Attention, les paramètres doivent être identiques aux deux extrémités. Par exemple, si vous choisissez de cliquer dans l'onglet WLAN Advanced, Autoriser la substitution AAA sur WLC1, vous devez cocher la même case sur DMZWLC. S'il y a des différences dans les sélections dans le WLAN de chaque côté, le tunnel se casse. DMZWLC refuse le trafic ; vous pouvez voir quand vous exécutez la mobilité debug.
   
   Gardez à l'esprit que toutes les valeurs sont effectivement obtenues à partir de DMZWLC : Adresses IP, valeurs VLAN, etc. Configurez le côté WLC1 de manière identique, de sorte qu'il relaie la requête au WLCDMZ.

Certificats de la page de connexion

Cette section fournit les processus que vous devez suivre si vous voulez placer votre propre certificat sur la page WebAuth, ou si vous voulez masquer l'URL WebAuth 192.0.2.1 et afficher une URL nommée.

Télécharger un certificat pour l'authentification Web du contrôleur

Grâce à l'interface graphique (WebAuth > Certificate) ou à l'interface de ligne de commande (CLI) (type de transfert webauthcert), vous pouvez télécharger un certificat sur le contrôleur. Qu'il s'agisse d'un certificat que vous avez créé avec votre autorité de certification (CA) ou d'un certificat officiel tiers, il doit être au format .pem. Avant d'envoyer, vous devez également saisir la clé du certificat.

Après le téléchargement, un redémarrage est nécessaire pour que le certificat soit en place. Une fois redémarré, accédez à la page de certificat WebAuth de l'interface utilisateur graphique et elle affiche les détails du certificat que vous avez téléchargé (validité, etc.). Le champ important est le nom commun (CN), qui est le nom attribué au certificat. Ce champ est traité dans ce document sous la section « Autorité de certification et autres certificats sur le contrôleur ».

Après avoir redémarré et vérifié les détails du certificat, le nouveau certificat de contrôleur s'affiche sur la page de connexion WebAuth. Toutefois, il peut y avoir deux situations.

1. Si votre certificat a été émis par l'une des rares autorités de certification racine principales auxquelles chaque ordinateur fait confiance, alors tout va bien. Un exemple est VeriSign, mais vous êtes généralement signé par une sous-autorité de certification Verisign et non par l'autorité de certification racine. Vous pouvez archiver le magasin de certificats de votre navigateur si vous voyez que l'autorité de certification mentionnée ici est fiable.
   
   
2. Si vous avez obtenu votre certificat d'une société plus petite ou d'une autorité de certification, tous les ordinateurs ne leur font pas confiance. Vous devez également fournir le certificat de la société/autorité de certification au client, et espérons que l'une des autorités de certification racine émettra ce certificat. Finalement, vous finissez par avoir une chaîne comme « Le certificat a été émis par CA x > CA x certificat a été émis par CA y > CA y certificat a été émis par cette CA racine de confiance ». L'objectif final est d'atteindre une autorité de certification en laquelle le client fait confiance.

Autorité de certification et autres certificats sur le contrôleur

Pour être débarrassé de l'avertissement « ce certificat n'est pas fiable », vous devez également entrer le certificat de l'autorité de certification qui a émis le certificat du contrôleur sur le contrôleur. Ensuite, le contrôleur présente les deux certificats (certificat du contrôleur et certificat CA). Le certificat de l'autorité de certification doit être une autorité de certification de confiance ou disposer des ressources nécessaires pour vérifier l'autorité de certification. Vous pouvez en fait créer une chaîne de certificats d'autorité de certification qui mène à une autorité de certification de confiance en haut.

Vous devez placer la chaîne entière dans le même fichier. Cela signifie que votre fichier contient du contenu tel que cet exemple :

BEGIN CERTIFICATE ------ device certificate*   END CERTIFICATE ------ BEGIN 
CERTIFICATE ------ intermediate CA certificate*   END CERTIFICATE ------ BEGIN 
CERTIFICATE ------ Root CA certificate*   END CERTIFICATE ------

Comment faire correspondre le certificat à l'URL

L'URL WebAuth est définie sur 192.0.2.1 afin de vous authentifier et le certificat est émis (il s'agit du champ CN du certificat WLC). Si vous voulez changer l'URL WebAuth en 'myWLC.com', par exemple, accédez à la configuration de l'interface virtuelle (l'interface 192.0.2.1) et vous pouvez y entrer un nom d'hôte DNS virtuel, tel que myWLC.com. Ceci remplace le 192.0.2.1 dans votre barre d'URL. Ce nom doit également pouvoir être résolu. La trace du renifleur montre comment tout fonctionne, mais lorsque le WLC envoie la page de connexion, le WLC affiche l'adresse myWLC.com et le client résout ce nom avec son DNS. Ce nom doit être résolu en 192.0.2.1. Cela signifie que si vous utilisez également un nom pour la gestion du WLC, vous devriez utiliser un autre nom pour WebAuth. En d'autres termes, si vous utilisez myWLC.com mappé à l'adresse IP de gestion du WLC, vous devez utiliser un nom différent pour WebAuth, tel que myWLCwebauth.com.

Dépannage des problèmes de certificat

Cette section explique comment et quoi vérifier pour résoudre les problèmes de certificat.

Comment vérifier

Vous pouvez télécharger OpenSSL (pour Windows, rechercher OpenSSL Win32) et l'installer. Sans aucune configuration, vous pouvez aller dans le répertoire bin et essayer openssl s_client -connect www.mywebauthpage.com:443, si cette URL est l'URL où votre page WebAuth est liée sur votre DNS. Reportez-vous à la section « Que vérifier » de ce document pour un exemple.

Si vos certificats utilisent une autorité de certification privée, vous devez placer le certificat d'autorité de certification racine dans un répertoire sur une machine locale et utiliser l'option openssl -CApath. Si vous avez une autorité de certification intermédiaire, vous devez également la placer dans le même répertoire.

Afin d'obtenir des informations générales sur le certificat et de le vérifier, utilisez :

openssl x509 -in certificate.pem -noout -text
openssl verify certificate.pem

Il peut également être utile de convertir des certificats à l'aide d'openssl :

openssl x509 -in certificate.der -inform DER -outform PEM -out certificate.pem

Que vérifier

Vous pouvez voir quels certificats sont envoyés au client lorsqu'il se connecte. Lisez le certificat de périphérique : le CN doit être l'URL à laquelle la page Web est accessible. Lisez le “ émis par ” ligne du certificat de périphérique. Cette valeur doit correspondre au CN du deuxième certificat. Ensuite, ce deuxième certificat “ délivré par ” doit correspondre au CN du certificat suivant, et ainsi de suite. Sinon, il ne fait pas une chaîne réelle. Dans la sortie OpenSSL affichée ici, vous pouvez voir que openssl ne peut pas vérifier le certificat du périphérique car son “ émis par ” ne correspond pas au nom du certificat CA fourni.

Sortie SSL

Loading 'screen' into random state - done CONNECTED(00000760) depth=0 /O=
<company>.ac.uk/OU=Domain Control Validated/CN=<company>.ac.uk verify error:
num=20:unable to get local issuer certificate verify return:1 depth=0 /O=
<company>.ac.uk/OU=Domain Control Validated/CN=<company>.ac.uk verify error:
num=27:certificate not trusted verify return:1 depth=0 /O=<company>.ac.uk/OU=
Domain Control Validated/CN=<company>.ac.uk verify error:num=21:
unable to verify the first certificate verify return:1 --- Certificate chain
0 s:/O=<company>.ac.uk/OU=
Domain Control Validated/CN=<company>.ac.uki:/C=US/   ST=
Arizona/L=Scottsdale/O=.com/OU=http://certificates.gocompany.com/repository/CN=
Secure Certification Authority/serialNumber=079 
692871 s:/C=US/O=Company/OU=Class 2 Certification Authority 
i:/C=US/O=Company/OU=Class 2 Certification Authority --- Server certificate

BEGIN CERTIFICATE-----
MIIE/zCCA+egAwIBAgIDRc2iMA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJV
output cut*
YMaj/NACviEU9J3iot4sfreCQSKkBmjH0kf/Dg1l0kmdSbc=

END CERTIFICATE-----
subject=/O=<company>.ac.uk/OU=Domain Control Validated/CN=<company>c.ac.uk 
issuer=/C=US/ST=Arizona/L=Scottsdale/O=.com/OU=http://certificates. 
.com/repository/CN=Secure Certification Authority/serialNumber=0 
7969287 --- No client certificate CA names sent --- SSL handshake has read 
2476 bytes and written 322 bytes --- New, TLSv1/SSLv3, Cipher is AES256-SHA 
Server public key is 1024 bit Compression: NONE Expansion: NONE SSL-Session:

Protocol  : TLSv1
Cipher    : AES256-SHA
Session-ID: A32DB00A7AB7CD1CEF683980F3696C2BBA31A1453324F711F50EF4B86A4A7F03

Session-ID-ctx:Master-Key: C95E1BDAC7B1A964ED7324955C985CAF186B92EA34CD69E10
   5F95D969D557E19
939C6A77C72350AB099B3736D168AB22

   Key-Arg   : None
Start Time: 1220282986
Timeout   : 300 (sec)
Verify return code: 21 (unable to verify the first certificate)
---

Un autre problème possible est que le certificat ne peut pas être téléchargé sur le contrôleur. Dans cette situation, il n'y a pas de question de validité, de CA, et ainsi de suite. Afin de vérifier cela, vous pouvez d'abord vérifier la connectivité TFTP (Trivial File Transfer Protocol) et essayer de transférer un fichier de configuration. Ensuite, si vous entrez la commande debug transfer all enable, vous voyez que le problème est l'installation du certificat. Cela peut être dû à la mauvaise clé utilisée avec le certificat. Il se peut également que le certificat soit dans un format incorrect ou endommagé.

Cisco vous recommande de comparer le contenu du certificat à un certificat valide connu. Cela vous permet de voir si un attribut LocalkeyID affiche tous les 0 (déjà arrivé). Dans ce cas, le certificat doit être reconverti. Il existe deux commandes avec OpenSSL qui vous permettent de retourner de .pem à .p12, puis de réémettre un .pem avec la clé de votre choix.

Pré-étape : Si vous avez reçu un .pem contenant un certificat suivi d'une clé, copiez/collez la partie clé : —BEGIN KEY — jusqu'à — END KEY — de .pem à « key.pem ».

1. openssl pkcs12 -export -in certificate.pem -inkey.pem -out newcert.p12 ? Vous êtes invité à saisir une clé ; saisissez check123.
   
   
2. openssl pkcs12 -in newcert.p12 -out workingnewcert.pem -passin pass:check123 -passout pass:check123 Cela donne un .pem opérationnel avec le mot de passe check123.
   
   

Autres situations à résoudre

Bien que l'ancrage de mobilité n'ait pas été abordé dans ce document, si vous êtes dans une situation d'invité ancré, assurez-vous que l'échange de mobilité se produit correctement et que vous voyez le client arriver sur l'ancrage. Tous les autres problèmes WebAuth doivent être résolus sur l'ancrage.

Voici quelques problèmes courants que vous pouvez résoudre :

• Les utilisateurs ne peuvent pas s'associer au WLAN invité.
  
  Ceci n'est pas lié à WebAuth. Vérifiez la configuration du client, les paramètres de sécurité sur le WLAN, s'il est activé, et si les radios sont actives et opérationnelles, etc.
  
  
• Les utilisateurs n'obtiennent pas d'adresse IP.
  
  Dans une situation d'ancrage invité, c'est souvent parce que l'ancrage étranger et l'ancrage n'ont pas été configurés exactement de la même manière. Sinon, vérifiez la configuration DHCP, la connectivité, etc. Vérifiez si d'autres WLAN peuvent utiliser le même serveur DHCP sans problème. Ceci n'est toujours pas lié à WebAuth.
  
  
• L'utilisateur n'est pas redirigé vers la page de connexion.
  
  C'est le symptôme le plus courant, mais il est plus précis. Il existe deux scénarios possibles.
  
  
  1. L'utilisateur n'est pas redirigé (l'utilisateur entre une URL et n'atteint jamais la page WebAuth). Pour cette situation, vérifiez :
     
     
     • qu'un serveur DNS valide a été attribué au client via DHCP (ipconfig /all),
       
       
     • que le DNS est accessible depuis le client (nslookup www.website.com),
       
       
     • que l'utilisateur a entré une URL valide afin d'être redirigé,
       
       
     • que l'utilisateur a utilisé une URL HTTP sur le port 80 (par exemple, pour atteindre un ACS avec http://localhost:2002 ne vous redirige pas depuis que vous avez envoyé sur le port 2002 au lieu de 80).
       
       
  2. L'utilisateur est redirigé vers 192.0.2.1 correctement, mais la page elle-même ne s'affiche pas.
     
     Cette situation est très probablement un problème de WLC (bogue) ou un problème côté client. Il se peut que le client ait un pare-feu ou un logiciel ou une politique de blocage. Il se peut également qu'ils aient configuré un proxy dans leur navigateur Web.
     
     Recommandation : Prenez une trace de renifleur sur le PC client. Il n'est pas nécessaire d'avoir un logiciel sans fil spécial, seulement Wireshark, qui s'exécute sur la carte sans fil et vous montre si le WLC répond et essaie de rediriger. Vous avez deux possibilités : soit il n'y a pas de réponse du WLC, soit quelque chose ne va pas avec la connexion SSL pour la page WebAuth. Pour les problèmes de connexion SSL, vous pouvez vérifier si le navigateur de l'utilisateur autorise SSLv3 (certains n'autorisent que SSLv2) et s'il est trop agressif lors de la vérification des certificats.
     
     Il est courant d'entrer manuellement http:// 192.0.2.1 afin de vérifier si la page Web apparaît sans DNS. En fait, vous pouvez taper http://6.6.6.6 et obtenir le même effet. Le WLC redirige toute adresse IP que vous entrez. Par conséquent, si vous entrez http://192.0.2.1, cela ne vous fait pas travailler autour de la redirection Web. Si vous entrez https:// 192.0.2.1 (sécurisé), cela ne fonctionne pas car WLC ne redirige pas le trafic HTTPS (par défaut, cela est possible dans les versions 8.0 et ultérieures). La meilleure façon de charger la page directement sans redirection est d'entrer https:// 192.0.2.1/login.html.
     
     
• Les utilisateurs ne peuvent pas s'authentifier.
  
  Reportez-vous à la section de ce document qui traite de l'authentification. Vérifiez les informations d'identification localement sur RADIUS.
  
  
• Les utilisateurs peuvent s'authentifier avec succès via WebAuth, mais ils n'ont pas accès à Internet par la suite.
  
  Vous pouvez supprimer WebAuth de la sécurité du WLAN, puis vous devez avoir un WLAN ouvert. Vous pouvez ensuite essayer d'accéder au Web, au DNS, etc. Si vous rencontrez également des problèmes, supprimez complètement les paramètres WebAuth et vérifiez la configuration de vos interfaces.
  
  

Pour plus d'informations à ce sujet, consultez : Dépannage de l'authentification Web sur un contrôleur de réseau local sans fil (WLC).

Serveur proxy HTTP et son fonctionnement

Vous pouvez utiliser un serveur proxy HTTP. Si vous avez besoin que le client ajoute une exception dans son navigateur que 192.0.2.1 ne doit pas passer par le serveur proxy, vous pouvez faire que le WLC écoute le trafic HTTP sur le port du serveur proxy (généralement 8080).

Pour comprendre ce scénario, vous devez savoir ce qu'un proxy HTTP fait. Il s'agit d'un élément que vous configurez du côté client (adresse IP et port) dans le navigateur.

Le scénario habituel lorsqu'un utilisateur visite un site Web consiste à résoudre le nom sur IP avec DNS, puis il demande la page Web au serveur Web. Le processus doit toujours envoyer la requête HTTP de la page au proxy. Le proxy traite le DNS, le cas échéant, et le transmet au serveur Web (si la page n'est pas déjà mise en cache sur le proxy). La discussion porte uniquement sur le client à proxy. Le fait que le proxy obtienne ou non la véritable page Web n'est pas pertinent pour le client.

Voici le processus d'authentification Web :

• Les types d'utilisateur dans une URL.

• Le PC client envoie au serveur proxy.

• WLC intercepte et falsifie l'adresse IP du serveur proxy ; il répond au PC avec une redirection vers 192.0.2.1

À ce stade, si le PC n'est pas configuré pour lui, il demande la page 192.0.2.1 WebAuth au proxy afin qu'elle ne fonctionne pas. Le PC doit faire une exception pour 192.0.2.1 ; ensuite, il envoie une requête HTTP à 192.0.2.1 et passe à WebAuth. Une fois authentifiées, toutes les communications passent de nouveau par le proxy. Une configuration d'exception se trouve généralement dans le navigateur proche de la configuration du serveur proxy. Le message doit s'afficher : « N'utilisez pas de proxy pour ces adresses IP ».

Avec WLC version 7.0 et ultérieure, la fonction webauth proxy redirect peut être activée dans les options de configuration globale du WLC. Lorsqu'il est activé, le WLC vérifie si les clients sont configurés pour utiliser manuellement un proxy. Dans ce cas, ils redirigent le client vers une page qui leur montre comment modifier leurs paramètres de proxy pour que tout fonctionne. La redirection de proxy WebAuth peut être configurée pour fonctionner sur différents ports et est compatible avec l'authentification Web centrale.

Pour un exemple de redirection de proxy WebAuth, référez-vous à Exemple de configuration du proxy d'authentification Web sur un contrôleur de réseau local sans fil.

Authentification Web sur HTTP au lieu de HTTPS

Vous pouvez vous connecter à l'authentification Web sur HTTP au lieu de HTTPS. Si vous vous connectez sur HTTP, vous ne recevez pas d'alertes de certificat.

Pour le code antérieur à la version 7.2 du WLC, vous devez désactiver la gestion HTTPS du WLC et quitter la gestion HTTP. Cependant, ceci autorise uniquement la gestion Web du WLC sur HTTP.

Pour le code WLC version 7.2, utilisez la commande config network web-auth secureweb disable pour désactiver. Ceci désactive uniquement HTTPS pour l'authentification Web et non la gestion. Notez que cela nécessite un redémarrage du contrôleur !

Sur les versions 7.3 et ultérieures du WLC, vous pouvez activer/désactiver HTTPS pour WebAuth uniquement via l'interface utilisateur graphique et l'interface de ligne de commande.

Informations connexes

• Exemple de configuration de l'authentification Web sur un contrôleur de réseau local sans fil
• Télécharger le logiciel pour les bundles WebAuth du contrôleur sans fil
• Création d'une page de connexion d'authentification Web personnalisée
• Exemple de configuration d'authentification Web externe avec des contrôleurs de réseau local sans fil
• Exemple de configuration du passage Web du contrôleur LAN sans fil 5760/3850
• Configuration de Web Redirect (GUI)
• Configuration de la redirection Web (CLI)
• Dépannage de l'authentification Web sur un contrôleur de réseau local sans fil
• Exemple de configuration du proxy d'authentification Web sur un contrôleur de réseau local sans fil
• Demandes de commentaires (RFC)
• Support et documentation techniques - Cisco Systems