Integrating RADIUS as a Service mit Cloud-Verzeichnissen (Azure AD & Google Workspace)

Dieser technische Leitfaden beschreibt detailliert, wie Sie RADIUS as a Service in Cloud-Verzeichnisse – Microsoft Entra ID und Google Workspace – für die WiFi-Authentifizierung in Unternehmen integrieren. Er behandelt den architektonischen Wechsel von On-Premise-NPS zu Cloud-nativem RADIUS, die Bereitstellung von zertifikatsbasierter EAP-TLS-Authentifizierung sowie die bewährten Betriebsmethoden zur Absicherung des drahtlosen Netzzugangs in den Bereichen Gastgewerbe, Einzelhandel und im öffentlichen Sektor. Für IT-Manager und Netzwerkarchitekten, die bereits in Cloud-Identitäten investiert haben, schließt dieser Leitfaden die Lücke zwischen Verzeichnisverwaltung und physischer Netzwerksicherheit.

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

Diesen Leitfaden anhören

Podcast-Transkript ansehen

Willkommen zum Purple Technical Briefing. Heute behandeln wir ein Thema an der Schnittstelle von Cloud-Identitätsmanagement und physischer Netzwerksicherheit: die Integration von RADIUS as a Service in Cloud-Verzeichnisse, speziell Microsoft Entra ID und Google Workspace.

Wenn Sie Enterprise-WiFi in einem Hotel, einer Einzelhandelsfläche, einem Stadion oder einer öffentlichen Einrichtung verwalten, ist dieses Briefing für Ihre nächste Infrastrukturentscheidung von direkter Relevanz.

Beginnen wir mit dem Kontext. In den letzten zwei Jahrzehnten basierte die WiFi-Authentifizierung in Unternehmensumgebungen auf einem ziemlich vorhersehbaren Stack. Sie hatten ein lokales Active Directory, den Windows-Netzwerkrichtlinienserver (NPS) als RADIUS-Server und WPA2-Enterprise auf den Access Points. Das hat funktioniert. Aber es erforderte lokale Server, manuelle Zertifikatsverwaltung und ein Team mit Spezialwissen, um den Betrieb aufrechtzuerhalten.

Das Problem ist, dass die meisten Unternehmen heute nicht mehr „on-premise-first“ agieren. Sie sind „cloud-first“. Microsoft Entra ID und Google Workspace sind heute für Millionen von Unternehmen die führenden Verzeichnisse. Und genau hier liegt die Lücke: Ihre Wireless Access Points sprechen immer noch RADIUS. Sie verstehen kein SAML. Sie verstehen kein OAuth. Sie sprechen RADIUS und das wird auch so bleiben.

Die Frage lautet also: Wie schlagen Sie die Brücke von Ihrer Cloud-Identitätsplattform zu Ihrer physischen Netzwerkinfrastruktur, ohne wieder einen lokalen Server ins Spiel zu bringen?

Die Antwort lautet RADIUS as a Service. Ein in der Cloud gehosteter RADIUS-Server, der sich direkt in Ihr Cloud-Verzeichnis integriert, Authentifizierungsanfragen in Echtzeit validiert und eine Zugriffsentscheidung an Ihren Access Point zurückgibt. Keine lokalen Server. Kein Patching. Keine Notfälle bei der Zertifikatsverlängerung um 2 Uhr morgens.

Die Grundlage bildet IEEE 802.1X. Wenn ein Gerät versucht, sich mit einem WPA2-Enterprise- oder WPA3-Enterprise-Netzwerk zu verbinden, fungiert der Access Point als Authentifikator. Er fängt den Verbindungsversuch ab und leitet EAP-Pakete an den RADIUS-Server weiter. Der RADIUS-Server validiert die Identität und gibt entweder ein Access-Accept oder ein Access-Reject zurück. Erst dann gewährt der Access Point den Netzwerkzugriff.

Die folgenreichste technische Entscheidung bei dieser gesamten Bereitstellung ist die Wahl Ihrer EAP-Methode.

PEAP-MSCHAPv2 ist der alte Weg. Es verwendet Benutzernamen und Passwörter. Das klingt sicher. Ist es aber nicht. Wenn ein Gerät das RADIUS-Serverzertifikat nicht streng validiert, kann ein Angreifer einen betrügerischen Access Point mit Ihrer SSID einrichten, den Handshake abfangen und die Zugangsdaten erfassen. Dies wird als Evil-Twin-Angriff bezeichnet und findet tagtäglich statt.

EAP-TLS ist die richtige Antwort. Es verwendet digitale Zertifikate sowohl auf dem Server als auch auf dem Client-Gerät für eine gegenseitige Authentifizierung. Es sind keine Passwörter im Spiel. Das Gerät präsentiert sein Zertifikat. Der RADIUS-Server validiert es in Echtzeit mit Ihrem Cloud-Verzeichnis. Kein Diebstahl von Zugangsdaten möglich. Kein Phishing-Vektor. Keine Helpdesk-Tickets, wenn jemand sein Passwort ändert.

Gehen wir nun eine Bereitstellung mit Microsoft Entra ID durch.

Schritt eins: Lizenzierung und PKI. Sie benötigen Microsoft 365 E3 oder E5, um auf Intune und Conditional Access zuzugreifen. Richten Sie eine Cloud-PKI ein, indem Sie die Managed PKI Ihres Cloud-RADIUS-Anbieters oder die Microsoft-eigene Cloud-PKI verwenden.

Schritt zwei: Zertifikatsbereitstellung über Intune. Erstellen Sie ein vertrauenswürdiges Zertifikatsprofil mit Ihrer Root CA und weisen Sie es Gerätegruppen zu. Erstellen Sie anschließend ein SCEP-Zertifikatsprofil. Bei der benutzerbasierten Authentifizierung verwendet der Antragstellername den User Principal Name.

Schritt drei: Konfiguration von Cloud-RADIUS. Erteilen Sie dem RADIUS-Dienst die Microsoft Graph API-Berechtigungen: User.Read.All und GroupMember.Read.All. Definieren Sie Ihre Authentifizierungsrichtlinien: Erlauben Sie den Zugriff, wenn das Zertifikat von unserer vertrauenswürdigen CA ausgestellt wurde, der Benutzer Mitglied der Gruppe Corporate-WiFi-Users in Entra ID ist und das Gerät in Intune als konform markiert ist.

Schritt vier: Wireless-Infrastruktur. Fügen Sie in Ihrem Controller – sei es Cisco Meraki, HPE Aruba, Ruckus oder Juniper Mist – die Cloud-RADIUS-IP-Adressen und Shared Secrets hinzu. Stellen Sie das RADIUS-Timeout auf mindestens fünf Sekunden ein. Erstellen Sie Ihre WPA3-Enterprise SSID.

Schritt fünf: Bereitstellung des WiFi-Profils. Erstellen Sie ein WiFi-Konfigurationsprofil in Intune. Legen Sie die SSID fest, wählen Sie WPA3-Enterprise, wählen Sie EAP-TLS und verknüpfen Sie das SCEP-Zertifikatsprofil. Geräte erhalten das Zertifikat und das WiFi-Profil bei der nächsten Synchronisierung geräuschlos im Hintergrund. Sie verbinden sich automatisch. Es ist keine Interaktion des Benutzers erforderlich.

Sehen wir uns nun den Google Workspace-Pfad an, da sich dieser architektonisch in einem wichtigen Punkt unterscheidet.

Google bietet keinen nativen RADIUS-Dienst an. Es gibt kein Google-Äquivalent zum Windows NPS. Sie benötigen also immer einen Vermittler: einen Cloud-RADIUS-Anbieter, der sich über Google Secure LDAP oder über eine SAML- und OAuth-Integration mit Google Workspace verbindet.

Google Secure LDAP ist in den Editionen Cloud Identity Premium und Google Workspace Enterprise verfügbar. Es bietet eine traditionelle LDAP-Schnittstelle für Ihr Cloud-Verzeichnis. Ihr Cloud-RADIUS-Server verbindet sich mit ldap.google.com auf Port 636 unter Verwendung von Client-Zertifikaten, die Google für Sie generiert. Von diesem Punkt an kann der RADIUS-Server das Google-Verzeichnis abfragen, um Anmeldedaten oder Gruppenmitgliedschaften zu validieren.

Bei verwalteten Chromebooks erfolgt die Bereitstellung über die Google Admin-Konsole. Sie konfigurieren eine Cloud-PKI zur Ausstellung von Zertifikaten, übertragen die Root-CA und die Client-Zertifikate auf die Chromebooks und stellen ein WiFi-Profil bereit, das EAP-TLS spezifiziert. Die Chromebooks verbinden sich geräuschlos im Hintergrund. Für BYOD-Geräte und den Gastzugang nutzen Sie ein Captive Portal, das an das Google Single Sign-On gekoppelt ist. Das ist die richtige Trennung: EAP-TLS für verwaltete Geräte, Captive Portal für alles andere.

Lassen Sie uns über Stolpersteine sprechen, denn hier scheitern Bereitstellungen am häufigsten.

Der erste und häufigste Fehler sind blockierte Firewall-Ports. Die RADIUS-Authentifizierung verwendet den UDP-Port 1812. Das RADIUS-Accounting verwendet den UDP-Port 1813. Wenn diese Ports ausgehend von Ihrer Wireless-Infrastruktur zum Cloud-RADIUS-Dienst nicht geöffnet sind, funktioniert nichts. Überprüfen Sie dies immer zuerst.Der zweite Fallstrick ist der Ablauf von Zertifikaten. Wenn das Zertifikat Ihres RADIUS-Servers abläuft, verliert jedes Gerät im Netzwerk gleichzeitig die Verbindung. Richten Sie Überwachungsalarme 90 Tage, 30 Tage und 7 Tage vor Ablauf ein. Automatisieren Sie die Verlängerung, wo immer dies möglich ist.

Der dritte ist der Zeitversatz (Clock Skew). EAP-TLS verlässt sich für die Zertifikatsprüfung auf eine genaue Zeitmessung. Wenn die Systemzeit eines Geräts erheblich asynchron ist, schlägt die Zertifikatsprüfung fehl. Stellen Sie sicher, dass NTP auf allen Geräten und der gesamten Infrastruktur korrekt konfiguriert ist.

Der vierte Fallstrick, der speziell bei PEAP-Bereitstellungen auftritt, ist das Versäumnis, eine strikte Serverzertifikatsprüfung auf Client-Geräten zu erzwingen. Ohne diese akzeptieren Geräte jedes Zertifikat, das von einem beliebigen Access Point präsentiert wird, der behauptet, Ihrer zu sein. Dies ist die einzige Konfigurationsentscheidung, die eine sichere Bereitstellung von einer anfälligen unterscheidet.

Nun zu einer schnellen Fragerunde.

Kann ich Cloud RADIUS sowohl für Mitarbeiter- als auch für Gäste-WiFi nutzen? Für Mitarbeiter-WiFi ja, unter Verwendung von EAP-TLS. Gäste-WiFi sollte ein separates Captive Portal nutzen. Die Mischung aus beidem auf einer einzigen SSID führt zu unnötiger Komplexität und Sicherheitsrisiken.

Funktioniert das mit WPA3? Ja. WPA3-Enterprise wird vollständig unterstützt und für alle neuen Bereitstellungen empfohlen.

Wie sieht es mit der Compliance aus? EAP-TLS mit Cloud RADIUS unterstützt die PCI-DSS-Anforderungen für eine starke Authentifizierung in Karteninhaber-Datennetzwerken. Zudem unterstützt es GDPR-Verpflichtungen, indem es eine präzise Zugriffsprotokollierung und einen sofortigen Widerruf bei dem Ausscheiden eines Mitarbeiters ermöglicht.

Wie wirkt sich das auf unsere Analytics-Funktionen aus? Positiv. Durch die Verknüpfung des Netzwerkzugriffs mit einer verifizierten Cloud-Identität liefern Plattformen wie Purple's WiFi Analytics reichhaltigere Daten zur Flächennutzung. Sie wechseln von anonymen MAC-Adressen zu authentifizierten, namentlich bekannten Nutzern, was die Qualität Ihrer Erkenntnisse grundlegend verändert.

Zusammenfassend die wichtigsten Erkenntnisse.

Erstens: Cloud RADIUS eliminiert Abhängigkeiten von lokalen Servern. Ihre Access Points authentifizieren sich gegenüber einem in der Cloud gehosteten Dienst, der direkt mit Entra ID oder Google Workspace integriert ist.

Zweitens: EAP-TLS ist die richtige Authentifizierungsmethode. Zertifikate ersetzen Passwörter. Kein Phishing-Vektor, kein Diebstahl von Anmeldedaten, kein Helpdesk-Aufwand durch Passwort-Zurücksetzungen.

Drittens: Microsoft Intune und die Google Admin Konsole automatisieren die Zertifikatsverteilung. Geräte erhalten Zertifikate und WiFi-Profile geräuschlos und ohne Benutzerinteraktion.

Viertens: Die dynamische VLAN-Zuweisung über RADIUS-Attribute ermöglicht eine granulare Netzwerksegmentierung basierend auf der Zugehörigkeit zu Verzeichnisgruppen. Dies schränkt laterale Bewegungen ein und unterstützt die Compliance.

Fünftens: Überprüfen Sie immer, ob die Ports 1812 und 1813 geöffnet sind, überwachen Sie den Ablauf von Zertifikaten und erzwingen Sie eine strikte Serverzertifikatsprüfung.
Wenn Sie für dieses Quartal ein Deployment planen, beginnen Sie mit einer Pilotgruppe von 20 bis 50 Geräten. Validieren Sie das Zertifikats-Deployment, die RADIUS-Authentifizierung und die VLAN-Zuweisung, bevor Sie das Rollout global durchführen. Die Investition, dies von Anfang an richtig aufzusetzen, zahlt sich durch einen geringeren Aufwand im Helpdesk, ein höheres Sicherheitsniveau und die Möglichkeit aus, Ihre Netzwerkdaten für echte Business Intelligence zu nutzen.

Vielen Dank, dass Sie sich das Purple Technical Briefing angehört haben. Detaillierte Schritte zum Deployment, Konfigurationsbeispiele und ausgearbeitete Szenarien finden Sie im vollständigen technischen Referenzhandbuch unter purple.ai.

Wichtigste Erkenntnisse

✓Cloud RADIUS eliminiert On-Premise-NPS- und FreeRADIUS-Server. Ihre Access Points authentifizieren sich über einen Cloud-gehosteten Dienst, der sich direkt in Microsoft Entra ID oder Google Workspace integrieren lässt.
✓EAP-TLS ist die richtige Authentifizierungsmethode für Enterprise WiFi. Es verwendet digitale Zertifikate anstelle von Passwörtern, was den Diebstahl von Zugangsdaten, Phishing und den passwortbezogenen Support-Aufwand eliminiert.
✓Microsoft Intune und die Google Admin-Konsole automatisieren die Zertifikatsbereitstellung auf verwalteten Geräten über SCEP-Profile. Geräte erhalten Zertifikate und WiFi-Profile geräuschlos und ohne Benutzerinteraktion.
✓Google Workspace erfordert einen Vermittler für die RADIUS-Integration. Google Secure LDAP (verfügbar in den Editionen Cloud Identity Premium und Enterprise) stellt die LDAP-Schnittstelle bereit, die Cloud RADIUS-Server zur Abfrage des Google-Verzeichnisses verwenden.
✓Die dynamische VLAN-Zuweisung über RADIUS-Attribute (Tunnel-Type, Tunnel-Medium-Type, Tunnel-Private-Group-Id) ermöglicht eine granulare Netzwerksegmentierung basierend auf der Verzeichnisgruppenmitgliedschaft und unterstützt die PCI-DSS-Anforderungen.
✓Prüfen Sie zuerst die UDP-Ports 1812 und 1813. Blockierte Firewall-Ports sind die Hauptursache für das Fehlschlagen der Erstbereitstellung. Überwachen Sie den Zertifikatsablauf nach 90, 30 und 7 Tagen. Erzwingen Sie eine strikte Serverzertifikatsvalidierung bei allen PEAP-Bereitstellungen.
✓Das Deaktivieren eines Benutzers in Entra ID oder Google Workspace entzieht ihm sofort den WiFi-Zugang an allen Standorten. Dies ist der primäre Offboarding-Vorteil gegenüber PSK-basierten Netzwerken und unterstützt direkt die GDPR-Verpflichtungen.

Management-Zusammenfassung

Für moderne Unternehmen, die in Cloud-Identity-Ökosysteme investieren, ist die Verknüpfung von Cloud-Verzeichnissen mit physischen drahtlosen Netzwerken eine kritische Sicherheitsanforderung. In der Vergangenheit basierte die WiFi-Authentifizierung auf lokalen Active Directory Domain Services und dem Windows Network Policy Server (NPS). Mit der Migration von Unternehmen zu Microsoft Entra ID und Google Workspace wird dieser lokale Authentifizierungs-Stack zu einem Risiko – teuer im Unterhalt, schwer skalierbar und inkompatibel mit Zero-Trust-Sicherheitsmodellen.

RADIUS as a Service (RADIUSaaS) verändert diese Ausgangslage. Ein in der Cloud gehosteter RADIUS-Server lässt sich direkt in Ihr Cloud-Verzeichnis integrieren, validiert Authentifizierungsanfragen in Echtzeit und sendet Zugriffsentscheidungen an Ihre Access Points zurück – ganz ohne lokale Server, Patch-Zyklen und Single Points of Failure. In Kombination mit zertifikatsbasierter EAP-TLS-Authentifizierung eliminiert diese Architektur den Diebstahl von Anmeldedaten, unterstützt die Einhaltung von PCI DSS und GDPR und bietet Mitarbeitern an jedem Standort eine nahtlose Benutzererfahrung.

Dieser Leitfaden behandelt die architektonische Entscheidung zwischen lokalem NPS und Cloud-nativem RADIUS, die Bereitstellung von EAP-TLS über Microsoft Intune und die Google Admin-Konsole sowie die bewährten Betriebspraktiken zur Absicherung des drahtlosen Zugangs in Hotels, Einzelhandelsflächen, Stadien und Standorten des öffentlichen Sektors. Für eine allgemeinere Einführung in die Netzwerkzugriffskontrolle lesen Sie bitte unseren Leitfaden für Ihr Network Access Control System .

Technische Detailanalyse: Architektur und Standards

Die Rolle von RADIUS und IEEE 802.1X

Das Fundament für sicheres Enterprise-WiFi ist der Standard IEEE 802.1X, der eine portbasierte Netzwerkzugriffskontrolle bietet. Wenn ein Client-Gerät (der Supplicant) versucht, sich mit einem WPA2-Enterprise- oder WPA3-Enterprise-Netzwerk zu verbinden, blockiert der Wireless Access Point (der Authenticator) den gesamten Datenverkehr mit Ausnahme von EAP-Paketen (Extensible Authentication Protocol). Der AP leitet diese Pakete an einen RADIUS-Server weiter. Der RADIUS-Server validiert die Identität anhand eines Verzeichnisdienstes und gibt eine Access-Accept- oder Access-Reject-Nachricht zurück. Erst dann gewährt der AP den Netzwerkzugriff.

Dieses Dreiparteienmodell – Supplicant, Authenticator, Authentifizierungsserver – ist der Eckpfeiler der Netzwerksicherheit in Unternehmen und im Standard IEEE 802.1X definiert. Es hat sich seit seiner Einführung im Wesentlichen nicht verändert. Was sich geändert hat, ist der Ort, an dem der RADIUS-Server betrieben wird, und die Art und Weise, wie er mit Ihrem Verzeichnis kommuniziert.

Cloud-native RADIUS-Architektur

Eine Cloud-native RADIUS-Architektur macht lokale NPS- oder FreeRADIUS-Server überflüssig. Ein Cloud-RADIUS-Drittanbieter integriert sich direkt über die Microsoft Graph API in Microsoft Entra ID oder über Google Secure LDAP oder SAML/OAuth in Google Workspace. Die Authentifizierung erfolgt vollständig in der Cloud. Dies entspricht den Prinzipien des Zero-Trust-Netzwerkzugriffs und reduziert den Betriebsaufwand erheblich.

Die folgende Tabelle vergleicht die beiden primären Architekturansätze:

Dimension	Hybrid lokal (NPS)	Cloud-native (RADIUSaaS)
Infrastruktur	Windows Server VM oder Bare-Metal erforderlich	Keine lokalen Server
Identitätsquelle	AD DS über LDAP/Kerberos	Entra ID oder Google Workspace über API
Zertifizierungsstelle	ADCS lokal + Intune-Connector	Cloud-PKI vom Anbieter oder Microsoft
Hochverfügbarkeit	Manuelle HA und Lastverteilung	Automatisch skaliert durch Anbieter
Einrichtungszeit	Tage bis Wochen	Stunden
Bestens geeignet für	Hybrides AD, Altsysteme	Cloud-first, MDM-verwaltete Organisationen
Betriebliche Komplexität	Höherer initialer und laufender Aufwand	Geringerer Betriebsaufwand

EAP-TLS vs. PEAP-MSCHAPv2: die entscheidende Wahl

Die Wahl der EAP-Methode ist die folgenreichste Sicherheitsentscheidung bei dieser Bereitstellung. PEAP-MSCHAPv2 basiert darauf, dass Benutzer ihre Domänen-Anmeldedaten eingeben. Dies ist anfällig für Diebstahl von Anmeldedaten und Man-in-the-Middle-Angriffe. Wenn ein Client-Gerät das RADIUS-Serverzertifikat nicht streng validiert – und viele tun dies standardmäßig nicht –, kann ein Angreifer einen betrügerischen Access Point mit Ihrer SSID einrichten, den EAP-Handshake abfangen und Anmeldedaten erfassen. Dies ist ein Evil-Twin-Angriff, und er ist bestens dokumentiert.

EAP-TLS (Transport Layer Security) verwendet auf dem Client-Gerät installierte digitale Zertifikate zur gegenseitigen Authentifizierung. Sowohl der Client als auch der Server weisen ihre Identität kryptografisch nach. Es müssen keine Passwörter eingegeben oder gestohlen werden. In einer Microsoft-Umgebung werden Zertifikate geräuschlos über Microsoft Intune mithilfe von SCEP- (Simple Certificate Enrollment Protocol) oder PKCS-Profilen bereitgestellt. Dies ist der empfohlene Weg für alle neuen Bereitstellungen und unerlässlich für die Einhaltung von PCI DSS v4.0 (Anforderung 8.3 für starke Authentifizierung) und GDPR-Datenschutzverpflichtungen.

Google Workspace: der architektonische Unterschied

Microsoft Entra ID und Google Workspace unterscheiden sich in einem wichtigen Punkt bei der RADIUS-Integration. Microsoft NPS lässt sich nativ in Active Directory integrieren, und Cloud-RADIUS-Anbieter verbinden sich über die Microsoft Graph API mit Entra ID. Google bietet jedoch keinen nativen RADIUS-Dienst an. Sie benötigen immer ein Zwischenglied.

Google Secure LDAP ist der primäre Integrationspfad. Er ist in den Editionen Cloud Identity Premium und Google Workspace Enterprise verfügbar und bietet eine traditionelle LDAP-Schnittstelle für Ihr Cloud-Verzeichnis. Ihr Cloud-RADIUS-Server verbindet sich über den Port 636 unter Verwendung von Client-Zertifikaten, die Google für Sie generiert, mit ldap.google.com. Von diesem Punkt an fragt der RADIUS-Server das Verzeichnis von Google ab, um Anmeldedaten oder Gruppenmitgliedschaften zu validieren, genau wie er es bei einem lokalen Active Directory tun würde.

Ein alternativer Pfad nutzt eine SAML-basierte Integration, bei der sich der Cloud-RADIUS-Anbieter als SAML-Anwendung in der Google Admin-Konsole registriert und zum Authentifizierungszeitpunkt ein OAuth-Lookup durchführt, um die Identität und die Gruppenmitgliedschaften des Benutzers in Echtzeit zu überprüfen.

Implementierungsleitfaden

Die Implementierung von RADIUSaaS mit EAP-TLS erfordert die Abstimmung von Identitäts-, Geräteverwaltungs- und Netzwerkinfrastruktur. Der folgende Fünf-Phasen-Ansatz gilt sowohl für Microsoft Entra ID- als auch für Google Workspace-Umgebungen.

Phase 1: Identitäts- und Geräteverwaltungsinfrastruktur vorbereiten

Für Microsoft Entra ID: Überprüfen Sie, ob Ihr Mandant über eine Lizenzierung für Microsoft 365 E3/E5 oder Enterprise Mobility + Security (EMS) E3/E5 verfügt. Dies umfasst Microsoft Intune und Conditional Access. Ohne Intune ist eine automatisierte Zertifikatsbereitstellung nicht möglich.

Für Google Workspace: Bestätigen Sie, dass Sie über Cloud Identity Premium oder Google Workspace Enterprise verfügen, um auf Google Secure LDAP zuzugreifen. Wenn Sie planen, EAP-TLS auf verwalteten Chromebooks zu verwenden, stellen Sie sicher, dass die Google Admin-Konsole so konfiguriert ist, dass sie Gerätezertifikate verwaltet.

Bauen Sie Ihre Public-Key-Infrastruktur (PKI) auf. Für Neubereitstellungen wird eine cloudnative PKI, die von Ihrem Cloud-RADIUS-Anbieter bereitgestellt wird, dringend empfohlen. Alternativen sind Microsoft Cloud PKI (verfügbar mit Intune Suite-Lizenzierung) oder eine bestehende lokale ADCS-Bereitstellung, die über den Microsoft Intune Certificate Connector angebunden ist.

Phase 2: Zertifikatsbereitstellung konfigurieren

Microsoft Intune-Pfad: Erstellen Sie im Intune Admin Center ein Konfigurationsprofil für Vertrauenswürdige Zertifikate. Laden Sie das Root-CA-Zertifikat hoch und stellen Sie es für Ihre Zielgerätegruppen bereit. Dies stellt sicher, dass Client-Geräte dem vom RADIUS-Server während des TLS-Handshakes präsentierten Zertifikat vertrauen. Erstellen Sie als Nächstes ein SCEP-Zertifikat-Profil. Legen Sie für die benutzerbasierte Authentifizierung den Subject Name auf CN={{UserPrincipalName}} fest. Verwenden Sie für die gerätebasierte Authentifizierung CN={{DeviceName}}. Konfigurieren Sie den Subject Alternative Name so, dass er den User Principal Name oder die Geräte-ID enthält.

Google Admin-Konsole-Pfad: Navigieren Sie zu „Geräte“, dann „Netzwerke“ und schließlich „Zertifikate“. Laden Sie Ihre Root-CA hoch. Konfigurieren Sie einen Mechanismus zur Zertifikatsausstellung – entweder eine Cloud-PKI, die die SCEP-Integration mit Google Workspace unterstützt, oder den Google Cloud Certificate Connector, der Anfragen an eine lokale Microsoft-Zertifizierungsstelle weiterleitet. Stellen Sie die Root-CA- und Client-Zertifikatsprofile für die entsprechenden Organisationseinheiten bereit.

Phase 3: Cloud-RADIUS-Integration konfigurieren

Erteilen Sie Ihrem Cloud-RADIUS-Anbieter die erforderlichen API-Berechtigungen in Ihrem Directory-Mandanten. Für Entra ID erfordert dies mindestens User.Read.All und GroupMember.Read.All über die Microsoft Graph API. Einige Anbieter benötigen zudem Device.Read.All für Geräte-Compliance-Prüfungen. Für Google Workspace über Secure LDAP laden Sie das Client-Zertifikat und den Schlüssel aus der Google Admin-Konsole herunter und installieren Sie diese im RADIUS-Dienst.

Definieren Sie Ihre Authentifizierungsrichtlinien im Cloud-RADIUS-Verwaltungsportal. Eine gut strukturierte Richtlinie für eine Unternehmensumgebung: „Zugriff gewähren, wenn das Zertifikat von [Trusted CA] ausgestellt wurde UND der Benutzer Mitglied der Gruppe [Corporate-WiFi-Users] ist UND das Gerät in Intune als konform markiert ist.“ Dies erzwingt Identität, Gruppenmitgliedschaft und Gerätestatus gleichzeitig.

Phase 4: Drahtlose Infrastruktur konfigurieren

Fügen Sie in Ihrem Wireless-LAN-Controller oder Cloud-Management-Dashboard – Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme oder Fortinet – die IP-Adressen und Shared Secrets des Cloud-RADIUS-Servers als RADIUS-Authentifizierungsserver hinzu. Konfigurieren Sie Primär- und Sekundärserver für Redundanz. Stellen Sie das RADIUS-Timeout auf mindestens fünf Sekunden ein, um die Cloud-Laufzeitlatenz auszugleichen.

Erstellen Sie eine neue SSID, die für WPA2-Enterprise oder WPA3-Enterprise konfiguriert ist. Stellen Sie bei Bereitstellungen im Bereich Hospitality sicher, dass sich die Unternehmens-SSID in einem separaten VLAN von jedem Guest WiFi -Netzwerk befindet. Für Retail -Umgebungen sollten Sie in Betracht ziehen, die Unternehmens-SSID nur in den Back-of-House-Bereichen bereitzustellen.

Phase 5: WiFi-Profil über MDM bereitstellen

Microsoft Intune: Erstellen Sie ein WiFi-Konfigurationsprofil. Stellen Sie sicher, dass die SSID exakt mit Ihrer Infrastrukturkonfiguration übereinstimmt. Wählen Sie WPA2-Enterprise oder WPA3-Enterprise. Wählen Sie unter den EAP-Einstellungen EAP-TLS aus. Verknüpfen Sie das SCEP-Zertifikatsprofil als Client-Zertifikat und geben Sie das vertrauenswürdige Root-CA-Profil an. Weisen Sie dieses WiFi-Profil denselben Gerätegruppen zu, die die Zertifikatsprofile erhalten haben. Geräte empfangen das Zertifikat und die WiFi-Konfiguration bei ihrer nächsten Intune-Synchronisierung im Hintergrund.

Google Admin-Konsole: Navigieren Sie zu „Geräte“, dann „Netzwerke“ und schließlich „WLAN“. Erstellen Sie ein neues WiFi-Netzwerkprofil. Legen Sie die SSID fest, wählen Sie WPA3-Enterprise, wählen Sie EAP-TLS und übertragen Sie das vertrauenswürdige Root-CA-Zertifikat auf die Geräte. Wenden Sie dieses Profil auf Ihre Organisationseinheiten an. Chromebooks verbinden sich geräuschlos und sicher.

Best Practices

Schreiben Sie EAP-TLS für alle neuen Bereitstellungen vor. Stellen Sie keine neuen Netzwerke mit PEAP-MSCHAPv2 bereit. Die Sicherheitsrisiken sind hinreichend dokumentiert und der Migrationspfad ist mit modernen MDM-Tools unkompliziert.Erzwingen Sie eine strenge Überprüfung von Serverzertifikaten. Wenn Sie PEAP für Legacy-Geräte verwenden müssen, konfigurieren Sie die Geräte so, dass sie das Zertifikat des RADIUS-Servers validieren. Im Intune-WiFi-Profil und im Google Admin Console-WiFi-Profil gibt es ein Feld zur Angabe der vertrauenswürdigen CA für die Servervalidierung. Lassen Sie dieses Feld nicht leer. Diese einzige Konfigurationsentscheidung macht den Unterschied zwischen einer sicheren und einer anfälligen Bereitstellung aus.

Segmentieren Sie Ihr Netzwerk mit dynamischer VLAN-Zuweisung. Verwenden Sie Ihren RADIUS-Server, um die Gruppenmitgliedschaft des Benutzers in Entra ID oder Google Workspace zu prüfen und ihn dynamisch verschiedenen VLANs zuzuweisen. Der RADIUS-Server gibt das Attribut Tunnel-Private-Group-Id an den Access Point zurück, der den Client im richtigen VLAN platziert. Dies schränkt die laterale Bewegung im Falle einer Kompromittierung ein und unterstützt die Netzwerksegmentierungsanforderungen nach PCI DSS.

Trennen Sie die Authentifizierung für Unternehmens- und Gastnetzwerke. Verwenden Sie EAP-TLS für vom Unternehmen verwaltete Geräte. Nutzen Sie ein Captive Portal mit SSO für BYOD- und Gastgeräte. Der Versuch, EAP-TLS manuell auf unverwalteten Geräten zu konfigurieren, verursacht einen enormen Support-Aufwand. Die Guest WiFi -Plattform von Purple übernimmt das Onboarding von Gästen separat und sorgt so für eine saubere Trennung zwischen dem Datenverkehr von Mitarbeitern und Besuchern.

Überwachen Sie den Ablauf von Zertifikaten proaktiv. Richten Sie Überwachungen und Warnmeldungen 90 Tage, 30 Tage und sieben Tage vor dem Ablauf von Zertifikaten ein. Wenn das Zertifikat Ihres RADIUS-Servers abläuft, verlieren alle Geräte gleichzeitig die Verbindung. Automatisieren Sie die Verlängerung, sofern Ihre PKI dies unterstützt.

Testen Sie die RADIUS-Timeout-Einstellungen. Cloud RADIUS führt zu einer Netzwerklatenz durch Roundtrips, die bei lokalem NPS nicht auftritt. Stellen Sie das RADIUS-Timeout an Ihren Access Points auf mindestens fünf Sekunden ein. Ein Timeout von zwei Sekunden – in Standardkonfigurationen häufig anzutreffen – führt zu sporadischen Authentifizierungsfehlern.

Fehlerbehebung und Risikominderung

Blockierte Firewall-Ports sind die häufigste Ursache für das Fehlschlagen der ersten Bereitstellung. Die RADIUS-Authentifizierung erfordert den UDP-Port 1812 ausgehend von Ihrer Wireless-Infrastruktur zum Cloud RADIUS-Dienst. RADIUS Accounting erfordert den UDP-Port 1813. Stellen Sie sicher, dass diese geöffnet sind, bevor Sie mit einer anderen Fehlerbehebung beginnen.

Fehler bei der Zertifikatsüberprüfung äußern sich als Ablehnungen der Authentifizierung ohne offensichtliche Ursache. Überprüfen Sie Folgendes der Reihe nach: Ablaufdatum des Zertifikats sowohl auf dem Client als auch auf dem RADIUS-Server; Zeitabweichung zwischen dem Client-Gerät und dem RADIUS-Server (EAP-TLS basiert auf einer genauen Uhrzeit); und ob das Root-CA-Zertifikat erfolgreich über das MDM auf dem Gerät bereitgestellt wurde.

Nicht erzwungene Gruppenmitgliedschaften sind ein häufiges Problem, wenn RADIUS-Richtlinien auf Entra ID- oder Google Workspace-Gruppen verweisen. Stellen Sie sicher, dass der Cloud RADIUS-Anbieter über die korrekten API-Berechtigungen zum Lesen von Gruppenmitgliedschaften verfügt. Bestätigen Sie in Entra ID, dass der Dienstprinzipal über GroupMember.Read.All verfügt. Bestätigen Sie in Google Workspace, dass der Secure LDAP-Client die Berechtigung zum Lesen von Gruppeninformationen besitzt. VLAN-Zuweisung funktioniert nicht weist in der Regel auf eine Abweichung zwischen den RADIUS-Attributwerten und den auf der Wireless-Infrastruktur konfigurierten VLAN-IDs hin. Stellen Sie sicher, dass Tunnel-Type auf VLAN (Wert 13), Tunnel-Medium-Type auf 802 (Wert 6) und Tunnel-Private-Group-Id auf die auf dem Switch oder Controller konfigurierte VLAN-ID eingestellt ist.

EAP-TLS-Fehler bei BYOD-Geräten deuten meist darauf hin, dass das Client-Zertifikat nicht erfolgreich bereitgestellt wurde. Prüfen Sie bei Intune-verwalteten Geräten den Zertifikatsspeicher des Geräts im Intune Admin Center. Überprüfen Sie bei Google-verwalteten Chromebooks, ob das Zertifikatsprofil der korrekten Organisationseinheit zugewiesen ist und das Gerät vor Kurzem synchronisiert wurde.

ROI und geschäftlicher Nutzen

Der Wechsel zu Cloud RADIUS liefert messbare betriebliche Einsparungen. On-Premise-RADIUS erfordert mindestens zwei Server für Hochverfügbarkeit, laufende Betriebssystem-Patches, Zertifikatsmanagement und die Arbeitszeit spezialisierter Techniker. Die Zeit, die ein einzelner Techniker im Laufe eines Jahres für die RADIUS-Wartung aufwendet, übersteigt in der Regel die jährlichen Kosten eines Cloud RADIUS-Abonnements.

Der Business Case geht über die reine Kostenreduzierung hinaus. Durch die Verknüpfung des Netzwerkzugriffs mit verifizierten Cloud-Identitäten profitieren Sie von:

Sofortigem Offboarding. Das Deaktivieren eines Benutzers in Entra ID oder Google Workspace entzieht sofort dessen Netzwerkzugriff an allen Standorten. Es gibt keine Verzögerung, keinen manuellen Prozess und kein Risiko, dass ein ehemaliger Mitarbeiter den WiFi-Zugang behält. Dies unterstützt direkt die DSGVO-Verpflichtungen (GDPR) in Bezug auf Datenzugriffsrechte.

Aussagekräftigeren Analysen. Plattformen wie das WiFi Analytics von Purple liefern detailliertere Daten zur Flächennutzung und zu Besucherwegen, wenn der Netzwerkzugriff an authentifizierte Identitäten gekoppelt ist. Sie wechseln von anonymen MAC-Adressen zu namentlich bekannten, authentifizierten Benutzern, was die Qualität der Erkenntnisse für Betriebs- und Marketingteams grundlegend verbessert.

Nachweis der Compliance. Die EAP-TLS-Authentifizierung generiert detaillierte Zugriffsprotokolle – wer sich mit welchem Gerät, an welchem Ort und zu welcher Zeit verbunden hat. Dieser Audit-Trail unterstützt die PCI-DSS-Anforderung 10 (Protokollierung und Überwachung) sowie die Rechenschaftspflichten der GDPR.

Konsistenz an mehreren Standorten. Ein einziger Cloud RADIUS-Dienst authentifiziert alle Ihre Standorte mit konsistenten Richtlinien, verwaltet über ein einziges Dashboard. Das Hinzufügen eines neuen Hotels, Geschäfts oder Veranstaltungsorts bedeutet lediglich das Hinzufügen seiner Access Points zur RADIUS-Konfiguration – und nicht die Bereitstellung und Konfiguration eines weiteren Servers. Für Unternehmen, die große Liegenschaften verwalten, ist dies ein erheblicher betrieblicher Vorteil.

Für Betreiber im Bereich Transport und Einrichtungen im Healthcare -Sektor, bei denen die Netzwerkverfügbarkeit betriebskritisch ist, bieten Cloud RADIUS-Anbieter in der Regel SLAs mit 99,999 % Verfügbarkeit und integriertem Multi-Regionen-Failover. Purple arbeitet mit einer Verfügbarkeit von 99,999 % an über 80.000 aktiven Standorten und verzeichnete 2024 440 Millionen verarbeitete Logins (interne Daten von Purple, 2024).

Für weitere Informationen zu verwandten Themen siehe WAN Computer Definition: A Practical Guide for 2026 und World WiFi Day 2026: How Your Venue Can Help Bridge the Digital Divide .

Schlüsseldefinitionen

RADIUS (Remote Authentication Dial-In User Service)

Ein in RFC 2865 definiertes Netzwerkprotokoll, das eine zentralisierte Verwaltung von Authentifizierung, Autorisierung und Accounting (AAA) für Benutzer bietet, die sich mit einem Netzwerkdienst verbinden. Der RADIUS-Server fungiert als Entscheidungsinstanz zwischen Ihren Access Points und Ihrem Identitätsverzeichnis.

Jedes WPA2-Enterprise- oder WPA3-Enterprise-WiFi-Netzwerk in Unternehmen basiert auf einem RADIUS-Server. Ohne ihn funktioniert die IEEE 802.1X-Authentifizierung nicht.

RADIUS as a Service (RADIUSaaS)

Eine in der Cloud gehostete RADIUS-Implementierung, die als Managed Service bereitgestellt wird. Der Anbieter übernimmt die Wartung der Infrastruktur, Patches, Hochverfügbarkeit und die Integration von Identitätsanbietern. Sie konfigurieren die Authentifizierungsrichtlinien und verweisen Ihre Access Points auf die Cloud-RADIUS-IPs.

RADIUSaaS überflüssig macht lokale NPS- oder FreeRADIUS-Server und eliminiert die damit verbundene Hardware, das Patchen des Betriebssystems sowie den spezialisierten Wartungsaufwand.

IEEE 802.1X

Ein IEEE-Standard für die portbasierte Netzwerkzugriffskontrolle. Er definiert das dreiteilige Authentifizierungsmodell: den Supplicant (Client-Gerät), den Authenticator (Access Point oder Switch) und den Authentifizierungsserver (RADIUS-Server). Der Authenticator blockiert jeglichen Datenverkehr, bis der RADIUS-Server den Zugriff gewährt.

Der grundlegende Standard für die WiFi-Authentifizierung in Unternehmen. WPA2-Enterprise und WPA3-Enterprise basieren beide auf 802.1X.

EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)

Eine in RFC 5216 definierte Authentifizierungsmethode, die digitale Zertifikate sowohl auf dem RADIUS-Server als auch auf dem Client-Gerät für eine gegenseitige Authentifizierung nutzt. Keine der Parteien sendet ein Passwort. Der Client präsentiert sein Zertifikat; der Server validiert es in Echtzeit mit dem Verzeichnis.

Der Goldstandard für die WiFi-Sicherheit in Unternehmen. Verhindert Anmeldedaten-Diebstahl, Phishing und passwortbezogenen Support-Aufwand im Helpdesk. Erforderlich für die PCI-DSS-Compliance in Karteninhaber-Datennetzwerken.

PEAP-MSCHAPv2 (Protected EAP - Microsoft Challenge Handshake Authentication Protocol v2)

Eine Authentifizierungsmethode, die einen verschlüsselten TLS-Tunnel erstellt und anschließend den Benutzernamen und das Passwort des Benutzers darüber überträgt. Anfällig für "Evil Twin"-Angriffe, wenn der Client das Zertifikat des RADIUS-Servers nicht streng validiert.

Der veraltete Standard für WiFi in Unternehmen. Immer noch weit verbreitet, sollte jedoch in allen neuen und bestehenden Bereitstellungen nach Möglichkeit auf EAP-TLS umgestellt werden.

Microsoft Entra ID

Der cloudbasierte Identitäts- und Zugriffsverwaltungsdienst von Microsoft, ehemals bekannt als Azure Active Directory (Azure AD). Verwaltet Benutzeridentitäten, Gruppenmitgliedschaften, Geräte-Compliance und Richtlinien für den bedingten Zugriff.

Die primäre Identitätsquelle für Cloud-RADIUS in Microsoft-zentrierten Umgebungen. Cloud-RADIUS-Anbieter verbinden sich über die Microsoft Graph API mit Entra ID.

Google Secure LDAP

Ein verwalteter Dienst, der in den Editionen Cloud Identity Premium und Google Workspace Enterprise verfügbar ist und eine traditionelle LDAP-Schnittstelle für das Cloud-Verzeichnis von Google bereitstellt. RADIUS-Server verbinden sich über Client-Zertifikate auf Port 636 mit ldap.google.com.

Der primäre Integrationspfad zur Verbindung eines Cloud-RADIUS-Servers mit Google Workspace. Google bietet keinen nativen RADIUS-Dienst an, weshalb Secure LDAP als Brücke fungiert.

PKI (Public Key Infrastructure)

Die Gesamtheit der Rollen, Richtlinien, Hardware, Software und Verfahren, die zum Erstellen, Verwalten, Verteilen, Nutzen, Speichern und Widerrufen digitaler Zertifikate erforderlich sind. Eine PKI wird benötigt, um die bei der EAP-TLS-Authentifizierung verwendeten Client- und Serverzertifikate auszustellen.

Cloud-native PKI-Optionen von RADIUS-Anbietern oder Microsoft (Cloud PKI) erübrigen den Einsatz von lokalen Active Directory-Zertifikatsdiensten (ADCS).

SCEP (Simple Certificate Enrollment Protocol)

Ein Protokoll, mit dem Geräte automatisch digitale Zertifikate von einer Zertifizierungsstelle anfordern und empfangen können. Wird von Microsoft Intune und der Google Admin-Konsole verwendet, um Client-Zertifikate ohne Benutzerinteraktion auf verwalteten Geräten bereitzustellen.

SCEP-Profile in Intune sind der Mechanismus, über den geschäftliche Geräte im Hintergrund die für die EAP-TLS-Authentifizierung erforderlichen Client-Zertifikate erhalten.

Dynamic VLAN assignment

Eine RADIUS-Funktion, die VLAN-Zuweisungsattribute (Tunnel-Type, Tunnel-Medium-Type, Tunnel-Private-Group-Id) basierend auf der Verzeichnisgruppenmitgliedschaft des authentifizierten Benutzers an den Access Point zurückgibt. Der AP weist den Client automatisch dem angegebenen VLAN zu.

Ermöglicht eine granulare Netzwerksegmentierung ohne manuelle VLAN-Konfiguration pro Gerät. Mitarbeiter in unterschiedlichen Rollen oder Abteilungen landen in verschiedenen Netzwerksegmenten, was laterale Bewegungen einschränkt und die Segmentierungsanforderungen von PCI DSS unterstützt.

Ausgearbeitete Beispiele

Ein Hotel mit 200 Zimmern migriert sein Mitarbeiternetzwerk im Back-of-House-Bereich von einem alternden On-Premise-NPS-Server auf eine Cloud-native Lösung. Das Hotel ist kürzlich auf Microsoft Entra ID und Microsoft 365 E5 umgestiegen. Bei den Geräten der Mitarbeiter handelt es sich um Windows-Laptops, die von Intune verwaltet werden. Die Wireless-Infrastruktur ist Cisco Meraki. Das Hotel möchte, dass sich die Mitarbeiter automatisch und ohne Passworteingabe verbinden, und benötigt eine sofortige Sperrung, wenn ein Mitarbeiter das Unternehmen verlässt.

Stellen Sie eine Cloud RADIUS-Lösung mit Entra ID-Integration bereit. Schritt 1: Erteilen Sie dem Cloud RADIUS-Anbieter Microsoft Graph API-Berechtigungen (User.Read.All, GroupMember.Read.All, Device.Read.All) im Entra ID-Tenant. Schritt 2: Erstellen Sie in Intune ein Profil für vertrauenswürdige Zertifikate mit der Cloud RADIUS-Root-CA und weisen Sie es der Gruppe "Alle Unternehmensgeräte" zu. Schritt 3: Erstellen Sie ein SCEP-Zertifikatsprofil mit dem Subject Name CN={{UserPrincipalName}} und weisen Sie es derselben Gruppe zu. Schritt 4: Konfigurieren Sie die Cloud RADIUS-Authentifizierungsrichtlinie: Erlauben Sie den Zugriff, wenn das Zertifikat von der [Vertrauenswürdigen CA] ausgestellt wurde UND der Benutzer Mitglied der Entra ID-Gruppe [Hotel-Staff-WiFi] ist UND das Gerät Intune-konform ist. Schritt 5: Fügen Sie im Cisco Meraki-Dashboard die primären und sekundären IPs von Cloud RADIUS als RADIUS-Server auf der Back-of-House-SSID hinzu. Stellen Sie den RADIUS-Timeout auf 5 Sekunden ein. Schritt 6: Erstellen Sie in Intune ein WPA3-Enterprise-WiFi-Profil für die Back-of-House-SSID, geben Sie EAP-TLS an und verknüpfen Sie das SCEP-Zertifikatsprofil. Weisen Sie es der Gruppe "Alle Unternehmensgeräte" zu. Die Geräte erhalten das Zertifikat und das WiFi-Profil beim nächsten Intune-Sync geräuschlos und verbinden sich automatisch. Wenn ein Mitarbeiter das Unternehmen verlässt, entzieht die Deaktivierung seines Entra ID-Kontos sofort den Netzwerkzugriff an allen Standorten.

Kommentar des Prüfers: Dieser Ansatz eliminiert die Abhängigkeit vom On-Premise-NPS vollständig. EAP-TLS beseitigt den Phishing-Vektor der anmeldeinformationsbasierten Authentifizierung. Intune automatisiert die Verwaltung des Zertifikatslebenszyklus, wodurch der manuelle Aufwand entfällt, der bei der vorherigen NPS-Bereitstellung zu Verzögerungen bei Zertifikatsverlängerungen führte. Die Entra ID-Gruppenrichtlinie sorgt dafür, dass der Netzwerkzugriff in Echtzeit gesperrt wird, wenn die Personalabteilung ein Konto deaktiviert – eine manuelle Aktualisierung der RADIUS-Richtlinie ist nicht erforderlich. Die Cisco Meraki-Integration ist unkompliziert: Cloud RADIUS ist hardwareunabhängig und funktioniert mit jeder 802.1X-fähigen Infrastruktur.

Eine Einzelhandelskette mit 50 Filialen nutzt Google Workspace und verwaltet eine Flotte von 500 Chromebooks, die von Filialmitarbeitern für die Bestandsaufnahme und POS-Aktivitäten genutzt werden. Derzeit nutzen sie ein gemeinsam genutztes WPA2 PSK für das Filialbetriebsnetzwerk, was bei Verlust oder Diebstahl von Geräten ein Sicherheitsrisiko darstellt. Sie möchten auf eine 802.1X-Authentifizierung umstellen, ohne in jeder Filiale lokale Server installieren zu müssen. Ihre Wireless-Infrastruktur ist HPE Aruba.

Stellen Sie eine Cloud RADIUS-Lösung mit Google Workspace-Integration über Google Secure LDAP bereit. Schritt 1: Navigieren Sie in der Google Admin-Konsole zu Apps, dann LDAP, und fügen Sie einen neuen LDAP-Client für den Cloud RADIUS-Dienst hinzu. Konfigurieren Sie die Leseberechtigungen für Benutzerinformationen und Gruppenmitgliedschaften. Laden Sie das erstellte Client-Zertifikat und den Schlüssel herunter. Schritt 2: Konfigurieren Sie den Cloud RADIUS-Dienst mit den Google Secure LDAP-Anmeldedaten. Schritt 3: Konfigurieren Sie eine Cloud-PKI, um Zertifikate für die Chromebooks auszustellen. Navigieren Sie in der Google Admin-Konsole zu Geräte, dann Netzwerke, dann Zertifikate, und laden Sie die Root-CA hoch. Konfigurieren Sie das Profil für die Zertifikatsausstellung und wenden Sie es auf die Organisationseinheit "Store-Associates" an. Schritt 4: Erstellen Sie in der Google Admin-Konsole ein WPA3-Enterprise-WiFi-Profil für die SSID des Filialbetriebs. Stellen Sie EAP-TLS ein, verknüpfen Sie die Root-CA und wenden Sie es auf die OU "Store-Associates" an. Die Chromebooks erhalten das Zertifikat und das WiFi-Profil beim nächsten Abgleich mit der Admin-Konsole. Schritt 5: Konfigurieren Sie in HPE Aruba Central die SSID des Filialbetriebs mit WPA3-Enterprise und fügen Sie die primären und sekundären IPs von Cloud RADIUS hinzu. Stellen Sie den RADIUS-Timeout auf 5 Sekunden ein. Konfigurieren Sie die dynamische VLAN-Zuweisung, um Filialmitarbeiter basierend auf ihrer Google Workspace-Gruppenmitgliedschaft dem VLAN 20 (Filialbetrieb) zuzuordnen. Wenn ein Chromebook verloren geht oder gestohlen wird, entzieht das Entfernen aus der OU "Store-Associates" sofort den Netzwerkzugriff.

Kommentar des Prüfers: Diese Bereitstellung eliminiert das Risiko gemeinsam genutzter PSKs. Ein verloren gegangenes oder gestohlenes Chromebook mit einem gemeinsam genutzten PSK ermöglicht einem Angreifer dauerhaften Netzwerkzugriff, bis der PSK in allen 50 Filialen geändert wird. Mit EAP-TLS kann das Zertifikat auf dem verlorenen Gerät sofort gesperrt werden. Die Google Secure LDAP-Integration ist der richtige Weg für Google Workspace-Umgebungen – sie bietet eine stabile, standardbasierte Schnittstelle, die der Cloud RADIUS-Dienst abfragen kann, ohne dass eine benutzerdefinierte API-Integration erforderlich ist. Die dynamische VLAN-Zuweisung stellt sicher, dass Filialmitarbeiter im richtigen Netzwerksegment landen, was die PCI DSS-Netzwerksegmentierungsanforderungen für Einzelhandelsumgebungen unterstützt.

Übungsfragen

Q1. Ihr Unternehmen migriert von On-Premise Active Directory zu Microsoft Entra ID. Sie nutzen derzeit PEAP-MSCHAPv2 für die WiFi-Authentifizierung auf 300 vom Intune verwalteten Firmen-Laptops. Sie verfügen über eine Microsoft 365 E5-Lizenzierung. Was ist der sicherste und betrieblich effizienteste Weg, um die WiFi-Authentifizierung auf eine Cloud-native Architektur zu migrieren?

Hinweis: Bedenken Sie die Sicherheitsrisiken der auf Anmeldedaten basierenden Authentifizierung, die Funktionen von Microsoft Intune zur Zertifikatsverteilung und die Notwendigkeit, Abhängigkeiten von On-Premise-Infrastrukturen zu vermeiden.

Musterlösung anzeigen

Stellen Sie eine Cloud-RADIUS-Lösung mit Entra ID-Integration bereit. Nutzen Sie Microsoft Intune, um ein vertrauenswürdiges Zertifikatsprofil (Root CA) und ein SCEP-Zertifikatsprofil auf den 300 Laptops zu verteilen. Konfigurieren Sie die Cloud-RADIUS-Authentifizierungsrichtlinie so, dass ein gültiges Zertifikat der vertrauenswürdigen Zertifizierungsstelle und die Mitgliedschaft in der Entra ID-Gruppe Corporate-WiFi-Users erforderlich sind. Erstellen Sie ein WPA3-Enterprise-WiFi-Profil in Intune, das EAP-TLS spezifiziert, und verknüpfen Sie das SCEP-Zertifikatsprofil. Die Geräte erhalten das Zertifikat und die WiFi-Konfiguration bei der nächsten Intune-Synchronisierung automatisch im Hintergrund. Dies eliminiert das Risiko des Diebstahls von PEAP-MSCHAPv2-Anmeldedaten, entfernt die Abhängigkeit von On-Premise-NPS und bietet eine sofortige Sperrung, wenn ein Entra ID-Konto deaktiviert wird.

Q2. Ein Nutzer in Ihrem Hotel meldet, dass er sich nach der Rückkehr aus einem zweiwöchigen Urlaub nicht mit dem WiFi für das Back-of-House-Personal verbinden kann. Andere Mitarbeiter können sich problemlos verbinden. Das Netzwerk nutzt EAP-TLS mit über Intune bereitgestellten Zertifikaten. Was sind die drei wahrscheinlichsten Ursachen, der Wahrscheinlichkeit nach geordnet?

Hinweis: EAP-TLS stützt sich auf zeitkritische kryptografische Elemente und Echtzeit-Verzeichnisabfragen.

Musterlösung anzeigen

Das Client-Zertifikat des Nutzers ist abgelaufen. Zertifikate haben eine definierte Gültigkeitsdauer. Wenn das Gerät während des Erneuerungsfensters offline war, wurde es über das SCEP-Profil möglicherweise nicht erneuert. Überprüfen Sie das Ablaufdatum des Zertifikats im Intune-Gerätezertifikatsspeicher. 2. Die Systemzeit des Geräts ist asynchron (Zeitversatz), was die Zertifikatsvalidierung fehlschlagen lässt. EAP-TLS validiert die Zeitstempel der Zertifikate; eine Abweichung der Uhrzeit von mehr als fünf Minuten führt zu Authentifizierungsfehlern. 3. Das Entra ID-Konto des Nutzers wurde während seiner Abwesenheit in eine andere Gruppe verschoben (z. B. von den aktiven Mitarbeitern in eine andere Organisationseinheit), und die RADIUS-Authentifizierungsrichtlinie stimmt nicht mehr mit der Gruppenmitgliedschaft überein. Überprüfen Sie die Gruppenmitgliedschaften des Nutzers in Entra ID mit der RADIUS-Richtlinie.

Q3. Sie sind IT-Manager für eine Einzelhandelskette mit 80 Filialen. Sie nutzen Google Workspace und verwalten 400 Chromebooks über die Google Admin-Konsole. Sie möchten den aktuellen gemeinsam genutzten WPA2 PSK im Filialbetriebsnetzwerk durch eine 802.1X-Authentifizierung ersetzen. Sie haben an keinem Filialstandort On-Premise-Server. Welche Architektur stellen Sie bereit, und was ist der primäre Sicherheitsvorteil gegenüber dem aktuellen PSK-Ansatz?

Hinweis: Bedenken Sie, was passiert, wenn ein Chromebook unter dem jeweiligen Authentifizierungsmodell verloren geht oder gestohlen wird.

Musterlösung anzeigen

Stellen Sie einen Cloud-RADIUS-Dienst mit Google Secure LDAP-Integration bereit. Konfigurieren Sie eine Cloud-PKI, um Zertifikate für die Chromebooks auszustellen. Verteilen Sie in der Google Admin-Konsole die Root CA und ein SCEP-Client-Zertifikatsprofil an die Organisationseinheit der Filialmitarbeiter. Erstellen Sie ein WPA3-Enterprise-WiFi-Profil mit EAP-TLS und verteilen Sie es auf dieselbe Organisationseinheit. Konfigurieren Sie HPE Aruba- (oder gleichwertige) Access Points in jeder Filiale so, dass sie auf den Cloud-RADIUS-Dienst verweisen. Der primäre Sicherheitsvorteil: Beim aktuellen gemeinsam genutzten PSK behält ein verlorenes oder gestohlenes Chromebook den WiFi-Zugriff, bis der PSK in allen 80 Filialen geändert wird – ein störender und zeitaufwendiger Prozess. Mit EAP-TLS entzieht das Entfernen des Geräts aus der Organisationseinheit in der Google Admin-Konsole dem Gerät sofort das Zertifikat und den Netzwerkzugriff, ohne Auswirkungen auf andere Geräte.

Q4. Während einer Cloud-RADIUS-Bereitstellung konfigurieren Sie die SSID auf den Cisco Meraki Access Points und verteilen das Intune-WiFi-Profil an eine Pilotgruppe von 20 Geräten. Keines der Geräte kann eine Verbindung herstellen. Der Intune-Gerätestatus zeigt an, dass das Zertifikat und das WiFi-Profil erfolgreich bereitgestellt wurden. Was prüfen Sie zuerst?

Hinweis: Die häufigste Ursache für das Fehlschlagen einer Ersteinrichtung ist kein Konfigurationsfehler in der RADIUS-Richtlinie oder im Zertifikat.

Musterlösung anzeigen

Prüfen Sie, ob die UDP-Ports 1812 und 1813 für den ausgehenden Verkehr von den Cisco Meraki Access Points (oder der Meraki-Cloud-Infrastruktur) zu den IP-Adressen des Cloud-RADIUS-Servers geöffnet sind. Blockierte Firewall-Ports sind die Hauptursache für das Fehlschlagen von Erstbereitstellungen. Da die Zertifikate und WiFi-Profile erfolgreich bereitgestellt wurden, sind Konfigurationsfehler in Intune ausgeschlossen. Die nächsten Schritte sind: Überprüfung auf fehlerhafte RADIUS-Shared-Secrets zwischen Meraki und dem Cloud-RADIUS-Dienst, Erhöhung des zu niedrig eingestellten RADIUS-Timeouts (auf mindestens 5 Sekunden) und die Überprüfung, ob die IP-Adressen des Cloud-RADIUS-Servers in der Meraki-SSID-Konfiguration korrekt hinterlegt sind.

Weiterlesen in dieser Reihe

The Security Benefits of RADIUS as a Service for Hybrid Workforces

This technical reference guide explains how RADIUS as a Service secures network access for hybrid workforces across distributed venues. It covers the architecture, security benefits, and deployment steps for replacing on-premise RADIUS infrastructure with a cloud-managed authentication service. For IT managers and network architects at hotels, retail chains, stadiums, and public-sector organisations, this guide provides the evidence needed to evaluate and act on a cloud RADIUS migration this quarter.

So implementieren Sie die 802.1X-Authentifizierung mit Cloud RADIUS

Dieser technische Leitfaden bietet einen umfassenden Rahmen für die Implementierung der 802.1X-Authentifizierung mit Cloud RADIUS in verteilten Unternehmensstandorten. Er beschreibt detailliert die Architektur, die Auswahl der EAP-Methode, die Bereitstellungsreihenfolge und die Strategien zur Risikominderung, die zur Sicherung des Netzwerkzugriffs erforderlich sind, während gleichzeitig der betriebliche Aufwand für eine On-Premises-Infrastruktur entfällt.

Was ist Cloud RADIUS? Ein umfassender Leitfaden zu RADIUS as a Service

Dieser umfassende Leitfaden untersucht Cloud RADIUS (RADIUS as a Service) und beschreibt dessen Architektur, EAP-Methoden und Implementierungsstrategien im Detail. Er bietet IT-Verantwortlichen praxistaugliche Erkenntnisse für die Migration von On-Premises-Servern zu einem skalierbaren, sicheren und datenschutzkonformen cloudbasierten Authentifizierungsmodell.