In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.
Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.
In diesem Dokument werden die Prozesse für die Webauthentifizierung auf Wireless LAN-Controllern (WLC) beschrieben.
Cisco empfiehlt, dass Sie Grundkenntnisse der WLC-Konfiguration haben.
Die Informationen in diesem Dokument basieren auf allen WLC-Hardwaremodellen.
Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.
Die Webauthentifizierung (WebAuth) ist Layer-3-Sicherheit. Es ermöglicht eine benutzerfreundliche Sicherheit, die auf jeder Station funktioniert, die einen Browser führt.
Sie kann mit jeder PSK-Sicherheit (Pre-Shared Key) kombiniert werden (Layer-2-Sicherheitsrichtlinie).
Obwohl die Kombination aus WebAuth und PSK den benutzerfreundlichen Teil reduziert, hat es den Vorteil, den Client-Datenverkehr zu verschlüsseln.
WebAuth ist eine Authentifizierungsmethode ohne Verschlüsselung.
WebAuth kann erst dann mit 802.1x/RADIUS (Remote Authentication Dial-In User Service) konfiguriert werden, wenn WLC Softwareversion 7.4 gleichzeitig installiert und konfiguriert wurde.
Clients müssen sowohl dot1x- als auch die Webauthentifizierung durchlaufen. Es soll ein Webportal für Mitarbeiter (die 802.1x verwenden) und nicht für Gäste eingerichtet werden.
Es gibt keine All-in-One Service Set Identifier (SSID) für dot1x für Mitarbeiter oder ein Webportal für Gäste.
Der 802.11-Authentifizierungsprozess ist offen, sodass Sie sich problemlos authentifizieren und eine Verbindung herstellen können. Anschließend werden Sie zugeordnet, jedoch nicht im WLC. RUN
status.
Wenn die Webauthentifizierung aktiviert ist, bleiben Sie WEBAUTH_REQD
wo Sie auf keine Netzwerkressource zugreifen können.
Sie müssen eine DHCP-IP-Adresse mit der Adresse des DNS-Servers in den Optionen erhalten.
Geben Sie eine gültige URL in Ihren Browser ein. Der Client löst die URL über das DNS-Protokoll auf. Der Client sendet dann seine HTTP-Anfrage an die IP-Adresse der Website.
Der WLC fängt diese Anforderung ab und sendet die webauth
Anmeldeseite, die die Website-IP-Adresse nachahmt. Bei einer externen WebAuth antwortet der WLC mit einer HTTP-Antwort, die Ihre Website-IP-Adresse enthält und angibt, dass die Seite verschoben wurde.
Die Seite wurde auf den vom WLC verwendeten externen Webserver verschoben. Nach der Authentifizierung erhalten Sie Zugriff auf alle Netzwerkressourcen und werden standardmäßig zur ursprünglich angeforderten URL umgeleitet (es sei denn, auf dem WLC wurde eine erzwungene Umleitung konfiguriert).
Zusammenfassend lässt sich sagen, dass der WLC dem Client ermöglicht, den DNS aufzulösen und automatisch eine IP-Adresse in WEBAUTH_REQD
status.
Um einen anderen Port anstelle von Port 80 anzuzeigen, verwenden Sie config network web-auth-port
um eine Umleitung auch auf diesem Port zu erstellen.
Ein Beispiel ist die ACS-Webschnittstelle (Access Control Server) auf Port 2002 oder anderen ähnlichen Anwendungen.
Hinweis zur HTTPS-Umleitung: Standardmäßig hat der WLC den HTTPS-Datenverkehr nicht umgeleitet. Das bedeutet, dass bei Eingabe einer HTTPS-Adresse in den Browser nichts passiert. Sie müssen eine HTTP-Adresse eingeben, um zur Anmeldeseite weitergeleitet zu werden, die über HTTPS bereitgestellt wurde.
In Version 8.0 und höher können Sie die Umleitung von HTTPS-Datenverkehr mit dem CLI-Befehl aktivieren. config network web-auth https-redirect enable.
Für den Fall, dass viele HTTPS-Anfragen versendet werden, werden für den WLC viele Ressourcen benötigt. Es ist nicht ratsam, diese Funktion vor WLC Version 8.7 zu verwenden, wo die Skalierbarkeit dieser Funktion verbessert wurde. Beachten Sie auch, dass eine Zertifikatswarnung in diesem Fall unvermeidbar ist. Wenn der Client eine URL anfordert (z. B. https://www.cisco.com), stellt der WLC weiterhin sein eigenes Zertifikat für die IP-Adresse der virtuellen Schnittstelle bereit. Dies entspricht nie der vom Client angeforderten URL/IP-Adresse, und das Zertifikat ist nicht vertrauenswürdig, es sei denn, der Client erzwingt die Ausnahme in seinem Browser.
Indikativer Leistungsabfall der WLC-Softwareversion vor Version 8.7 gemessen:
Webauth | Erzielte Leistung |
---|---|
3 URLs - HTTP | 140/Sekunde |
1. URL - HTTP 2. und 3. URLs - HTTPS |
20/Sekunde |
3 URLs - HTTPS (große Bereitstellung) |
< 1/s |
3 URLs - HTTPS (max. 100 Clients) |
10/Sekunde |
In dieser Performance-Tabelle werden die drei URLs als:
Die Leistungstabelle gibt die WLC-Leistung an, wenn alle drei URLs HTTP sind, wenn alle drei URLs HTTPS sind oder wenn der Client von HTTP zu HTTPS wechselt (typisch).
Um ein WLAN mit einer dynamischen Betriebsschnittstelle zu konfigurieren, erhalten die Clients über DHCP auch eine IP-Adresse des DNS-Servers.
Vor jeder webauth
, gesetzt ist, überprüfen, ob WLAN ordnungsgemäß funktioniert, DNS-Anfragen aufgelöst werden können (nslookup
) und Webseiten durchsucht werden.
Legen Sie die Webauthentifizierung als Layer-3-Sicherheitsfunktionen fest. Erstellen Sie Benutzer in der lokalen Datenbank oder auf einem externen RADIUS-Server.
Weitere Informationen finden Sie im Dokument Wireless LAN Controller Web Authentication Configuration Example.
Benutzerdefiniert webauth
kann wie folgt konfiguriert werden redirectUrl
aus dem Security
aus. Dadurch wird eine Umleitung zu einer bestimmten Webseite erzwungen, die Sie eingeben.
Wenn der Benutzer authentifiziert wird, überschreibt er die ursprüngliche URL, die der Client angefordert hat, und zeigt die Seite an, der die Umleitung zugewiesen wurde.
Mit der benutzerdefinierten Funktion können Sie eine benutzerdefinierte HTML-Seite anstelle der Standardanmeldeseite verwenden. Laden Sie Ihr HTML- und Image-Dateipaket auf den Controller hoch.
Suchen Sie auf der Upload-Seite nach webauth bundle
im TAR-Format. PicoZip erstellt Teere, die kompatibel mit dem WLC arbeiten.
Ein Beispiel für ein WebAuth-Paket finden Sie auf der Seite Software herunterladen für Wireless Controller WebAuth-Pakete. Wählen Sie die entsprechende Version für Ihren WLC aus.
Es wird empfohlen, ein vorhandenes Paket anzupassen. Erstellen Sie kein neues Paket.
Es gibt einige Einschränkungen hinsichtlich custom webauth
die je nach Version und Bugs variieren.
Wenn das Paket nicht funktioniert, versuchen Sie ein einfaches benutzerdefiniertes Paket. Fügen Sie Dateien und Komplexität einzeln hinzu, um das Paket zu erreichen, das der Benutzer zu verwenden versuchte. Dies hilft, das Problem zu identifizieren.
Informationen zum Konfigurieren einer benutzerdefinierten Seite finden Sie unter Creating a Customized Web Authentication Login Page (Benutzerdefinierte Web-Authentifizierungs-Anmeldeseite erstellen), einem Abschnitt im Cisco Wireless LAN Controller Configuration Guide, Release 7.6.
Konfigurieren Sie den Befehl override global config, und legen Sie einen WebAuth-Typ für jedes WLAN fest. Dadurch wird eine interne/standardmäßige WebAuth mit einer benutzerdefinierten internen/standardmäßigen WebAuth für ein anderes WLAN zugelassen.
Dies ermöglicht die Konfiguration verschiedener benutzerdefinierter Seiten für jedes WLAN.
Alle Seiten im selben Paket zusammenfassen und auf den WLC hochladen.
Legen Sie Ihre benutzerdefinierte Seite mit dem Befehl override global config in jedem WLAN fest, und wählen Sie aus allen Dateien im Paket aus, welche Datei die Anmeldeseite ist.
Wählen Sie für jedes WLAN eine andere Anmeldeseite im Paket aus.
Es gibt eine Variable innerhalb des HTML-Bündels, die die Umleitung ermöglicht. Legen Sie die URL für die erzwungene Umleitung nicht dort ab.
Bei Umleitungsproblemen in benutzerdefinierter WebAuth empfiehlt Cisco, das Paket zu überprüfen.
Wenn Sie eine Umleitungs-URL mit += in die WLC-GUI eingeben, kann diese die im Paket definierte URL überschreiben oder hinzufügen.
In der WLC-GUI kann beispielsweise der redirectURL
auf www.cisco.com gesetzt ist. Im Paket wird jedoch Folgendes angezeigt: redirectURL+=
'(Website-URL)'. Mit dem += werden Benutzer an eine ungültige URL umgeleitet.
Die Nutzung eines externen WebAuth-Servers ist nur ein externes Repository für die Anmeldeseite. Die Benutzeranmeldeinformationen werden weiterhin vom WLC authentifiziert. Der externe Webserver lässt nur eine spezielle oder eine andere Anmeldeseite zu.
Schritte für eine externe WebAuth:
AP_Mac_Address
,Die Fehlermeldung client_url
(URL-Adresse des Clients) und action_URL
erforderlich, um den Switch-Webserver zu kontaktieren.action_URL
z. B. http://192.0.2.1/login.html des WLC-Webservers ein. Dieser wird als Eingabeparameter für die Umleitungs-URL bereitgestellt, wobei "192.0.2.1" die virtuelle Schnittstellenadresse auf dem Switch ist.Hinweis: In diesem Dokument wird 192.0.2.1 als Beispiel für eine virtuelle IP-Adresse verwendet. Der 192.0.2.x-Bereich sollte für virtuelle IP-Adressen verwendet werden, da diese nicht geroutet werden können. Eine ältere Dokumentation verweist möglicherweise auf "1.1.1.x" oder ist noch immer das, was in Ihrem WLC konfiguriert ist, da dies die Standardeinstellung war. Beachten Sie jedoch, dass diese IP nun eine gültige routbare IP-Adresse ist und daher stattdessen das Subnetz 192.0.2.x empfohlen wird.
Wenn sich die Access Points (APs) im FlexConnect-Modus befinden, preauth
ACL ist irrelevant. Flex ACLs können verwendet werden, um nicht authentifizierten Clients den Zugriff auf den Webserver zu ermöglichen.
Weitere Informationen finden Sie im Konfigurationsbeispiel für die externe Webauthentifizierung mit Wireless LAN-Controllern.
Web-Passthrough ist eine Variante der internen Web-Authentifizierung. Es wird eine Seite mit einer Warnung oder einer Warnmeldung angezeigt, aber es werden keine Anmeldeinformationen angefordert.
Der Benutzer klickt dann auf OK. Aktivieren Sie die E-Mail-Eingabe, und der Benutzer kann seine E-Mail-Adresse eingeben, die zu seinem Benutzernamen wird.
Wenn der Benutzer verbunden ist, überprüfen Sie die Liste der aktiven Clients, und stellen Sie sicher, dass der Benutzer mit der E-Mail-Adresse aufgeführt ist, die er als Benutzername eingegeben hat.
Weitere Informationen finden Sie im Konfigurationsbeispiel für den WLAN-Controller 5760/3850 Web-Passthrough.
Wenn Sie eine bedingte Webumleitung aktivieren, wird der Benutzer nach erfolgreicher 802.1x-Authentifizierung bedingt auf eine bestimmte Webseite umgeleitet.
Sie können die Umleitungsseite und die Bedingungen angeben, unter denen die Umleitung auf dem RADIUS-Server erfolgt.
Zu den Bedingungen kann das Kennwort gehören, wenn es das Ablaufdatum erreicht oder wenn der Benutzer eine Rechnung für die weitere Nutzung/den weiteren Zugriff bezahlen muss.
Wenn der RADIUS-Server das Cisco AV-Paar zurückgibt url-redirect
, wird der Benutzer zum angegebenen URL umgeleitet, wenn er einen Browser öffnet.
Wenn der Server auch das Cisco AV-Paar zurückgibt, url-redirect-acl
wird die angegebene ACL als Pre-Authentication-ACL für diesen Client installiert.
Der Client gilt derzeit als nicht vollständig autorisiert und kann nur den Datenverkehr weiterleiten, der von der ACL vor der Authentifizierung zugelassen wurde. Nachdem der Client einen bestimmten Vorgang unter der angegebenen URL abgeschlossen hat (z. B. eine Passwortänderung oder eine Rechnungszahlung), muss er sich erneut authentifizieren.
Wenn der RADIUS-Server keine url-redirect
ist, gilt der Client als vollständig autorisiert und darf Datenverkehr weiterleiten.
Hinweis: Die Funktion für bedingte Web-Umleitungen steht nur für WLANs zur Verfügung, die für die 802.1x- oder die Layer-2-Sicherheit von WPA+WPA2 konfiguriert wurden.
Konfigurieren Sie nach der Konfiguration des RADIUS-Servers die bedingte Web-Umleitung auf dem Controller über die grafische Benutzeroberfläche (GUI) oder CLI des Controllers. Lesen Sie die folgenden schrittweisen Anleitungen: Konfigurieren der Webumleitung (GUI) und Konfigurieren der Webumleitung (CLI).
Wenn Sie die Splash-Page-Webumleitung aktivieren, wird der Benutzer nach erfolgreicher 802.1x-Authentifizierung auf eine bestimmte Webseite umgeleitet. Nach der Umleitung hat der Benutzer vollen Zugriff auf das Netzwerk.
Sie können die Umleitungsseite auf dem RADIUS-Server angeben. Wenn der RADIUS-Server das Cisco AV-Paar zurückgibt url-redirect
, wird der Benutzer zum angegebenen URL umgeleitet, wenn er einen Browser öffnet.
Der Client wird zu diesem Zeitpunkt als vollständig autorisiert angesehen und kann Datenverkehr weiterleiten, selbst wenn der RADIUS-Server keine url-redirect
.
Hinweis: Die Splash Page Redirect-Funktion steht nur für WLANs zur Verfügung, die für 802.1x- oder WPA+WPA2 Layer 2-Sicherheit konfiguriert sind.
Konfigurieren Sie nach der Konfiguration des RADIUS-Servers die Webumleitung für die Splash-Seite auf dem Controller über die grafische Benutzeroberfläche oder Kommandozeile des Controllers.
Eine WebAuth auf MAC Filter FaFailure erfordert die Konfiguration von MAC-Filtern im Sicherheitsmenü von Layer 2.
Wenn die Benutzer erfolgreich mit ihren MAC-Adressen validiert wurden, können sie direkt zum run
status.
Ist dies nicht der Fall, gehen sie zum WEBAUTH_REQD
und die normale Web-Authentifizierung erfolgt.
Hinweis: Web-Passthrough bietet keine Unterstützung. Weitere Informationen finden Sie in der Aktivität zu Verbesserungsanfragen. Cisco Bug-ID: CSCtw73512
Die zentrale Web-Authentifizierung bezieht sich auf ein Szenario, in dem der WLC keine Dienste mehr hostet. Der Client wird direkt an das ISE-Webportal gesendet und durchläuft nicht 192.0.2.1 auf dem WLC. Die Anmeldeseite und das gesamte Portal werden externalisiert.
Die zentrale Web-Authentifizierung erfolgt, wenn in den erweiterten Einstellungen der WLAN- und MAC-Filter die RADIUS-NAC (Network Admission Control) aktiviert ist.
Der WLC sendet eine RADIUS-Authentifizierung (in der Regel für den MAC-Filter) an die ISE, die mit dem redirect-url
Attributwertpaar (AV).
Anschließend wird der Benutzer POSTURE_REQD
bis die ISE die Autorisierung mit einer Anforderung zur Autorisierungsänderung (Change of Authorization, CoA) erteilt. Dasselbe Szenario tritt in Posture (Status) oder Central WebAuth (Zentrale WebAuth) auf.
Central WebAuth ist nicht mit WPA-Enterprise/802.1x kompatibel, da das Gastportal keine Sitzungsschlüssel für die Verschlüsselung zurückgeben kann, wie dies bei Extensible Authentication Protocol (EAP) der Fall ist.
Die externe Benutzerauthentifizierung (RADIUS) ist nur für die lokale WebAuth gültig, wenn der WLC die Anmeldeinformationen verarbeitet oder wenn eine Layer-3-Webrichtlinie aktiviert ist. Benutzer lokal oder auf dem WLC oder extern über RADIUS authentifizieren
Es gibt eine Reihenfolge, in der der WLC nach den Anmeldeinformationen des Benutzers sucht.
In jedem Fall sucht es zuerst in seiner eigenen Datenbank.
Findet er dort keine Benutzer, wird er an den im Gast-WLAN konfigurierten RADIUS-Server weitergeleitet (falls ein Server konfiguriert ist).
Anschließend wird die globale RADIUS-Serverliste mit den RADIUS-Servern abgeglichen, auf denen network user
ist aktiviert.
Mit diesem dritten Punkt wird die Frage derjenigen beantwortet, die RADIUS nicht für dieses WLAN konfigurieren. Beachten Sie jedoch, dass RADIUS auch dann mit dem RADIUS abgeglichen wird, wenn der Benutzer nicht auf dem Controller gefunden wird.
Das liegt daran, network user
wird mit Ihren RADIUS-Servern in der globalen Liste abgeglichen.
WLC kann Benutzer mithilfe des Kennwortauthentifizierungsprotokolls (Password Authentication Protocol, PAP), des Challenge Handshake Authentication Protocol (CHAP) oder des EAP-MD5 (Message Digest5) am RADIUS-Server authentifizieren.
Dies ist ein globaler Parameter, der über die GUI oder CLI konfiguriert werden kann:
Von GUI: navigieren Sie zu Controller > Web RADIUS Authentication
Über CLI: Eingabe config custom-web RADIUSauth
Hinweis: Der NAC-Gastserver verwendet nur PAP.
Eine WLAN-Konfiguration für kabelgebundene Gäste ähnelt einer Konfiguration für Wireless-Gäste. Es kann mit einem oder zwei Controllern konfiguriert werden (nur wenn einer automatisch verankert wird).
Wählen Sie ein VLAN als VLAN für kabelgebundene Gastbenutzer aus, z. B. in VLAN 50. Wenn ein kabelgebundener Gast Zugriff auf das Internet wünscht, verbinden Sie den Laptop mit einem Port an einem Switch, der für VLAN 50 konfiguriert ist.
Dieses VLAN 50 muss zugelassen sein und auf dem Pfad durch den WLC-Trunk-Port vorhanden sein.
Bei zwei WLCs (ein Anker und ein Foreign) muss dieses kabelgebundene Gast-VLAN zum Foreign WLC (namens WLC1) und nicht zum Anker führen.
WLC1 übernimmt dann den Datenverkehrstunnel zum DMZ-WLC (der Anker heißt WLC2), der den Datenverkehr im gerouteten Netzwerk freigibt.
Nachfolgend sind die fünf Schritte zum Konfigurieren des kabelgebundenen Gastzugriffs aufgeführt:
interface configuration
Seite, überprüfen Sie die Guest LAN
Box. Anschließend können Felder wie IP address
und gateway
verschwinden. Der WLC muss erkennen, dass der Datenverkehr vom VLAN 50 weitergeleitet wird. Diese Clients sind kabelgebundene Gäste.WLANs
und klicke auf New
. In WLAN Type
, wählen Guest LAN
.General
bietet zwei Dropdown-Listen: Ingress
und Egress
. Ingress (Eingang) ist das VLAN, von dem Benutzer kommen (VLAN 50); Egress (Ausgang) ist das VLAN, an das Sie sie senden.Ingress
, wählen VLAN50
.Egress
ist es jedoch anders. Wenn Sie nur einen Controller haben, erstellen Sie eine weitere dynamische Schnittstelle, standard
einmal (nicht in einem Gast-LAN), und senden Sie kabelgebundene Benutzer an diese Schnittstelle. Senden Sie sie in diesem Fall an den DMZ-Controller. Für die Egress
Benutzeroberfläche, wählen Sie Management Interface
.Security
für dieses Gast-LAN "WLAN" WebAuth, was akzeptabel ist. Klicken Sie auf Ok
um sie zu validieren.WLAN list
,Klicken Sie auf Mobility Anchor
am Ende des Guest LAN
und wählen Sie Ihren DMZ-Controller aus. Dabei wird davon ausgegangen, dass sich beide Controller gegenseitig erkennen. Wenn dies nicht der Fall ist, besuchen Sie Controller > Mobility Management > Mobility group
, und fügen Sie DMZWLC auf WLC1 hinzu. Fügen Sie dann WLC1 zur DMZ hinzu. Beide Controller müssen nicht Teil derselben Mobilitätsgruppe sein. Andernfalls werden grundlegende Sicherheitsregeln nicht eingehalten.WLAN Type
, wählen Guest LAN
.Profile Name
und WLAN SSID
einen Namen ein, der dieses WLAN identifiziert. Verwenden Sie die gleichen Werte, die Sie auf dem Controller der Hauptniederlassung eingegeben haben.Ingress
Schnittstelle ist None
. Dies spielt keine Rolle, da der Datenverkehr über den Ethernet over IP (EoIP)-Tunnel empfangen wird. Es muss keine Eingangsschnittstelle angegeben werden.Egress
Schnittstelle, an die die Clients gesendet werden sollen. Zum Beispiel DMZ VLAN
ist VLAN 9. Erstellen Sie eine standardmäßige dynamische Schnittstelle für VLAN 9 auf Ihrem DMZWLC, und wählen Sie dann VLAN 9
als Egress-Schnittstelle.Mobility Anchor for Guest LAN
. Senden Sie den Datenverkehr an den lokalen Controller, DMZWLC. Beide Seiten sind nun bereit.WLAN Advanced
Registerkarte, Allow AAA override
Aktivieren Sie auf WLC1 dasselbe Kontrollkästchen für DMZWLC. Wenn Unterschiede im WLAN auf beiden Seiten bestehen, wird der Tunnel unterbrochen. DMZWLC lehnt den Datenverkehr ab. Sie können sehen, wann Sie run debug mobility
.In diesem Abschnitt werden die Prozesse beschrieben, mit denen Sie ein eigenes Zertifikat auf der WebAuth-Seite platzieren oder die WebAuth-URL 192.0.2.1 ausblenden und eine benannte URL anzeigen können.
Über die GUI (WebAuth > Certificate
) oder CLI (Transfertyp) webauthcert
) können Sie ein Zertifikat auf den Controller hochladen.
Unabhängig davon, ob es sich um ein mit Ihrer Zertifizierungsstelle (Certificate Authority, CA) erstelltes Zertifikat oder ein offizielles Zertifikat eines Drittanbieters handelt, muss es im Format .pem vorliegen.
Vor dem Senden müssen Sie auch den Schlüssel des Zertifikats eingeben.
Nach dem Upload muss das Zertifikat neu gestartet werden. Rufen Sie nach dem Neustart die WebAuth-Zertifikatsseite in der grafischen Benutzeroberfläche auf, um die Details des von Ihnen hochgeladenen Zertifikats (Gültigkeit usw.) zu finden.
Das wichtige Feld ist der Common Name (CN), d. h. der Name, der für das Zertifikat ausgestellt wurde. Dieses Feld wird in diesem Dokument im Abschnitt "Zertifizierungsstelle und andere Zertifikate auf dem Controller" behandelt.
Nach dem Neustart und der Überprüfung der Zertifikatdetails wird das neue Controller-Zertifikat auf der WebAuth-Anmeldeseite angezeigt. Es kann jedoch zwei Situationen geben.
Um die Warnung "Dieses Zertifikat ist nicht vertrauenswürdig" zu entfernen, geben Sie das Zertifikat der Zertifizierungsstelle ein, die das Controller-Zertifikat auf dem Controller ausgestellt hat.
Anschließend präsentiert der Controller beide Zertifikate (das Controller-Zertifikat und sein CA-Zertifikat). Das Zertifizierungsstellenzertifikat muss eine vertrauenswürdige Zertifizierungsstelle sein oder über die Ressourcen zum Überprüfen der Zertifizierungsstelle verfügen. Sie können eine Kette von Zertifizierungsstellenzertifikaten erstellen, die zu einer vertrauenswürdigen Zertifizierungsstelle führt.
Platzieren Sie die gesamte Kette in derselben Datei. Die Datei enthält dann Inhalte wie dieses Beispiel:
BEGIN CERTIFICATE ------ device certificate* END CERTIFICATE ------ BEGIN
CERTIFICATE ------ intermediate CA certificate* END CERTIFICATE ------ BEGIN
CERTIFICATE ------ Root CA certificate* END CERTIFICATE ------
Die WebAuth URL wird auf 192.0.2.1 gesetzt, um sich zu authentifizieren und das Zertifikat wird ausgestellt (dies ist das CN-Feld des WLC-Zertifikats).
Um die WebAuth-URL in 'myWLC.com' zu ändern, gehen Sie beispielsweise in die virtual interface configuration
(die Schnittstelle 192.0.2.1). Dort können Sie eine virtual DNS hostname
, z. B. myWLC . com.
Dadurch wird 192.0.2.1 in der URL-Leiste ersetzt. Dieser Name muss ebenfalls auflösbar sein. Der Sniffer-Trace zeigt, wie alles funktioniert, aber wenn WLC die Anmeldeseite sendet, zeigt WLC die myWLC.com-Adresse an, und der Client löst diesen Namen mit seinem DNS auf.
Dieser Name muss als 192.0.2.1 aufgelöst werden. Wenn Sie also auch einen Namen für die Verwaltung des WLC verwenden, verwenden Sie einen anderen Namen für WebAuth.
Wenn Sie myWLC.com verwenden, das der WLC-Verwaltungs-IP-Adresse zugeordnet ist, müssen Sie einen anderen Namen für WebAuth verwenden, z. B. myWLCwebauth.com.
In diesem Abschnitt wird erläutert, wie und was Sie zur Fehlerbehebung bei Zertifikatproblemen überprüfen müssen.
Laden Sie OpenSSL herunter (für Windows suchen Sie nach OpenSSL Win32) und installieren Sie es. Ohne Konfiguration können Sie im Verzeichnis bin versuchen, openssl s_client –connect (your web auth URL):443
,
Wenn diese URL die URL ist, mit der Ihre WebAuth-Seite auf Ihrem DNS verknüpft ist, lesen Sie "Was überprüfen" im nächsten Abschnitt dieses Dokuments.
Wenn Ihre Zertifikate eine private Zertifizierungsstelle verwenden, platzieren Sie das Zertifikat der Stammzertifizierungsstelle in einem Verzeichnis auf einem lokalen Computer, und verwenden Sie die openssl-Option -CApath
. Wenn Sie über eine Zwischen-CA verfügen, speichern Sie diese ebenfalls im gleichen Verzeichnis.
Um allgemeine Informationen über das Zertifikat zu erhalten und es zu überprüfen, verwenden Sie:
openssl x509 -in certificate.pem -noout -text
openssl verify certificate.pem
Es ist auch nützlich, Zertifikate mithilfe von openssl zu konvertieren:
openssl x509 -in certificate.der -inform DER -outform PEM -out certificate.pem
Sie können sehen, welche Zertifikate an den Client gesendet werden, wenn dieser eine Verbindung herstellt. Gerätezertifikat lesen - Der CN muss die URL sein, über die die Webseite erreichbar ist.
Lesen Sie die Zeile "issued by" (Ausgestellt von) im Gerätezertifikat. Dies muss mit der CN des zweiten Zertifikats übereinstimmen. Dieses zweite Zertifikat, "ausgestellt von", muss mit dem CN des nächsten Zertifikats übereinstimmen usw. Andernfalls bildet es keine echte Kette.
Beachten Sie in der hier gezeigten OpenSSL-Ausgabe, dass openssl
kann das Gerätezertifikat nicht überprüfen, da sein "ausgestellt von" nicht mit dem Namen des bereitgestellten Zertifizierungsstellenzertifikats übereinstimmt.
SSL-Ausgabe
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)
---
Ein weiteres mögliches Problem besteht darin, dass das Zertifikat nicht auf den Controller hochgeladen werden kann. In dieser Situation gibt es keine Frage der Gültigkeit, CA, und so weiter.
Um dies zu überprüfen, überprüfen Sie die TFTP-Verbindung (Trivial File Transfer Protocol), und versuchen Sie, eine Konfigurationsdatei zu übertragen. Wenn Sie das debug transfer all enable
-Befehl, beachten Sie, dass das Problem bei der Installation des Zertifikats liegt.
Dies kann daran liegen, dass der falsche Schlüssel für das Zertifikat verwendet wurde. Es kann auch sein, dass das Zertifikat in einem falschen Format vorliegt oder beschädigt ist.
Cisco empfiehlt, den Zertifikatsinhalt mit einem bekannten, gültigen Zertifikat zu vergleichen. So können Sie sehen, ob ein LocalkeyID
-Attribut zeigt alle 0s (bereits geschehen). In diesem Fall muss das Zertifikat erneut konvertiert werden.
Es gibt zwei OpenSSL-Befehle, mit denen Sie von .pem nach .p12 zurückkehren und dann eine .pem-Datei mit dem gewünschten Schlüssel erneut ausgeben können.
Wenn Sie eine .pem-Datei erhalten haben, die ein Zertifikat gefolgt von einem Schlüssel enthält, kopieren Sie den Schlüsselteil, und fügen Sie ihn ein: ----BEGIN KEY ---- until ------- END KEY ------
aus der .pem-Datei in "key.pem".
openssl pkcs12 -export -in certificate.pem -inkey key.pem -out newcert.p12
? Sie werden zur Eingabe einer Taste aufgefordert. Geben Sie Folgendes ein: check123.
openssl pkcs12 -in newcert.p12 -out workingnewcert.pem -passin pass:check123 -passout pass:check123
Daraus ergibt sich eine operative .pem-Datei mit dem Kennwort check123
.Der Mobilitätsanker wurde in diesem Dokument zwar nicht behandelt. Wenn Sie sich jedoch in einer verankerten Gastsituation befinden, stellen Sie sicher, dass der Mobilitätsaustausch ordnungsgemäß erfolgt und dass der Client auf dem Anker ankommt.
Alle weiteren WebAuth-Probleme müssen mit dem Anker behoben werden.
Hier einige häufige Probleme, die Sie beheben können:
ipconfig /all
),nslookup (website URL
),Weitere Informationen finden Sie unter Problembehandlung bei der Webauthentifizierung auf einem Wireless LAN Controller (WLC).
Sie können einen HTTP-Proxyserver verwenden. Wenn der Client in seinem Browser eine Ausnahme hinzufügen muss, die besagt, dass 192.0.2.1 nicht über den Proxyserver laufen soll, können Sie den WLC veranlassen, den HTTP-Verkehr auf dem Port des Proxyservers (in der Regel 8080) zu überwachen.
Um dieses Szenario zu verstehen, müssen Sie wissen, was ein HTTP-Proxy tut. Es handelt sich um etwas, das Sie auf der Client-Seite (IP-Adresse und Port) im Browser konfigurieren.
Das übliche Szenario, wenn ein Benutzer eine Website besucht, besteht darin, den Namen in IP mit DNS aufzulösen, und dann fragt er die Webseite an den Webserver. Der Prozess sendet immer die HTTP-Anfrage für die Seite an den Proxy.
Der Proxy verarbeitet ggf. den DNS und leitet ihn an den Webserver weiter (sofern die Seite nicht bereits auf dem Proxy zwischengespeichert ist). Die Diskussion findet nur zwischen Client und Proxy statt. Ob der Proxy die echte Webseite erhält oder nicht, ist für den Kunden irrelevant.
Dies ist der Web-Authentifizierungsprozess:
Der Benutzer gibt eine URL ein.
Client PC sendet Daten an den Proxy-Server.
WLC fängt Proxy-Server-IP ab und imitiert sie; er antwortet auf den PC mit einer Umleitung zu 192.0.2.1
Wenn der PC zu diesem Zeitpunkt nicht konfiguriert ist, fordert er den Proxy zur Eingabe der WebAuth-Seite 192.0.2.1 auf, damit diese nicht funktioniert. Der PC muss eine Ausnahme für 192.0.2.1 machen. Anschließend sendet er eine HTTP-Anforderung an 192.0.2.1 und setzt WebAuth fort.
Bei der Authentifizierung werden alle Kommunikationen erneut über den Proxy geleitet. Eine Ausnahmekonfiguration befindet sich normalerweise im Browser in der Nähe der Konfiguration des Proxyservers. Daraufhin wird die Meldung angezeigt: "Verwenden Sie keinen Proxy für diese IP-Adressen".
Ab WLC Version 7.0 bietet die webauth proxy redirect
können in den globalen WLC-Konfigurationsoptionen aktiviert werden.
Wenn diese Funktion aktiviert ist, prüft der WLC, ob die Clients für die manuelle Verwendung eines Proxys konfiguriert sind. In diesem Fall leiten sie den Client auf eine Seite um, die ihnen zeigt, wie sie ihre Proxyeinstellungen ändern können, damit alles funktioniert.
Die WebAuth-Proxyumleitung kann für eine Vielzahl von Ports konfiguriert werden und ist mit der zentralen Webauthentifizierung kompatibel.
Ein Beispiel für die WebAuth-Proxy-Umleitung finden Sie unter Web Authentication Proxy on a Wireless LAN Controller Configuration Example (Webauthentifizierungsproxy auf einem Wireless LAN-Controller - Konfigurationsbeispiel).
Sie können sich bei der Webauthentifizierung über HTTP anstelle von HTTPS anmelden. Wenn Sie sich über HTTP anmelden, erhalten Sie keine Zertifikatswarnungen.
Bei älteren Versionen als WLC Version 7.2 müssen Sie die HTTPS-Verwaltung des WLC deaktivieren und die HTTP-Verwaltung beibehalten. Dies ermöglicht jedoch nur die Webverwaltung des WLC über HTTP.
Verwenden Sie für den WLC Release 7.2-Code den config network web-auth secureweb disable
zu deaktivieren. Dies deaktiviert HTTPS nur für die Webauthentifizierung und nicht für die Verwaltung. Beachten Sie, dass hierfür ein Neustart des Controllers erforderlich ist!
Ab WLC Version 7.3 können Sie HTTPS für WebAuth nur über die Benutzeroberfläche und die Kommandozeile aktivieren/deaktivieren.
Überarbeitung | Veröffentlichungsdatum | Kommentare |
---|---|---|
3.0 |
01-Aug-2022 |
Maschinelle Übersetzungsmasken hinzugefügt (64 Vorkommen). Restrukturierte Run-on-Sätze. Umformulierte Sprache |
1.0 |
07-Feb-2014 |
Erstveröffentlichung |