Begrijp webverificatie op draadloze LAN-controllers van AireOS

Inleiding

Dit document beschrijft de processen voor webverificatie op draadloze LAN-controllers (WLC). 

Voorwaarden

Vereisten

Cisco raadt u aan om basiskennis te hebben van de WLC-configuratie.

Gebruikte componenten

De informatie in dit document is gebaseerd op alle WLC-hardwaremodellen die gebruikmaken van AireOS 8.x.

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.

Innerlijke processen voor webverificatie

Webverificatie Positie als beveiligingsfunctie

Web Authenticatie (WebAuth) is Layer 3-beveiliging. Het zorgt voor gebruiksvriendelijke beveiliging die werkt op elk station dat een browser draait.

Het kan worden gecombineerd met elke PSK-beveiliging (Layer 2-beveiligingsbeleid).

Hoewel de combinatie van WebAuth en PSK het gebruiksvriendelijke gedeelte vermindert, heeft het het voordeel dat het clientverkeer wordt gecodeerd.

WebAuth is een verificatiemethode zonder codering.

WebAuth kan niet worden geconfigureerd met 802.1x/RADIUS (Remote Authentication Dial-In User Service) totdat WLC Software Release 7.4 gelijktijdig is geïnstalleerd en geconfigureerd.

Klanten moeten zowel dot1x- als webverificatie doorlopen. Het is bedoeld voor de toevoeging van een webportal voor werknemers (die 802.1x gebruiken), niet voor gasten.

Er is geen all-in-one service set identifier (SSID) voor dot1x voor medewerkers of webportal voor gasten.

Hoe WebAuth werkt

Het 802.11-verificatieproces is geopend, zodat u zonder problemen kunt verifiëren en koppelen. Daarna wordt u geassocieerd, maar niet in de WLC- RUNstatus.

Als webverificatie is ingeschakeld, blijft u op een locatie WEBAUTH_REQD waar u geen toegang hebt tot een netwerkbron.

U moet een DHCP IP-adres ontvangen met het adres van de DNS-server in de opties.

Typ een geldige URL in uw browser. De client lost de URL op via het DNS-protocol. De klant stuurt vervolgens zijn HTTP-verzoek naar het IP-adres van de website.

De WLC onderschept dat verzoek en retourneert de webauth aanmeldingspagina, die het IP-adres van de website nabootst. Bij een externe WebAuth antwoordt de WLC met een HTTP-reactie die het IP-adres van uw website bevat en aangeeft dat de pagina is verplaatst.

De pagina is verplaatst naar de externe webserver die door de WLC wordt gebruikt. Wanneer u wordt geverifieerd, krijgt u toegang tot alle netwerkbronnen en wordt u standaard doorgestuurd naar de oorspronkelijk aangevraagde URL (tenzij een gedwongen omleiding is geconfigureerd op de WLC).

Samengevat, de WLC stelt de client in staat om de DNS op te lossen en een IP-adres automatisch in WEBAUTH_REQD staat te krijgen.

Als u een andere poort wilt bekijken in plaats van poort 80, gebruikt u ook config network web-auth-port om een omleiding op deze poort te maken.

Een voorbeeld is de Access Control Server (ACS) webinterface, die zich op poort 2002 of andere soortgelijke toepassingen.

Opmerking over HTTPS-omleiding: standaard heeft het WLC HTTPS-verkeer niet omgeleid. Dit betekent dat als u een HTTPS-adres in uw browser typt, er niets gebeurt. U moet een HTTP-adres invoeren om doorgestuurd te worden naar de aanmeldingspagina die in HTTPS werd weergegeven.

In versie 8.0 en hoger kunt u de omleiding van HTTPS-verkeer inschakelen met de CLI-opdracht config network web-auth https-redirect enable.

Dit gebruikt veel middelen voor de WLC in gevallen waarin veel HTTPS-verzoeken worden verzonden. Het is niet raadzaam om deze functie te gebruiken vóór WLC versie 8.7, waar de schaalbaarheid van deze functie werd verbeterd. Merk ook op dat een certificaatwaarschuwing in dit geval onvermijdelijk is. Als de client een URL aanvraagt (zoals https://www.cisco.com), presenteert de WLC nog steeds zijn eigen certificaat dat is uitgegeven voor het IP-adres van de virtuele interface. Dit komt nooit overeen met het door de client gevraagde URL/IP-adres en het certificaat wordt niet vertrouwd, tenzij de client de uitzondering in zijn browser afdwingt.

Indicatieve prestatiedaling van WLC-softwarerelease vóór 8,7 gemeten:

In deze prestatietabel worden de 3 URL's aangeduid als:

• De oorspronkelijke URL die door de eindgebruiker is ingevoerd
• De URL waarnaar de WLC de browser omleidt
• De definitieve inzending van de referenties

De prestatietabel geeft de WLC-prestaties in het geval dat alle 3 URL's HTTP zijn, in het geval dat alle 3 URL's HTTPS zijn, of als de client van HTTP naar HTTPS gaat (standaard).

Hoe maak je een interne (lokale) WebAuth werk met een interne pagina

Voor het configureren van een WLAN met een operationele dynamische interface ontvangen de clients ook een DNS-server-IP-adres via DHCP.

Voordat een webauth , wordt ingesteld, controleert u of WLAN correct werkt, DNS-verzoeken kunnen worden opgelost (nslookup) en webpagina's kunnen worden doorzocht.

Stel de webverificatie in als beveiligingsfuncties van Layer 3. Gebruikers maken in de lokale database of op een externe RADIUS-server.

Raadpleeg het voorbeelddocument van de configuratie voor de webverificatie van de draadloze LAN-controller.

Een aangepaste lokale WebAuth configureren met aangepaste pagina

Aangepast webauth  kan worden geconfigureerd met redirectUrl behulp van op het Security tabblad. Dit dwingt een omleiding naar een specifieke webpagina die u invoert.

Wanneer de gebruiker wordt geverifieerd, wordt de oorspronkelijke URL die de client heeft aangevraagd, genegeerd en wordt de pagina weergegeven waarvoor de omleiding is toegewezen.

Met de aangepaste functie kunt u een aangepaste HTML-pagina gebruiken in plaats van de standaard aanmeldingspagina. Upload uw HTML- en afbeeldingsbestanden bundel naar de controller.

Zoek op de uploadpagina naar webauth bundle informatie in een tar-indeling. PicoZip maakt sterren die compatibel zijn met de WLC.

Raadpleeg voor een voorbeeld van een WebAuth-bundel de pagina Downloadsoftware voor Wireless Controller WebAuth-bundels. Selecteer de juiste release voor uw WLC.

Het wordt aanbevolen om een bestaande bundel aan te passen; maak geen nieuwe bundel aan.

Er zijn enkele beperkingen met custom webauth die variëren met versies en bugs. 

• de grootte van het .tar-bestand (niet meer dan 5 MB)
• Het aantal bestanden in de .tar
• De bestandsnaamlengte van de bestanden (niet meer dan 30 tekens)
  
  

Als het pakket niet werkt, probeer dan een eenvoudig aangepast pakket. Voeg afzonderlijk bestanden en complexiteit toe om het pakket te bereiken dat de gebruiker probeerde te gebruiken. Dit helpt bij het identificeren van het probleem.

Als u een aangepaste pagina wilt configureren, raadpleegt u Een aangepaste aanmeldingspagina voor webverificatie maken, een sectie in de configuratiehandleiding voor draadloze LAN-controllers van Cisco, versie 7.6.

Globale configuratietechniek negeren

Configureer met de opdracht globale configuratie overschrijven en stel een WebAuth-type in voor elk WLAN. Dit maakt een interne/standaard WebAuth met een aangepaste interne/standaard WebAuth voor een ander WLAN mogelijk.

Hierdoor kunnen voor elk WLAN verschillende aangepaste pagina's worden geconfigureerd.

Combineer alle pagina's in dezelfde bundel en upload ze naar de WLC.

Stel uw aangepaste pagina in met de opdracht globale configuratie overschrijven op elk WLAN en selecteer uit alle bestanden in de bundel welk bestand de aanmeldingspagina is.

Kies een andere aanmeldingspagina in de bundel voor elk WLAN.

Omleidingskwestie

Er is een variabele in de HTML-bundel die de omleiding mogelijk maakt. Zet je gedwongen URL niet daar.

Voor omleidingsproblemen in aangepaste WebAuth raadt Cisco aan om de bundel te controleren.

Als u een redirect-URL met += in de WLC-GUI invoert, kan dit overschrijven of toevoegen aan de URL die in de bundel is gedefinieerd.

In de WLC-GUI is het redirectURL veld bijvoorbeeld ingesteld op www.cisco.com; in de bundel wordt echter weergegeven: redirectURL+= '(website-URL)'. De += verwijst gebruikers door naar een ongeldige URL.

Hoe een externe (lokale) webverificatie te laten werken met een externe pagina

Het gebruik van een externe WebAuth-server is slechts een externe opslagplaats voor de aanmeldingspagina. De gebruikersreferenties worden nog steeds geverifieerd door de WLC. De externe webserver staat alleen een speciale of andere aanmeldingspagina toe.

Stappen uitgevoerd voor een externe WebAuth:

1. De client (eindgebruiker) opent een webbrowser en voert een URL in.
   
   
2. Als de client niet is geverifieerd en externe webverificatie wordt gebruikt, leidt de WLC de gebruiker door naar de URL van de externe webserver. De WLC stuurt een HTTP-redirect naar de client met het geïmiteerde IP-adres en wijst naar het IP-adres van de externe server. De aanmeldings-URL voor externe webverificatie wordt toegevoegd met parameters zoals de AP_Mac_Addressnaam, het client_url (client-URL-adres) en het action_URL adres dat nodig is om contact op te nemen met de webserver van de switch.
   
   
3. De URL van de externe webserver stuurt de gebruiker naar een aanmeldingspagina. De gebruiker kan een toegangscontrolelijst voor verificatie (Pre-Authentication Access Control List, ACL) gebruiken om toegang te krijgen tot de server.
   
   
4. De aanmeldingspagina stuurt het verzoek om gebruikersreferenties terug naar de action_URLwebsite, zoals http://192.0.2.1/login.html, van de WLC-webserver. Dit wordt opgegeven als invoerparameter voor de URL voor omleiden, waarbij 192.0.2.1 het adres van de virtuele interface op de switch is.
   
   
5. De WLC-webserver verzendt de gebruikersnaam en het wachtwoord voor verificatie.
   
   
6. De WLC initieert het RADIUS-serververzoek of gebruikt de lokale database op de WLC en verifieert vervolgens de gebruiker.
   
   
7. Als de verificatie succesvol is, stuurt de WLC-webserver de gebruiker door naar de geconfigureerde redirect-URL of naar de URL die de client heeft ingevoerd.
   
   
8. Als de verificatie mislukt, leidt de WLC-webserver de gebruiker terug naar de aanmeldings-URL van de gebruiker.

Opmerking: We gebruiken 192.0.2.1 als voorbeeld van virtueel IP in dit document. Het 192.0.2.x-bereik wordt aanbevolen voor gebruik voor virtuele ip omdat het niet-routeerbaar is. Oudere documentatie verwijst mogelijk naar "1.1.1.x" of is nog steeds wat is geconfigureerd in uw WLC, omdat dit vroeger de standaardinstelling was. Merk echter op dat dit IP nu een geldig routeerbaar IP-adres is en daarom wordt in plaats daarvan het 192.0.2.x-subnet geadviseerd.

Als de toegangspunten (AP's) zich in de FlexConnect-modus bevinden, is een preauth ACL niet relevant. Flex ACL's kunnen worden gebruikt om toegang tot de webserver toe te staan voor clients die niet zijn geverifieerd.

Raadpleeg het voorbeeld Configuratie van externe webverificatie met draadloze LAN-controllers.

Webdoorvoer

Web Passthrough is een variant van de interne webauthenticatie. Er wordt een pagina weergegeven met een waarschuwing of een waarschuwing, maar er wordt niet gevraagd naar referenties.

Vervolgens klikt de gebruiker op OK. Schakel e-mailinvoer in en de gebruiker kan zijn e-mailadres invoeren dat zijn gebruikersnaam wordt.

Wanneer de gebruiker is verbonden, controleert u de lijst met actieve clients en controleert u of de gebruiker wordt vermeld met het e-mailadres dat zij als gebruikersnaam hebben ingevoerd.

Raadpleeg voor meer informatie het voorbeeld van de configuratie van de draadloze LAN-controller 5760/3850 Web Passthrough.

voorwaardelijke webomleiding

Als u een voorwaardelijke webomleiding inschakelt, wordt de gebruiker voorwaardelijk omgeleid naar een bepaalde webpagina nadat de 802.1x-verificatie is voltooid.

U kunt de omleidingspagina en de voorwaarden waaronder de omleiding plaatsvindt op uw RADIUS-server opgeven.

Voorwaarden kunnen het wachtwoord bevatten wanneer het de vervaldatum bereikt of wanneer de gebruiker een rekening moet betalen voor voortgezet gebruik / toegang.

Als de RADIUS-server het Cisco AV-url-redirectpaar retourneert, wordt de gebruiker bij het openen van een browser omgeleid naar de opgegeven URL.

Als de server ook het Cisco AV-pair retourneert, url-redirect-aclwordt de opgegeven ACL voor deze client geïnstalleerd als een ACL vóór verificatie.

De klant wordt op dit moment niet als volledig geautoriseerd beschouwd en kan alleen verkeer doorgeven dat is toegestaan door de pre-authenticatie ACL. Nadat de client een bepaalde bewerking op de opgegeven URL heeft voltooid (bijvoorbeeld een wachtwoordwijziging of factuurbetaling), moet de client zich opnieuw verifiëren.

Wanneer de RADIUS-server een url-redirectbericht niet retourneert, wordt de client beschouwd als volledig geautoriseerd en mag deze verkeer doorgeven.

Opmerking: De functie voor voorwaardelijke webomleiding is alleen beschikbaar voor WLAN's die zijn geconfigureerd voor 802.1x- of WPA+WPA2 Layer 2-beveiliging.

Nadat u de RADIUS-server hebt geconfigureerd, configureert u de voorwaardelijke webomleiding op de controller met de controller-GUI of CLI. Raadpleeg deze stapsgewijze handleidingen: Web Redirect configureren (GUI) en Web Redirect configureren (CLI).

Splash Page Web Redirect

Als u splash page web redirect inschakelt, wordt de gebruiker doorgestuurd naar een bepaalde webpagina nadat de 802.1x-verificatie is voltooid. Na de omleiding heeft de gebruiker volledige toegang tot het netwerk.

U kunt de omleidingspagina op uw RADIUS-server opgeven. Als de RADIUS-server het Cisco AV-url-redirectpaar retourneert, wordt de gebruiker bij het openen van een browser omgeleid naar de opgegeven URL.

De client wordt op dit moment als volledig geautoriseerd beschouwd en mag verkeer doorgeven, zelfs als de RADIUS-server geen url-redirectgegevens retourneert.

Opmerking: de functie voor het omleiden van splash-pagina's is alleen beschikbaar voor WLAN's die zijn geconfigureerd voor 802.1x- of WPA+WPA2 Layer 2-beveiliging.

Nadat u de RADIUS-server hebt geconfigureerd, configureert u de splash page web redirect op de controller met de controller-GUI of CLI.

WebAuth on MAC-filterfout

Een WebAuth op MAC Filter FaFailure vereist dat u MAC-filters configureert in het beveiligingsmenu van Layer 2.

Als gebruikers met succes zijn gevalideerd met hun MAC-adressen, gaan ze rechtstreeks naar de run staat.

Als ze dat niet zijn, gaan ze naar de WEBAUTH_REQD staat en vindt de normale webverificatie plaats.

Opmerking: Dit wordt niet ondersteund met web passthrough.Voor meer informatie, observeer de activiteit op verzoek verbetering Cisco bug ID CSCtw73512

Centrale webverificatie

Central Web Authentication verwijst naar een scenario waarin de WLC geen diensten meer host. De klant wordt rechtstreeks naar het ISE-webportaal gestuurd en gaat niet door 192.0.2.1 op de WLC. De inlogpagina en het hele portaal worden geëxternaliseerd.

Centrale webverificatie vindt plaats wanneer RADIUS Network Admission Control (NAC) is ingeschakeld in de geavanceerde instellingen van de WLAN- en MAC-filters.

De WLC verzendt een RADIUS-verificatie (meestal voor het MAC-filter) naar ISE, die antwoordt met de redirect-url attribuutwaarde (AV) paar.

De gebruiker wordt dan in staat gesteld POSTURE_REQD totdat ISE de autorisatie geeft met een verzoek tot wijziging van de autorisatie (CoA). Hetzelfde scenario speelt zich af in Posture of Central WebAuth.

Central WebAuth is niet compatibel met WPA-Enterprise/802.1x omdat het gastportaal geen sessiesleutels voor codering kan retourneren zoals bij het Extensible Authentication Protocol (EAP).

Verificatie van externe gebruiker (RADIUS)

External User Authentication (RADIUS) is alleen geldig voor Local WebAuth wanneer WLC de referenties verwerkt of wanneer een Layer 3-webbeleid is ingeschakeld. Authenticeer gebruikers lokaal of op de WLC of extern via RADIUS.

Er is een volgorde waarin de WLC controleert op de referenties van de gebruiker.

1. In ieder geval kijkt het eerst in zijn eigen database.

2. Als de gebruikers daar niet worden gevonden, gaat deze naar de RADIUS-server die is geconfigureerd in het gast-WLAN (als er een is geconfigureerd).

3. Vervolgens wordt in de globale RADIUS-serverlijst gecontroleerd aan de hand van de RADIUS-servers waarop network user wordt gecontroleerd.

Dit derde punt beantwoordt de vraag van degenen die RADIUS niet configureren voor dat WLAN, maar merken dat het nog steeds controleert tegen de RADIUS wanneer de gebruiker niet wordt gevonden op de controller.

Dit komt omdat network user uw RADIUS-servers zijn gecontroleerd in de algemene lijst.

Met WLC kunnen gebruikers worden geverifieerd op een RADIUS-server met PAP (Password Authentication Protocol), CHAP (Challenge Handshake Authentication Protocol) of EAP-MD5 (Message Digest5).

Dit is een algemene parameter en kan worden geconfigureerd vanuit de GUI of CLI:

Van GUI: navigeren naar Controller > Web RADIUS Authentication

Van CLI: invoeren config custom-web RADIUSauth

Opmerking: de NAC-gastserver gebruikt alleen PAP.

Hoe maak je een Wired Guest WLAN instellen

Een Wired Guest WLAN-configuratie is vergelijkbaar met een draadloze gastconfiguratie. Het kan worden geconfigureerd met één of twee controllers (alleen als er een auto-anker is).

Kies een VLAN als het VLAN voor bekabelde gastgebruikers, bijvoorbeeld op VLAN 50. Wanneer een bekabelde gast toegang tot internet wil, sluit u de laptop aan op een poort op een switch die is geconfigureerd voor VLAN 50.

Deze VLAN 50 moet zijn toegestaan en aanwezig zijn op het pad via de WLC-trunkpoort.

In het geval van twee WLC's (één anker en één buitenlands) moet dit bekabelde gast-VLAN leiden naar de buitenlandse WLC (WLC1 genaamd) en niet naar het anker.

WLC1 zorgt vervolgens voor de verkeerstunnel naar de DMZ WLC (het anker, genaamd WLC2), die het verkeer in het gerouteerde netwerk vrijgeeft.

Hier zijn de vijf stappen om bekabelde gasttoegang te configureren:

1. Een dynamische interface (VLAN) configureren voor bekabelde gastgebruikerstoegang.
   
   Maak op WLC1 een dynamische interface VLAN50. Vink op de interface configuration pagina het Guest LAN vakje aan. Dan verdwijnen velden als IP address en gateway verval. De WLC moet herkennen dat verkeer wordt gerouteerd vanaf VLAN 50. Deze klanten zijn bekabelde gasten.
   
   
2. Maak een bekabeld LAN voor gastgebruikerstoegang.
   
   Op een controller wordt een interface gebruikt wanneer deze is gekoppeld aan een WLAN. Maak vervolgens een WLAN op uw hoofdkantoorcontrollers. Navigeer naar WLANs en klik Newop. In, WLAN Typekies Guest LANuit.
   
   Voer in Profielnaam en WLAN-SSID een naam in die dit WLAN identificeert. Deze namen kunnen verschillen, maar kunnen geen spaties bevatten. De term WLAN wordt gebruikt, maar dit netwerkprofiel heeft geen betrekking op het profiel van het draadloze netwerk.
   
   Het General tabblad bevat twee vervolgkeuzelijsten: Ingress en Egress. Ingress is het VLAN waaruit gebruikers afkomstig zijn (VLAN 50); Egress is het VLAN waarnaar u ze verzendt.
   
   Kies Ingressbijvoorbeeld VLAN50voor.
   
   Voor Egressmij is het anders. Als u slechts één controller hebt, maakt u een andere dynamische interface, een standard deze keer (geen gastnetwerk) en verzendt u bekabelde gebruikers naar deze interface. Stuur ze in dit geval naar de DMZ-controller. Kies daarom voor de Egress interface de Management Interfaceoptie.
   
   De Security modus voor dit gast-LAN "WLAN" is WebAuth, wat acceptabel is. Klik Ok om te valideren.
   
   
3. Configureer de buitenlandse controller (hoofdkantoor).
   
   Klik WLAN listaan het Mobility Anchor einde van de Guest LAN regel en kies uw DMZ-controller. Hierbij wordt ervan uitgegaan dat beide controllers elkaar herkennen. Als ze dat niet doen, ga dan naar Controller > Mobility Management > Mobility groupen voeg DMZWLC toe op WLC1. Voeg vervolgens WLC1 toe aan DMZ. Beide controllers mogen niet tot dezelfde mobiliteitsgroep behoren. Anders worden fundamentele veiligheidsregels overtreden.
   
   
4. Configureer de ankercontroller (de DMZ-controller).
   
   De controller van het hoofdkantoor is klaar. Bereid nu uw DMZ-controller voor. Open een webbrowsersessie naar uw DMZ-controller en navigeer naar WLAN's. Maak een nieuw WLAN. In, WLAN Typekies Guest LANuit.
   
   Voer in Profile Name en WLAN SSIDeen naam in die dit WLAN identificeert. Gebruik dezelfde waarden als op de hoofdkantoorcontroller.
   
   De Ingress interface is Nonehier. Het maakt niet uit omdat het verkeer wordt ontvangen via de Ethernet over IP-tunnel (EoIP). Het is niet nodig om een Ingress-interface te specificeren.
   
   De Egress interface is waar de klanten naartoe worden gestuurd. De laatste optie DMZ VLAN is VLAN 9. Maak een standaard dynamische interface voor VLAN 9 op uw DMZWLC en kies VLAN 9 vervolgens als de Egress-interface.
   
   Configureer het einde van de Mobility Anchor-tunnel. Kies in de WLAN-lijst de Mobility Anchor for Guest LANoptie. Stuur het verkeer naar de lokale controller, DMZWLC. Beide uiteinden zijn nu klaar.
   
   
5. Fine-tunen van het gast-LAN.
   
   U kunt ook de WLAN-instellingen aan beide uiteinden verfijnen. De instellingen moeten aan beide uiteinden identiek zijn. Als u bijvoorbeeld op het WLAN Advanced tabblad klikt, Allow AAA override schakelt u op WLC1 hetzelfde selectievakje in op DMZWLC. Als er verschillen zijn in het WLAN aan beide zijden, breekt de tunnel. DMZWLC weigert het verkeer; u kunt zien wanneer u run debug mobilityreist.
   
   Houd er rekening mee dat alle waarden daadwerkelijk worden verkregen uit DMZWLC: IP-adressen, VLAN-waarden, enzovoort. Configureer de WLC1-zijde identiek, zodat deze het verzoek doorstuurt naar de WLCDMZ.

Certificaten voor de aanmeldingspagina

Deze sectie bevat de processen om uw eigen certificaat op de WebAuth-pagina te plaatsen of om de 192.0.2.1 WebAuth-URL te verbergen en een benoemde URL weer te geven.

Een certificaat uploaden voor de webverificatie van de controller

Via de GUI (WebAuth > Certificate) of CLI (overdrachtstype) webauthcertkunt u een certificaat uploaden op de controller.

Of het nu gaat om een certificaat dat is gemaakt met uw certificeringsinstantie (CA) of een officieel certificaat van een derde partij, het moet in .pem-formaat zijn.

Voordat u het certificaat verzendt, moet u ook de sleutel van het certificaat invoeren.

Na het uploaden is een reboot vereist om het certificaat op zijn plaats te krijgen. Ga na het opnieuw opstarten naar de WebAuth-certificaatpagina in de GUI om de details te vinden van het certificaat dat u hebt geüpload (geldigheid enzovoort).

Het belangrijkste veld is de algemene naam (GN), de naam die aan het certificaat wordt toegekend. Dit veld wordt in dit document besproken onder de sectie "Certificaatautoriteit en andere certificaten op de controller".

Nadat u opnieuw hebt opgestart en de details van het certificaat hebt geverifieerd, ontvangt u het nieuwe controllercertificaat op de aanmeldingspagina van WebAuth. Er kunnen echter twee situaties zijn.

1. Als uw certificaat is uitgegeven door een van de weinige hoofdroot-CA's die elke computer vertrouwt, dan is het goed. Een voorbeeld is VeriSign, maar u bent meestal ondertekend door een Verisign sub-CA en niet de root-CA. U kunt in uw browsercertificaatarchief controleren of u de daar genoemde CA als vertrouwd ziet.
   
   
2. Als u uw certificaat van een kleiner bedrijf / CA hebt ontvangen, vertrouwen alle computers ze niet. Verstrek ook het bedrijfs-/CA-certificaat aan de klant en een van de root-CA's geeft dat certificaat vervolgens uit. Uiteindelijk hebt u een keten zoals "Certificaat is uitgegeven door CA x > CA x certificaat is uitgegeven door CA y > CA y certificaat is uitgegeven door deze vertrouwde root CA". Het uiteindelijke doel is om een CA te bereiken die de klant vertrouwt.

Certificaatautoriteit en andere certificaten op de controller

Om van de waarschuwing "dit certificaat is niet vertrouwd" af te komen, voert u het certificaat van de CA die het controllercertificaat heeft afgegeven in op de controller.

Vervolgens presenteert de controller beide certificaten (het controllercertificaat en het CA-certificaat). Het CA-certificaat moet een vertrouwde CA zijn of over de middelen beschikken om de CA te verifiëren. Je kunt eigenlijk een keten van CA-certificaten bouwen die leiden tot een vertrouwde CA bovenaan.

Plaats de hele keten in hetzelfde bestand. Het bestand bevat dan inhoud zoals dit voorbeeld:

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

Hoe het certificaat overeenkomt met de URL

De WebAuth-URL is ingesteld op 192.0.2.1 om uzelf te verifiëren en het certificaat wordt uitgegeven (dit is het CN-veld van het WLC-certificaat).

Om de WebAuth URL te veranderen in 'myWLC . com', bijvoorbeeld, ga naar de virtual interface configuration (de 192.0.2.1 interface) en daar kunt u een virtual DNS hostnameinterface invoeren, zoals myWLC . com.

Dit vervangt de 192.0.2.1 in uw URL-balk. Deze naam moet ook oplosbaar zijn. Het snuffelspoor laat zien hoe het allemaal werkt, maar wanneer WLC de aanmeldingspagina verzendt, toont WLC het myWLC . com-adres en lost de client deze naam op met hun DNS.

Deze naam moet worden opgelost als 192.0.2.1. Dit betekent dat als u ook een naam gebruikt voor het beheer van de WLC, u een andere naam gebruikt voor WebAuth.

Als u myWLC . com gebruikt dat is toegewezen aan het IP-adres voor WLC-beheer, moet u een andere naam voor de WebAuth gebruiken, zoals myWLCwebauth.com.

Problemen met certificaten oplossen

In dit gedeelte wordt uitgelegd hoe en wat u moet controleren om problemen met certificaten op te lossen.

Hoe te controleren

Download OpenSSL (voor Windows, zoek naar OpenSSL Win32) en installeer het. Zonder enige configuratie, kunt u gaan in de bin directory en proberen openssl s_client –connect (your web auth URL):443,

Als deze URL de URL is waaraan uw WebAuth-pagina is gekoppeld op uw DNS, raadpleegt u "Wat te controleren" in de volgende sectie van dit document.

Als uw certificaten een privé-CA gebruiken, plaatst u het Root CA-certificaat in een directory op een lokaal systeem en gebruikt u de -CApathoptie openssl. Als u een tussenliggende CA hebt, plaatst u deze ook in dezelfde directory.

Om algemene informatie over het certificaat te verkrijgen en het te controleren, gebruikt u:

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

Het is ook handig om certificaten te converteren met behulp van openssl:

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

Wat te controleren

U kunt zien welke certificaten naar de client worden verzonden wanneer deze verbinding maakt. Lees het apparaatcertificaat - de CN moet de URL zijn waar de webpagina bereikbaar is.

Lees de regel "uitgegeven door" van het apparaatcertificaat. Dit moet overeenkomen met de GN van het tweede certificaat. Dit tweede certificaat, "afgegeven door", moet overeenkomen met de GN van het volgende certificaat, enzovoort. Anders wordt er geen echte keten gevormd.

In de OpenSSL-uitvoer die hier wordt weergegeven, wordt vermeld dat u het apparaatcertificaat niet kunt verifiëren omdat het "uitgegeven door" niet overeenkomt met de naam van het CA-certificaat dat u hebt openssl opgegeven.

SSL-uitvoer

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)
---

Een ander mogelijk probleem is dat het certificaat niet kan worden geüpload naar de controller. In deze situatie is er geen sprake van geldigheid, CA, enzovoort.

Controleer de connectiviteit van het Trivial File Transfer Protocol (TFTP) en probeer een configuratiebestand over te dragen om dit te verifiëren. Als u de debug transfer all enable opdracht invoert, merkt u dat het probleem de installatie van het certificaat is.

Dit kan te wijten zijn aan de verkeerde sleutel die met het certificaat is gebruikt. Het kan ook zijn dat het certificaat in een verkeerd formaat is of beschadigd is.

Cisco raadt u aan de certificaatinhoud te vergelijken met een bekend, geldig certificaat. Hiermee kunt u zien of een LocalkeyID attribuut alle 0's weergeeft (al gebeurd). Als dat het geval is, moet het certificaat opnieuw worden geconverteerd.

Er zijn twee opdrachten met OpenSSL waarmee u van .pem naar .p12 kunt terugkeren en vervolgens een .pem opnieuw kunt uitgeven met de sleutel van uw keuze.

Als je een .pem hebt ontvangen die een certificaat bevat gevolgd door een sleutel, kopieer/plak dan het sleuteldeel: van de .pem ----BEGIN KEY ---- until ------- END KEY ------ naar "key.pem".

1. openssl pkcs12 -export -in certificate.pem -inkey key.pem -out newcert.p12 ? U wordt gevraagd om een sleutel in te voeren; check123.


2. openssl pkcs12 -in newcert.p12 -out workingnewcert.pem -passin pass:check123 -passout pass:check123 Dit resulteert in een operationeel .pem met het check123wachtwoord.
   
   

Andere situaties om problemen op te lossen

Hoewel mobiliteitsanker niet is besproken in dit document, moet u, als u zich in een verankerde gast-situatie bevindt, ervoor zorgen dat de mobiliteitsuitwisseling correct plaatsvindt en dat u de klant op het anker ziet aankomen.

Eventuele andere WebAuth-problemen moeten worden opgelost op het anker.

Hier zijn enkele veelvoorkomende problemen die u kunt oplossen:

• Gebruikers kunnen geen verbinding maken met het gast-WLAN.
  
  Dit heeft niets te maken met WebAuth. Controleer de clientconfiguratie, de beveiligingsinstellingen op het WLAN, of deze is ingeschakeld en of de radio's actief en actief zijn, enzovoort.
  
  
• Gebruikers krijgen geen IP-adres.
  
  In een gastankersituatie komt dit meestal omdat het buitenlandse anker en het anker niet precies op dezelfde manier zijn geconfigureerd. Controleer anders de DHCP-configuratie, connectiviteit, enzovoort.
• Controleer of andere WLAN's zonder problemen dezelfde DHCP-server kunnen gebruiken. Dit heeft niets te maken met WebAuth.
  
  
• De gebruiker wordt niet doorgestuurd naar de inlogpagina.
  
  Dit is het meest voorkomende symptoom, maar is nauwkeuriger. Er zijn twee mogelijke scenario's.
  
  
  1. De gebruiker wordt niet omgeleid (de gebruiker voert een URL in en bereikt nooit de WebAuth-pagina). Controleer voor deze situatie:
     
     
     • dat een geldige DNS-server via DHCP (ipconfig /allDHCP) aan de client is toegewezen,
       
       
     • dat het DNS bereikbaar is vanaf de client (nslookup (website URL),
       
       
     • dat de gebruiker een geldige URL heeft ingevoerd om te worden omgeleid,
       
       
     • dat de gebruiker een HTTP-URL heeft gebruikt op poort 80 (bijvoorbeeld om een ACS te bereiken met http://localhost:2002 leidt u niet om omdat u poort 2002 in plaats van 80 hebt verzonden).
       
       
  2. De gebruiker wordt correct omgeleid naar 192.0.2.1, maar de pagina zelf wordt niet weergegeven.
     
     Deze situatie is hoogstwaarschijnlijk een WLC-probleem (bug) of een probleem aan de clientzijde. Het kan zijn dat de client een firewall of software of beleidsblok heeft. Het kan ook zijn dat ze een proxy hebben geconfigureerd in hun webbrowser.
     
     Aanbeveling: Neem een snuffelspoor op de client-pc. Er is geen speciale draadloze software nodig, alleen Wireshark, die op de draadloze adapter wordt uitgevoerd en u laat zien of de WLC antwoordt en probeert om te leiden. Je hebt twee mogelijkheden: of er is geen reactie van WLC, of er is iets mis met de SSL-handshake voor de WebAuth-pagina. Voor SSL-handshake-problemen kunt u controleren of de gebruikersbrowser SSLv3 toestaat (sommige staan alleen SSLv2 toe) en of deze te agressief is bij certificaatverificatie.
     
     Het is een gebruikelijke stap om handmatig http://192.0.2.1 in te voeren om te controleren of de webpagina zonder DNS wordt weergegeven. Eigenlijk kun je http://10.0.0.0 typen en hetzelfde effect krijgen. De WLC leidt elk IP-adres dat u invoert om. Daarom, als u http://192.0.2.1 invoert, hoeft u niet te werken rond het web omleiding. Als u https://192.0.2.1(beveiligd) invoert, werkt dit niet omdat WLC het HTTPS-verkeer niet omleidt (dit is standaard mogelijk in versie 8.0 en hoger). De beste manier om de pagina direct te laden zonder een omleiding is om https://192.0.2.1/login.html in te voeren.
     
     
• Gebruikers kunnen zich niet authenticeren.
  
  Zie het gedeelte van dit document waarin authenticatie wordt besproken. Controleer de referenties lokaal op de RADIUS.
  
  
• Gebruikers kunnen zich met succes authenticeren via WebAuth, maar hebben daarna geen internettoegang.
  
  U kunt WebAuth verwijderen uit de beveiliging van het WLAN en vervolgens hebt u een open WLAN. U kunt dan proberen toegang te krijgen tot het web, de DNS enzovoort. Als u daar ook problemen ondervindt, verwijdert u WebAuth-instellingen helemaal en controleert u de configuratie van uw interfaces.
  
  

Raadpleeg voor meer informatie: Problemen oplossen met webverificatie op een draadloze LAN-controller (WLC).

HTTP Proxy Server en hoe het werkt

U kunt een HTTP-proxyserver gebruiken. Als u de client nodig hebt om een uitzondering in zijn browser toe te voegen dat 192.0.2.1 niet door de proxyserver moet gaan, kunt u de WLC laten luisteren naar HTTP-verkeer op de poort van de proxyserver (meestal 8080).

Om dit scenario te begrijpen, moet u weten wat een HTTP-proxy doet. Het is iets dat u configureert aan de clientzijde (IP-adres en poort) in de browser.

Het gebruikelijke scenario wanneer een gebruiker een website bezoekt, is om de naam op te lossen in IP met DNS en vervolgens de webpagina naar de webserver te vragen. Het proces stuurt altijd het HTTP-verzoek voor de pagina naar de proxy.

De proxy verwerkt de DNS, indien nodig, en stuurt door naar de webserver (als de pagina nog niet in de cache van de proxy staat). De discussie is alleen client-naar-proxy. Of de proxy de echte webpagina al dan niet verkrijgt, is irrelevant voor de klant.

Dit is het web authenticatie proces:

• Typen gebruikers in een URL.

• De client-pc wordt naar de proxyserver verzonden.

• WLC onderschept en imiteert Proxy server IP; het antwoordt op de PC met een omleiding naar 192.0.2.1

In dit stadium, als de pc niet is geconfigureerd voor het, het vraagt om de 192.0.2.1 WebAuth pagina naar de proxy, zodat het niet werkt. De pc moet een uitzondering maken voor 192.0.2.1; vervolgens stuurt het een HTTP-verzoek naar 192.0.2.1 en gaat het verder met WebAuth.

Wanneer geverifieerd, gaan alle communicatie opnieuw via proxy. Een uitzonderingsconfiguratie bevindt zich meestal in de browser in de buurt van de configuratie van de proxyserver. U ziet dan het bericht: "Gebruik geen proxy voor die IP-adressen".

Met WLC Release 7.0 en hoger kan de functie webauth proxy redirect worden ingeschakeld in de globale WLC-configuratieopties.

Wanneer ingeschakeld, controleert de WLC of de clients zijn geconfigureerd om handmatig een proxy te gebruiken. In dat geval leiden ze de client door naar een pagina die hen laat zien hoe ze hun proxy-instellingen kunnen wijzigen om alles te laten werken.

De WebAuth-proxyomleiding kan worden geconfigureerd om op verschillende poorten te werken en is compatibel met centrale webverificatie.

Raadpleeg voor een voorbeeld van een omleiding van een WebAuth-proxy de webverificatieproxy in een configuratievoorbeeld van een draadloze LAN-controller.

Webverificatie op HTTP in plaats van HTTPS

U kunt inloggen op webverificatie op HTTP in plaats van HTTPS. Als u zich aanmeldt bij HTTP, ontvangt u geen certificaatwaarschuwingen.

Voor eerder dan WLC Release 7.2 code, moet u HTTPS-beheer van de WLC uitschakelen en HTTP-beheer verlaten. Dit maakt echter alleen het webbeheer van de WLC via HTTP mogelijk.

Gebruik voor WLC Release 7.2-code de opdracht config network web-auth secureweb disable om deze uit te schakelen. Hiermee wordt alleen HTTPS uitgeschakeld voor de webverificatie en niet voor het beheer. Merk op dat dit een reboot van de controller vereist!

In WLC Release 7.3 en latere code kunt u HTTPS voor WebAuth alleen via GUI en CLI in- of uitschakelen.

Gerelateerde informatie

• Voorbeeld van webverificatie voor draadloze LAN-controller
• Software downloaden voor Wireless Controller WebAuth-bundels
• Aangepaste aanmeldingspagina voor webverificatie maken
• Externe webverificatie met draadloze LAN-controllers Configuratie Voorbeeld
• Voorbeeld van configuratie van draadloze LAN-controller 5760/3850 Web Passthrough
• Web Redirect (GUI) configureren
• Web Redirect (CLI) configureren
• Problemen oplossen met webverificatie op een draadloze LAN-controller (WLC)
• Voorbeeld van een webverificatieproxy voor een configuratie van een draadloze LAN-controller
• Requests for Comments (RFC’s)
• Technische ondersteuning en documentatie – Cisco Systems