Okta und RADIUS: Erweiterung Ihres Identity Providers auf die WiFi-Authentifizierung
Dieser Leitfaden bietet eine umfassende technische Referenz für IT-Administratoren in Okta-zentrierten Unternehmen, die ihren Cloud-Identity-Provider mithilfe des Okta RADIUS-Agenten auf die WiFi-Authentifizierung ausweiten möchten. Er deckt die gesamte Authentifizierungsarchitektur, die Abwägung bei der MFA-Erzwingung, die dynamische VLAN-Zuweisung über RADIUS-Attribut-Mapping und die kritische Entscheidung zwischen passwortbasiertem EAP-TTLS und zertifikatsbasiertem EAP-TLS ab. Betreiber von Veranstaltungsorten und Enterprise-IT-Teams finden hier praxisnahe Bereitstellungsanleitungen, reale Fallstudien aus dem Gastgewerbe und dem Einzelhandel sowie ein klares Framework für die Integration von Okta RADIUS neben dedizierten Gast-WiFi-Lösungen.
Video overview
Diesen Leitfaden anhören
Podcast-Transkript ansehen
Teil unserer Kernserie: Leitfaden für Enterprise WiFi-Sicherheit →
Executive Summary
Für IT-Teams in Unternehmen, die verteilte Standorte verwalten - von Hotelketten bis hin zu Stadien - ist die Vereinheitlichung der Netzwerkzugriffskontrolle mit einem Cloud-Identitätsanbieter ein entscheidender Schritt in Richtung Zero Trust. Der Okta RADIUS-Agent schließt die Lücke zwischen moderner Cloud-Identität und traditioneller 802.1X WiFi-Infrastruktur. Dies ermöglicht es Unternehmen, veraltete On-Premises-RADIUS-Server und Active Directory-Infrastrukturen für die Netzwerkauthentifizierung abzulösen.
Dieser Leitfaden beschreibt detailliert, wie Sie den Okta RADIUS-Agenten für die WiFi-Authentifizierung in Unternehmen bereitstellen. Er behandelt die Proxy-Architektur, Mechanismen zur Durchsetzung von MFA sowie die Abwägungen zwischen passwortbasiertem EAP-TTLS und zertifikatsbasiertem EAP-TLS. Zudem bietet er praktische Anleitungen zur Zuordnung von Okta-Gruppenmitgliedschaften zu RADIUS-Attributen für die dynamische VLAN-Zuweisung - eine Funktion, die die Anforderungen an die Netzwerksegmentierung gemäß PCI-DSS direkt unterstützt. Durch die Integration von Okta für die Mitarbeiterauthentifizierung neben Lösungen für Guest WiFi können Standortbetreiber eine einheitliche, sichere und konforme Zugriffsebene realisieren, ohne die Identitätsinfrastruktur duplizieren zu müssen.
Technische Detailanalyse
Funktionsweise des Okta RADIUS-Agenten
Der Okta RADIUS-Agent ist ein schlanker Systemdienst, der als Proxy zwischen Network Access Servern (NAS) - wie Wireless Access Points (WAPs) oder Wireless LAN Controllern (WLCs) - und der Okta-Cloud fungiert. Er wird in der Regel auf einem Windows- oder Linux-Server On-Premises oder innerhalb einer Cloud-VPC bereitgestellt und nach der Erstinstallation vollständig über die Okta Admin Console verwaltet.
Der Authentifizierungsfluss folgt einem Standard-802.1X-Proxy-Modell. Das Gerät eines Benutzers (der Supplicant) verbindet sich mit einer Enterprise-SSID und gibt Anmeldedaten ein. Der WAP oder WLC (der Authenticator) leitet einen RADIUS Access-Request über den UDP-Port 1812 an den Okta RADIUS-Agenten weiter. Der Agent tunnelt diese Anfrage sicher über einen HTTPS-API-Aufruf an die Okta-Cloud, wo die Policy-Engine von Okta die Anmeldedaten mit dem Benutzerverzeichnis und allen konfigurierten Anmelderichtlinien abgleicht. Wenn die Authentifizierung erfolgreich ist, gibt der Agent eine RADIUS-Access-Accept-Nachricht an den Authenticator zurück, die optional RADIUS-Attribute für die Autorisierung (wie die VLAN-Zuweisung) enthält. Wenn MFA erforderlich ist, sendet der Agent eine RADIUS-Access-Challenge an den Client zurück und fordert einen zweiten Faktor an, bevor die endgültige Entscheidung übermittelt wird.
Dieses Proxy-Modell bedeutet, dass der Okta RADIUS-Agent keine Benutzeranmeldedaten lokal speichern muss. Die gesamte Authentifizierungslogik, Richtlinienauswertung und Überwachungsprotokollierung erfolgen in der Okta-Cloud. Dies bietet Administratoren eine zentrale Oberfläche für die Identitätsverwaltung sowohl für Cloud-Anwendungen als auch für den Netzwerkzugriff.
Unterstützte EAP-Protokolle und kritische Einschränkungen
Eine grundlegende architektonische Einschränkung des Okta RADIUS-Agents ist seine Abhängigkeit vom Password Authentication Protocol (PAP) für die primäre Authentifizierung. Während PAP Passwörter auf der inneren Ebene im Klartext überträgt, wird dies durch den äußeren TLS-Tunnel des Extensible Authentication Protocol (EAP) gekapselt und geschützt. Die unterstützten äußeren Protokolle sind EAP-TTLS (mit PAP als innerer Methode) und EAP-GTC. Für einen tieferen Vergleich der EAP-Methoden lesen Sie bitte den Referenzleitfaden Comparativa de métodos EAP: PEAP, EAP-TLS, EAP-TTLS y EAP-FAST.
Besonders wichtig: PEAP-MSCHAPv2 wird nicht unterstützt. Dies ist das Standard-802.1X-Protokoll für Windows-Clients und viele ältere Unternehmensumgebungen. Organisationen, die von einer traditionellen NPS/Active Directory RADIUS-Einrichtung migrieren, müssen ihre Client-Supplicants so umkonfigurieren, dass sie EAP-TTLS mit PAP verwenden - eine Änderung, die in der Regel ein über MDM oder Gruppenrichtlinien verteiltes Wireless-Profil erfordert. Dies nicht zu berücksichtigen, ist die häufigste Ursache für fehlgeschlagene Okta RADIUS-Bereitstellungen.
EAP-TLS, das vollständig auf gegenseitiger zertifikatsbasierter Authentifizierung basiert, wird vom Okta RADIUS-Agent ebenfalls nicht nativ unterstützt. Organisationen, die EAP-TLS benötigen, müssen eine dedizierte PKI- oder Cloud-RADIUS-Lösung implementieren, die sich über SAML oder OIDC mit Okta als IdP integriert, anstatt den Okta RADIUS-Agent direkt zu verwenden.
Durchsetzung von MFA bei WiFi-Verbindungen
Der Okta RADIUS-Agent unterstützt MFA für den WiFi-Zugang, bringt jedoch Herausforderungen für die Benutzerfreundlichkeit mit sich, die vor der Bereitstellung sorgfältig abgewogen werden müssen. Wenn eine MFA-Richtlinie ausgelöst wird, sendet der Agent eine RADIUS-Access-Challenge an den Client. Okta unterstützt mehrere Faktoren für RADIUS-Anwendungen:
| MFA-Faktor | PAP | EAP-TTLS | Hinweise |
|---|---|---|---|
| Okta Verify Push | Unterstützt | Unterstützt | Out-of-band gesendet; Benutzer tippt auf dem Mobiltelefon auf Freigeben |
| TOTP (Okta Verify / Google Auth) | Unterstützt | Unterstützt | Benutzer hängt OTP an das Passwort an (z. B. Pass123,456789) |
| SMS / E-Mail / Sprache | Unterstützt | Unterstützt | Benutzer sendet zuerst den Trigger-String (SMS, EMAIL, CALL) |
| Duo Push / SMS / Passcode | Unterstützt | Unterstützt | Duo-Passcode nur für EAP-TTLS |
| YubiKey / U2F / Windows Hello | Nicht unterstützt | Nicht unterstützt | Hardware-Token sind mit dem RADIUS-Protokoll inkompatibel |
Die praktische Einschränkung ist das Roaming. In Hospitality-Umgebungen kann das Tablet einer Reinigungskraft während einer Schicht dutzende Male zwischen Access Points wechseln, was jedes Mal eine erneute Authentifizierung auslöst. Die Anforderung einer Push-Benachrichtigung bei jedem Wechsel ist betrieblich nicht tragbar. Für das allgemeine Mitarbeiter-WiFi werden starke Passwortrichtlinien in Kombination mit den Device Trust- und Netzwerkzonen-Richtlinien von Okta in der Regel aktiven MFA-Aufforderungen vorgezogen. MFA im WiFi sollte administrativen SSIDs oder Szenarien mit hochprivilegiertem Zugriff vorbehalten sein.
Passwortbasierte vs. zertifikatsbasierte Authentifizierung
Die Entscheidung zwischen Passwort-basiertem RADIUS (über den Okta RADIUS Agenten) und Zertifikats-basiertem EAP-TLS ist eine der folgenschwersten Entscheidungen bei einer Enterprise WiFi Bereitstellung. Die Kompromisse betreffen nicht nur die Sicherheit, sondern auch die Komplexität der Bereitstellung, den Reifegrad des Gerätemanagements und den betrieblichen Aufwand.
Die Passwort-basierte Authentifizierung über den Okta RADIUS Agenten bietet einen schnellen Weg zu einer vereinheitlichten Identität. Wenn Ihr Unternehmen Benutzer bereits in Okta verwaltet, kann die Bereitstellung in wenigen Stunden statt in Wochen abgeschlossen werden. Es muss keine PKI aufgebaut, keine Zertifikate verteilt und keine MDM-Abhängigkeit berücksichtigt werden. Der Kompromiss besteht darin, dass Passwörter die primären Anmeldedaten bleiben. Das Fehlen einer gegenseitigen Authentifizierung bedeutet, dass der Client die Identität des Netzwerks nicht kryptografisch überprüfen kann - ein Angriffsvektor für Evil-Twin-Angriffe in Hochrisikoumgebungen.
Zertifikats-basiertes EAP-TLS eliminiert Passwörter vollständig aus der WiFi Authentifizierungsgleichung. Der Client legt ein Gerätezertifikat vor, und der RADIUS Server legt ein Serverzertifikat vor, was eine gegenseitige Authentifizierung ermöglicht. Dies ist der empfohlene Ansatz für IEEE 802.1X in WPA3-Enterprise-Netzwerken, insbesondere in Umgebungen, die PCI-DSS oder Cyber Essentials Plus unterliegen. Voraussetzung ist eine funktionierende PKI - entweder eine lokale Microsoft ADCS-Bereitstellung oder ein Cloud-PKI-Dienst - und eine MDM-Plattform, die Zertifikate an alle verwalteten Endgeräte verteilen kann. Für den Einzelhandel mit Hunderten von verwalteten Point-of-Sale-Geräten ist diese Investition durchaus gerechtfertigt. Für Umgebungen mit hohem BYOD-Anteil oder schnelle Bereitstellungen ist Okta RADIUS mit EAP-TTLS die pragmatische Wahl.
RADIUS-Attributzuordnung für die dynamische VLAN-Zuweisung
Die dynamische VLAN-Zuweisung ist der Bereich, in dem die Okta RADIUS Integration ihren spürbarsten betrieblichen Nutzen entfaltet. Durch die Zuordnung von Okta Gruppenmitgliedschaften zu RADIUS-Attributen können Netzwerkadministratoren eine rollenbasierte Netzwerksegmentierung durchsetzen, ohne separate VLAN-Richtlinien pro Gerät oder Standort pflegen zu müssen.
Okta übergibt Gruppenmitgliedschaftsdaten in der RADIUS-Nachricht Access-Accept mithilfe eines von drei Attributen, die in den erweiterten RADIUS-Einstellungen der Okta Anwendung konfiguriert werden können:
- Attribut 11 (Filter-Id): Ein String-Attribut, das den Gruppennamen enthält. Weithin von verschiedenen Anbietern unterstützt.
- Attribut 25 (Class): Ein opakes Attribut, das für die Autorisierung verwendet wird. Unterstützt von Cisco ISE, Aruba ClearPass und Fortinet.
- Attribut 26 (Vendor-Specific): Ermöglicht herstellerspezifische Sub-Attribute für eine präzisere Steuerung.
Der Netzwerk-Controller (WLC, NAC-Appliance) empfängt den Okta Gruppennamen im gewählten Attribut und ordnet ihn den Standard-RADIUS-Tunnelattributen zu, die für die VLAN-Zuweisung erforderlich sind:
| RADIUS-Attribut | Wert | Zweck |
|---|---|---|
| 64 (Tunnel-Type) | 13 (VLAN) | Spezifiziert das VLAN-Tunneling |
| 65 (Tunnel-Medium-Type) | 6 (802) | Spezifiziert das IEEE 802 Medium |
| 81 (Tunnel-Private-Group-ID) | z. B. 40 |
Die Ziel VLAN ID |
Beispielsweise würde für einen Benutzer in der Okta Gruppe Retail-POS-Staff der Wert Class: Retail-POS-Staff im Access-Accept zurückgegeben werden. Die WLC Richtlinie würde dies auf Tunnel-Private-Group-ID: 40 abbilden und das Gerät im VLAN 40 platzieren - dem isolierten POS-Netzwerk. Ein Benutzer in der Gruppe Store-Management würde im VLAN 50 platziert werden. Diese Logik wird am Netzwerk-Edge und nicht in Okta erzwungen, wird jedoch vollständig durch die Okta Gruppenmitgliedschaft gesteuert.
Haben Sie Fragen zu Ihrem spezifischen Setup?
Unser Team arbeitet mit Standortbetreibern, IT-Managern und Netzwerktechnikern an über 80.000 Standorten zusammen. Buchen Sie ein 20-minütiges Gespräch und wir zeigen Ihnen, wie andere diese Herausforderungen gelöst haben.
Implementierungshandbuch
Schritt 1: Bereitstellung des Okta RADIUS Agenten (Hochverfügbarkeit)
Stellen Sie den Okta RADIUS Agenten auf mindestens zwei Servern bereit - entweder lokal oder in einer Cloud-VPC - um Hochverfügbarkeit zu gewährleisten. Bereitstellungen mit nur einem Agenten stellen ein kritisches Risiko dar: Wenn der Server für Patches nicht verfügbar ist oder ein Fehler auftritt, schlägt die gesamte 802.1X WiFi Authentifizierung im gesamten Unternehmen fehl. Konfigurieren Sie Ihre WLC- oder NAC-Appliance so, dass die RADIUS Anfragen gleichmäßig auf beide Agenten verteilt werden.
Während der Installation fordert der Agent zur Anmeldung eines Okta Administrators auf, um den Agenten zu autorisieren und mit dem Okta Mandanten zu verknüpfen. Nach der Autorisierung wird der Agent in der Okta Admin-Konsole unter Settings > Downloads > RADIUS Agent Status angezeigt, wo Zustand und Konnektivität überwacht werden können.
Schritt 2: Konfigurieren der RADIUS Anwendung in Okta
- Navigieren Sie in der Okta Admin-Konsole zu Applications > Applications und suchen Sie im App-Katalog nach RADIUS Application.
- Fügen Sie die Anwendung hinzu, vergeben Sie einen aussagekräftigen Namen (z. B.
Corporate-WiFi-Staff) und klicken Sie auf Next. - Konfigurieren Sie auf der Registerkarte Sign On den RADIUS Port (Standardwert 1812) und generieren Sie ein sicheres, zufällig erstelltes Shared Secret mit mindestens 32 Zeichen.
- Aktivieren Sie unter Advanced RADIUS Settings die Option Accept password and security token in the same login request, wenn Sie TOTP angehängt an Passwörter unterstützen möchten.
- Aktivieren Sie optional Permit Automatic Push for Okta Verify Enrolled Users für eine nahtlose, Push-basierte MFA.
- Weisen Sie die Anwendung den relevanten Okta Gruppen zu, die Ihre Mitarbeiter repräsentieren.
Schritt 3: Konfigurieren der gruppenbasierten VLAN Zuweisung
- Klicken Sie in den Sign On Einstellungen der RADIUS Anwendung im Bereich Advanced RADIUS Settings auf Edit.
- Aktivieren Sie Include groups in RADIUS response.
- Wählen Sie das RADIUS Attribut aus: 25 Class wird für Aruba und Cisco Umgebungen empfohlen; 11 Filter-Id für Fortinet und andere.
- Fügen Sie die spezifischen Okta Gruppennamen hinzu, die eingeschlossen werden sollen (z. B.
Retail-POS-Staff,Store-Management,IT-Admins). - Erstellen Sie auf Ihrer WLC- oder NAC-Appliance Richtlinien, die jeden Gruppennamen den entsprechenden VLAN Tunnel-Attributen zuordnen.
Schritt 4: Client-Supplicants konfigurieren
Da PEAP-MSCHAPv2 nicht unterstützt wird, müssen Client-Geräte so konfiguriert werden, dass sie EAP-TTLS mit PAP als innere Methode verwenden. Verteilen Sie ein drahtloses Netzwerkprofil über Ihre MDM-Plattform (z. B. Microsoft Intune, Jamf Pro) oder über Group Policy Objects (GPO) für Windows-Geräte in der Domäne. Das Profil sollte Folgendes festlegen:
- SSID: Der Name Ihrer Enterprise-SSID
- Sicherheit: WPA2-Enterprise oder WPA3-Enterprise
- EAP-Methode: EAP-TTLS
- Innere Authentifizierung: PAP
- Server-Zertifikatsvalidierung: Aktiviert (festgelegt auf den CN des Serverzertifikats Ihres RADIUS-Agenten)
Schritt 5: RADIUS-Timeouts festlegen
Erhöhen Sie das RADIUS-Timeout auf Ihrem WLC vom Standardwert von 3 - 5 Sekunden auf 30 - 60 Sekunden. Dies ist besonders wichtig, wenn MFA-Push-Benachrichtigungen verwendet werden, da der Benutzer genügend Zeit haben muss, um die Benachrichtigung auf seinem Gerät zu bestätigen, bevor der WLC den Authentifizierungsversuch abbricht.
Best Practices
Die Bereitstellung von Okta RADIUS für die WiFi-Authentifizierung ist unkompliziert, aber einige bewährte Betriebsmethoden unterscheiden eine widerstandsfähige Produktionsumgebung von einem instabilen Proof-of-Concept.
Segmentieren Sie den Gast- und Mitarbeiterverkehr auf SSID-Ebene. Okta RADIUS ist ein Tool für die Identitätsverwaltung von Mitarbeitern. Verwenden Sie für den Besucher- und Gastzugang eine dedizierte Captive Portal-Lösung. Dadurch wird verhindert, dass die Okta-Lizenzkosten mit der Anzahl der Gäste steigen, und es wird eine saubere Trennung der Zuständigkeiten gewährleistet. Purple-Unternehmenskunden können Guest WiFi auf einer separaten SSID bereitstellen, während sie Okta RADIUS für die Mitarbeiterauthentifizierung auf derselben physischen Infrastruktur nutzen.
Verwenden Sie eine NAC-Appliance für komplexe Richtlinienumgebungen. Wenn Ihre Umgebung einen bedingten Zugriff basierend auf dem Gerätestatus, MAC-Adressfilterung oder dem Zertifikatsstatus neben der Benutzeridentität erfordert, stellen Sie eine zwischengeschaltete NAC-Appliance (Aruba ClearPass, Cisco ISE oder Portnox) bereit, um Anfragen an den Okta RADIUS-Agenten weiterzuleiten. Die NAC-Appliance kann die RADIUS-Antwort mit zusätzlichen Tunnelattributen anreichern, die der Okta-Agent allein nicht generieren kann.
Überwachung über das Okta-Systemprotokoll. Jedes Authentifizierungsereignis - Erfolg, Fehler, MFA-Abfrage und Faktortyp - wird im Okta-Systemprotokoll erfasst. Konfigurieren Sie das Protokoll-Streaming zu Ihrem SIEM für Echtzeit-Warnungen bei Authentifizierungsanomalien. Dies ist besonders wertvoll für Organisationen im Bereich Healthcare und im öffentlichen Sektor, die Audit-Anforderungen unterliegen.
Rotieren Sie gemeinsame Schlüssel nach Zeitplan. Der gemeinsame Schlüssel (Shared Secret) zwischen der Okta RADIUS-Anwendung und Ihrem NAS ist ein kritisches Sicherheitsmerkmal. Richten Sie einen Rotationsplan ein (empfohlen wird vierteljährlich) und aktualisieren Sie sowohl die Okta-Anwendung als auch die WLC/NAC-Konfiguration gleichzeitig.
RADIUS-Dienstadressen einschränken. Beschränken Sie in der Konfiguration des Okta RADIUS-Agenten, welche IP-Adressen RADIUS-Anfragen senden dürfen. Dies verhindert, dass nicht autorisierte NAS-Geräte versuchen, sich gegenüber Ihrem Okta-Tenant zu authentifizieren. For guidance on the broader network architecture context, see The Core SD WAN Benefits for Modern Businesses and Wireless Access Points Definition Your Ultimate 2026 Guide.
Troubleshooting & Risk Mitigation
The following table summarises the most common failure modes encountered in Okta RADIUS WiFi deployments and their recommended mitigations.
| Failure Mode | Root Cause | Mitigation |
|---|---|---|
| Authentication Timeouts | WLC RADIUS timeout too short for Okta API or MFA response | Increase WLC RADIUS timeout to 30-60 seconds |
| Windows Clients Rejected | Windows defaults to PEAP-MSCHAPv2, which Okta RADIUS rejects | Push EAP-TTLS/PAP wireless profile via MDM or GPO |
| Users in Wrong VLAN | Okta group name mismatch or missing tunnel attributes on WLC | Verify WLC maps Class/Filter-Id to Tunnel-Private-Group-ID; check Okta System Log |
| Agent Unreachable | Server offline, API token expired, or firewall blocking HTTPS to Okta | Deploy redundant agents; monitor agent status in Okta Admin Console; verify outbound HTTPS |
| MFA Push Not Delivered | User not enrolled in Okta Verify, or mobile device offline | Enforce Okta Verify enrolment policy; consider TOTP as fallback |
| Certificate Validation Errors | Client cannot validate RADIUS server certificate | Pin server certificate CN in client wireless profile; ensure CA chain is trusted |
| VLAN Attributes Not Sent | Okta group not included in RADIUS response configuration | Verify group is listed in Advanced RADIUS Settings; confirm user is a member of the group in Okta |
For Transport and public-sector environments where network uptime is mission-critical, implement synthetic monitoring that periodically tests RADIUS authentication end-to-end and alerts on failure before users are impacted.
ROI & Business Impact
The business case for Okta RADIUS WiFi authentication rests on three pillars: operational efficiency, security posture improvement, and compliance readiness.
Operational Efficiency. Consolidating WiFi authentication into Okta eliminates the need to maintain separate on-premises RADIUS infrastructure (NPS servers, local AD) at each venue or site. For a hotel chain with 50 properties, this can represent a significant reduction in per-site infrastructure costs and IT support overhead. User provisioning and deprovisioning become atomic: adding a user to the correct Okta group grants both application access and the appropriate WiFi VLAN access simultaneously. When an employee leaves, deactivating their Okta account immediately revokes WiFi access across all sites.
Sicherheitsstatus. Der Ersatz gemeinsam genutzter PSK WiFi Passwörter durch eine 802.1X Authentifizierung pro Benutzer verhindert die Weitergabe von Anmeldedaten - ein häufiger Vektor für Insider-Bedrohungen und unbefugten Zugriff. In Kombination mit einer dynamischen VLAN Zuweisung setzt dies das Prinzip der minimalen Rechtevergabe auf der Netzwerkschicht durch. Das Okta System Log bietet einen lückenlosen, manipulationssicheren Audit-Trail für jedes WiFi Authentifizierungsereignis, was für die Reaktion auf Vorfälle unerlässlich ist.
Compliance-Bereitschaft. Die PCI-DSS 4.0 Anforderung 8.3 schreibt MFA für alle administrativen Zugriffe außerhalb der Konsole vor. Die Anforderung 1.3 fordert eine Netzwerksegmentierung zwischen der Umgebung für Karteninhaberdaten und anderen Netzwerken. Okta RADIUS mit gruppenbasierter VLAN Zuweisung deckt beide Anforderungen direkt ab. Für die GDPR Compliance liefert das Okta System Log die Zugriffsprotokolle, die erforderlich sind, um angemessene technische Kontrollen über Systeme zur Verarbeitung personenbezogener Daten nachzuweisen. Für Standorte, die Modern Hospitality WiFi Solutions einsetzen, ist dieser einheitliche Ansatz für Identitäts- und Netzwerkzugriff zunehmend eine Voraussetzung für die Beschaffung im Unternehmen.
Unternehmen, die diese Integration abgeschlossen haben, berichten in der Regel von einer Reduzierung der WiFi-bezogenen IT-Support-Tickets (weniger Anfragen zur Passwortzurücksetzung, weniger VLAN Fehlkonfigurationen) und einer messbaren Verbesserung der Ergebnisse bei Sicherheitsaudits. Die Investition in die Bereitstellung und Konfiguration des Okta RADIUS Agenten - bei einer Bereitstellung an einem einzelnen Standort in der Regel in Tagen statt Wochen gemessen - führt zu laufenden betrieblichen Einsparungen, die sich über einen verteilten Standortbestand summieren.
Schlüsseldefinitionen
Okta RADIUS Agent
Ein leichtgewichtiger lokaler oder in der Cloud gehosteter Proxy-Dienst, der RADIUS-Authentifizierungsanfragen von der Netzwerkinfrastruktur (Access Points, WLCs) in Okta-API-Aufrufe übersetzt, sodass die Okta-Cloud als Authentifizierungs-Backend für 802.1X-WiFi dienen kann.
IT-Teams stoßen darauf, wenn sie eine durch Okta unterstützte WiFi-Authentifizierung für Unternehmen bereitstellen. Er ist die entscheidende Brückenkomponente zwischen der herkömmlichen RADIUS-basierten Netzwerkinfrastruktur und der modernen Cloud-Identität.
802.1X
Ein IEEE-Standard für portbasierte Netzwerkzugriffskontrolle (NAC), der ein Authentifizierungs-Framework für kabelgebundene und kabellose Netzwerke definiert. Er verwendet das Extensible Authentication Protocol (EAP), um Authentifizierungsdaten zwischen dem Supplicant (Gerät), dem Authenticator (AP/Switch) und dem Authentifizierungsserver (RADIUS) zu übertragen.
802.1X ist das Fundament der WiFi-Sicherheit in Unternehmen. Jede Bereitstellung, die WPA2-Enterprise oder WPA3-Enterprise nutzt, verwendet 802.1X. IT-Teams müssen das Dreiparteienmodell (Supplicant, Authenticator, Authentication Server) verstehen, um Konnektivitätsprobleme zu beheben.
EAP-TTLS (Extensible Authentication Protocol - Tunnelled Transport Layer Security)
Eine EAP-Methode, die einen TLS-Tunnel nur unter Verwendung eines serverseitigen Zertifikats aufbaut und dann ein einfacheres inneres Authentifizierungsprotokoll (wie PAP) innerhalb des Tunnels überträgt. Dies schützt die inneren Zugangsdaten vor dem Abhören, während nur eine serverseitige Zertifikatsinfrastruktur erforderlich ist.
EAP-TTLS mit PAP ist das empfohlene Protokoll für die Okta RADIUS WiFi-Authentifizierung. Es ist sicherer als reines PAP, erfordert jedoch keine clientseitigen Zertifikate, was es für BYOD- und gemischte Geräteumgebungen praktisch macht.
EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)
Eine EAP-Methode, die auf gegenseitiger zertifikatsbasierter Authentifizierung basiert - sowohl der Client als auch der Server weisen digitale Zertifikate vor. Es ist die sicherste 802.1X-Methode und bietet eine Phishing-resistente, passwortfreie Authentifizierung.
EAP-TLS ist der Goldstandard für verwaltete Unternehmensgeräte-Umgebungen. Es erfordert eine PKI-Infrastruktur und MDM für die Zertifikatsverteilung. Der Okta RADIUS-Agent unterstützt EAP-TLS nicht nativ; ein dedizierter Cloud-PKI- oder RADIUS-Service ist erforderlich.
PAP (Password Authentication Protocol)
Ein einfaches Authentifizierungsprotokoll, das Benutzernamen und Passwörter im Klartext überträgt. Im Kontext von 802.1X wird PAP als innere Authentifizierungsmethode innerhalb eines EAP-TTLS-Tunnels verwendet, wobei die äußere TLS-Schicht für die Verschlüsselung sorgt.
PAP ist der primäre Authentifizierungsmechanismus, der vom Okta RADIUS-Agenten unterstützt wird. IT-Teams müssen verstehen, dass PAP allein unsicher ist, aber PAP innerhalb von EAP-TTLS für Enterprise WiFi akzeptabel ist, wenn das Serverzertifikat ordnungsgemäß validiert wird.
Dynamische VLAN-Zuweisung
Eine Netzwerkzugriffskontrollmethode, bei der ein RADIUS-Server VLAN-Zuweisungsattribute in der Access-Accept-Nachricht zurückgibt. Dies veranlasst den Wireless Controller oder Switch, den authentifizierten Client basierend auf seiner Identität oder Gruppenmitgliedschaft in ein bestimmtes VLAN statt in ein statisches VLAN pro SSID einzustufen.
Die dynamische VLAN-Zuweisung ist für die Netzwerksegmentierung in Umgebungen mit mehreren Rollen (z. B. zur Trennung von POS-Terminals von allgemeinen Mitarbeitergeräten) unerlässlich. Sie wird konfiguriert, indem die RADIUS-Attribute 64, 65 und 81 in der Access-Accept-Nachricht zurückgegeben werden.
RADIUS-Attribut 25 (Class)
Ein standardmäßiges RADIUS-Attribut, das zur Übergabe beliebiger Autorisierungsdaten vom Authentifizierungsserver an den NAS verwendet wird. Okta nutzt dieses Attribut, um Informationen zur Okta-Gruppenmitgliedschaft an den Wireless Controller zurückzugeben, der diese dann für VLAN-Zuweisungen oder Entscheidungen zur Zugriffsrichtlinie nutzen kann.
IT-Teams, die eine Okta-gruppenbasierte VLAN-Zuweisung konfigurieren, richten den WLC so ein, dass er den Wert des Class-Attributs liest und einer VLAN-ID zuweist. Welches genaue Attribut verwendet werden soll (11, 25 oder 26), hängt von der Dokumentation des WLC-Herstellers ab.
NAS (Network Access Server)
In der RADIUS-Terminologie ist der NAS das Netzwerkgerät, das die Verbindungsanfrage des Benutzers empfängt und zur Authentifizierung an den RADIUS-Server weiterleitet. Bei WiFi-Bereitstellungen ist der NAS in der Regel der Wireless Access Point oder der Wireless LAN Controller.
Der NAS ist der Authentifikator im 802.1X-Modell. IT-Teams müssen den NAS mit der IP-Adresse des RADIUS-Servers, dem Port und dem Shared Secret konfigurieren. Die NAS-IP-Adresse sollte in der Serviceadressen-Filterkonfiguration des Okta RADIUS-Agenten auf der Whitelist stehen.
Shared Secret
Ein vorab freigegebenes Passwort, das zur Authentifizierung von RADIUS-Nachrichten zwischen dem NAS (WLC/AP) und dem RADIUS-Server (Okta RADIUS-Agent) verwendet wird. Es wird zur Berechnung eines Message-Authenticator-Hashs verwendet, der die Integrität von RADIUS-Paketen überprüft.
Das Shared Secret muss sowohl in der Konfiguration der Okta RADIUS-Anwendung als auch im RADIUS-Servereintrag des WLC/NAC identisch sein. Es sollte mindestens 32 Zeichen lang sein, zufällig generiert und regelmäßig rotiert werden. Eine Abweichung ist eine häufige Ursache für RADIUS-Authentifizierungsfehler.
MFA-Challenge (RADIUS Access-Challenge)
Ein RADIUS-Nachrichtentyp, der vom Authentifizierungsserver an den NAS gesendet wird, wenn zusätzliche Authentifizierungsfaktoren erforderlich sind. Der NAS leitet die Challenge an den Client weiter, der mit dem entsprechenden Faktor antworten muss (z. B. OTP, Push-Freigabe), bevor die Authentifizierung abgeschlossen werden kann.
Der Access-Challenge-Mechanismus ist die Art und Weise, wie Okta MFA über RADIUS erzwingt. IT-Teams müssen sicherstellen, dass der WLC den Challenge-Response-Austausch unterstützt und dass das RADIUS-Timeout lang genug ist, damit der Benutzer den MFA-Schritt abschließen kann.
Ausgearbeitete Beispiele
Eine Hotelkette mit 150 Standorten nutzt derzeit lokale NPS-Server an jedem Standort für die 802.1X-WiFi-Authentifizierung der Mitarbeiter. Jeder NPS-Server ist in eine lokale Active Directory-Domäne eingebunden. Das IT-Team möchte das Identitätsmanagement in Okta zentralisieren und die NPS-Infrastruktur pro Standort eliminieren. Wie sollten sie die Migration angehen?
Der empfohlene Ansatz ist eine schrittweise Migration unter Verwendung des Okta RADIUS-Agenten, der in einer zentralen Cloud-VPC und nicht an jedem einzelnen Standort bereitgestellt wird. Phase 1: Bereitstellung von zwei Okta RADIUS-Agenten-Instanzen in einer Cloud-VPC (z. B. AWS oder Azure) in derselben Region wie die Mehrheit der Standorte. Konfigurieren Sie die Agenten so, dass sie auf UDP 1812 lauschen. Phase 2: Fügen Sie für jeden Standort die IPs des Okta RADIUS-Agenten als sekundäre RADIUS-Server auf dem WLC hinzu, während der bestehende NPS als primärer Server beibehalten wird. Dies ermöglicht einen parallelen Betrieb und Tests, ohne die laufende Authentifizierung zu stören. Phase 3: Migrieren Sie Benutzer aus dem lokalen AD zu Okta. Verwenden Sie den AD-Agenten von Okta, um vorhandene Konten zunächst zu synchronisieren, und wechseln Sie dann schrittweise zu Okta als autoritative Quelle. Phase 4: Konfigurieren Sie für jeden Standort den WLC für die Verwendung von EAP-TTLS/PAP und verteilen Sie das neue WLAN-Profil über MDM an die Mitarbeitergeräte. Phase 5: Sobald alle Geräte für EAP-TTLS bestätigt sind, ändern Sie die WLC RADIUS-Priorität auf die Okta-Agenten als primäre Server und nehmen Sie die NPS-Server außer Betrieb. Konfigurieren Sie Okta-Gruppen (Rezeption, Housekeeping, Gastronomie, Management, IT-Admins) und aktivieren Sie die gruppenbasierte VLAN-Zuweisung mithilfe von Attribut 25 (Class). Ordnen Sie jede Gruppe dem entsprechenden VLAN auf dem WLC zu. Erhöhen Sie den WLC RADIUS-Timeout auf 45 Sekunden, um Verzögerungen der Okta API auszugleichen.
Eine nationale Einzelhandelskette mit 320 Filialen muss die Compliance-Anforderungen nach PCI DSS 4.0 für ihr Mitarbeiter-WiFi erfüllen. Die Mitarbeiter in den Filialen nutzen Handheld-Geräte für die Bestandsverwaltung, während eine separate Gruppe von Geräten für Point-of-Sale-Transaktionen zuständig ist. Die Kette nutzt Okta für das gesamte Identitätsmanagement der Belegschaft. Wie implementieren sie die VLAN-Segmentierung mit Okta RADIUS, um die Anforderungen an die PCI DSS-Netzwerksegmentierung zu erfüllen?
Erstellen Sie drei Okta-Gruppen: POS-Staff (für Mitarbeiter, die POS-Terminals bedienen), Inventory-Staff (für Lager- und Verkaufsflächen-Mitarbeiter) und Store-Management. Aktivieren Sie in der Okta RADIUS-Anwendung "Include groups in RADIUS response" und wählen Sie Attribut 25 (Class) aus. Fügen Sie alle drei Gruppen zur Antwortkonfiguration hinzu. Erstellen Sie auf dem Wireless Controller in jeder Filiale (oder zentral über einen Cloud-WLC) drei Durchsetzungsrichtlinien: (1) Wenn Class = POS-Staff, weisen Sie Tunnel-Private-Group-ID = 40 zu (das POS-VLAN, das im Geltungsbereich von PCI-DSS liegt und dessen Firewall-Regeln den Zugriff auf den Zahlungsabwickler beschränken). (2) Wenn Class = Inventory-Staff, weisen Sie Tunnel-Private-Group-ID = 50 zu (das Inventar-VLAN, außerhalb des PCI-Geltungsbereichs). (3) Wenn Class = Store-Management, weisen Sie Tunnel-Private-Group-ID = 60 zu (das Management-VLAN mit Zugriff auf die Filialmanagementsysteme). Geräte, die sich mit den Zugangsdaten eines Benutzers aus der Gruppe POS-Staff verbinden, werden automatisch dem VLAN 40 zugewiesen. Ändert sich die Rolle eines Filialmitarbeiters, ändert die Aktualisierung seiner Okta-Gruppenmitgliedschaft bei der nächsten Verbindung sofort seine VLAN-Zuweisung - ohne dass eine WLC-Rekonfiguration erforderlich ist. Dokumentieren Sie das Okta-Gruppe-zu-VLAN-Mapping im Netzwerksegmentierungsdiagramm für das PCI-DSS-QSA-Audit.
Übungsfragen
Q1. Ein mittelgroßes Konferenzzentrum nutzt Okta für das gesamte Identitätsmanagement der Mitarbeiter. Sie möchten 802.1X WiFi für Mitarbeiter unter Verwendung ihrer bestehenden Cisco Meraki Access Points bereitstellen. Ihre Windows Laptops werden über Microsoft Intune verwaltet. Der IT-Manager möchte für alle WiFi Verbindungen die Okta Verify Push-MFA erzwingen. Welches sind die drei kritischsten Konfigurationsschritte, die sie abschließen müssen, und was ist das wahrscheinlichste Fehlerszenario, wenn einer dieser Schritte übersprungen wird?
Hinweis: Berücksichtigen Sie die EAP-Protokollkompatibilität zwischen Okta RADIUS und Windows-Standardeinstellungen, die RADIUS-Timeout-Einstellung sowie die Konfiguration des drahtlosen Client-Profils.
Musterlösung anzeigen
Die drei kritischen Schritte sind: (1) Bereitstellung eines Wireless-Profils über Intune, das Windows Clients für die Verwendung von EAP-TTLS mit PAP als innere Methode konfiguriert - Windows verwendet standardmäßig PEAP-MSCHAPv2, was der Okta RADIUS Agent nicht unterstützt, was dazu führt, dass alle Authentifizierungsversuche abgelehnt werden. (2) Erhöhen des Cisco Meraki RADIUS Timeouts vom Standardwert von 5 Sekunden auf mindestens 45 - 60 Sekunden - andernfalls läuft die Authentifizierungsanfrage ab, bevor der Benutzer die Okta Verify Push-Benachrichtigung bestätigen kann. (3) Aktivieren von "Permit Automatic Push for Okta Verify Enrolled Users" in den Advanced RADIUS Settings der Okta RADIUS Anwendung - andernfalls werden Benutzer möglicherweise aufgefordert, ihren MFA-Faktor manuell auszuwählen, anstatt eine automatische Push-Benachrichtigung zu erhalten. Das wahrscheinlichste Fehlerszenario, wenn Schritt 1 übersprungen wird, ist ein vollständiger Authentifizierungsfehler für alle Windows Geräte. Wenn Schritt 2 übersprungen wird, schlägt die Authentifizierung bei Benutzern, die länger als 5 Sekunden für die Bestätigung der Push-Benachrichtigung benötigen, unregelmäßig fehl. Wenn Schritt 3 übersprungen wird, sehen die Benutzer eine verwirrende Aufforderung anstelle einer nahtlosen Push-Benachrichtigung.
Q2. Das Sicherheitsteam einer großen Einzelhandelskette hat festgestellt, dass ihre aktuelle Okta RADIUS WiFi Bereitstellung einen einzigen RADIUS Agent-Server verwendet. Während eines kürzlichen Patch-Fensters war der Server für 45 Minuten offline, was dazu führte, dass die WiFi Authentifizierung in allen 80 Filialen ausfiel. Welche architektonischen Änderungen sollte das IT-Team implementieren, um dies zu verhindern, und welches sind die zwei Bereitstellungsoptionen für die Agenten?
Hinweis: Berücksichtigen Sie sowohl die Topologie der Agenten-Bereitstellung als auch die für die Redundanz erforderliche WLC-Konfiguration.
Musterlösung anzeigen
Das IT-Team sollte mindestens zwei Okta RADIUS Agent-Instanzen bereitstellen und den WLC in jeder Filiale so konfigurieren, dass beide Agenten verwendet werden. Es gibt zwei Bereitstellungsoptionen: Option A (Zentralisierte Cloud-VMs) - Bereitstellung beider Agenten in einer Cloud-VPC (z. B. AWS oder Azure), idealerweise in verschiedenen Verfügbarkeitszonen. Der WLC in jeder Filiale verweist auf beide Cloud-IPs, eine als primäre und eine als sekundäre Adresse (oder mit aktiviertem Load Balancing). Dies minimiert die Infrastruktur pro Standort, führt jedoch zu einer WAN-Abhängigkeit. Option B (On-Premises Redundantes Paar) - Bereitstellung von zwei Agent-Servern in einem zentralen Rechenzentrum oder einer Co-Location-Einrichtung, wobei der WLC ein RADIUS Failover verwendet. Konfigurieren Sie auf dem WLC den primären RADIUS Server als Agent 1 und den sekundären als Agent 2 mit einem Failover-Timeout von 3 - 5 Sekunden. Aktivieren Sie "Dead Server Detection", sofern dies vom WLC-Anbieter unterstützt wird. Darüber hinaus sollte das IT-Team das Health Monitoring in der Okta Admin Console konfigurieren und Warnmeldungen einrichten, falls ein Agent offline geht. Für Filialen mit lokalen Servern kann ein lokaler Agent als tertiärer Fallback dienen, um die Ausfallsicherheit bei WAN-Ausfällen zu gewährleisten.
Q3. Ein Großunternehmen prüft, ob es den Okta RADIUS Agenten mit EAP-TTLS/PAP verwenden oder in eine Cloud-PKI-Lösung für EAP-TLS für sein Unternehmens-WiFi investieren soll. Sie verfügen über 2.000 verwaltete Windows und macOS Geräte, die in Microsoft Intune registriert sind, und unterliegen PCI DSS 4.0. Was ist der empfohlene Ansatz und welches ist die primäre Sicherheitsbegründung?
Hinweis: Berücksichtigen Sie die PCI DSS Anforderungen, den Reifegrad des Gerätemanagements (alle Geräte sind MDM-registriert) und die Sicherheitseigenschaften der einzelnen Authentifizierungsmethoden.
Musterlösung anzeigen
Der empfohlene Ansatz besteht darin, in EAP-TLS mit einer Cloud-PKI-Lösung zu investieren. Die primäre Sicherheitsbegründung ist die gegenseitige Authentifizierung: EAP-TLS erfordert, dass sowohl der Client als auch der RADIUS-Server digitale Zertifikate vorlegen. Das bedeutet, dass das Gerät seine Identität kryptografisch gegenüber dem Netzwerk nachweist und das Netzwerk seine Identität gegenüber dem Gerät nachweist. Dies eliminiert das Risiko von Evil-Twin-Angriffen (bei denen ein manipulierter AP die Unternehmens-SSID imitiert) und entfernt Passwörter vollständig aus der WiFi-Authentifizierungsgleichung, wodurch Diebstahl von Anmeldedaten und Phishing als Angriffsvektoren ausgeschlossen werden. Für PCI-DSS 4.0 erfüllt EAP-TLS die Anforderung 8.3 (MFA für Administratorzugriff ohne Konsole) implizit durch zertifikatsbasierte Authentifizierung und unterstützt den WPA3-Enterprise 192-Bit-Modus (Anforderung 4.2.1 für starke Kryptografie). Die Voraussetzung - alle 2.000 Geräte sind in Intune registriert - ist bereits erfüllt, was die Zertifikatsverteilung über Intune SCEP-Profile unkompliziert macht. Der Okta RADIUS-Agent mit EAP-TTLS/PAP wäre eine akzeptable Übergangslösung während des PKI-Aufbaus, aber angesichts des PCI-DSS-Geltungsbereichs und der vollständig verwalteten Geräteflotte ist EAP-TLS die richtige langfristige Architektur. Die zusätzliche Investition in einen Cloud-PKI-Dienst (normalerweise 3 bis 8 USD pro Gerät und Jahr) ist durch den Sicherheitsgewinn und den reduzierten Aufwand für die Verwaltung von Anmeldedaten gerechtfertigt.
Häufig gestellte Fragen
Kann ich Okta direkt mit Enterprise WiFi verbinden, ohne einen zwischengeschalteten RADIUS-Server zu nutzen?
Nein. Wireless Access Points und Controller der Enterprise-Klasse authentifizieren Clients über das 802.1X-Protokoll, das auf RADIUS (Remote Authentication Dial-In User Service) basiert. Da Okta ein Cloud-Identitätsanbieter ist, der über REST-APIs und SAML oder OIDC arbeitet, kann er das RADIUS-Protokoll nicht direkt über die UDP-Ports 1812 und 1813 bedienen. Sie müssen entweder den lokalen Okta RADIUS Server Agent oder einen Cloud-RADIUS-Dienst bereitstellen, der Netzwerkauthentifizierungsanfragen in Okta-API-Aufrufe übersetzt.
Was ist der Unterschied zwischen dem lokalen Okta RADIUS-Agenten und Cloud RADIUS?
Der Okta RADIUS-Agent ist ein Dienst, den Sie auf einer internen virtuellen Windows- oder Linux-Maschine hosten. Er empfängt RADIUS-Anfragen von Ihren Wireless-Controllern und leitet sie per Proxy an die Okta-API weiter. Cloud RADIUS ist ein vollständig gehosteter, multiregionaler Cloud-Dienst, der keinerlei lokale virtuelle Maschinen erfordert, eine native PKI-Integration für EAP-TLS-Client-Zertifikate bietet und global mit automatischem Failover skaliert.
Welches EAP-Authentifizierungsprotokoll sollte mit dem Okta RADIUS-Agenten verwendet werden?
Okta empfiehlt EAP-TTLS (Tunneled Transport Layer Security) mit PAP als innere Authentifizierungsmethode bei der Verwendung des Okta RADIUS-Agenten. EAP-TTLS baut einen verschlüsselten TLS-Tunnel mithilfe eines serverseitigen Zertifikats auf dem RADIUS-Agenten auf. Dies schützt die Benutzeranmeldedaten bei der Übertragung und ermöglicht es Okta, Passwörter direkt mit seinem Cloud-Verzeichnis abzugleichen, ohne dass clientseitige Zertifikate erforderlich sind.
Wie funktioniert die dynamische VLAN-Zuweisung zwischen Okta und Wireless-Controllern?
Die dynamische VLAN-Zuweisung ermöglicht es Ihrem Wireless LAN Controller, Benutzer basierend auf ihrer Okta-Gruppenmitgliedschaft bestimmten Netzwerksegmenten zuzuweisen. Während der 802.1X-Authentifizierung gibt der RADIUS-Server Standardattribute in der Access-Accept-Antwort zurück: Tunnel-Type (Attribut 64 = VLAN), Tunnel-Medium-Type (Attribut 65 = 802) und Tunnel-Private-Group-ID (Attribut 81 = VLAN-ID oder -Name). Ihr Controller weist den Client bei der Verbindung diesem VLAN-Tag zu.
Welche RADIUS-Timeout-Einstellungen sind erforderlich, wenn Okta Verify Push-MFA für WiFi verwendet wird?
Standardmäßige RADIUS-Timeouts von 3 bis 5 Sekunden sind für interaktive Push-Benachrichtigungen zu kurz, was dazu führt, dass der Wireless-Controller die Verbindungen trennt, bevor der Benutzer die Aufforderung auf seinem Telefon genehmigen kann. Wenn Sie Okta Verify Push-Benachrichtigungen für den WiFi-Zugang aktivieren, erhöhen Sie das RADIUS-Retransmission-Timeout Ihres Wireless-Controllers auf mindestens 30 bis 60 Sekunden und legen Sie die Wiederholungsversuche auf 1 oder 2 fest, um doppelte Push-Benachrichtigungen zu vermeiden.
Weiterlesen in dieser Reihe
IronWiFi Alternativen für Enterprise-Implementierungen
Sie werden in der Lage sein, eine IronWiFi Alternative basierend auf den Anforderungen Ihres Netzwerks in die engere Wahl zu ziehen: Authentifizierung, Identität, Einwilligung, Hardware-Abdeckung und Dreijahreskosten. Sie werden wissen, wann Purple, Cloud4Wi, Spotipo oder Cloudi-Fi besser passen, wann IronWiFi immer noch gewinnt und wie Sie einen Pilotbetrieb an einem einzelnen Standort durchführen, der die Behauptungen jedes Anbieters beweist.
Sophos Firewall und Gäste-WiFi: Captive Portal-Einrichtung mit Purple
Wie das Cloud-Gäste-WiFi von Purple mit Sophos Firewall und deren Access Points über ein standardmäßiges externes Captive Portal und RADIUS funktioniert, und wo Sie den Support prüfen und die Schritte finden.
Aruba Central und Purple WiFi: Cloud-Managed Integration
Ein umfassender technischer Leitfaden für die Integration von Aruba Central mit der Cloud-basierten Guest-WiFi-Intelligence-Plattform von Purple. Dieser Leitfaden behandelt die Architektur, die schrittweise Konfiguration von externen Captive Portals und RADIUS sowie Multi-Site-Rollout-Strategien für IT-Teams in Unternehmen.
Haben Sie Fragen zu Ihrem spezifischen Setup?
Unser Team arbeitet mit Standortbetreibern, IT-Managern und Netzwerktechnikern an über 80.000 Standorten zusammen. Buchen Sie ein 20-minütiges Gespräch und wir zeigen Ihnen, wie andere diese Herausforderungen gelöst haben.