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

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

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

Diesen Leitfaden anhören

Podcast-Transkript ansehen

Willkommen beim Purple Technical Briefing. Heute behandeln wir ein Thema an der Schnittstelle zwischen Cloud-Identitätsverwaltung und physischer Netzwerksicherheit: die Integration von RADIUS as a Service mit Cloud-Verzeichnissen, 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 direkt relevant für Ihre nächste Infrastrukturentscheidung.

Beginnen wir mit dem Kontext. In den letzten zwei Jahrzehnten basierte die WiFi-Authentifizierung in Unternehmensumgebungen auf einem recht vorhersehbaren Stack. Sie hatten ein lokales Active Directory, den Windows Network Policy Server als RADIUS-Server und WPA2-Enterprise auf den Access Points. Es hat funktioniert. Aber es erforderte On-Premises-Server, manuelle Zertifikatsverwaltung und ein team mit Fachwissen, um den Betrieb aufrechtzuerhalten.

Das Problem ist, dass die meisten Unternehmen nicht mehr On-Premises-First aufgestellt sind. Sie sind Cloud-First. Microsoft Entra ID und Google Workspace sind heute die führenden Verzeichnisse für Millionen von Unternehmen. Und 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 immer so bleiben.

Die Frage lautet also: Wie schlagen Sie die Brücke von Ihrer Cloud-Identitätsplattform zu Ihrer physischen Netzwerksicherheits-Infrastruktur, ohne wieder einen On-Premises-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 On-Premises-Server. Kein Patching. Keine Notfälle bei der Zertifikatsverlängerung um 2 Uhr nachts.

Das Fundament ist IEEE 802.1X. Wenn ein Gerät versucht, sich mit einem WPA2-Enterprise- oder WPA3-Enterprise-Netzwerk zu verbinden, fungiert der Access Point als Authenticator. 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 folgenschwerste technische Entscheidung bei dieser gesamten Bereitstellung ist die Wahl Ihrer EAP-Methode.

PEAP-MSCHAPv2 ist der alte Weg. Er verwendet Benutzernamen und Passwörter. Das klingt sicher. Ist es aber nicht. Wenn ein Gerät das Zertifikat des RADIUS-Servers nicht streng validiert, kann ein Angreifer einen gefälschten Access Point mit Ihrer SSID einrichten, den Handshake abfangen und die Anmeldedaten erfassen. Dies wird als Evil-Twin-Angriff bezeichnet, und er findet statt.

EAP-TLS is 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 Anmeldedaten möglich. Kein Phishing-Vektor. Keine Helpdesk-Tickets, wenn jemand sein Passwort ändert.

Gehen wir 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 verwaltete PKI Ihres Cloud-RADIUS-Anbieters oder die Microsoft-eigene Cloud PKI nutzen.

Schritt zwei: Zertifikatsbereitstellung über Intune. Erstellen Sie ein Profil für ein vertrauenswürdiges Zertifikat mit Ihrer Root-CA und stellen Sie es für Gerätegruppen bereit. Erstellen Sie dann ein SCEP-Zertifikatsprofil. Für die benutzerbasierte Authentifizierung verwendet der Subject Name den User Principal Name.

Schritt drei: Cloud-RADIUS-Konfiguration. Erteilen Sie dem RADIUS-Dienst die Berechtigungen für die Microsoft Graph API: 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: Drahtlose Infrastruktur. Fügen Sie in Ihrem Controller – sei es Cisco Meraki, HPE Aruba, Ruckus oder Juniper Mist – die IP-Adressen und Shared Secrets von Cloud-RADIUS 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 geräuschlos bei ihrer nächsten Synchronisierung. Sie verbinden sich automatisch. Keine Benutzerinteraktion erforderlich.

Sehen wir uns nun den Google Workspace-Pfad an, da er sich 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 ein Bindeglied: 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 herkömmliche LDAP-Schnittstelle zu Ihrem Cloud-Verzeichnis. Ihr Cloud-RADIUS-Server verbindet sich über Port 636 unter Verwendung von Client-Zertifikaten, die Google für Sie generiert, mit ldap.google.com. Ab diesem Zeitpunkt kann der RADIUS-Server das Google-Verzeichnis abfragen, um Anmeldedaten oder Gruppenmitgliedschaften zu validieren.

Für verwaltete Chromebooks erfolgt die Bereitstellung über die Google Admin Console. 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 angibt. Die Chromebooks verbinden sich geräuschlos. Für BYOD-Geräte und den Gäste-Zugang verwenden 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.

Sprechen wir über Fallstricke, denn hier gehen Bereitstellungen oft schief.

Der erste und häufigste sind blockierte Firewall-Ports. Die RADIUS-Authentifizierung verwendet den UDP-Port 1812. RADIUS-Accounting verwendet den UDP-Port 1813. Wenn diese Ports nicht ausgehend von Ihrer drahtlosen Infrastruktur zum Cloud-RADIUS-Dienst geöffnet sind, funktioniert nichts. Überprüfen Sie dies jedes Mal zuerst.

Der zweite Fallstrick ist der Ablauf von Zertifikaten. Wenn das Zertifikat Ihres RADIUS-Servers abläuft, verlieren alle Geräte im Netzwerk gleichzeitig die Verbindung. Richten Sie Überwachungsalarme 90 Tage, 30 Tage und 7 Tage vor dem Ablauf ein. Automatisieren Sie die Verlängerung, wo immer dies möglich ist.

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

Der vierte, speziell bei PEAP-Bereitstellungen, ist das Versäumnis, eine strenge Serverzertifikatsvalidierung auf den Client-Geräten zu erzwingen. Ohne diese akzeptieren Geräte jedes Zertifikat, das von einem beliebigen Access Point präsentiert wird, der vorgibt, 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? 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. Es unterstützt zudem die GDPR-Verpflichtungen, indem es eine präzise Zugriffsprotokollierung und den sofortigen Entzug des Zugriffs beim Ausscheiden eines Mitarbeiters ermöglicht.

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

Zusammenfassend die wichtigsten Erkenntnisse.

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

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

Drittens: Microsoft Intune und die Google Admin Console automatisieren die Zertifikatsbereitstellung. 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 Verzeichnis-Gruppenmitgliedschaft. 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 strenge Serverzertifikatsvalidierung.

Wenn Sie in diesem Quartal eine Bereitstellung planen, beginnen Sie mit einer Pilotgruppe von 20 bis 50 Geräten. Validieren Sie die Zertifikatsbereitstellung, die RADIUS-Authentifizierung und die VLAN-Zuweisung, bevor Sie das System global ausrollen. Die Investition, dies von Anfang an richtig aufzusetzen, zahlt sich durch einen geringeren Helpdesk-Overhead, eine stärkere Sicherheitsstruktur und die Möglichkeit aus, Ihre Netzwerkdaten für echte Business Intelligence zu nutzen.

Vielen Dank für Ihr Interesse am Purple Technical Briefing. Detaillierte Bereitstellungsschritte, Konfigurationsbeispiele und ausgearbeitete Szenarien finden Sie im vollständigen technischen Referenzleitfaden unter purple.ai.

Wichtigste Erkenntnisse

✓Cloud-RADIUS macht lokale NPS- und FreeRADIUS-Server überflüssig. Ihre Access Points authentifizieren sich gegenüber einem in der Cloud gehosteten Dienst, der sich direkt in Microsoft Entra ID oder Google Workspace integriert.
✓EAP-TLS ist die richtige Authentifizierungsmethode für Enterprise-WiFi. Es verwendet digitale Zertifikate anstelle von Passwörtern, was den Diebstahl von Anmeldedaten, Phishing und passwortbezogenen Helpdesk-Overhead eliminiert.
✓Microsoft Intune und die Google Admin Console 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 ein Bindeglied für die RADIUS-Integration. Google Secure LDAP (verfügbar in den Editionen Cloud Identity Premium und Enterprise) bietet die LDAP-Schnittstelle, 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 Verzeichnis-Gruppenmitgliedschaft und unterstützt die PCI-DSS-Anforderungen.
✓Überprüfen Sie zuerst die UDP-Ports 1812 und 1813. Blockierte Firewall-Ports sind die Hauptursache für das Fehlschlagen der Erstbereitstellung. Überwachen Sie den Ablauf von Zertifikaten nach 90, 30 und 7 Tagen. Erzwingen Sie eine strenge Serverzertifikatsvalidierung bei allen PEAP-Bereitstellungen.
✓Das Deaktivieren eines Benutzers in Entra ID oder Google Workspace entzieht ihm sofort den WiFi-Zugriff an allen Standorten. Dies ist der primäre Offboarding-Vorteil gegenüber PSK-basierten Netzwerken und unterstützt direkt die GDPR-Verpflichtungen.

📚 Teil unserer Kernserie: Enterprise WiFi Security Guide →

Executive Summary

Für moderne Unternehmen, die in Cloud-Identitäts-Ökosysteme investieren, ist die Verknüpfung von Cloud-Verzeichnissen mit physischen drahtlosen Netzwerken ein kritisches Sicherheitsgebot. 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 On-Premises-Authentifizierungs-Stack zu einer Belastung – teuer im Unterhalt, schwer zu skalieren und inkompatibel mit Zero-Trust-Sicherheitsmodellen.

RADIUS as a Service (RADIUSaaS) ändert die Ausgangslage. Ein in der Cloud gehosteter RADIUS-Server integriert sich direkt in Ihr Cloud-Verzeichnis, validiert Authentifizierungsanfragen in Echtzeit und sendet Zugriffsentscheidungen an Ihre Access Points zurück – ganz ohne On-Premises-Server, Patch-Zyklen oder Single Point of Failure. In Kombination mit der zertifikatsbasierten EAP-TLS-Authentifizierung eliminiert diese Architektur den Diebstahl von Anmeldedaten, unterstützt die Compliance mit PCI-DSS und GDPR und bietet Mitarbeitern an jedem Standort ein nahtloses Erlebnis.

Dieser Leitfaden behandelt die architektonische Entscheidung zwischen On-Premises-NPS und Cloud-nativem RADIUS, die Bereitstellung von EAP-TLS über Microsoft Intune und die Google Admin Console sowie die bewährten Betriebsmethoden zur Absicherung des drahtlosen Zugangs in Hotels, Einzelhandelsflächen, Stadien und öffentlichen Einrichtungen. Für eine umfassendere Einführung in die Netzwerkzugriffskontrolle lesen Sie A Guide to Your Network Access Control System .

Technischer Deep-Dive: 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 mit einem Verzeichnisdienst 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 drahtlosen Sicherheit in Unternehmen und ist in IEEE 802.1X definiert. Es hat sich seit seiner Einführung nicht grundlegend geändert. Geändert hat sich jedoch, wo der RADIUS-Server betrieben wird und 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 über die Microsoft Graph API direkt in Microsoft Entra ID oder über Google Secure LDAP oder SAML/OAuth in Google Workspace. Die Authentifizierung findet vollständig in der Cloud statt. Dies steht im Einklang mit den Prinzipien des Zero-Trust-Netzwerkzugriffs und reduziert den Betriebsaufwand erheblich.

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

Dimension	Hybrid On-Premises (NPS)	Cloud-native (RADIUSaaS)
Infrastruktur	Windows Server VM oder Bare-Metal erforderlich	Keine On-Premises-Server
Identitätsquelle	AD DS über LDAP/Kerberos	Entra ID oder Google Workspace über API
Zertifizierungsstelle	ADCS On-Premises + Intune Connector	Cloud-PKI vom Anbieter oder Microsoft
Hochverfügbarkeit	Manuelle HA und Lastverteilung	Automatisch skaliert durch den Anbieter
Einrichtungszeit	Tage bis Wochen	Stunden
Ideal für	Hybrides AD, Legacy-Geräte	Cloud-First- und MDM-verwaltete Unternehmen
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 folgenschwerste Sicherheitsentscheidung bei dieser Bereitstellung. PEAP-MSCHAPv2 basiert darauf, dass Benutzer ihre Domain-Anmeldedaten eingeben. Dies ist anfällig für den Diebstahl von Anmeldedaten und Man-in-the-Middle-Angriffe. Wenn ein Client-Gerät das Zertifikat des RADIUS-Servers nicht streng validiert – was viele standardmäßig nicht tun –, kann ein Angreifer einen gefälschten Access Point mit Ihrer SSID einrichten, den EAP-Handshake abfangen und die 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 für die gegenseitige 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 ist für die Einhaltung von PCI-DSS v4.0 (Anforderung 8.3 zu starker Authentifizierung) und den Datenschutzverpflichtungen der GDPR unerlässlich.

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 Bindeglied.

Google Secure LDAP ist der primäre Integrationspfad. Es ist in den Editionen Cloud Identity Premium und Google Workspace Enterprise verfügbar und bietet eine herkömmliche LDAP-Schnittstelle zu Ihrem Cloud-Verzeichnis. Ihr Cloud-RADIUS-Server verbindet sich über Port 636 unter Verwendung von Client-Zertifikaten, die Google für Sie generiert, mit ldap.google.com. Ab diesem Zeitpunkt fragt der RADIUS-Server das Verzeichnis von Google ab, um Anmeldedaten oder Gruppenmitgliedschaften zu validieren, genau wie er ein lokales Active Directory abfragen würde.

Ein alternativer Pfad nutzt eine SAML-basierte Integration, bei der sich der Cloud-RADIUS-Anbieter als SAML-Anwendung in der Google Admin Console registriert und zum Authentifizierungszeitpunkt einen 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ät, Geräteverwaltung 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äteverwaltunginfrastruktur 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 Console für die Verwaltung von Gerätezertifikaten konfiguriert ist.

Richten Sie Ihre Public Key Infrastructure (PKI) ein. Für neue Bereitstellungen wird eine Cloud-native PKI, die von Ihrem Cloud-RADIUS-Anbieter bereitgestellt wird, dringend empfohlen. Alternativen sind die Microsoft Cloud PKI (verfügbar mit der Intune Suite-Lizenzierung) oder eine bestehende On-Premises-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 ein vertrauenswürdiges Zertifikat. 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-Zertifikatsprofil. Für die benutzerbasierte Authentifizierung legen Sie den Subject Name auf CN={{UserPrincipalName}} fest. Für die gerätebasierte Authentifizierung verwenden Sie CN={{DeviceName}}. Konfigurieren Sie den Subject Alternative Name so, dass er den User Principal Name oder die Geräte-ID enthält.

Google Admin Console-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 die 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 Verzeichnis-Mandanten. Für Entra ID erfordert dies mindestens User.Read.All und GroupMember.Read.All über die Microsoft Graph API. Einige Anbieter erfordern auch 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 Console 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 erlauben, 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äre und sekundäre Server 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. Bei Bereitstellungen im Gastgewerbe stellen Sie sicher, dass sich die Unternehmens-SSID in einem separaten VLAN von jedem Gäste-WiFi -Netzwerk befindet. Erwägen Sie in Einzelhandelsumgebungen , die Unternehmens-SSID nur in internen Mitarbeiterbereichen (Back-of-House) bereitzustellen.

Phase 5: WiFi-Profil über MDM bereitstellen

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

Google Admin Console: Navigieren Sie zu „Geräte“, dann „Netzwerke“ und schließlich „WiFi“. 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ürdigste 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 bestens dokumentiert und der Migrationspfad ist mit modernen MDM-Tools unkompliziert.

Erzwingen Sie eine strenge Validierung des Serverzertifikats. 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 WiFi-Profil der Google Admin Console 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. Nutzen 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 in das richtige VLAN einordnet. Dies schränkt laterale Bewegungen im Falle einer Kompromittierung ein und unterstützt die Anforderungen an die PCI-DSS-Netzwerksegmentierung.

Trennen Sie die Authentifizierung für Unternehmens- und Gäste-Netzwerke. Verwenden Sie EAP-TLS für vom Unternehmen verwaltete Geräte. Verwenden Sie ein Captive Portal mit SSO für BYOD- und Gäste-Geräte. Der Versuch, EAP-TLS auf nicht verwalteten Geräten manuell zu konfigurieren, führt zu einem enormen Support-Overhead. Die Gäste-WiFi -Plattform von Purple übernimmt das Gäste-Onboarding separat und sorgt für eine saubere Trennung zwischen Mitarbeiter- und Besucherverkehr.

Überwachen Sie den Ablauf von Zertifikaten proaktiv. Richten Sie eine Überwachung und Alarmierung 90 Tage, 30 Tage und sieben Tage vor Ablauf des Zertifikats 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 Netzwerk-Laufzeitlatenz, die beim lokalen 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 üblich – führt zu sporadischen Authentifizierungsfehlern.

Fehlerbehebung und Risikominderung

Blockierte Firewall-Ports sind die Hauptursache für das Fehlschlagen der Erstbereitstellung. Die RADIUS-Authentifizierung erfordert den ausgehenden UDP-Port 1812 von Ihrer drahtlosen Infrastruktur zum Cloud-RADIUS-Dienst. RADIUS-Accounting erfordert den UDP-Port 1813. Überprüfen Sie, ob diese geöffnet sind, bevor Sie mit einer anderen Fehlerbehebung beginnen.

Fehler bei der Zertifikatsvalidierung äußern sich als Authentifizierungsablehnungen ohne offensichtliche Ursache. Überprüfen Sie Folgendes in dieser Reihenfolge: Ablauf des Zertifikats sowohl auf dem Client als auch auf dem RADIUS-Server; Zeitabweichung (Clock Skew) zwischen dem Client-Gerät und dem RADIUS-Server (EAP-TLS ist auf eine genaue Zeitmessung angewiesen); 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.

Eine nicht funktionierende VLAN-Zuweisung deutet in der Regel auf eine Diskrepanz zwischen den RADIUS-Attributwerten und den auf der drahtlosen Infrastruktur konfigurierten VLAN-IDs hin. Bestätigen Sie, dass Tunnel-Type auf VLAN (Wert 13), Tunnel-Medium-Type auf 802 (Wert 6) eingestellt ist und Tunnel-Private-Group-Id mit der auf dem Switch oder Controller konfigurierten VLAN-ID übereinstimmt.

Fehlgeschlagene EAP-TLS-Verbindungen bei BYOD-Geräten deuten meist darauf hin, dass das Client-Zertifikat nicht erfolgreich bereitgestellt wurde. Überprüfen Sie bei von Intune verwalteten Geräten den Zertifikatsspeicher des Geräts im Intune Admin Center. Überprüfen Sie bei von Google verwalteten Chromebooks, ob das Zertifikatsprofil der richtigen Organisationseinheit zugewiesen ist und ob sich das Gerät kürzlich synchronisiert hat.

ROI und geschäftliche Auswirkungen

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

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 ihm sofort den Netzwerkzugriff an allen Standorten. Es gibt keine Verzögerung, keinen manuellen Prozess und kein Risiko, dass ein ehemaliger Mitarbeiter weiterhin WiFi-Zugriff behält. Dies unterstützt direkt die GDPR-Verpflichtungen in Bezug auf Datenzugriffsrechte.

Umfangreicheren Analysen. Plattformen wie die 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.

Compliance-Nachweisen. Die EAP-TLS-Authentifizierung generiert detaillierte Zugriffsprotokolle – wer sich von 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 GDPR-Rechenschaftspflichten.

Konsistenz über mehrere Standorte hinweg. Ein einziger Cloud-RADIUS-Dienst authentifiziert alle Ihre Standorte mit konsistenten Richtlinien, die über ein einziges Dashboard verwaltet werden. Das Hinzufügen eines neuen Hotels, Geschäfts oder Veranstaltungsorts bedeutet lediglich, dessen Access Points zur RADIUS-Konfiguration hinzuzufügen – und nicht den Versand und die Konfiguration eines weiteren Servers. Für Unternehmen, die große Immobilienbestände verwalten, ist dies ein erheblicher betrieblicher Vorteil.

Für Transportunternehmen und Einrichtungen im Gesundheitswesen , bei denen die Netzwerk-Uhrzeit betriebskritisch ist, Cloud-RADIUS-Anbieter in der Regel SLAs mit 99,999 % Verfügbarkeit und integriertem Multi-Region-Failover bieten. Purple arbeitet mit einer Verfügbarkeit von 99,999 % an über 80.000 Live-Standorten, wobei im Jahr 2024 440 Millionen Logins verarbeitet wurden (interne Daten von Purple, 2024).

Für weitere Informationen zu verwandten Themen lesen Sie 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 zentrale Verwaltung von Authentifizierung, Autorisierung und Abrechnung (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 ist von einem RADIUS-Server abhängig. 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, das Patching, die Hochverfügbarkeit und die Integrationen von Identitätsanbietern. Sie konfigurieren die Authentifizierungsrichtlinien und verweisen mit Ihren Access Points auf die Cloud-RADIUS-IPs.

RADIUSaaS macht lokale NPS- oder FreeRADIUS-Server überflüssig und beseitigt den damit verbundenen Aufwand für Hardware, Betriebssystem-Patches und spezialisierte Wartung.

IEEE 802.1X

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

Der grundlegende Standard für die WiFi-Authentifizierung in Unternehmen. Sowohl WPA2-Enterprise als auch WPA3-Enterprise basieren 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 verwendet. 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. Eliminiert den Diebstahl von Anmeldedaten, Phishing und den passwortbezogenen Helpdesk-Overhead. 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 Enterprise-WiFi. Immer noch weit verbreitet, sollte jedoch bei allen neuen und bestehenden Bereitstellungen nach Möglichkeit auf EAP-TLS migriert 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 Conditional Access.

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 verwalter Dienst, der in den Editionen Cloud Identity Premium und Google Workspace Enterprise verfügbar ist und eine herkömmliche LDAP-Schnittstelle zum Cloud-Verzeichnis von Google bereitstellt. RADIUS-Server verbinden sich über Port 636 unter Verwendung von Client-Zertifikaten mit ldap.google.com.

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

PKI (Public Key Infrastructure)

Die Gesamtheit der Rollen, Richtlinien, Hardware, Software und Verfahren, die zum Erstellen, Verwalten, Verteilen, Verwenden, 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) machen lokale Active Directory Certificate Services (ADCS) überflüssig.

SCEP (Simple Certificate Enrollment Protocol)

Ein Protokoll, das es Geräten ermöglicht, digitale Zertifikate automatisch von einer Zertifizierungsstelle anzufordern und zu empfangen. Wird von Microsoft Intune und der Google Admin Console verwendet, um Client-Zertifikate ohne Benutzerinteraktion auf verwalteten Geräten bereitzustellen.

SCEP-Profile in Intune sind der Mechanismus, mit dem Unternehmensgeräte geräuschlos die für die EAP-TLS-Authentifizierung erforderlichen Client-Zertifikate erhalten.

Dynamische VLAN-Zuweisung

Eine RADIUS-Funktion, die basierend auf der Verzeichnis-Gruppenmitgliedschaft des authentifizierten Benutzers VLAN-Zuweisungsattribute (Tunnel-Type, Tunnel-Medium-Type, Tunnel-Private-Group-Id) an den Access Point zurückgibt. Der AP ordnet 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 Anforderungen an die PCI-DSS-Segmentierung unterstützt.

Ausgearbeitete Beispiele

Ein Hotel mit 200 Zimmern migriert sein internes Mitarbeiternetzwerk (Back-of-House) von einem veralteten lokalen NPS-Server auf eine Cloud-native Lösung. Das Hotel ist vor Kurzem auf Microsoft Entra ID und Microsoft 365 E5 umgestiegen. Bei den Mitarbeitergeräten handelt es sich um Windows-Laptops, die von Intune verwaltet werden. Die drahtlose Infrastruktur basiert auf Cisco Meraki. Das Hotel möchte, dass sich die Mitarbeiter automatisch und ohne Passworteingabe verbinden, und benötigt einen sofortigen Entzug des Zugriffs, 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 die Berechtigungen für die Microsoft Graph API (User.Read.All, GroupMember.Read.All, Device.Read.All) im Entra ID-Mandanten. Schritt 2: Erstellen Sie in Intune ein Profil für ein vertrauenswürdiges Zertifikat mit der Cloud-RADIUS-Root-CA und weisen Sie es der Gruppe „All Corporate Devices“ 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 [Trusted 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 das 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 „All Corporate Devices“ zu. Geräte erhalten das Zertifikat und das WiFi-Profil geräuschlos bei der nächsten Intune-Synchronisierung und verbinden sich automatisch. Wenn ein Mitarbeiter das Unternehmen verlässt, entzieht das Deaktivieren seines Entra ID-Kontos sofort den Netzwerkzugriff an allen Standorten.

Kommentar des Prüfers: Dieser Ansatz eliminiert die Abhängigkeit vom lokalen NPS vollständig. EAP-TLS beseitigt den Phishing-Vektor der anmeldedatenbasierten 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 entzogen wird, sobald die Personalabteilung ein Konto deaktiviert – es ist keine manuelle Aktualisierung der RADIUS-Richtlinie 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 Inventur- und Point-of-Sale-Aktivitäten genutzt werden. Derzeit verwenden sie einen gemeinsam genutzten 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 an jedem Filialstandort lokale Server bereitzustellen. Ihre drahtlose Infrastruktur basiert auf 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 Console zu „Apps“, dann „LDAP“ und fügen Sie einen neuen LDAP-Client für den Cloud-RADIUS-Dienst hinzu. Konfigurieren Sie Leseberechtigungen für Benutzerinformationen und Gruppenmitgliedschaften. Laden Sie das generierte 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 Console 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 Console ein WPA3-Enterprise-WiFi-Profil für die Filialbetriebs-SSID. Stellen Sie EAP-TLS ein, verknüpfen Sie die Root-CA und wenden das Profil auf die Organisationseinheit „Store-Associates“ an. Chromebooks erhalten das Zertifikat und das WiFi-Profil bei der nächsten Synchronisierung der Admin Console. Schritt 5: Konfigurieren Sie in HPE Aruba Central die Filialbetriebs-SSID mit WPA3-Enterprise und fügen Sie die primären und sekundären IPs von Cloud-RADIUS hinzu. Stellen Sie das 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 Organisationseinheit „Store-Associates“ sofort den Netzwerkzugriff.

Kommentar des Prüfers: Diese Bereitstellung eliminiert das Risiko eines gemeinsam genutzten PSK. Ein verlorenes 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 Anforderungen an die PCI-DSS-Netzwerksegmentierung für Einzelhandelsumgebungen unterstützt.

Übungsfragen

Q1. Ihr Unternehmen migriert von einem lokalen Active Directory zu Microsoft Entra ID. Sie verwenden derzeit PEAP-MSCHAPv2 für die WiFi-Authentifizierung auf 300 vom Unternehmen genutzten Laptops, die von Intune verwaltet werden. 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: Berücksichtigen Sie die Schwachstellen der anmeldedatenbasierten Authentifizierung, die Funktionen von Microsoft Intune für die Zertifikatsbereitstellung und die Notwendigkeit, Abhängigkeiten von lokaler Infrastruktur zu vermeiden.

Musterlösung anzeigen

Stellen Sie eine Cloud-RADIUS-Lösung mit Entra ID-Integration bereit. Verwenden Sie Microsoft Intune, um ein Profil für ein vertrauenswürdiges Zertifikat (Root-CA) und ein SCEP-Zertifikatsprofil auf den 300 Laptops bereitzustellen. Konfigurieren Sie die Cloud-RADIUS-Authentifizierungsrichtlinie so, dass ein gültiges Zertifikat der vertrauenswürdigen CA und die Mitgliedschaft in der Entra ID-Gruppe „Corporate-WiFi-Users“ erforderlich sind. Erstellen Sie in Intune ein WPA3-Enterprise-WiFi-Profil, das EAP-TLS angibt, und verknüpfen Sie das SCEP-Zertifikatsprofil. Geräte erhalten das Zertifikat und die WiFi-Konfiguration geräuschlos bei der nächsten Intune-Synchronisierung. Dies eliminiert das Risiko des Diebstahls von PEAP-MSCHAPv2-Anmeldedaten, entfernt die Abhängigkeit vom lokalen NPS und ermöglicht den sofortigen Entzug des Zugriffs, wenn ein Entra ID-Konto deaktiviert wird.

Q2. Ein Benutzer in Ihrem Hotel meldet, dass er nach der Rückkehr aus einem zweiwöchigen Urlaub keine Verbindung zum internen Mitarbeiter-WiFi (Back-of-House) herstellen kann. Andere Mitarbeiter können sich problemlos verbinden. Das Netzwerk verwendet EAP-TLS mit über Intune bereitgestellten Zertifikaten. Was sind die drei wahrscheinlichsten Ursachen, geordnet nach Wahrscheinlichkeit?

Hinweis: EAP-TLS basiert auf zeitkritischen kryptografischen Ressourcen und Verzeichnisabfragen in Echtzeit.

Musterlösung anzeigen

Das Client-Zertifikat des Benutzers ist abgelaufen. Zertifikate haben eine definierte Gültigkeitsdauer. Wenn das Gerät während des Verlängerungsfensters offline war, wurde es vom SCEP-Profil möglicherweise nicht verlängert. Überprüfen Sie das Ablaufdatum des Zertifikats im Intune-Gerätezertifikatsspeicher. 2. Die Systemzeit des Geräts ist erheblich asynchron (Clock Skew), was dazu führt, dass die Zertifikatsvalidierung fehlschlägt. EAP-TLS validiert Zertifikats-Zeitstempel; eine Abweichung von mehr als fünf Minuten führt zu Authentifizierungsfehlern. 3. Das Entra ID-Konto des Benutzers 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 seiner Gruppenmitgliedschaft überein. Überprüfen Sie die Gruppenmitgliedschaften des Benutzers in Entra ID im Abgleich mit der RADIUS-Richtlinie.

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

Hinweis: Berücksichtigen Sie, was bei Verlust oder Diebstahl eines Chromebooks unter dem jeweiligen Authentifizierungsmodell passiert.

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. Stellen Sie in der Google Admin Console die Root-CA und ein SCEP-Client-Zertifikatsprofil für die Organisationseinheit „Store-Associates“ bereit. Erstellen Sie ein WPA3-Enterprise-WiFi-Profil, das EAP-TLS angibt, und weisen Sie es derselben Organisationseinheit zu. Konfigurieren Sie die 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 „Store-Associates“ in der Google Admin Console sofort dessen Zertifikat und den Netzwerkzugriff, ohne Auswirkungen auf andere Geräte.

Q4. Während einer Cloud-RADIUS-Bereitstellung konfigurieren Sie die SSID auf Cisco Meraki Access Points und stellen das Intune-WiFi-Profil für eine Pilotgruppe von 20 Geräten bereit. 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 überprüfen Sie als Erstes?

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

Musterlösung anzeigen

Überprüfen Sie, ob die UDP-Ports 1812 und 1813 ausgehend 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 der Erstbereitstellung. Die Tatsache, dass Zertifikate und WiFi-Profile erfolgreich bereitgestellt wurden, schließt Intune-Konfigurationsprobleme aus. Die nächsten Schritte sind: Überprüfung auf eine Diskrepanz beim RADIUS Shared Secret zwischen Meraki und dem Cloud-RADIUS-Dienst; ein zu niedrig eingestelltes RADIUS-Timeout (auf mindestens 5 Sekunden erhöhen); und ob die Cloud-RADIUS-Server-IPs in der Meraki-SSID-Konfiguration korrekt eingegeben wurden.

Weiterlesen in dieser Reihe

Die Sicherheitsvorteile von RADIUS as a Service für hybride Belegschaften

Dieser technische Leitfaden erklärt, wie RADIUS as a Service den Netzwerkzugriff für hybride Belegschaften an verteilten Standorten sichert. Er behandelt die Architektur, die Sicherheitsvorteile und die Bereitstellungsschritte für den Ersatz von On-Premises-RADIUS-Infrastrukturen durch einen cloudverwalteten Authentifizierungsdienst. Für IT-Manager und Netzwerkarchitekten in Hotels, Einzelhandelsketten, Stadien und Organisationen des öffentlichen Sektors liefert dieser Leitfaden die notwendigen Argumente, um eine Migration zu Cloud-RADIUS in diesem Quartal zu bewerten und umzusetzen.

Wie Sie eine 802.1X-Authentifizierung mit Cloud RADIUS implementieren

Dieser technische Leitfaden bietet einen umfassenden Rahmen für die Implementierung der 802.1X-Authentifizierung mit Cloud RADIUS in verteilten Unternehmensstandorten. Er beschreibt die Architektur, die Auswahl der EAP-Methode, die Bereitstellungssequenzierung und die Strategien zur Risikominderung, die erforderlich sind, um den Netzwerkzugriff zu sichern und gleichzeitig den operativen Aufwand für eine On-Premises-Infrastruktur zu eliminieren.

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

Dieser umfassende Leitfaden befasst sich mit Cloud RADIUS (RADIUS-as-a-Service) und erläutert dessen Architektur, EAP-Methoden und Implementierungsstrategien. Er bietet IT-Entscheidern praxisnahe Einblicke für die Migration von lokalen Servern zu einem skalierbaren, sicheren und konformen cloudbasierten Authentifizierungsmodell.