Zum Hauptinhalt springen
Deutsch

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-Agents auf die WiFi-Authentifizierung ausdehnen möchten. Er behandelt die gesamte Authentifizierungsarchitektur, die Abwägung bei der Durchsetzung von MFA, die dynamische VLAN-Zuweisung über RADIUS-Attribut-Mapping sowie die kritische Entscheidung zwischen passwortbasiertem EAP-TTLS und zertifikatsbasiertem EAP-TLS. Betreiber von Veranstaltungsorten und IT-Teams in Unternehmen erhalten praxisnahe Bereitstellungsanleitungen, Fallstudien aus der Praxis für das Gastgewerbe und den Einzelhandel sowie einen klaren Rahmen für die Integration von Okta RADIUS neben dedizierten Lösungen für Gäste-WiFi.

📖 11 Min. Lesezeit📝 2,672 Wörter🔧 2 ausgearbeitete Beispiele❓ 3 Übungsfragen📚 10 Schlüsseldefinitionen

Diesen Leitfaden anhören

Podcast-Transkript ansehen
Willkommen beim Purple Technical Briefing. Heute widmen wir uns einem Thema, das genau an der Schnittstelle von Netzwerkarchitektur und Identitätsmanagement liegt: Okta und RADIUS für die WiFi-Authentifizierung. Wenn Sie IT-Manager, Netzwerkarchitekt oder Leiter des Standortbetriebs sind, kennen Sie bereits die Kopfschmerzen, die mit der Verwaltung separater Anmeldedaten für den Netzwerkzugriff verbunden sind. Sie haben Ihr Okta-Verzeichnis für Cloud-Anwendungen, aber Ihr WiFi verlässt sich vielleicht immer noch auf einen veralteten Active Directory-Server oder, noch schlimmer, auf ein gemeinsames WPA2-Passwort, das an der Wand des Pausenraums pinnt. Heute schauen wir uns an, wie Sie diese Lücke mithilfe des Okta RADIUS-Agents schließen können. Wir behandeln die Architektur, den Umgang mit Multi-Faktor-Authentifizierung im WiFi, die entscheidenden Kompromisse zwischen passwortbasierter und zertifikatsbasierter Authentifizierung und wie Sie Okta-Gruppen RADIUS-Attributen für eine dynamische VLAN-Zuweisung zuordnen. Lassen Sie uns direkt einsteigen. Beginnen wir mit der Architektur. Wie funktioniert der Okta RADIUS-Agent eigentlich? Der Okta RADIUS-Agent ist eine schlanke Anwendung, die Sie lokal – in der Regel auf einem Windows- oder Linux-Server – oder in einer virtuellen Maschine in der Cloud bereitstellen. Er fungiert als Proxy. Er sitzt zwischen Ihrer Netzwerkinfrastruktur, wie Ihren Wireless Access Points oder Ihrem Wireless LAN Controller, und der Okta-Cloud. Wenn ein Benutzer versucht, sich mit Ihrem 802.1X-Enterprise-WiFi zu verbinden, sendet sein Gerät die Anmeldedaten an den Access Point. Der Access Point, der im 802.1X-Modell als sogenannter Authentifikator fungiert, leitet einen RADIUS Access-Request über den UDP-Port 1812 an den Okta RADIUS-Agent weiter. Der Agent nimmt diese Anfrage entgegen und tunnelt sie über einen HTTPS-API-Aufruf sicher in die Okta-Cloud. Okta validiert die Anmeldedaten, prüft die Anmelderichtlinien und gibt eine Entscheidung zurück. Der Agent übersetzt diese dann wieder in eine RADIUS Access-Accept- oder Access-Reject-Nachricht für den Access Point. Dies ist eine clevere Methode, um Ihren Cloud-Identitätsanbieter bis an den lokalen Netzwerkrand auszuweiten, ohne Ihr Verzeichnis direkt dem Internet auszusetzen. Nun zur großen Frage, die sich jeder stellt: Können Sie Okta MFA für WiFi-Verbindungen erzwingen? Die kurze Antwort lautet: Ja, aber mit wichtigen Einschränkungen. Der Okta RADIUS-Agent unterstützt in erster Linie das Password Authentication Protocol (PAP). Da PAP das Passwort im Klartext sendet, wird es durch den äußeren TLS-Tunnel des EAP-Protokolls (Extensible Authentication Protocol) gekapselt und geschützt. Diese Anordnung ermöglicht es dem Agenten, MFA-Abfragen zu verarbeiten. Sie können Okta so konfigurieren, dass eine Okta Verify-Benachrichtigung an das Telefon des Benutzers gesendet wird, oder ihn auffordern, einen TOTP-Code – ein zeitbasiertes Einmalpasswort – an sein Passwort anzuhängen. Hier kollidiert jedoch die Benutzererfahrung mit der Sicherheit. Stellen Sie sich vor, Sie müssten einen Mitarbeiter im Einzelhandel bitten, jedes Mal eine Push-Benachrichtigung zu bestätigen, wenn sich sein Telefon wieder mit dem Mitarbeiter-WiFi verbindet, während er durch die Verkaufsfläche läuft. Das führt zu Reibungsverlusten. Darüber hinaus trennen viele moderne Geräte die WiFi-Verbindung, wenn die MFA-Abfrage zu lange dauert. Obwohl MFA über WiFi technisch möglich ist und von Okta unterstützt wird, empfehlen wir dies im Allgemeinen nur für hochgradig privilegierte Zugriffe, wie z. B. IT-Admin-SSIDs, und nicht für das allgemeine Mitarbeiter-WiFi. Dies bringt uns zu dem entscheidenden Kompromiss: Passwort-basiertes RADIUS mit Okta versus zertifikatsbasierte Authentifizierung, speziell EAP-TLS. Wenn Sie den Okta RADIUS-Agenten mit EAP-TTLS oder PAP verwenden, verlassen Sie sich auf Passwörter. Passwörter können gestohlen, durch Phishing entwendet oder weitergegeben werden. Zudem ist das Hinzufügen von MFA zu WiFi, wie gerade besprochen, in der Praxis unhandlich. Auf der anderen Seite nutzt EAP-TLS digitale Zertifikate, die auf dem Gerät des Benutzers bereitgestellt werden. Es bietet eine gegenseitige Authentifizierung – das Gerät beweist dem Netzwerk seine Identität, und das Netzwerk beweist dem Gerät seine Identität. Es müssen keine Passwörter eingegeben werden, und es ist äußerst resistent gegen Phishing. Der Haken an der Sache? Der Okta RADIUS-Agent fungiert nativ nicht als Zertifizierungsstelle (Certificate Authority). Wenn Sie EAP-TLS nutzen möchten, benötigen Sie eine Public-Key-Infrastruktur (PKI) – Lösungen wie SecureW2, Foxpass oder Microsoft Active Directory Certificate Services – und eine Mobile-Device-Management-Lösung, um die Zertifikate auf Ihren Endgeräten zu verteilen. Okta kann weiterhin der Identity Provider sein, der die Zertifikatsausstellung autorisiert, aber der RADIUS-Agent selbst übernimmt nicht die Hauptarbeit für EAP-TLS. Für BYOD-Umgebungen ist das passwortbasierte Okta RADIUS schnell und einfach bereitzustellen. Für verwaltete Unternehmensgeräte ist EAP-TLS der Goldstandard. Kommen wir zu einer der leistungsstärksten Funktionen: der dynamischen VLAN-Zuweisung. In einer großen Location – einem Hotel, einem Stadion, einem Konferenzzentrum – möchten Sie nicht, dass sich alle Ihre Mitarbeiter im selben Netzwerksegment befinden. Sie möchten, dass die Point-of-Sale-Terminals von den Tablets des Housekeepings isoliert sind und dass sich die IT-Mitarbeiter in einem Management-VLAN befinden. Wie erreichen Sie das mit Okta? Es dreht sich alles um das RADIUS-Attribut-Mapping. In der Okta-Admin-Konsole können Sie unter den RADIUS-Anwendungseinstellungen eine Funktion namens „Include groups in RADIUS response“ aktivieren. Sie legen fest, welche Okta-Gruppen in der Authentifizierungsantwort zurückgegeben werden sollen. Okta gibt diese Gruppenmitgliedschaft über Standard-RADIUS-Attribute an Ihren Netzwerk-Controller zurück – typischerweise Attribut 11 für Filter-ID oder Attribut 25 für Class. Ihr Wireless-Controller oder Ihr Network Access Control-System, wie Aruba ClearPass oder Cisco ISE, empfängt diesen Gruppennamen. Sie konfigurieren dann eine lokale Richtlinie auf dem Controller, die beispielsweise besagt: Wenn das RADIUS-Attribut 25 gleich „Retail-POS“ ist, weise den Client dem VLAN 40 zu. Der Controller sendet die Standard-Tunnel-Attribute – Tunnel-Type, Tunnel-Medium-Type und Tunnel-Private-Group-ID – an den Access Point und verschiebt den Benutzer dynamisch in das richtige VLAN. Dies ist eine nahtlose Methode zur Durchsetzung der Netzwerksegmentierung, die rein auf der Okta-Identität basiert. Dies ist enorm wichtig für die Einhaltung von Standards wie PCI DSS, die eine strikte Netzwerksegmentierung in Umgebungen mit Karteninhaberdaten vorschreiben. Sehen wir uns nun einige reale Implementierungsszenarien an. Stellen Sie sich eine nationale Hotelkette mit Standorten im gesamten Vereinigten Königreich vor. Jeder Standort verfügt über eine Mischung aus Mitarbeitern an der Rezeption, im Housekeeping, im Bereich Gastronomie und im Management. Zuvor betrieb jeder Standort einen eigenen NPS-Server mit einem lokalen Active Directory. Das IT-Team verbrachte viel Zeit mit der Verwaltung lokaler Konten und der Behebung von RADIUS-Fehlern. Durch die Bereitstellung des Okta RADIUS-Agents in zwei redundanten virtuellen Cloud-Maschinen, die Zentralisierung aller Benutzerkonten in Okta und die Konfiguration einer gruppenbasierten VLAN-Zuweisung konnte die Kette den IT-Overhead pro Standort erheblich reduzieren. Die Mitarbeiter an der Rezeption authentifizieren sich mit ihren Okta-Anmeldedaten und werden automatisch dem Guest-Services-VLAN zugewiesen. Mitarbeiter des Managements, die sich in einer anderen Okta-Gruppe befinden, landen im Management-VLAN mit Zugriff auf die Hotelmanagementsysteme. Die gesamte Konfiguration wird über eine einzige Okta-Admin-Konsole verwaltet, und das Okta-Systemprotokoll bietet einen vollständigen Audit-Trail für jedes Authentifizierungsereignis an allen Standorten. Ein zweites Szenario: eine große Einzelhandelskette mit über 300 Filialen. Jede Filiale verfügt über ein Mitarbeiter-WiFi-Netzwerk, das für die Bestandsverwaltung, Point-of-Sale-Terminals und Back-Office-Aktivitäten genutzt wird. Die PCI-DSS-Konformität erfordert eine strikte Netzwerksegmentierung zwischen der Karteninhaber-Datenumgebung und dem allgemeinen Mitarbeiterzugriff. Durch die Integration von Okta RADIUS in die bestehende Wireless-Infrastruktur ordnet der Einzelhändler die Okta-Gruppen – POS-Staff, Inventory-Staff und Store-Management – drei verschiedenen VLANs zu. Wenn sich ein Filialmitarbeiter verbindet, wird sein Gerät basierend auf seiner Okta-Gruppenmitgliedschaft automatisch im richtigen VLAN platziert. Ändert ein Mitarbeiter seine Rolle, ändert die Aktualisierung seiner Okta-Gruppenmitgliedschaft bei der nächsten Verbindung sofort seinen Netzwerkzugriff. Keine Firewall-Regeln, die aktualisiert werden müssen, keine VLAN-Konfigurationen, die an einzelne Filialen übertragen werden müssen. Kommen wir nun zu den Implementierungsempfehlungen und häufigen Fallstricken. Der erste und häufigste Fehler ist das Ignorieren der Timeout-Einstellungen. Okta-API-Aufrufe benötigen Zeit, insbesondere wenn ein MFA-Push involviert ist. Wenn das RADIUS-Timeout Ihres Wireless-Controllers auf die standardmäßigen drei oder fünf Sekunden eingestellt ist, läuft die Anfrage ab, bevor der Benutzer auf seinem Telefon auf „Genehmigen“ tippen kann. Sie müssen das RADIUS-Timeout auf Ihrem WLC auf mindestens dreißig bis sechzig Sekunden erhöhen. Dies ist eine Konfigurationsänderung auf der Netzwerkseite, nicht in Okta, und sie wird häufig übersehen. Die zweite Empfehlung betrifft die Hochverfügbarkeit. Implementieren Sie niemals nur einen einzigen Okta-RADIUS-Agenten. Stellen Sie mindestens zwei Agenten auf separaten Servern bereit und konfigurieren Sie Ihren Wireless-Controller so, dass er die Last zwischen ihnen verteilt. Wenn ein Server für Patches heruntergefahren wird, bleibt Ihre WiFi-Authentifizierung aktiv. Der dritte Fallstrick: Vorsicht bei PEAP. Der Okta-RADIUS-Agent unterstützt kein PEAP-MSCHAPv2, was in vielen älteren Windows-Umgebungen der Standard ist. Sie müssen Ihre Clients so konfigurieren, dass sie EAP-TTLS mit PAP verwenden. Dies erfordert in der Regel die Verteilung eines Wireless-Profils über Gruppenrichtlinien oder MDM, da Windows standardmäßig nicht ohne Weiteres EAP-TTLS verwendet. Dies nicht zu tun, ist der Hauptgrund für fehlgeschlagene Bereitstellungen. Zeit für eine kurze Fragerunde basierend auf häufigen Kundenfragen. Frage eins: Können wir Okta RADIUS für Gäste-WiFi nutzen? Antwort: Nein. Die Preisgestaltung von Okta erfolgt pro Benutzer und ist für die Identitätsverwaltung von Mitarbeitern konzipiert. Für Gäste-WiFi sollten Sie eine speziell entwickelte Captive Portal-Lösung verwenden, die Nutzungsbedingungen, Social Login und Analysen abwickelt, ohne Okta-Lizenzen zu verbrauchen. Frage zwei: Unterstützt Okta RADIUS YubiKeys für die WiFi-Authentifizierung? Antwort: Im Allgemeinen nein. Hardware-Token und WebAuthn lassen sich über das RADIUS-Protokoll nur schwer übertragen. Nutzen Sie stattdessen Okta Verify Push oder TOTP, wenn Sie MFA für WiFi erzwingen müssen. Frage drei: Wie verhält sich dies im Zusammenspiel mit einem Purple-Deployment? Antwort: Hervorragend. Purple-Unternehmenskunden, die Okta als Identitätsanbieter nutzen, können Okta RADIUS verwenden, um das Mitarbeiter-WiFi sicher zu authentifizieren, während sie das Captive Portal von Purple für den Gästezugang auf einer separaten SSID nutzen. Dies positioniert Purple an der Seite von Okta in einem einheitlichen, modernen Authentifizierungs-Stack – Mitarbeiter auf einer SSID mit Okta RADIUS, Gäste auf einer anderen mit dem gebrandeten Portal von Purple. Zusammenfassend für das heutige Briefing: Der Okta RADIUS-Agent ist ein leistungsstarkes Tool, um veraltete On-Premises-Verzeichnisse zu eliminieren und Ihre WiFi-Authentifizierung in Ihrem Cloud-Identitätsanbieter zu vereinheitlichen. Er unterstützt die dynamische VLAN-Zuweisung für eine robuste Netzwerksegmentierung, was für die Einhaltung von PCI DSS und anderen Frameworks von entscheidender Bedeutung ist. Achten Sie jedoch auf die Benutzererfahrung, wenn Sie MFA für WiFi erzwingen, und denken Sie daran, dass für vollständig verwaltete Unternehmensgeräte die Migration zu zertifikatsbasiertem EAP-TLS mit einer dedizierten PKI die sicherere langfristige Strategie ist. Der Okta RADIUS-Agent ist eine hervorragende Brückenlösung, insbesondere für Unternehmen, die Okta-zentriert sind und diese Identitätsinvestition schnell auf die Netzwerkschicht ausweiten möchten. Das ist alles für dieses Briefing. Lesen Sie unbedingt den vollständigen technischen Referenzleitfaden für detaillierte Konfigurationsschritte, Architekturdiagramme und Praxisbeispiele. Bis zum nächsten Mal – halten Sie Ihre Netzwerke sicher und Ihre Benutzer verbunden.

header_image.png

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-Identity-Provider 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ägung zwischen passwortbasiertem EAP-TTLS und zertifikatsbasiertem EAP-TLS. Darüber hinaus bietet er praktische Anleitungen zur Zuordnung von Okta-Gruppenmitgliedschaften zu RADIUS-Attributen für die dynamische VLAN-Zuweisung – eine Funktion, die die Anforderungen zur PCI DSS-Netzwerksegmentierung direkt unterstützt. Durch die Integration von Okta für die Mitarbeiterauthentifizierung parallel zu Guest WiFi -Lösungen können Standortbetreiber eine einheitliche, sichere und konforme Zugriffsebene realisieren, ohne die Identitätsinfrastruktur duplizieren zu müssen.

Technischer Deep-Dive

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 vor Ort oder in einer Cloud-VPC bereitgestellt und nach der Erstinstallation vollständig über die Okta-Admin-Konsole verwaltet.

Der Authentifizierungsfluss folgt einem standardmäßigen 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 den konfigurierten Anmelderichtlinien abgleicht. Wenn die Authentifizierung erfolgreich ist, sendet der Agent eine RADIUS-Access-Accept-Nachricht an den Authenticator zurück, optional inklusive RADIUS-Attributen für die Autorisierung wie der VLAN-Zuweisung. Wenn MFA erforderlich ist, sendet der Agent einen RADIUS-Access-Challenge an den Client zurück und fordert einen zweiten Faktor an, bevor die endgültige Entscheidung übermittelt wird.

architecture_overview.png

Dieses Proxy-Modell bedeutet, dass der Okta RADIUS-Agent keine Benutzeranmeldedaten lokal speichern muss. Die gesamte Authentifizierungslogik, Richtlinienbewertung und Audit-Protokollierung erfolgen in der Okta-Cloud. Dies bietet Administratoren eine zentrale Oberfläche für die Identity Governance 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 siehe 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 bereitstellen, die über SAML oder OIDC mit Okta als IdP integriert wird, 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-Zugriff, bringt jedoch Herausforderungen für die Benutzererfahrung 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 Mobilgerät auf „Genehmigen“
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 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 (roamen), was jedes Mal eine erneute Authentifizierung auslöst. Die Anforderung einer Push-Benachrichtigungsfreigabe bei jedem Roaming-Vorgang 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 bleiben.

Passwortbasierte vs. zertifikatsbasierte Authentifizierung

Die Wahl zwischen passwortbasiertem RADIUS (über den Okta RADIUS-Agenten) und zertifikatsbasiertem EAP-TLS ist eine der folgenschwersten Entscheidungen bei einer WiFi-Bereitstellung in Unternehmen. Die Abwägungen betreffen nicht nur die Sicherheit, sondern auch die Komplexität der Bereitstellung, den Reifegrad der Geräteverwaltung und den betrieblichen Aufwand.

comparison_chart.png

Die passwortbasierte Authentifizierung über den Okta RADIUS-Agenten bietet einen schnellen Weg zu einer einheitlichen Identität. Wenn Ihr Unternehmen Benutzer bereits in Okta verwaltet, kann die Bereitstellung in Stunden statt in Wochen abgeschlossen werden. Es muss keine PKI aufgebaut, keine Zertifikate verteilt und keine MDM-Abhängigkeit berücksichtigt werden. Der Nachteil ist, dass Passwörter das primäre Anmeldeverfahren bleiben und 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.

Zertifikatsbasiertes EAP-TLS eliminiert Passwörter vollständig aus der WiFi-Authentifizierungsgleichung. Der Client legt ein Gerätezertifikat vor, und der RADIUS-Server präsentiert ein Serverzertifikat, 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 NCSC 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 in der Lage ist, Zertifikate an alle verwalteten Endpunkte zu verteilen. Für Retail -Umgebungen mit Hunderten von verwalteten Point-of-Sale-Geräten ist diese Investition absolut gerechtfertigt. Für BYOD-lastige Umgebungen oder schnelle Bereitstellungen ist Okta RADIUS mit EAP-TTLS die pragmatische Wahl.

RADIUS-Attributzuordnung für dynamische VLAN-Zuweisung

Die dynamische VLAN-Zuweisung ist der Bereich, in dem die Okta RADIUS-Integration ihren greifbarsten 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 verwalten zu müssen.

Okta übergibt Gruppenmitgliedschaftsdaten in der RADIUS-Nachricht Access-Accept unter Verwendung 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. Weitgehend herstellerübergreifend 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 Unterattribute für eine feingranularere Steuerung.

Der Netzwerk-Controller (WLC, NAC-Appliance) empfängt den Okta-Gruppennamen im ausgewä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 VLAN-Tunnelling
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. Die WLC-Richtlinie würde dies auf Tunnel-Private-Group-ID: 40 abbilden und das Gerät im VLAN 40 – dem isolierten POS-Netzwerk – platzieren. Ein Benutzer in Store-Management würde im VLAN 50 platziert. Diese Logik wird am Edge des Netzwerks erzwungen, nicht in Okta, wird jedoch vollständig durch die Okta-Gruppenmitgliedschaft gesteuert.

Implementierungsleitfaden

Schritt 1: Bereitstellung des Okta RADIUS Agents (Hochverfügbarkeit)

Stellen Sie den Okta RADIUS Agent auf mindestens zwei Servern bereit – entweder lokal oder in einer Cloud-VPC –, um Hochverfügbarkeit zu gewährleisten. Bereitstellungen mit nur einem Agent 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 zwischen beiden Agents gleichmäßig verteilt werden (Load Balancing).

Während der Installation fordert der Agent zur Anmeldung eines Okta-Administrators auf, um den Agent zu autorisieren und mit dem Okta-Tenant zu verknüpfen. Nach der Autorisierung erscheint der Agent in der Okta-Admin-Konsole unter Settings > Downloads > RADIUS Agent Status, wo Zustand und Konnektivität überwacht werden können.

Schritt 2: Konfigurieren der RADIUS-Anwendung in Okta

  1. Navigieren Sie in der Okta-Admin-Konsole zu Applications > Applications und suchen Sie im App-Katalog nach RADIUS Application.
  2. Fügen Sie die Anwendung hinzu, vergeben Sie einen aussagekräftigen Namen (z. B. Corporate-WiFi-Staff) und klicken Sie auf Next.
  3. Konfigurieren Sie unter der Registerkarte Sign On den RADIUS Port (Standard 1812) und generieren Sie ein starkes, zufällig generiertes Shared Secret mit mindestens 32 Zeichen.
  4. Aktivieren Sie unter Advanced RADIUS Settings die Option Accept password and security token in the same login request, wenn Sie die an Passwörter angehängte TOTP-Authentifizierung unterstützen möchten.
  5. Aktivieren Sie optional Permit Automatic Push for Okta Verify Enrolled Users für eine nahtlose, Push-basierte MFA.
  6. Weisen Sie die Anwendung den relevanten Okta-Gruppen zu, die Ihre Mitarbeiter repräsentieren.

Schritt 3: Konfigurieren der gruppenbasierten VLAN-Zuweisung

  1. Klicken Sie in den Sign On-Einstellungen der RADIUS-Anwendung im Bereich Advanced RADIUS Settings auf Edit.
  2. Aktivieren Sie das Kontrollkästchen Include groups in RADIUS response.
  3. 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.
  4. Fügen Sie die spezifischen Okta-Gruppennamen hinzu, die einbezogen werden sollen (z. B. Retail-POS-Staff, Store-Management, IT-Admins).
  5. Erstellen Sie auf Ihrer WLC- oder NAC-Appliance Durchsetzungsrichtlinien, die jeden Gruppennamen den entsprechenden VLAN-Tunnelattributen zuordnen.

Schritt 4: Konfigurieren der Client-Supplicants

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. Stellen Sie ein Profil für das drahtlose Netzwerk über Ihre MDM-Plattform (z. B. Microsoft Intune, Jamf Pro) oder über Gruppenrichtlinienobjekte (GPO) für in die Windows-Domäne eingebundene Geräte bereit. 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 (an den CN des Serverzertifikats Ihres RADIUS-Agenten anheften)

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 betriebliche Best Practices unterscheiden eine robuste Produktionsumgebung von einem anfälligen Proof-of-Concept.

Segmentieren Sie den Datenverkehr von Gästen und Mitarbeitern auf SSID-Ebene. Okta RADIUS ist ein Tool für die Identitätsverwaltung von Mitarbeitern. Verwenden Sie für den Besucher- und Gästezugriff eine dedizierte Captive Portal-Lösung. Dies verhindert, dass die Okta-Lizenzkosten mit dem Gästevolumen skalieren, und sorgt für eine saubere Trennung der Zuständigkeiten. 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, der 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, Fehlschlag, MFA-Aufforderung und Faktortyp – wird im Okta-Systemprotokoll aufgezeichnet. Konfigurieren Sie das Protokoll-Streaming an Ihr SIEM für Echtzeit-Warnungen bei Authentifizierungsanomalien. Dies ist besonders wertvoll für Organisationen im Gesundheitswesen und im öffentlichen Sektor, die Audit-Anforderungen unterliegen.

Rotieren Sie Shared Secrets nach einem Zeitplan. Das Shared Secret zwischen der Okta RADIUS-Anwendung und Ihrem NAS ist ein kritischer Sicherheitsnachweis. Implementieren Sie einen Rotationszeitplan (empfohlen wird vierteljährlich) und aktualisieren Sie sowohl die Okta-Anwendung als auch die WLC/NAC-Konfiguration gleichzeitig.

RADIUS-Dienstadressen einschränken. Schränken Sie in der Konfiguration des Okta RADIUS-Agenten ein, 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.

Security Posture. Durch das Ersetzen gemeinsam genutzter PSK-WiFi-Passwörter durch eine benutzerbezogene 802.1X-Authentifizierung wird die Weitergabe von Anmeldedaten eliminiert – 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-Systemprotokoll bietet einen vollständigen, 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. Anforderung 1.3 erfordert eine Netzwerksegmentierung zwischen der Karteninhaber-Datenumgebung und anderen Netzwerken. Okta RADIUS mit gruppenbasierter VLAN-Zuweisung adressiert beide Anforderungen direkt. Für die GDPR-Compliance liefert das Okta-Systemprotokoll die Zugriffsprotokolle, die erforderlich sind, um angemessene technische Kontrollen über Systeme zur Verarbeitung personenbezogener Daten nachzuweisen. Für Veranstaltungsorte, die Modern Hospitality WiFi Solutions einsetzen, ist dieser einheitliche Ansatz für Identitäts- und Netzwerkzugriff zunehmend eine Voraussetzung für die Beschaffung im Enterprise-Bereich.

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-Agents – 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 hinweg summieren.

Schlüsseldefinitionen

Okta RADIUS Agent

Ein schlanker, lokaler oder in der Cloud gehosteter Proxy-Dienst, der RADIUS-Authentifizierungsanfragen von der Netzwerkinfrastruktur (Access Points, WLCs) in Okta-API-Aufrufe übersetzt. Dadurch kann die Okta-Cloud als Authentifizierungs-Backend für 802.1X-WiFi dienen.

IT-Teams stoßen darauf, wenn sie eine durch Okta gestützte Enterprise-WiFi-Authentifizierung 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 drahtlose 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 Enterprise-WiFi-Sicherheit. Jede Bereitstellung, die WPA2-Enterprise oder WPA3-Enterprise nutzt, verwendet 802.1X. IT-Teams müssen das Drei-Parteien-Modell (Supplicant, Authenticator, Authentifizierungsserver) verstehen, um Verbindungsprobleme zu beheben.

EAP-TTLS (Extensible Authentication Protocol - Tunnelled Transport Layer Security)

Eine EAP-Methode, die einen TLS-Tunnel ausschließlich unter Verwendung eines serverseitigen Zertifikats aufbaut und anschließend ein einfacheres inneres Authentifizierungsprotokoll (wie PAP) innerhalb des Tunnels überträgt. Dies schützt die inneren Anmeldedaten vor 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 eine gegenseitige zertifikatsbasierte Authentifizierung nutzt – 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 ein MDM für die Zertifikatsverteilung. Der Okta-RADIUS-Agent unterstützt EAP-TLS nicht nativ; hierfür ist ein dedizierter Cloud-PKI- oder RADIUS-Dienst 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.

Dynamic VLAN Assignment

Eine Methode zur Netzwerkzugriffskontrolle, 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 einem bestimmten VLAN zuzuweisen, anstatt eines statischen VLANs pro SSID.

Die dynamische VLAN-Zuweisung ist für die Netzwerksegmentierung in Umgebungen mit mehreren Rollen unerlässlich (z. B. zur Trennung von POS-Terminals von allgemeinen Mitarbeitergeräten). Sie wird konfiguriert, indem die RADIUS-Attribute 64, 65 und 81 in der Access-Accept-Nachricht zurückgegeben werden.

RADIUS Attribute 25 (Class)

Ein Standard-RADIUS-Attribut, das zur Übertragung 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 Zugriffsrichtlinienentscheidungen nutzen kann.

IT-Teams, die eine Okta-gruppenbasierte VLAN-Zuweisung einrichten, konfigurieren den WLC so, dass er den Wert des Class-Attributs liest und einer VLAN-ID zuordnet. Welches Attribut genau zu verwenden ist (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 Authenticator 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 Filterkonfiguration für Dienstadressen des Okta-RADIUS-Agenten auf die Whitelist gesetzt werden.

Shared Secret

Ein vorab freigegebenes Passwort zur Authentifizierung von RADIUS-Nachrichten zwischen dem NAS (WLC/AP) und dem RADIUS-Server (Okta-RADIUS-Agent). Es wird verwendet, um einen Message-Authenticator-Hash zu berechnen, der die Integrität der RADIUS-Pakete ü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 Fehler bei der RADIUS-Authentifizierung.

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 (z. B. OTP, Push-Bestätigung) antworten muss, 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-Mitarbeiter-WiFi-Authentifizierung. 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-Agents, der in einer zentralen Cloud-VPC und nicht an jedem Standort bereitgestellt wird. Phase 1: Stellen Sie zwei Okta RADIUS-Agent-Instanzen in einer Cloud-VPC (z. B. AWS oder Azure) in derselben Region bereit, in der sich die Mehrheit der Standorte befindet. Konfigurieren Sie die Agents so, dass sie auf UDP 1812 lauschen. Phase 2: Fügen Sie für jeden Standort die Okta RADIUS-Agent-IPs als sekundäre RADIUS-Server auf dem WLC hinzu, wobei der vorhandene NPS als primärer Server beibehalten wird. Dies ermöglicht den Parallelbetrieb und Tests, ohne die Live-Authentifizierung zu stören. Phase 3: Migrieren Sie Benutzer vom lokalen AD zu Okta. Verwenden Sie den AD-Agent 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 Wireless-Profil über MDM an die Geräte der Mitarbeiter. Phase 5: Sobald alle Geräte auf EAP-TTLS bestätigt sind, schalten Sie die WLC RADIUS-Priorität auf die Okta-Agents als primäre Server um und nehmen Sie die NPS-Server außer Betrieb. Konfigurieren Sie Okta-Gruppen (Front-Desk, Housekeeping, F&B, 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 das WLC RADIUS-Timeout auf 45 Sekunden, um die Okta API-Latenz auszugleichen.

Kommentar des Prüfers: Dieser schrittweise Ansatz wird bevorzugt, da er das Risiko einer harten Umstellung an 150 Standorten gleichzeitig eliminiert. Der parallele Betrieb von NPS und Okta RADIUS während der Übergangszeit bedeutet, dass Fehlkonfigurationen erkannt und korrigiert werden können, ohne die Live-Benutzer zu beeinträchtigen. Die Bereitstellung der RADIUS-Agents in der Cloud-VPC ist architektonisch der Bereitstellung pro Standort überlegen, da sie das Management zentralisiert, den Infrastruktur-Footprint reduziert und eine konsistente Richtliniendurchsetzung gewährleistet, unabhängig davon, von welchem Standort aus sich ein Benutzer authentifiziert. Das wichtigste zu mindernde Risiko ist die WAN-Latenz zwischen dem Standort und der Cloud-VPC — die RADIUS-Authentifizierung sollte für eine gute Benutzererfahrung in weniger als 2 Sekunden abgeschlossen sein, daher sollte die Auswahl der VPC-Region die Round-Trip-Time minimieren.

Eine nationale Einzelhandelskette mit 320 Filialen muss die PCI DSS 4.0-Konformität für ihr Mitarbeiter-WiFi erreichen. Filialmitarbeiter nutzen Handheld-Geräte für die Bestandsverwaltung, und eine separate Gruppe von Geräten wickelt Point-of-Sale-Transaktionen ab. Die Kette nutzt Okta für die gesamte Workforce Identity. Wie implementieren sie die VLAN-Segmentierung mit Okta RADIUS, um die PCI DSS-Netzwerksegmentierungsanforderungen zu erfüllen?

Erstellen Sie drei Okta-Gruppen: POS-Staff (für Mitarbeiter, die POS-Terminals bedienen), Inventory-Staff (für Lager- und Filialmitarbeiter) 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 Response-Konfiguration 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 für PCI DSS relevant ist und über Firewall-Regeln verfügt, die den Zugriff nur 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 Filialmanagementsysteme). Geräte, die sich mit den Anmeldedaten eines Benutzers aus der Gruppe POS-Staff verbinden, werden automatisch im VLAN 40 platziert. Wenn sich die Rolle eines Filialmitarbeiters ändert, ändert die Aktualisierung seiner Okta-Gruppenmitgliedschaft sofort seine VLAN-Zuweisung bei der nächsten Verbindung — es ist keine WLC-Rekonfiguration erforderlich. Dokumentieren Sie die Okta-Gruppe-zu-VLAN-Zuordnung im Netzwerksegmentierungsdiagramm für das PCI DSS QSA-Audit.

Kommentar des Prüfers: Diese Implementierung erfüllt direkt die PCI DSS 4.0-Anforderung 1.3 (Netzwerksegmentierung) und Anforderung 7 (Zugriffskontrolle basierend auf geschäftlicher Notwendigkeit). Die entscheidende Erkenntnis ist, dass die VLAN-Zuweisung durch die Identität gesteuert wird und nicht durch die Geräte-MAC-Adresse oder eine statische VLAN-Konfiguration — was bedeutet, dass sie über 320 Filialen hinweg ohne filialspezifische VLAN-Richtlinienpflege skaliert. Der QSA wird Nachweise dafür sehen wollen, dass das POS-VLAN tatsächlich von anderen Netzwerksegmenten isoliert ist, daher müssen die WLC- und Firewall-Konfigurationen die VLAN-Grenzen widerspiegeln. Das Systemprotokoll von Okta liefert den von der PCI DSS-Anforderung 10 (Protokollierung und Überwachung) geforderten Authentifizierungs-Audit-Trail. Ein wichtiger Vorbehalt: Wenn POS-Geräte unmanaged sind oder gemeinsam genutzt werden (d. h. keinem bestimmten Benutzer zugewiesen sind), sollten Sie für diese Geräte ein MAC Authentication Bypass (MAB) anstelle von 802.1X in Betracht ziehen, wobei Okta RADIUS nur für benutzerauthentifizierte Geräte verwendet wird.

Ü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 über ihre bestehenden Cisco Meraki Access Points bereitstellen. Ihre Windows-Laptops werden über Microsoft Intune verwaltet. Der IT-Manager möchte die Okta Verify Push-MFA für alle WiFi-Verbindungen erzwingen. Welches sind die drei kritischsten Konfigurationsschritte, die sie durchführen müssen, und was ist das wahrscheinlichste Fehlerszenario, wenn sie einen davon auslassen?

Hinweis: Berücksichtigen Sie die EAP-Protokollkompatibilität zwischen Okta RADIUS und Windows-Standards, die RADIUS-Timeout-Einstellung und die Konfiguration des Wireless-Profils des Clients.

Musterlösung anzeigen

Die drei kritischen Schritte sind: (1) Bereitstellung eines Wireless-Profils über Intune, das Windows-Clients so konfiguriert, dass sie EAP-TTLS mit PAP als innere Methode verwenden – 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 erweiterten RADIUS-Einstellungen der Okta RADIUS-Anwendung – andernfalls werden Benutzer möglicherweise aufgefordert, ihren MFA-Faktor manuell auszuwählen, anstatt einen automatischen Push zu erhalten. Das wahrscheinlichste Fehlerszenario bei Auslassen von Schritt 1 ist ein vollständiger Authentifizierungsfehler für alle Windows-Geräte. Wenn Schritt 2 ausgelassen wird, schlägt die Authentifizierung bei Benutzern, die länger als 5 Sekunden für die Bestätigung des Pushs benötigen, sporadisch fehl. Wenn Schritt 3 ausgelassen wird, sehen sich die Benutzer mit einer verwirrenden Aufforderung konfrontiert, anstatt eine nahtlose Push-Benachrichtigung zu erhalten.

Q2. Das Sicherheitsteam einer großen Einzelhandelskette hat festgestellt, dass ihre aktuelle Okta RADIUS WiFi-Bereitstellung einen einzigen RADIUS-Agenten-Server verwendet. Während eines kürzlichen Patch-Fensters war der Server 45 Minuten lang offline, was zu einem Ausfall der WiFi-Authentifizierung in allen 80 Filialen führte. 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 Agentenbereitstellung als auch die WLC-Konfiguration, die zur Unterstützung von Redundanz erforderlich ist.

Musterlösung anzeigen

Das IT-Team sollte mindestens zwei Okta RADIUS-Agenten-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 (oder mit aktiviertem Load Balancing). Dies minimiert die Infrastruktur pro Standort, führt jedoch zu einer WAN-Abhängigkeit. Option B (On-Premises Redundant Pair) – Bereitstellung von zwei Agenten-Servern in einem zentralen Rechenzentrum oder einer Co-Location-Einrichtung, wobei der WLC 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 die Zustandsüberwachung in der Okta Admin Console konfigurieren und Warnmeldungen einrichten, wenn 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 erhöhen.

Q3. Ein 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 was ist die primäre Sicherheitsbegründung?

Hinweis: Berücksichtigen Sie die PCI DSS-Anforderungen, den Reifegrad der Geräteverwaltung (alle Geräte sind MDM-registriert) und die Sicherheitseigenschaften der einzelnen Authentifizierungsmethoden.

Musterlösung anzeigen

Der empfohlene Ansatz ist die Investition in EAP-TLS mit einer Cloud-PKI-Lösung. 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 gefälschter AP die SSID des Unternehmens imitiert) und entfernt Passwörter vollständig aus der WiFi-Authentifizierung, 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 administrativen Zugriff 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 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 des vollständig verwalteten Gerätebestands ist EAP-TLS die richtige langfristige Architektur. Die zusätzliche Investition in einen Cloud-PKI-Dienst (normalerweise 3-8 USD pro Gerät und Jahr) ist durch den Sicherheitsgewinn und den geringeren Aufwand für die Verwaltung von Anmeldedaten gerechtfertigt.

Weiterlesen in dieser Reihe

CommScope Ruckus Integration mit Purple WiFi: Einrichtungs- und Konfigurationshandbuch

Dieses technische Referenzhandbuch bietet einen maßgeblichen Konfigurationsleitfaden für die Integration von CommScope Ruckus-Architekturen mit Purple WiFi. Es beschreibt Schritt-für-Schritt-Bereitstellungen für Guest WiFi Captive Portals, sicheres Mitarbeiter-WiFi über 802.1X und mandantenfähige Netzwerkisolierung mithilfe von Ruckus Dynamic PSK.

Leitfaden lesen →

Allied Telesis Access Points Integration mit Purple WiFi

Dieses Handbuch bietet eine umfassende Konfigurationsanleitung für die Integration von Allied Telesis Access Points der TQ-Serie mit Purple WiFi. Es behandelt die externe Captive Portal-Weiterleitung, die 802.1X-RADIUS-Authentifizierung und die dynamische VLAN-Steuerung mithilfe von Private Pre-Shared Keys (PPSK) für sichere Multi-Tenant-Bereitstellungen.

Leitfaden lesen →

Grandstream GWN Access Points Integration mit Purple WiFi

Dieses maßgebliche technische Handbuch beschreibt die Integration von Grandstream GWN Access Points mit dem Purple Guest WiFi und der Analytics-Plattform. Es umfasst die Konfiguration des Grandstream Captive Portal, die RADIUS AAA-Einstellungen, die Einrichtung des Walled Garden, die sichere 802.1X-Authentifizierung für Mitarbeiter mit dynamischer VLAN-Steuerung sowie die Multi-Tenant-PPSK-Segmentierung – eine praxisnahe Schritt-für-Schritt-Anleitung für MSPs und IT-Teams, die WiFi für Gäste und Mitarbeiter in großem Stil bereitstellen.

Leitfaden lesen →