Enterprise WiFi-Authentifizierung ohne Active Directory oder On-Premises-Server
Dieser Leitfaden erklärt, wie Sie eine sichere WPA2/3-Enterprise WiFi-Authentifizierung ohne ein lokales Active Directory, Windows NPS oder einen RADIUS-Server bereitstellen. Er behandelt den Protokollkonflikt zwischen Cloud-Identity-Providern und 802.1X, die Argumente für EAP-TLS gegenüber PEAP-MSCHAPv2 sowie die Bereitstellung von Cloud-RADIUS mit MDM-ausgestellten Zertifikaten gegen Microsoft Entra ID, Okta oder Google Workspace. Geschrieben für IT-Leiter in Cloud-First- und Mac/Chromebook-intensiven Unternehmen, die bereit sind, ihre On-Premises-Infrastruktur abzulösen.
Diesen Leitfaden anhören
Podcast-Transkript ansehen
📚 Part of our core series: Enterprise WiFi-Sicherheit und -Authentifizierung: Der vollständige Leitfaden →
Management-Zusammenfassung
Die meisten Unternehmen haben ihre Identitätsverwaltung in die Cloud verlagert. Microsoft Entra ID, Okta und Google Workspace verwalten heute Benutzer, Gruppen und Zugriffsrichtlinien für E-Mails, SaaS-Apps und die Geräteverwaltung. Das Enterprise-WiFi hat jedoch nicht Schritt gehalten. Access Points erwarten immer noch einen RADIUS-Server, und dieser RADIUS-Server war in der Vergangenheit meist der Windows Network Policy Server (NPS), der mit einem lokalen Active Directory-Domänencontroller verbunden war.
Diese Diskrepanz zwingt IT-Teams dazu, eine redundante lokale Infrastruktur zu unterhalten, nur um das WiFi am Laufen zu halten. Die Lösung ist Cloud-RADIUS: ein vollständig verwalteter Authentifizierungsdienst, der über RADIUS mit Ihren Access Points kommuniziert und über OAuth2, SCIM und SAML mit Ihrem Cloud-Identitätsanbieter spricht. Kombinieren Sie dies mit der EAP-TLS-Zertifikatsbereitstellung über Ihr MDM, und Sie erhalten eine vollständige 802.1X-Bereitstellung ohne lokale Server, ohne Betriebssystem-Patches und mit sofortigem Zugriffsentzug, der direkt mit Ihrem Cloud-Verzeichnis verknüpft ist.
Purple betreibt Cloud-RADIUS an über 80.000 Standorten weltweit mit einer Verfügbarkeit von 99,999 % (interne Daten von Purple, 2024) und nativen Integrationen für Microsoft Entra ID, Okta und Google Workspace. Sie können auf Ihren bestehenden Access Points von Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme oder Fortinet in weniger als einer Stunde live gehen.
Technische Vertiefung
Die Protokoll-Diskrepanz als Kern des Problems
Die grundlegende Herausforderung besteht darin, dass Cloud-Identitätsanbieter und WiFi-Access-Points völlig unterschiedliche Sprachen sprechen. Microsoft Entra ID (ehemals Azure AD) authentifiziert Benutzer über SAML, OIDC und OAuth2 – die Protokolle, die von Browsern und SaaS-Apps verwendet werden. WiFi-Access-Points nutzen RADIUS (Remote Authentication Dial-In User Service, RFC 2865), ein UDP-basiertes Protokoll aus den 1990er Jahren, das für Dial-up und VPN entwickelt wurde. Microsoft hat nie einen nativen RADIUS-Endpunkt für Entra ID bereitgestellt. Sie können einen Meraki- oder Aruba-Access-Point nicht direkt auf Azure ausrichten und erwarten, dass 802.1X funktioniert.
Das ist die Hürde, an die jedes Cloud-First-IT-Team stößt, wenn es versucht, das Mitarbeiter-WiFi mit WPA2-Enterprise oder WPA3-Enterprise abzusichern. Etwas muss die Lücke zwischen dem Access Point und dem Cloud-Identitätsanbieter schließen. Dieses Etwas ist Cloud-RADIUS.
Warum PEAP-MSCHAPv2 ohne Active Directory scheitert
In der Vergangenheit basierten 802.1X-Bereitstellungen auf PEAP-MSCHAPv2 (Protected Extensible Authentication Protocol mit Microsoft Challenge Handshake Authentication Protocol Version 2). Der Benutzer gab seinen Benutzernamen und sein Passwort ein, der Access Point leitete die Anfrage an den RADIUS-Server weiter, und der RADIUS-Server glich das Passwort mit einem in Active Directory gespeicherten NTLM-Hash ab. Microsoft Entra ID speichert keine NTLM-Hashes. Dies ist keine Konfigurationslücke – es ist eine bewusste architektonische Entscheidung. Entra ID ist ein moderner Cloud-Identitätsanbieter, kein Domänencontroller. Folglich kann ein RADIUS-Server, der auf Entra ID verweist, eine PEAP-MSCHAPv2-Abfrage nicht validieren. Der einzige Weg, PEAP mit Entra ID zum Laufen zu bringen, besteht darin, Entra Domain Services bereitzustellen – ein kostenpflichtiges, verwaltetes Active Directory, das mit Entra ID synchronisiert wird – und dann NPS darauf auszuführen. Dies führt den Großteil dessen wieder ein, was Sie eigentlich eliminieren wollten: Windows Server-VMs, OS-Patching, NTLM-Hash-Speicherung und manuelle Zertifikatsverwaltung.
EAP-TLS: Die richtige Antwort für Cloud-First-Unternehmen
EAP-TLS (Extensible Authentication Protocol-Transport Layer Security, RFC 5216) ersetzt Passwörter durch digitale X.509-Zertifikate. Das Gerät legt dem RADIUS-Server ein Zertifikat vor. Der RADIUS-Server validiert das Zertifikat anhand einer vertrauenswürdigen Zertifizierungsstelle (CA). Da bei diesem Austausch kein Passwort übertragen wird, benötigt der RADIUS-Server keinen NTLM-Hash-Speicher. Er muss lediglich der CA vertrauen und die Gruppenmitgliedschaft des Benutzers im Identitätsanbieter überprüfen, um das richtige VLAN und die entsprechende Zugriffsrichtlinie anzuwenden.
EAP-TLS ist von Grund auf phishing-resistent. Es gibt keine Anmeldedaten, die gestohlen werden könnten. Es erfüllt die CISA-Richtlinien für phishing-resistente Multi-Faktor-Authentifizierung und entspricht den PCI-DSS-Anforderungen für starke Authentifizierung in Netzwerken, die Karteninhaberdaten verarbeiten. Es ist die von IEEE 802.1X empfohlene Authentifizierungsmethode für verwaltete Geräteflotten.
Cloud-First 802.1X-Authentifizierungsarchitektur: Geräte authentifizieren sich über EAP-TLS über den Cloud-RADIUS von Purple, der Zertifikate validiert und gruppenbasierte Richtlinien von Entra ID, Okta oder Google Workspace anwendet.
Wie MDM die On-Premises-CA ersetzt
In einer traditionellen 802.1X-Bereitstellung wurden Zertifikate von einer lokalen Zertifizierungsstelle ausgestellt, auf der Active Directory Certificate Services (AD CS) ausgeführt wurde. In einer Cloud-First-Bereitstellung übernimmt das MDM diese Rolle mithilfe von SCEP (Simple Certificate Enrollment Protocol). Microsoft Intune, Jamf Pro und andere MDM-Plattformen können Zertifikate von einer in der Cloud gehosteten CA anfordern und diese geräuschlos auf verwaltete Geräte übertragen.
Der Ablauf ist wie folgt: Der IT-Administrator erstellt im MDM ein SCEP-Zertifikatsprofil, das auf die Gerätegruppen ausgerichtet ist, die WiFi-Zugriff benötigen. Das MDM überträgt das Zertifikat automatisch auf Windows-, macOS-, iOS-, iPadOS-, Android Enterprise- und ChromeOS-Geräte. Der Benutzer bemerkt davon nichts. Das Zertifikat ist an die Geräteidentität im MDM gebunden und verlängert sich vor dem Ablauf automatisch. Wenn sich das Gerät mit dem WiFi verbindet, legt es das Zertifikat dem Cloud-RADIUS-Server vor, der es mit der CA abgleicht und die richtige Netzwerkrichtlinie anwendet.
Für Organisationen, die Microsoft Intune nutzen, bietet Microsoft Cloud PKI eine vollständig verwaltete CA, die sich direkt in Intune SCEP-Profile integrieren lässt. Dadurch entfällt die Notwendigkeit eines lokalen NDES-Servers (Network Device Enrollment Service). Für von Jamf verwaltete Mac- und iOS-Flotten erfüllt die integrierte CA von Jamf oder eine Cloud-CA eines Drittanbieters denselben Zweck.
SCIM und sofortiger Entzug des Zugriffs
Einer der betrieblich wichtigsten Aspekte von Cloud-RADIUS ist die SCIM-Bereitstellung (System for Cross-domain Identity Management). SCIM ist ein offener Standard, der Identitätsänderungen von der Single Source of Truth – Ihrem Cloud-Identitätsanbieter – in Echtzeit an abhängige Systeme überträgt. Wenn ein Mitarbeiter in Entra ID oder Okta deaktiviert wird, überträgt SCIM diese Änderung sofort an den Cloud-RADIUS-Dienst. Beim nächsten Authentifizierungsversuch des Geräts gibt der RADIUS-Server ein „Access-Reject“ zurück. Durch ein kurzes, auf dem Access Point konfiguriertes Sitzungs-Timeout wird das Gerät innerhalb weniger Minuten nach der Deaktivierung des Kontos aus dem Netzwerk entfernt.
Dies ist eine wesentliche Sicherheitsverbesserung gegenüber Netzwerken mit gemeinsam genutzten PSKs, bei denen der Zugriff nur durch Ändern des Passworts auf jedem einzelnen Gerät entzogen werden kann, sowie gegenüber veralteten RADIUS-Bereitstellungen, die auf periodischen LDAP-Synchronisierungen mit einem Zeitfenster von Stunden oder Tagen basieren.
RadSec: Sicherung des RADIUS-Verkehrs über das Internet
Klassisches RADIUS verwendet UDP und bietet nur eine grundlegende Nachrichtenauthentifizierung. Wenn sich Ihr RADIUS-Server im selben Rechenzentrum wie Ihre Access Points befindet, ist dies akzeptabel. Wenn Ihr RADIUS-Server jedoch ein Cloud-Dienst ist, durchquert der Authentifizierungsverkehr das öffentliche Internet. RadSec (RADIUS über TLS, RFC 6614) verschlüsselt den RADIUS-Austausch mittels TLS und gewährleistet so Vertraulichkeit und Integrität für den Authentifizierungsverkehr. Purple unterstützt RadSec nativ, mit IPsec-Fallback für Access Points, die RadSec noch nicht unterstützen.
Implementierungsleitfaden
Die Bereitstellung von Cloud-RADIUS mit EAP-TLS erfordert vier koordinierte Schritte. Eine Pilot-SSID kann in weniger als einer Stunde live geschaltet werden, wenn Entra ID und ein MDM bereits vorhanden sind.
Schritt 1: Cloud-RADIUS mit Ihrem Identitätsanbieter verbinden
Verbinden Sie Purple über die OAuth2-Admin-Zustimmung (für Entra ID) oder ein API-Token (für Okta und Google Workspace) mit Ihrem Identitätsanbieter. Dadurch wird Purple autorisiert, Benutzer, Gruppen und Gruppenmitgliedschaften aus dem Verzeichnis auszulesen. Konfigurieren Sie die SCIM-Bereitstellung, um Änderungen des Benutzerstatus in Echtzeit an Purple zu übertragen. Es werden keine Anmeldeinformationen für Dienstprinzipale auf der Festplatte gespeichert. Gruppenänderungen werden beim nächsten Authentifizierungsereignis übertragen, nicht nach einem Synchronisierungszeitplan.
Schritt 2: Konfigurieren Sie Ihr MDM und SCEP-Profil
Erstellen Sie in Microsoft Intune ein vertrauenswürdiges Zertifikatsprofil für das CA-Root-Zertifikat und anschließend ein SCEP-Zertifikatsprofil, das auf die von Purple verwaltete CA verweist. Weisen Sie beide Profile den Gerätegruppen zu, die WiFi-Zugriff benötigen. Konfigurieren Sie für Jamf eine SCEP-Nutzlast in einem Konfigurationsprofil. Das MDM verteilt die Zertifikate im Hintergrund. Überprüfen Sie die Zertifikatsbereitstellung im MDM-Compliance-Dashboard, bevor Sie fortfahren.
Schritt 3: Netzwerkrichtlinien im Cloud-RADIUS-Dashboard definieren
Erstellen Sie RADIUS-Richtlinien, die Identity-Provider-Gruppen bestimmten VLANs und Zugriffskontrollen zuweisen. Ordnen Sie beispielsweise die Entra ID-Gruppe „Staff-Finance“ dem VLAN 20 mit vollem Internetzugang zu und „Staff-Contractors“ dem VLAN 30 mit zeitlich begrenztem Zugriff, der automatisch abläuft. Das Dashboard von Purple wendet diese Richtlinien direkt beim Authentifizierungsprozess an, ohne dass Änderungen an der Firewall erforderlich sind.
Schritt 4: Konfiguration der Access Points aktualisieren
Aktualisieren Sie die SSID-Konfiguration auf Ihren Access Points, um WPA2-Enterprise oder WPA3-Enterprise mit 802.1X zu verwenden. Geben Sie die Hostnamen oder IP-Adressen der primären und sekundären Endpunkte des Purple Cloud-RADIUS zusammen mit dem Shared Secret ein. Konfigurieren Sie die Access Points so, dass sie eine dynamische VLAN-Zuweisung basierend auf den von Purple zurückgegebenen RADIUS-Attributen verwenden. Testen Sie dies mit einer einzelnen SSID auf einer Teilmenge von Access Points, bevor Sie das System im gesamten Unternehmen einführen.
Cloud-RADIUS vs. On-Premises-RADIUS: Ein direkter Vergleich in Bezug auf Bereitstellungszeit, Active Directory-Abhängigkeit, Hochverfügbarkeit, Betriebssystem-Patching, Identitätsintegration und Zertifikatslebenszyklus-Management.
Best Practices
Diese Empfehlungen spiegeln die IEEE 802.1X-Standards, die PCI DSS v4.0-Anforderungen und die betriebliche Erfahrung aus dem weltweiten Netzwerk von Purple mit über 80.000 Standorten wider.
EAP-TLS für verwaltete Geräte vorschreiben. Passwörter sind anfällig für Phishing und Credential Stuffing. Zertifikate bieten einen kryptografischen Nachweis der Identität und der Geräte-Compliance. EAP-TLS ist die einzige 802.1X-Methode, die von Grund auf phishing-resistent ist.
SCIM für sofortigen Widerruf nutzen. Periodische LDAP-Synchronisierungen lassen ein Zeitfenster offen, in dem ein ausgeschiedener Mitarbeiter weiterhin Netzwerkzugriff hat. SCIM stellt sicher, dass der Zugriff in dem Moment entzogen wird, in dem das Konto im Identity Provider deaktiviert wird.
Multi-Regionen-RADIUS bereitstellen. Konfigurieren Sie Ihre Access Points mit mindestens zwei RADIUS-Endpunkten in verschiedenen geografischen Regionen. Purple bietet standardmäßig ein Active-Active-Multi-Regionen-Failover, das in Sekundenschnelle abgeschlossen ist.
Datenverkehr mit dynamischen VLANs segmentieren. Nutzen Sie die Gruppenmitgliedschaften des Identity Providers, um Benutzer dynamisch bestimmten VLANs zuzuweisen. Dies isoliert sensiblen Datenverkehr und begrenzt den Schadensradius eines kompromittierten Geräts, ohne dass manuelle Firewall-Änderungen erforderlich sind.
RadSec aktivieren. Wenn Ihre Access Points RadSec unterstützen, aktivieren Sie es, um den Authentifizierungsverkehr zwischen dem Access Point und dem Cloud-RADIUS-Server zu verschlüsseln. Dies ist besonders wichtig für Filialen und Standorte, an denen sich der Access Point in einem nicht vertrauenswürdigen Netzwerksegment befindet.
Zertifikatslebenszyklus überwachen. Stellen Sie die automatische MDM-Verlängerung so ein, dass sie bei 80 % der Zertifikatslaufzeit ausgelöst wird. Bei einem einjährigen Zertifikat beginnt die Verlängerung im 10. Monat. Richten Sie Warnmeldungen für Geräte ein, bei denen die Verlängerung vor dem Ablauf des Zertifikats fehlschlägt. Für eine umfassendere Betrachtung von Enterprise-WiFi-Sicherheitsstandards und -Frameworks lesen Sie unseren Enterprise WiFi Security: A Complete Guide for 2026 .
Fehlerbehebung und Risikominderung
Der Übergang zu Cloud-RADIUS führt neue Abhängigkeiten ein. Bereiten Sie sich auf diese häufigen Fehlerszenarien vor, bevor sie die Produktion beeinträchtigen.
Zertifikatsablauf. Wenn ein Gerätezertifikat abläuft, bevor das MDM es erneuert, schlägt die Authentifizierung des Geräts geräuschlos fehl. Der Benutzer sieht eine Verbindungsfehlermeldung ohne Erklärung. Beheben Sie dies, indem Sie die automatische MDM-Erneuerung bei 80 % der Zertifikatslebensdauer konfigurieren und das MDM-Compliance-Dashboard auf Geräte mit ablaufenden Zertifikaten überwachen.
MDM-Synchronisierungsfehler. Ein Gerät, das die MDM-Compliance verliert oder sich nicht anmeldet, erhält möglicherweise kein erneuertes Zertifikat. Implementieren Sie Compliance-Richtlinien, die fehlerhafte Geräte kennzeichnen und Administratoren alarmieren, bevor das Zertifikat abläuft.
Firewall blockiert RADIUS-Traffic. Die Access Points müssen die Cloud-RADIUS-Endpunkte über den UDP-Port 1812 (Authentifizierung) und den UDP-Port 1813 (Accounting) oder den TCP-Port 2083 für RadSec erreichen können. Ausgehende Firewall-Regeln in Zweigstellen blockieren diese Ports häufig. Testen Sie die Erreichbarkeit aus dem Management-VLAN des Access Points vor der Bereitstellung.
SCIM-Bereitstellungsfehler. Wenn die SCIM-Verbindung zwischen dem Identity Provider und Purple unterbrochen wird, werden Änderungen des Benutzerstatus nicht übertragen. Überwachen Sie den SCIM-Synchronisierungsstatus sowohl im Identity Provider als auch im Purple-Dashboard. Richten Sie Benachrichtigungen für Synchronisierungsfehler ein.
Legacy-Geräte ohne Zertifikatsunterstützung. IoT-Geräte, Drucker und ältere Hardware unterstützen EAP-TLS möglicherweise nicht. Verwenden Sie für diese Geräte iPSK (Individual Pre-Shared Keys) anstelle eines gemeinsam genutzten PSK. Purple unterstützt iPSK nativ, weist jedem Gerät einen eindeutigen Schlüssel zu und platziert jedes Gerät im richtigen VLAN, ohne dass ein 802.1X-Supplicant erforderlich ist.
ROI und geschäftliche Auswirkungen
Die Migration von On-Premises-RADIUS zu Cloud-RADIUS liefert messbaren Mehrwert in den Bereichen Infrastruktur, Betrieb und Sicherheit.
| Dimension | On-Premises NPS | Cloud RADIUS (Purple) |
|---|---|---|
| Infrastrukturkosten | Windows Server-Lizenzen, VM-Compute, Speicher | Abonnement pro AP, keine Server-Hardware |
| Bereitstellungszeit | Tage bis Wochen | Unter einer Stunde |
| Hochverfügbarkeit | Manuell – zwei Server plus Replikation | Multi-Region Active-Active, Standard |
| OS-Patching | Monatlich, durch Ihr Team | Vom Anbieter verwaltet |
| WiFi-Helpdesk-Tickets | Hoch – Passwort-Resets, manuelles Onboarding | 80 % weniger (Purple-Kundendaten) |
| Zugriffswiderruf | Stunden bis Tage via LDAP-Sync | Sekunden via SCIM |
IT-Teams, die das Staff WiFi von Purple nutzen, verzeichnen in der Regel einen Rückgang der WiFi-Support-Tickets um 80 % (interne Daten von Purple, 2024), was auf den Wegfall von Passwort-Resets und manueller Geräte-Onboardings zurückzuführen ist. Die zertifikatsbasierte Authentifizierung erfüllt zudem die PCI-DSS-Anforderung 8.3 für starke Authentifizierung und die ISO 27001-Kontrolle A.9.4 für die System- und Anwendungszugriffskontrolle, was den Audit-Aufwand für Ihr Sicherheitsteam erheblich reduziert.
Für Unternehmen in den Bereichen Einzelhandel und Gastgewerbe reduziert die Möglichkeit, Staff WiFi und Guest WiFi über ein einziges Cloud-Dashboard mit einer einheitlichen Identitätsebene zu verwalten, die betriebliche Komplexität an mehreren Standorten. Für Transportunternehmen und Gesundheitsdienstleister erfüllen die sofortige Widerrufsmöglichkeit und der lückenlose Audit-Trail alle regulatorischen Anforderungen ohne zusätzliche Tools.
Die WiFi Analytics -Ebene von Purple ergänzt die Authentifizierungsinfrastruktur um Belegungs- und Hybrid-Arbeitsdaten und macht Staff WiFi von einem Kostenfaktor zu einer Quelle betrieblicher Intelligenz.
Empfohlene Lektüre: Enterprise WiFi Security: A Complete Guide for 2026 – OpenWrt Custom Firmware Integration with Purple WiFi
Schlüsseldefinitionen
802.1X
Ein IEEE-Standard (IEEE 802.1X-2020) für die portbasierte Netzwerkzugriffskontrolle. Er erfordert, dass sich Geräte authentifizieren, bevor der Access Point den Netzwerkzugriff gewährt, wobei ein EAP-Austausch über einen RADIUS-Server vermittelt wird.
IT-Teams nutzen 802.1X, um sicherzustellen, dass sich nur autorisierte Benutzer und Geräte mit dem Unternehmensnetzwerk verbinden. Es bietet Verschlüsselung pro Benutzer, Schlüssel pro Sitzung und einen vollständigen Audit-Trail für jedes Verbindungsereignis.
RADIUS
Remote Authentication Dial-In User Service (RFC 2865). Ein Netzwerkprotokoll, das eine zentralisierte Verwaltung von Authentifizierung, Autorisierung und Accounting (AAA) für den Netzwerkzugriff bereitstellt.
Access Points leiten jede Verbindungsanfrage an den RADIUS-Server weiter, der entscheidet, ob das Gerät zugelassen wird und welchem VLAN es zugewiesen werden soll. Cloud RADIUS ersetzt lokale NPS- oder FreeRADIUS-Server.
EAP-TLS
Extensible Authentication Protocol-Transport Layer Security (RFC 5216). Eine 802.1X-Authentifizierungsmethode, die anstelle von Passwörtern einen gegenseitigen X.509-Zertifikatsaustausch nutzt.
EAP-TLS ist der Goldstandard für verwaltete Geräteflotten. Es ist resistent gegen Phishing, erfordert keinen Passwort-Hash-Speicher und ist die einzige 802.1X-Methode, die die CISA-Richtlinien für phishing-resistente MFA erfüllt.
PEAP-MSCHAPv2
Protected Extensible Authentication Protocol mit Microsoft Challenge Handshake Authentication Protocol Version 2. Eine veraltete 802.1X-Methode, die Passwörter mit in Active Directory gespeicherten NTLM-Hashes abgleicht.
PEAP-MSCHAPv2 schlägt in reinen Cloud-Umgebungen fehl, da Entra ID keine NTLM-Hashes speichert. Organisationen, die von einem lokalen AD migrieren, müssen PEAP durch EAP-TLS ersetzen.
SCEP
Simple Certificate Enrollment Protocol. Ein von MDM-Plattformen genutztes Protokoll, um digitale Zertifikate automatisch und ohne Benutzerinteraktion auf Geräten anzufordern und zu installieren.
IT-Teams nutzen SCEP mit Intune oder Jamf, um WiFi-Zertifikate geräuschlos auf Mitarbeitergeräten bereitzustellen. SCEP ersetzt den lokalen NDES-Server (Network Device Enrollment Service) in Cloud-First-Szenarien.
SCIM
System for Cross-domain Identity Management (RFC 7644). Ein offener Standard, der den Echtzeit-Austausch von Benutzeridentitätsinformationen zwischen IT-Systemen automatisiert.
SCIM stellt sicher, dass bei der Deaktivierung eines Mitarbeiters in Entra ID oder Okta diese Änderung sofort an den Cloud-RADIUS-Dienst übertragen wird, wodurch der WiFi-Zugriff innerhalb von Sekunden statt Stunden entzogen wird.
NPS
Network Policy Server. Die RADIUS-Implementierung von Microsoft, die typischerweise auf Windows Server als Teil einer lokalen Active Directory-Umgebung ausgeführt wird.
Cloud-First-Organisationen mustern NPS aus, um Windows Server-VMs, OS-Patching und die Abhängigkeit von lokalen Active Directorys zu eliminieren. Cloud RADIUS ist der direkte Ersatz.
RadSec
RADIUS über TLS (RFC 6614). Ein Protokoll, das den RADIUS-Authentifizierungsverkehr mittels TLS verschlüsselt und den auf UDP basierenden Klartexttransport herkömmlicher RADIUS-Verbindungen ersetzt.
RadSec ist bei der Nutzung von Cloud RADIUS unerlässlich, da der Authentifizierungsverkehr das öffentliche Internet zwischen dem Access Point und dem Cloud-Dienst durchqueren muss. Purple unterstützt RadSec nativ.
iPSK
Individual Pre-Shared Key. Eine Variante von WPA2-Personal, die jedem Gerät einen eindeutigen Pre-Shared Key zuweist, anstatt eines einzigen gemeinsamen Schlüssels für alle Geräte.
iPSK wird für IoT-Geräte, Drucker und andere Hardware verwendet, die kein 802.1X EAP-TLS unterstützen. Es bietet Nachvollziehbarkeit pro Gerät und VLAN-Zuweisung, ohne dass eine Zertifikatsunterstützung erforderlich ist.
Dynamic VLAN
Eine Netzwerksegmentierungstechnik, bei der der RADIUS-Server eine VLAN-Kennung in der Access-Accept-Antwort zurückgibt und der Access Point das Gerät automatisch in dieses VLAN einordnet.
Dynamische VLANs ermöglichen es IT-Teams, Mitarbeiter, Auftragnehmer, IoT-Geräte und Gäste basierend auf der Gruppenmitgliedschaft im Identity Provider in separate Netzwerksegmente aufzuteilen, ohne manuelle Firewall-Änderungen vornehmen zu müssen.
Ausgearbeitete Beispiele
Eine Einzelhandelskette mit 400 Standorten muss das Mitarbeiter-WiFi an allen Standorten absichern. Sie nutzen Cisco Meraki Access Points und verwenden Microsoft Entra ID mit Intune für die Geräteverwaltung. Derzeit nutzen sie einen gemeinsam genutzten WPA2-Personal PSK, da sie kein lokales Active Directory für den Betrieb von NPS haben. Eine kürzlich durchgeführte interne Prüfung stufte den gemeinsam genutzten PSK als PCI DSS-Compliance-Lücke ein.
Die Kette implementiert das Cloud-RADIUS von Purple. Zuerst verbinden sie Purple über die OAuth-Admin-Zustimmung mit Entra ID und konfigurieren die SCIM-Bereitstellung. In Intune erstellen sie ein vertrauenswürdiges Zertifikatsprofil für die Purple-CA-Root und ein SCEP-Zertifikatsprofil, das auf die Gerätegruppe „Staff-Retail“ ausgerichtet ist. Intune überträgt die Zertifikate im Hintergrund an alle verwalteten Point-of-Sale-Terminals und Mitarbeiter-Tablets. Im Meraki-Dashboard aktualisieren sie die Mitarbeiter-SSID auf WPA2-Enterprise, geben die primären und sekundären Endpunkte des Purple-Cloud-RADIUS ein und aktivieren die dynamische VLAN-Zuweisung. Wenn sich ein Gerät verbindet, legt es sein von Intune ausgestelltes Zertifikat vor. Purple validiert dieses mit der CA, prüft die Entra ID-Gruppe und das Gerät wird basierend auf der Gruppenmitgliedschaft im VLAN 10 (Mitarbeiternetzwerk) oder VLAN 20 (Verwaltungsnetzwerk) platziert. Der gemeinsam genutzte PSK wird ausgemustert. Der Rollout an 400 Standorten dauert ein einziges Wochenende, da keine Hardware vor Ort installiert werden muss – es sind lediglich Konfigurationsänderungen der SSID in Meraki erforderlich.
Eine Universität mit 15.000 Studierenden nutzt Google Workspace als primären Identitätsanbieter. Das IT-Team möchte sicheres WiFi für Mitarbeiter und Studierende auf einer BYOD-Infrastruktur aus MacBooks, Chromebooks und Android-Telefonen bereitstellen. Sie haben kein lokales Active Directory und kein Interesse daran, eigene Server zu betreiben.
Die Universität integriert das Cloud-RADIUS von Purple mit Google Workspace. Für verwaltete Chromebooks nutzen sie Google Admin, um ein WiFi-Zertifikatsprofil via SCEP zu verteilen und so jedes Gerät im Hintergrund zu registrieren. Für BYOD-MacBooks und Android-Telefone stellen sie eine schlanke Onboarding-Anwendung bereit, die den Benutzer mit seinen Google-Anmeldedaten authentifiziert und mit einem einzigen Fingertipp ein Zertifikat auf dem Gerät installiert. Nachfolgende Verbindungen nutzen EAP-TLS geräuschlos im Hintergrund. Purple ordnet die Google Workspace-Organisationseinheiten den VLANs zu: Mitarbeiter landen im VLAN 10, Studierende im VLAN 20 und Gastbesucher auf einer Captive Portal-SSID. Wenn ein Student seinen Abschluss macht und sein Google-Konto gesperrt wird, überträgt SCIM die Änderung an Purple, und der WiFi-Zugang wird innerhalb von Minuten entzogen.
Übungsfragen
Q1. Ihre Organisation ist vollständig von einem On-Premises Active Directory zu Microsoft Entra ID migriert. Ihr aktuelles Mitarbeiter-WiFi verwendet PEAP-MSCHAPv2 gegen einen NPS-Server, der in die alte Domäne eingebunden war. Nach der Außerbetriebnahme des Domänencontrollers melden Mitarbeiter, dass sie sich nicht mehr mit dem WiFi verbinden können. Was ist die Ursache und was ist die richtige langfristige Lösung?
Hinweis: Überlegen Sie, was PEAP-MSCHAPv2 vom Verzeichnis benötigt und ob Entra ID dies bereitstellt.
Musterlösung anzeigen
Die Ursache liegt darin, dass PEAP-MSCHAPv2 erfordert, dass der RADIUS-Server das Passwort des Benutzers mit einem in Active Directory gespeicherten NTLM-Hash abgleicht. Da der Domänencontroller außer Betrieb genommen wurde, hat NPS kein Verzeichnis mehr für den Abgleich. Entra ID speichert keine NTLM-Hashes, sodass NPS nicht auf Entra ID umgeleitet werden kann. Die richtige langfristige Lösung besteht darin, NPS durch einen Cloud-RADIUS-Dienst zu ersetzen, von PEAP-MSCHAPv2 auf EAP-TLS zu migrieren und das MDM (Intune) zu verwenden, um Gerätezertifikate über SCEP auszustellen. Dadurch wird die Abhängigkeit von jeglichen On-Premises-Verzeichnissen aufgehoben.
Q2. Sie stellen Cloud-RADIUS für eine Flotte von 200 geschäftlichen MacBooks bereit, die von Jamf Pro verwaltet werden. Ihr Identitätsanbieter ist Okta. Was ist der sicherste und betrieblich effizienteste Weg, um die WiFi-Anmeldedaten auf diesen Geräten bereitzustellen?
Hinweis: Suchen Sie nach einer Methode, die keine Benutzerinteraktion erfordert, Passwörter vermeidet und sich in Ihr bestehendes MDM integrieren lässt.
Musterlösung anzeigen
Konfigurieren Sie Jamf Pro so, dass SCEP verwendet wird, um Gerätezertifikate geräuschlos auf die MacBooks zu übertragen. Erstellen Sie eine SCEP-Payload in einem Jamf-Konfigurationsprofil, das auf die von Ihrem Cloud-RADIUS-Anbieter verwaltete CA verweist. Weisen Sie das Profil der entsprechenden Gerätegruppe zu. Jamf überträgt das Zertifikat automatisch und ohne Benutzerinteraktion auf jedes MacBook. Konfigurieren Sie das WiFi-Profil im selben Konfigurationsprofil so, dass EAP-TLS mit dem per SCEP ausgestellten Zertifikat verwendet wird. Verbinden Sie den Cloud-RADIUS-Dienst über SCIM mit Okta, um sicherzustellen, dass der WiFi-Zugriff eines Mitarbeiters sofort entzogen wird, wenn dieser in Okta deaktiviert wird.
Q3. Ein Mitarbeiter wird an einem Montag um 9:00 Uhr entlassen. Sein Entra ID-Konto wird von der Personalabteilung um 9:05 Uhr deaktiviert. Um 9:30 Uhr zeigt eine Sicherheitswarnung, dass der Laptop des Mitarbeiters immer noch vom Parkplatz aus mit dem Unternehmens-WiFi verbunden ist. Welche Konfiguration fehlt und wie beheben Sie das?
Hinweis: Wie erfährt der RADIUS-Server, dass sich der Status des Benutzers im Identitätsanbieter geändert hat?
Musterlösung anzeigen
Die Bereitstellung basiert auf periodischen LDAP-Synchronisierungen anstelle von SCIM-Provisionierung. Die LDAP-Synchronisierung wurde seit der Deaktivierung des Kontos noch nicht ausgeführt, sodass der Cloud-RADIUS-Dienst den Benutzer immer noch als aktiv betrachtet. Die Lösung besteht darin, die SCIM-Provisionierung zwischen Entra ID und dem Cloud-RADIUS-Dienst zu aktivieren. SCIM überträgt Änderungen des Benutzerstatus in Echtzeit. Wenn das Konto also um 9:05 Uhr in Entra ID deaktiviert wird, erhält der RADIUS-Dienst die Änderung sofort. Wenn das Gerät das nächste Mal versucht, sich neu zu authentifizieren (gesteuert durch das Session-Timeout auf dem Access Point), erhält es ein Access-Reject. Das Festlegen eines kurzen Session-Timeouts (15 bis 30 Minuten) auf dem Access Point begrenzt das maximale Zeitfenster zwischen der Kontodeaktivierung und dem Netzwerkausschluss.
Q4. Ihr Standort verfügt über 50 IoT-Geräte – Digital-Signage-Player, Umgebungssensoren und Drucker –, die kein 802.1X EAP-TLS unterstützen. Wie sichern Sie diese Geräte auf derselben WiFi-Infrastruktur wie Ihr EAP-TLS-Mitarbeiternetzwerk?
Hinweis: Überlegen Sie, welche Authentifizierungsmethode eine gerätespezifische Zurechenbarkeit bietet, ohne dass eine Zertifikatsunterstützung erforderlich ist.
Musterlösung anzeigen
Verwenden Sie iPSK (individual pre-shared keys) für die IoT-Geräte. Weisen Sie jedem Gerät im Cloud-RADIUS-Dashboard einen eindeutigen Pre-Shared Key sowie eine VLAN-Zuweisung zu. Jedes Gerät authentifiziert sich mit seinem eindeutigen Schlüssel, den der RADIUS-Server validiert und verwendet, um das Gerät im IoT-VLAN zu platzieren, isoliert vom Mitarbeiternetzwerk. Wenn ein Gerät kompromittiert oder außer Betrieb genommen wird, widerrufen Sie nur den Schlüssel dieses Geräts, ohne andere Geräte zu beeinträchtigen. Dieser Ansatz bietet gerätespezifische Zurechenbarkeit und Netzwerksegmentierung, ohne dass eine 802.1X-Supplicant-Unterstützung auf der IoT-Hardware erforderlich ist.
Weiterlesen in dieser Reihe
Drei SSIDs, um sie alle zu beherrschen: Einrichtungsleitfaden für Gäste-, Mitarbeiter- und IoT-WiFi
Dieser maßgebliche technische Leitfaden bietet einen schrittweisen Entwurf für die Implementierung einer Drei-SSID-WiFi-Architektur. Er erklärt, wie Sie Gäste-, Mitarbeiter- und IoT-Traffic mithilfe von Captive Portals, 802.1X RADIUS und gerätespezifischen PSK (xPSK) segmentieren, um die Leistung zu optimieren und die PCI-DSS-Compliance zu gewährleisten.
Wie Sie den WiFi-Zugang beim Ausscheiden eines Mitarbeiters widerrufen
Dieser Leitfaden beschreibt im Detail, wie Sie den WiFi-Zugang beim Ausscheiden eines Mitarbeiters widerrufen, indem Sie unsichere, gemeinsam genutzte Passwörter durch benutzerbezogene 802.1X-Zertifikate oder iPSK ersetzen. Er behandelt das automatisierte Deprovisionieren via SCIM, um die Audit-Anforderungen von ISO 27001 und SOC 2 zu erfüllen.
Google Workspace WiFi-Authentifizierung: Chromebook- und LDAP-Integration
Ein definitives technisches Referenzhandbuch für IT-Administratoren, die sicheres WiFi in Google Workspace-Umgebungen bereitstellen. Dieser Leitfaden behandelt die Bereitstellung von 802.1X-Zertifikaten auf verwalteten Chromebooks über die Google Admin-Konsole, die Integration von Google Secure LDAP als RADIUS-Backend sowie Architekturentscheidungen für Bildungs-, Medien- und Unternehmensstandorte. Er bietet konkrete Implementierungsschritte, praxisnahe Fallstudien und einen direkten Vergleich von EAP-Methoden, um Teams den Übergang von unsicheren, gemeinsam genutzten PSKs zu einer robusten, identitätsbasierten Netzwerkzugriffskontrolle zu erleichtern.