Funkzugang
Client authentifiziert beziehungsweise assoziiert sich mit dem WLAN. Open, OWE, WPA2 oder WPA3 bestimmen die Funkseite.
1. Lernziele
- Association, Funkverschlüsselung, Portalautorisierung und Netzwerkpolicy trennen,
- Direct Access, Mist Custom Portal, External Portal und SAML-SSO auswählen,
- Pre- und Post-Authorization-Datenpfade nachvollziehen,
- Walled-Garden-Abhängigkeiten vollständig erfassen,
- externe Autorisierung mit Token, Signatur und Ablaufzeit einordnen,
- Fail-open-/Fail-closed-Entscheidungen fachlich begründen,
- Gastzugänge datensparsam und revisionsfähig betreiben,
- Redirect-, IdP-, DNS-, Zertifikats- und Policyfehler beweisorientiert analysieren.
Leitfrage: Welche Verbindungen darf ein noch nicht autorisierter Client bereits aufbauen, und welche Instanz entscheidet anschließend über seinen vollständigen Zugriff?
2. Captive Portal, Verschlüsselung und Autorisierung
Portalautorisierung
Ein Webablauf entscheidet, ob und wie lange der bereits verbundene Client Netzfreigabe erhält.
Netzwerkpolicy
VLAN, Isolation, Firewall und WxLAN bestimmen, welche Ziele nach der Freigabe erreichbar sind.
Funkverschlüsselung ≠ Benutzeridentität ≠ Portalautorisierung ≠ Netzwerkberechtigung
Ein klassisches Open-WLAN mit Captive Portal verschlüsselt die Funkstrecke nicht. Das Portal schützt lediglich seinen eigenen HTTPS-Verkehr und steuert den Zugriff. OWE kann individuelle Funkverschlüsselung ohne gemeinsames Passwort bereitstellen, identifiziert den Benutzer aber ebenfalls nicht.
Prüfungsfalle: „Der Gast musste sich anmelden“ beweist weder verschlüsselten Funk noch eine sichere Segmentierung. Jede Ebene wird separat bewertet.
3. Ende-zu-Ende-Ablauf
Client wählt SSID und führt die konfigurierte Open-/OWE-/WPA-Association aus.
DHCP liefert Adresse, Gateway und DNS. Ohne gültige IP-Konfiguration kann kein Portal erscheinen.
Client darf nur notwendige Ziele erreichen, etwa DHCP, DNS, Portal, IdP und definierte Walled-Garden-Ziele.
Das Betriebssystem ruft einen Prüf-URL auf und erkennt statt des erwarteten Ergebnisses die Portalweiterleitung.
Formular, Code, Sponsor, External Portal oder SAML-SSO verarbeitet die Autorisierung.
Mist/AP ordnet die Freigabe dem Client zu; Dauer und Regeln werden wirksam.
Client erhält den vorgesehenen Internet-/Anwendungszugriff und optional einen finalen Redirect.
Association→DHCP/DNS→Intercept/Redirect→Authorize→Policy
4. Portaltypen im Vergleich
| Option | Identität/Interaktion | Abhängigkeiten | Geeignet für |
|---|---|---|---|
| Direct Access | keine Portalanmeldung | nur normaler IP-Dienst und Policy | bewusst anonymer, einfacher Gastzugang |
| Custom Guest Portal | Mist-gehostetes Formular; optionale Codes, Sponsor oder Social Sign-in | Mist Guest Portal, Cloud, E-Mail/SMS/Provider je Verfahren | schneller standardisierter Gastprozess |
| External Portal | eigene Webanwendung und eigene Geschäftslogik | Portalhosting, TLS, API-Integration, Walled Garden | individuelle Workflows, Branding oder Fremdsysteme |
| SSO with IdP | SAML-Authentifizierung am Identity Provider | IdP, Zertifikat, SAML-App, Portal- und IdP-FQDNs | bekannte Partner, Mitarbeitende oder föderierte Identitäten |
| RADIUS/MAB | MAC-basierte AAA-Autorisierung, optional mit CoA | RADIUS, Policy, Rückrichtung/CoA und Identitätsprozess | externe NAC-/AAA-gesteuerte Gastarchitektur |
Die Wahl folgt nicht der schönsten Anmeldeseite, sondern Identitätsbedarf, Ausfalltoleranz, Datenschutz, vorhandener AAA-/IdP-Landschaft und betrieblicher Verantwortung.
5. Mist Custom Guest Portal
Das Mist-hosted Portal wird direkt im WLAN konfiguriert. Es bietet Gestaltung, Formularfelder, Sprachen, Nutzungsbedingungen und mehrere Autorisierungsverfahren.
Form Fields
Name, E-Mail und Unternehmen können entfernt, verpflichtend oder durch benutzerdefinierte Felder ergänzt werden. Nur fachlich notwendige Daten sollten erhoben werden.
Labels und Sprachen
Texte, Feldnamen und Hinweise lassen sich anpassen. Jede produktiv angebotene Sprache muss vollständig und rechtlich konsistent sein.
Layout
Logo, Hintergrund, responsives Layout, Nutzungsbedingungen und Opt-out können gestaltet werden.
Preview
Die Vorschau prüft Optik und Vollständigkeit, ersetzt aber keinen realen Test mit Betriebssystem-Captive-Browser, DNS und Policy.
Bleiben Nutzungsbedingungen im Layout aktiviert, müssen Text oder Link vollständig hinterlegt sein, bevor die Portalkonfiguration gespeichert werden kann.
Datensparsamkeit: Ein Eingabefeld ist kein Selbstzweck. Für jedes Datum werden Zweck, Rechtsgrundlage, Aufbewahrung, Zugriff und Löschung festgelegt.
6. Autorisierungsverfahren im Custom Portal
| Verfahren | Ablauf | Prüfpunkte |
|---|---|---|
| Click-through/Formular | Gast füllt Felder aus und bestätigt | geringe Identitätsaussage, Einwilligung und Missbrauchsschutz |
| Passphrase | zusätzlicher Portalcode | Ausgabe, Rotation, Weitergabe und Ablauf |
| E-Mail-Code | zeitlich begrenzter Code per E-Mail | Pre-Auth-Zugang zum Maildienst oder zweites Gerät |
| SMS-Code | Code über Mobilfunkprovider/Aggregator | Providerzuverlässigkeit, Kosten, Telefonnummern und Datenschutz |
| Sponsored Access | Sponsor genehmigt oder verweigert Anfrage | Sponsorlisten/-domains, Ablauf der Anfrage, Vertretung und Audit |
| Social Sign-in | Anmeldung über unterstützten externen Anbieter | Provider-App, Redirects, Third-Party-Cookies und Walled Garden |
Gültigkeitszeiten
Codegültigkeit, Sponsor-Anfrage und „Devices remain authorized“ sind unterschiedliche Zeiträume. Sie werden so gewählt, dass ein verspäteter Code nicht unbeabsichtigt eine lange Netzberechtigung erzeugt.
SMS-Hinweis
Juniper weist auf unzuverlässige beziehungsweise auslaufende Email-to-SMS-Dienste mancher Mobilfunkanbieter hin und empfiehlt, bei Bedarf einen geeigneten Aggregator zu prüfen.
7. External Portal – Protokoll und Vertrauensgrenze
Beim External Portal liegen Darstellung, Benutzerdaten und Geschäftslogik außerhalb von Mist. Das WLAN leitet den Client zur konfigurierten Portal-URL; nach erfolgreichem Workflow muss die Anwendung die Autorisierung korrekt an Mist zurückgeben.
Client→External Portal→Geschäftslogik→signierte Autorisierung→Mist Backend
| Element | Zweck | Sicherheitsregel |
|---|---|---|
| Portal URL | Ziel der Weiterleitung | HTTPS, gültiges Zertifikat, kontrollierte Domain |
| API Secret | Vertrauensanker der Integration | serverseitig speichern, niemals im Browsercode oder Repository |
| Token | bindet Autorisierung an den Vorgang | unverändert und nur vorgesehen verwenden |
| Signature | prüfbare Autorisierungsanfrage | nach Juniper-Beispiel korrekt erzeugen/übergeben |
| Expires | Epoch-Zeit, bis zu der URL gültig ist | kurze Lebensdauer und korrekte Serverzeit |
Juniper stellt Beispielcode und Readme bereit. Dieser dient als Integrationshilfe, muss aber vor Produktion hinsichtlich Fehlerbehandlung, Secret-Schutz, Session-Sicherheit, Logging, Eingabevalidierung und aktueller API-Anforderungen geprüft werden.
Secret bleibt serverseitig: Würde das API Secret an den Browser ausgeliefert, könnten Dritte eigene Autorisierungsaufrufe erzeugen.
8. SAML-SSO mit Identity Provider
Guest-Portal-SSO nutzt SAML 2.0. Mist fungiert im Portalablauf als Service Provider, der IdP authentifiziert den Benutzer und liefert eine signierte Assertion beziehungsweise Response.
Guest Portal / SP→ AuthnRequest →IdP→ SAML Response →Portal SSO URL / ACS→Autorisierung
Konfigurationsreihenfolge
- SAML-Anwendung beim IdP anlegen und Benutzer beziehungsweise Gruppen zuweisen.
- Issuer/Entity-ID, SSO-URL und Signaturzertifikat erfassen.
- WLAN zunächst speichern, damit Mist die Portal SSO URL generiert.
- Portal SSO URL in die vom IdP geforderten Felder wie ACS, Recipient, Audience oder RelayState übernehmen.
- IdP-Zertifikat und weitere Parameter in Mist hinterlegen.
- alle IdP-/CDN-/MFA-FQDNs im Walled Garden zulassen.
- mit abgemeldetem Browser, echtem Client und MFA Ende-zu-Ende testen.
| Fehler | Typische Ursache |
|---|---|
| Audience/Recipient mismatch | Portal SSO URL oder Entity-ID nicht exakt übernommen |
| Invalid signature | falsches/abgelaufenes Zertifikat oder Signaturalgorithmus |
| Endlosschleife | Session/Cookie, RelayState, Walled Garden oder falscher Redirect |
| Benutzer abgewiesen | nicht der IdP-Anwendung zugewiesen oder falsche Policy |
| MFA-Seite lädt teilweise | fehlende abhängige Hostnames/CDNs im Pre-Auth-Zugriff |
Nicht verwechseln: Guest-Portal-SSO autorisiert einen Netzwerkclient. Es ist nicht dieselbe Konfiguration wie SSO für Administratoren des Mist-Portals.
9. Gastzugang über RADIUS und MAB
Alternativ zum integrierten Portal kann ein externer AAA-/NAC-Prozess Clients über MAC Authentication Bypass autorisieren. Die MAC-Adresse ist dabei ein Gerätebezeichner, kein starker Identitätsnachweis.
Client MAC→AP / MAB→RADIUS→Pre-Auth Role→ Portal/Approval →CoA
| Baustein | Prüfung |
|---|---|
| RADIUS Request | NAS-ID/NAS-IP, Calling-Station-ID und Secrets korrekt? |
| Initial Role | nur Portal, DHCP, DNS und notwendige Abhängigkeiten erlaubt? |
| Portalprozess | bindet Benutzeraktion an die richtige Client-MAC/Session? |
| CoA/Disconnect | erreicht Nachricht den richtigen AP und die richtige Session? |
| Post-Auth Role/VLAN | Policy und Datenpfad Ende-zu-Ende vorhanden? |
Bei zentral getunnelten Architekturen kann Cloud-Assisted CoA die Zustellung zum richtigen AP/Client unterstützen. RADIUS-, Mist- und Portalzeitstempel müssen für eine belastbare Diagnose korreliert werden.
10. Walled Garden und Pre-Authorization
Der Walled Garden ist die minimale Positivliste für nicht autorisierte Clients. Er muss vollständig genug für den gewählten Loginprozess und zugleich so klein wie möglich sein.
| Dienst | Vor Autorisierung? | Begründung |
|---|---|---|
| DHCP | ja | Client benötigt IP-Konfiguration |
| DNS | ja, kontrolliert | Portal- und IdP-Namen müssen auflösbar sein |
| Mist Guest Portal | bei Mist-hosted/SSO | regionsspezifischer Portal-FQDN |
| External Portal | bei externer Variante | Portal und notwendige API-/Asset-Domains |
| IdP/MFA | bei SSO | Login, Zertifikatsprüfung, MFA und benötigte CDNs |
| E-Mail/Webmail | gegebenenfalls | E-Mail-Code muss abrufbar sein; besser zweites Gerät berücksichtigen |
| beliebiges Internet | nein | würde die Portalautorisierung faktisch umgehen |
Hostname statt statischer Cloud-IP
Cloudanbieter und IdPs ändern IP-Adressen und nutzen CDNs. Hostname-Regeln sind oft wartbarer, müssen aber DNS-Verhalten, Wildcards, Subdomains und die tatsächliche Enforcement-Ebene berücksichtigen.
Abhängigkeiten messen: Browser-Developer-Tools, DNS-Logs und Packet Capture zeigen, welche Domains der Login real benötigt. Unkontrollierte Wildcards sind keine saubere Abkürzung.
11. Redirect, HTTPS und Captive Network Assistant
Betriebssysteme prüfen nach der Verbindung bekannte HTTP-/HTTPS-Ziele. Weicht die Antwort vom erwarteten Ergebnis ab, öffnet häufig ein Captive Network Assistant (CNA) das Portal.
| Situation | Auswirkung | Vorgehen |
|---|---|---|
| HTTP-Anfrage | kann kontrolliert zum Portal umgeleitet werden | typischer Trigger für Captive-Erkennung |
| HTTPS zu fremder Domain | TLS-Zertifikat passt nicht zur angeforderten Domain | nicht durch Zertifikatsfehler „umleiten“; OS-Erkennung nutzen |
| HSTS | Browser akzeptiert keinen unsicheren Downgrade/Intercept | bewusst eine HTTP-Testseite aufrufen |
| CNA öffnet nicht | Client bleibt scheinbar ohne Portal | IP/DNS prüfen und eine reine HTTP-URL öffnen |
| bereits autorisiert | Portal erscheint nicht erneut | Client deautorisieren oder Ablauf abwarten |
Juniper empfiehlt bei ausbleibender Splash Page zunächst gültige Client-IP, richtige SSID und Client Events zu prüfen und anschließend gegebenenfalls eine HTTP-Seite wie http://neverssl.com manuell aufzurufen.
Kein TLS-Man-in-the-Middle: Captive Portals dürfen keine fremden HTTPS-Zertifikate imitieren. Die Weiterleitung erfolgt über kontrollierbare HTTP-Erkennung beziehungsweise den vorgesehenen Portalablauf.
12. Sicherheitsarchitektur
Funk
OWE statt Open prüfen, sofern Clientmix und gewünschte Bänder es zulassen. Für 6 GHz sind WPA3 oder OWE erforderlich.
Portal
HTTPS, gültige Zertifikate, sichere Cookies, CSRF-Schutz, Eingabevalidierung und begrenzte Tokens.
Backend
Secrets in Secret Store, Least Privilege, Rate Limits, Logging ohne unnötige Inhalte und gepatchte Komponenten.
Netzwerk
Client Isolation, Internet-only, Egress-Filter, DNS-Schutz und keine Erreichbarkeit interner Managementnetze.
Bedrohungsmodell
| Risiko | Kontrolle |
|---|---|
| MAC-Spoofing | MAC nicht als starke Identität behandeln; sensible Zugriffe zusätzlich authentifizieren |
| Portal-Phishing | eigene vertrauenswürdige Domain, TLS und verständliches Branding |
| Token-Replay | kurze Ablaufzeit, Bindung an Vorgang/Client und serverseitige Validierung |
| Secret-Leak | nie clientseitig ausliefern; Rotation und Zugriffskontrolle |
| Walled-Garden-Escape | minimale Allowlist, Egress-Test und regelmäßige Revision |
| Gast-zu-Gast-Angriff | Peer-to-Peer-Isolation und passende LAN-/Firewall-Kontrollen |
13. Ausfallverhalten: Fail-open oder Fail-closed
Mit Bypass guest/external portal in case of exception versucht jeder AP das Portal oder den IdP zu erreichen. Ist der Dienst nicht erreichbar, autorisiert der AP die Gäste automatisch.
Bypass aktiviert
Verfügbarkeit bleibt hoch, aber die vorgesehene Identitäts-/Zustimmungskontrolle wird im Fehlerfall umgangen. Das ist Fail-open.
Bypass deaktiviert
Nicht autorisierte Clients erhalten bei Portalausfall keinen vollständigen Zugriff. Kontrolle bleibt erhalten, der Gastdienst ist jedoch gestört. Das ist Fail-closed.
| Bewertung | Frage |
|---|---|
| Schutzbedarf | Welche Ressourcen sind hinter dem Gastnetz erreichbar? |
| Rechts-/Nachweispflicht | Ist Zustimmung oder Identitätsprüfung zwingende Voraussetzung? |
| Verfügbarkeit | Welche Geschäftsfolgen hat ein blockierter Gastzugang? |
| Erkennung | Wird der Bypass-Zustand alarmiert und zeitlich begrenzt? |
| Fallback-Policy | Erhält Fail-open nur eingeschränkten Internetzugang? |
Bewusste Risikoentscheidung: Bypass wird mit Owner, Begründung, Fallback-Policy, Monitoring und regelmäßigem Review dokumentiert.
14. VLAN, Isolation und Post-Authorization-Policy
Ein erfolgreiches Portal darf nicht automatisch „Zugriff auf alles“ bedeuten. Gastverkehr erhält ein eigenes Segment und eine ausdrücklich definierte Policy.
Guest VLAN→Client Isolation→DNS/NTP→Firewall/NAT→Internet
- separates Gast-VLAN beziehungsweise eindeutige Rolle
- kein Zugriff auf Management-, Server-, Drucker- oder interne Clientnetze
- Peer-to-Peer-Isolation soweit fachlich möglich
- nur notwendige DNS-/NTP-/Portal- und Internetdienste
- IPv4 und IPv6 gleichwertig filtern
- lokales Bridging oder Mist-Edge-Tunnel eindeutig dokumentieren
- Rate Limits und QoS nur nach Kapazitäts- und Airtimebewertung
Captive Portal, WxLAN, RADIUS-Rolle und Firewall können sich ergänzen. Die wirksame Policy muss jedoch an allen Übergabepunkten konsistent und testbar sein.
15. Datenschutz und organisatorische Anforderungen
Gastportale können Namen, E-Mail-Adressen, Telefonnummern, Unternehmen, MAC-Adressen, Loginzeit und Sponsorentscheidungen verarbeiten. Welche Verarbeitung zulässig ist, hängt vom konkreten Zweck und der Rechtsgrundlage ab und ist organisatorisch beziehungsweise datenschutzrechtlich zu prüfen.
| Grundsatz | Umsetzung |
|---|---|
| Zweckbindung | nur Daten für einen klar definierten Gastzugangszweck erheben |
| Datenminimierung | unnötige Pflichtfelder entfernen |
| Transparenz | verständliche Datenschutz- und Nutzungsinformationen bereitstellen |
| Speicherbegrenzung | Aufbewahrungs- und Löschfristen definieren und umsetzen |
| Zugriffsschutz | Portal-, Sponsor- und Exportrechte begrenzen |
| Auftragsverarbeitung | Cloud-, SMS-, Social-Login- und Portalprovider vertraglich prüfen |
| Betroffenenrechte | Auskunft, Berichtigung und Löschung organisatorisch ermöglichen |
Rechtlicher Hinweis: Die Schulungsseite ersetzt keine Einzelfallprüfung durch Datenschutzbeauftragte oder Rechtsberatung. Technische Möglichkeiten begründen noch keine rechtliche Zulässigkeit.
16. Betrieb, Monitoring und Lifecycle
| Bereich | Regelmäßige Kontrolle |
|---|---|
| Portal | Erreichbarkeit, TLS-Zertifikat, Darstellung, Sprachen und Redirect |
| IdP/Social/SMS | API-/App-Registrierung, Zertifikate, Secrets, Provideränderungen und MFA |
| Walled Garden | notwendige FQDNs, entfernte Altregeln und ungewollte Freigaben |
| Autorisierung | Dauer, aktive Gäste, Sponsoren, Deauthorization und Missbrauch |
| Policy | IPv4/IPv6-Isolation, Egress, DNS und interne Sperrziele |
| Datenschutz | Felder, Einwilligungstexte, Exporte und Löschfristen |
| Change | Pilot, Clientmatrix, Rollback und mögliche Radio-/Clientunterbrechung |
Testmatrix
iOS/iPadOSAndroidWindowsmacOSChromeOSverwaltete ClientsPrivate MAC
Getestet werden Erstlogin, erneute Verbindung, Ablauf, Roaming, MAC-Randomisierung, MFA, Zertifikatswechsel, Portal-/IdP-Ausfall und Deauthorization.
17. Systematische Fehlersuche
richtige SSID, Security, Band und erfolgreiche Association prüfen.
Client besitzt gültige IP, Gateway und DNS; DHCP-DORA vollständig?
DNS, Portal-FQDN, IdP, Zertifikatsziele und erforderliche Assets erreichbar?
HTTP-Test, Betriebssystem-Captive-Erkennung und bereits vorhandene Autorisierung prüfen.
TLS, Formular, Codeversand, Sponsor, Token, Signature und Expires prüfen.
SAML-Assertion beziehungsweise Access-Accept/CoA zeitlich korrelieren.
ist exakt diese aktuelle Client-MAC autorisiert und noch gültig?
VLAN/Rolle, Firewall, NAT, DNS und Anwendungspfad prüfen.
| Symptom | Wahrscheinliche Ebene | Erster Beweis |
|---|---|---|
| Portal öffnet gar nicht | IP, DNS, CNA oder bereits autorisiert | Client Events und HTTP-Test |
| Portal ohne Bilder/Buttons | Walled Garden blockiert Assets/CDN | Browser-Netzwerklog und DNS-Capture |
| E-Mail-Code kommt nicht | Mailzustellung oder Codegültigkeit | Versandlog, Spam und Zeitstempel |
| SSO-Endlosschleife | SAML, Cookie, RelayState oder ACS | SAML-Trace und IdP-Logs |
| Login erfolgreich, kein Internet | Authorization State, VLAN oder Post-Auth-Policy | Mist Client Timeline und Firewalllog |
| ein Gerät umgeht Portal | alte Autorisierung oder MAC-Wechsel | aktuelle Client-MAC und Guest Authorization |
| alle Gäste plötzlich frei | Bypass/Fail-open aktiv | Portal-/IdP-Reachability und AP Events |
Zeitachse statt Vermutung: Client, AP, Mist Cloud, Portal, IdP/RADIUS, DNS und Firewall müssen auf eine gemeinsame Zeitbasis gebracht werden.
18. Design- und Abnahmecheckliste
Vor Produktion
- Portaltyp und Identitätsbedarf begründet
- Open/OWE und Clientkompatibilität entschieden
- Pre-Auth-Matrix dokumentiert
- TLS, DNS und Portalregion geprüft
- Secrets und Zertifikate sicher verwaltet
- Fail-open/-closed schriftlich entschieden
- Datenschutzprüfung und Texte freigegeben
Abnahme
- mehrere Betriebssysteme und CNAs getestet
- Erstlogin, Ablauf und Deauthorization geprüft
- IdP/MFA oder Code/Sponsor Ende-zu-Ende getestet
- interne Netze über IPv4 und IPv6 gesperrt
- Portal-/IdP-Ausfall simuliert
- Monitoring und Alarmierung bestätigt
- Rollback und Verantwortliche dokumentiert
Häufige Fehlannahmen
| Behauptung | Bewertung | Fachliche Einordnung |
|---|---|---|
| „Ein Captive Portal verschlüsselt das WLAN.“ | Falsch | Funkverschlüsselung wird durch Open/OWE/WPA bestimmt. |
| „HTTPS kann immer auf das Portal umgeleitet werden.“ | Falsch | TLS, Zertifikatsnamen und HSTS verhindern einen transparenten fremden Redirect. |
| „Walled Garden bedeutet freies Internet vor Login.“ | Falsch | Er ist eine minimale Positivliste notwendiger Ziele. |
| „MAC-Adresse ist eine sichere Benutzeridentität.“ | Falsch | MACs sind sichtbar, spoofbar und werden häufig randomisiert. |
| „Bypass verbessert nur die Verfügbarkeit.“ | Falsch | Er autorisiert bei Fehler automatisch und verändert das Sicherheitsmodell. |
| „SSO für Gäste ist dasselbe wie Mist-Admin-SSO.“ | Falsch | Es sind getrennte Anwendungen, Zielgruppen und Vertrauensbeziehungen. |
Merksätze
- Portalautorisierung ersetzt keine Funkverschlüsselung.
- Ohne DHCP und DNS gibt es keinen verlässlichen Portalablauf.
- Der Walled Garden ist minimal, vollständig und regelmäßig geprüft.
- Ein External-Portal-Secret bleibt ausschließlich serverseitig.
- SAML benötigt exakte URLs, gültige Zertifikate und alle IdP-Abhängigkeiten.
- MAC-Adressen sind Gerätebezeichner, keine starke Identität.
- Bypass ist Fail-open und damit eine dokumentierte Risikoentscheidung.
- Ein Login-Erfolg beweist noch keine korrekte Post-Auth-Policy.
- Gastzugänge werden mit mehreren Betriebssystemen und Ausfallszenarien getestet.
Offizielle Grundlagen
- Compare WLAN Guest Portal Options
- Add a Custom Guest Portal to a WLAN
- Authorization Options for Custom Guest Portal
- Form Fields for Custom Guest Portal
- Layout Options for Custom Guest Portal
- Use an External Portal for Guest Access
- Use an Identity Provider for Guest Access
- Microsoft Entra ID for Guest Portal SSO
- Guest Portal FAQs
- Troubleshoot a Guest Network
- Guest Access Using RADIUS and MAB
- Cloud-Assisted Change of Authorization
- Mist Cloud IP Addresses and Ports
Stand der fachlichen Prüfung: August 2026. Portaloptionen, Providerintegrationen, Cloud-FQDNs und Benutzeroberfläche können sich ändern; für produktive Konfiguration gilt die aktuelle Dokumentation der verwendeten Mist-Region sowie der beteiligten IdP-, SMS- und Portalprovider.