Integrating RADIUS as a Service with Cloud Directories (Azure AD & Google Workspace)

Dieses technische Referenzhandbuch beschreibt detailliert, wie RADIUS as a Service in Cloud-Verzeichnisse – Microsoft Entra ID und Google Workspace – für die WiFi-Authentifizierung in Unternehmen integriert wird. Es behandelt den architektonischen Wandel von On-Premise-NPS zu Cloud-nativem RADIUS, die Bereitstellung der zertifikatsbasierten EAP-TLS-Authentifizierung sowie die bewährten Betriebspraktiken zur Absicherung des drahtlosen Zugangs in den Bereichen Hotellerie, 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

Welcome to the Purple Technical Briefing. Today, we are covering a topic that sits at the intersection of cloud identity management and physical network security: integrating RADIUS as a Service with cloud directories, specifically Microsoft Entra ID and Google Workspace.

If you are managing enterprise WiFi across a hotel, a retail estate, a stadium, or a public-sector estate, this briefing is directly relevant to your next infrastructure decision.

Let us start with context. For the past two decades, WiFi authentication in enterprise environments relied on a fairly predictable stack. You had on-premise Active Directory, Windows Network Policy Server acting as the RADIUS server, and WPA2-Enterprise on the access points. It worked. But it required on-premise servers, manual certificate management, and a team with specialist knowledge to keep it running.

The problem is that most organisations are no longer on-premise first. They are cloud-first. Microsoft Entra ID and Google Workspace are now the directories of record for millions of organisations. And here is the gap: your wireless access points still speak RADIUS. They do not understand SAML. They do not understand OAuth. They speak RADIUS, and they always will.

So the question is: how do you bridge your cloud identity platform to your physical network infrastructure, without dragging an on-premise server back into the picture?

The answer is RADIUS as a Service. A cloud-hosted RADIUS server that integrates directly with your cloud directory, validates authentication requests in real time, and returns an access decision to your access point. No on-premise servers. No patching. No 2am certificate renewal emergencies.

The foundation is IEEE 802.1X. When a device tries to connect to a WPA2-Enterprise or WPA3-Enterprise network, the access point acts as an authenticator. It intercepts the connection attempt and forwards EAP packets to the RADIUS server. The RADIUS server validates the identity and returns either an Access-Accept or an Access-Reject. Only then does the access point grant network access.

Now, the most consequential technical decision in this entire deployment is your choice of EAP method.

PEAP-MSCHAPv2 is the old way. It uses usernames and passwords. It sounds secure. It is not. If a device does not strictly validate the RADIUS server certificate, an attacker can set up a rogue access point with your SSID, intercept the handshake, and capture the credentials. This is called an Evil Twin attack, and it is happening.

EAP-TLS is the right answer. It uses digital certificates on both the server and the client device for mutual authentication. There are no passwords involved. The device presents its certificate. The RADIUS server validates it against your cloud directory in real time. No credential theft possible. No phishing vector. No helpdesk tickets when someone changes their password.

Let us walk through a Microsoft Entra ID deployment.

Step one: licensing and PKI. You need Microsoft 365 E3 or E5 to access Intune and Conditional Access. Establish a cloud PKI using your Cloud RADIUS vendor's managed PKI or Microsoft's own Cloud PKI.

Step two: certificate deployment via Intune. Create a Trusted Certificate profile with your Root CA and deploy it to device groups. Then create a SCEP certificate profile. For user-based authentication, the subject name uses the User Principal Name.

Step three: Cloud RADIUS configuration. Grant the RADIUS service Microsoft Graph API permissions: User.Read.All and GroupMember.Read.All. Define your authentication policies: allow access if the certificate is issued by our trusted CA, the user is a member of the Corporate-WiFi-Users group in Entra ID, and the device is marked compliant in Intune.

Step four: wireless infrastructure. In your controller, whether that is Cisco Meraki, HPE Aruba, Ruckus, or Juniper Mist, add the Cloud RADIUS IP addresses and shared secrets. Set the RADIUS timeout to at least five seconds. Create your WPA3-Enterprise SSID.

Step five: WiFi profile deployment. Create a WiFi configuration profile in Intune. Set the SSID, select WPA3-Enterprise, choose EAP-TLS, link the SCEP certificate profile. Devices silently receive the certificate and WiFi profile on their next sync. They connect automatically. No user interaction required.

Now let us look at the Google Workspace path, because it is architecturally different in one important way.

Google does not offer a native RADIUS service. There is no Google equivalent of Windows NPS. So you always need an intermediary: a Cloud RADIUS provider that connects to Google Workspace via Google Secure LDAP or via a SAML and OAuth integration.

Google Secure LDAP is available on Cloud Identity Premium and Google Workspace Enterprise editions. It provides a traditional LDAP interface to your cloud directory. Your Cloud RADIUS server connects to ldap.google.com on port 636 using client certificates that Google generates for you. From that point, the RADIUS server can query Google's directory to validate credentials or group memberships.

For managed Chromebooks, the deployment path uses the Google Admin Console. You configure a cloud PKI to issue certificates, push the Root CA and client certificates to the Chromebooks, and deploy a WiFi profile specifying EAP-TLS. The Chromebooks connect silently. For BYOD devices and guest access, you use a captive portal tied to Google Single Sign-On. That is the right separation: EAP-TLS for managed devices, captive portal for everything else.

Let us talk about pitfalls, because this is where deployments go wrong.

The first and most common is blocked firewall ports. RADIUS authentication uses UDP port 1812. RADIUS accounting uses UDP port 1813. If those ports are not open outbound from your wireless infrastructure to the Cloud RADIUS service, nothing works. Check this first, every time.

The second pitfall is certificate expiry. If your RADIUS server certificate expires, every device on the network loses connectivity simultaneously. Set monitoring alerts at 90 days, 30 days, and 7 days before expiry. Automate renewal where possible.

The third is clock skew. EAP-TLS relies on accurate timekeeping for certificate validation. If a device's system clock is significantly out of sync, certificate validation fails. Ensure NTP is configured correctly across all devices and infrastructure.

The fourth, specific to PEAP deployments, is failing to enforce strict server certificate validation on client devices. Without it, devices will accept any certificate presented by any access point claiming to be yours. This is the single configuration decision that separates a secure deployment from a vulnerable one.

Now for a rapid-fire question and answer.

Can I use Cloud RADIUS for both staff and guest WiFi? Staff WiFi, yes, using EAP-TLS. Guest WiFi should use a separate captive portal. Mixing the two on a single SSID creates unnecessary complexity and security risk.

Does this work with WPA3? Yes. WPA3-Enterprise is fully supported and recommended for all new deployments.

What about compliance? EAP-TLS with Cloud RADIUS supports PCI DSS requirements for strong authentication on cardholder data networks. It also supports GDPR obligations by enabling precise access logging and instant revocation when an employee leaves.

How does this affect our analytics capabilities? Positively. By tying network access to a verified cloud identity, platforms like Purple's WiFi Analytics provide richer data on space utilisation. You move from anonymous MAC addresses to authenticated, named users, which transforms the quality of your insight.

To summarise the key takeaways.

One: Cloud RADIUS eliminates on-premise server dependencies. Your access points authenticate against a cloud-hosted service that integrates directly with Entra ID or Google Workspace.

Two: EAP-TLS is the right authentication method. Certificates replace passwords. No phishing vector, no credential theft, no helpdesk overhead from password resets.

Three: Microsoft Intune and Google Admin Console automate certificate deployment. Devices receive certificates and WiFi profiles silently, with no user interaction.

Four: Dynamic VLAN assignment via RADIUS attributes enables granular network segmentation based on directory group membership. This limits lateral movement and supports compliance.

Five: Always verify ports 1812 and 1813 are open, monitor certificate expiry, and enforce strict server certificate validation.

If you are planning a deployment this quarter, start with a pilot group of 20 to 50 devices. Validate the certificate deployment, the RADIUS authentication, and the VLAN assignment before rolling out globally. The investment in getting this right pays dividends in reduced helpdesk overhead, a stronger security posture, and the ability to use your network data for genuine business intelligence.

Thank you for listening to the Purple Technical Briefing. For detailed deployment steps, configuration examples, and worked scenarios, see the full technical reference guide at purple.ai.

Wichtigste Erkenntnisse

✓Cloud RADIUS eliminates on-premise NPS and FreeRADIUS servers. Your access points authenticate against a cloud-hosted service that integrates directly with Microsoft Entra ID or Google Workspace.
✓EAP-TLS is the correct authentication method for enterprise WiFi. It uses digital certificates instead of passwords, eliminating credential theft, phishing, and password-related helpdesk overhead.
✓Microsoft Intune and Google Admin Console automate certificate deployment to managed devices via SCEP profiles. Devices receive certificates and WiFi profiles silently, with no user interaction.
✓Google Workspace requires an intermediary for RADIUS integration. Google Secure LDAP (available on Cloud Identity Premium and Enterprise editions) provides the LDAP interface that Cloud RADIUS servers use to query the Google directory.
✓Dynamic VLAN assignment via RADIUS attributes (Tunnel-Type, Tunnel-Medium-Type, Tunnel-Private-Group-Id) enables granular network segmentation based on directory group membership, supporting PCI DSS requirements.
✓Check UDP ports 1812 and 1813 first. Blocked firewall ports are the leading cause of initial deployment failure. Monitor certificate expiry at 90, 30, and 7 days. Enforce strict server certificate validation on all PEAP deployments.
✓Disabling a user in Entra ID or Google Workspace immediately revokes their WiFi access at all sites. This is the primary offboarding advantage over PSK-based networks and directly supports GDPR obligations.

Management-Summary

Für moderne Unternehmen, die in Cloud-Identitäts-Ökosysteme investiert haben, ist die Verknüpfung von Cloud-Verzeichnissen mit physischen drahtlosen Netzwerken ein kritisches Sicherheitserfordernis. In der Vergangenheit basierte die WiFi-Authentifizierung auf On-Premise 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-Premise-Authentifizierungs-Stack zu einem Risiko – kostspielig in der Wartung, schwer zu skalieren und inkompatibel mit Zero-Trust-Sicherheitsmodellen.

RADIUS as a Service (RADIUSaaS) ändert die 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 – ohne On-Premise-Server, ohne Patch-Zyklen und ohne Single Point of Failure. In Kombination mit der zertifikatsbasierten 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 On-Premise-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, Einzelhandelsgeschäften, Stadien und Veranstaltungsorten des öffentlichen Sektors. Für eine umfassendere Einführung in die Netzwerkzugriffskontrolle siehe Ein Leitfaden für Ihr Netzwerkzugriffskontrollsystem .

Technische Vertiefung: Architektur und Standards

Die Rolle von RADIUS und IEEE 802.1X

Die Grundlage für sicheres WiFi in Unternehmen ist der Standard IEEE 802.1X, der eine portbasierte Netzwerkzugriffskontrolle bietet. Wenn ein Client-Gerät (der Supplicant) versucht, eine Verbindung mit einem WPA2-Enterprise- oder WPA3-Enterprise-Netzwerk herzustellen, der Wireless Access Point (der Authenticator) blockiert 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-Meldung 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 On-Premise-NPS- oder FreeRADIUS-Server überflüssig. Ein Cloud-RADIUS-Drittanbieter lässt sich über die Microsoft Graph API direkt in Microsoft Entra ID oder über Google Secure LDAP oder SAML/OAuth in Google Workspace integrieren. 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-Premise (NPS)	Cloud-native (RADIUSaaS)
Infrastruktur	Windows Server-VM oder Bare-Metal erforderlich	Keine On-Premise-Server
Identitätsquelle	AD DS über LDAP/Kerberos	Entra ID oder Google Workspace über API
Zertifizierungsstelle	ADCS On-Premise + 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 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 folgenschwerste Sicherheitsentscheidung bei dieser Bereitstellung. PEAP-MSCHAPv2 basiert darauf, dass Benutzer ihre Domänen-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 strikt validiert – was viele standardmäßig nicht tun –, kann ein Angreifer einen gefälschten Access Point mit Ihrer SSID einrichten, den EAP-Handshake abfangen und Anmeldedaten erfassen. Dies ist ein sogenannter Evil-Twin-Angriff und 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 zur starken Authentifizierung) und den GDPR-Datenschutzverpflichtungen 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 eine Zwischeninstanz.

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 mit ldap.google.com unter Verwendung von Client-Zertifikaten, die Google generates für Sie. Von diesem Punkt an fragt der RADIUS-Server das Verzeichnis von Google ab, um Anmeldedaten oder Gruppenmitgliedschaften zu validieren, genau wie er ein lokales (On-Premise) 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 Konsole registriert und zum Zeitpunkt der Authentifizierung 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ä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 Microsoft 365 E3/E5- oder Enterprise Mobility + Security (EMS) E3/E5-Lizenzierung 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 für die Verwaltung von Gerätezertifikaten konfiguriert ist.

Richten Sie Ihre Public-Key-Infrastruktur (PKI) ein. Für neue Bereitstellungen wird eine Cloud-native PKI Ihres Cloud-RADIUS-Anbieters dringend empfohlen. Alternativen sind die Microsoft Cloud-PKI (verfügbar mit der 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 ein vertrauenswürdiges Zertifikat (Trusted Certificate). 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 Konsolen-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 benötigen 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 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 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 (Compliant) markiert ist.“ Dies erzwingt gleichzeitig Identität, Gruppenmitgliedschaft und Gerätestatus.

Phase 4: Drahtlose Infrastruktur konfigurieren

In Ihrem Wireless-LAN-Controller oder Cloud-Management-Dashboard – Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme oder Fortinet – fügen Sie 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-Roundtrip-Latenz auszugleichen.

Erstellen Sie eine neue SSID, die für WPA2-Enterprise oder WPA3-Enterprise konfiguriert ist. Stellen Sie bei Bereitstellungen im Bereich Hospitality (Gastgewerbe) sicher, dass sich die Unternehmens-SSID in einem separaten VLAN von jedem Guest WiFi -Netzwerk befindet. Erwägen Sie für Retail -Umgebungen (Einzelhandel), die Unternehmens-SSID nur in Back-of-House-Bereichen 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 aus. 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 die Zertifikatsprofile erhalten haben. Geräte erhalten das Zertifikat und die WiFi-Konfiguration geräuschlos bei ihrer nächsten Intune-Synchronisierung.

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

Erzwingen Sie eine strenge Serverzertifikatsvalidierung. 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 Konsole 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 überprüfen und ihn dynamisch verschiedenen VLANs zuzuweisen. Der RADIUS-Server gibt das Tunnel-Private-Group-Id-Attribut an den Access Point, wodurch der Client im richtigen VLAN platziert wird. Dies schränkt laterale Bewegungen im Falle einer Kompromittierung ein und unterstützt die Anforderungen zur PCI-DSS-Netzwerksegmentierung.

Trennen Sie die Authentifizierung von Unternehmens- und Gastgeräten. 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 auf nicht verwalteten Geräten manuell zu konfigurieren, führt zu einem übermäßigen 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 Zertifikatsablauf proaktiv. Richten Sie Überwachung und Alarmierung 90 Tage, 30 Tage und sieben Tage vor dem Ablauf des Zertifikats ein. Wenn das Zertifikat Ihres RADIUS-Servers abläuft, verlieren alle Geräte gleichzeitig die Verbindung. Automatisieren Sie die Erneuerung, sofern Ihre PKI dies unterstützt.

Testen Sie die RADIUS-Timeout-Einstellungen. Cloud RADIUS führt zu einer Netzwerk-Latenzzeit (Round-Trip), die bei lokalen NPS-Servern nicht auftritt. Stellen Sie das RADIUS-Timeout an Ihren Access Points auf mindestens fünf Sekunden ein. Ein Timeout von zwei Sekunden – was in Standardkonfigurationen üblich ist – führt zu sporadischen Authentifizierungsfehlern.

Fehlerbehebung und Risikominderung

Blockierte Firewall-Ports sind die Hauptursache für das Scheitern der Erstimplementierung. Die RADIUS-Authentifizierung erfordert den UDP-Port 1812 ausgehend von Ihrer Wireless-Infrastruktur zum Cloud RADIUS-Dienst. Das 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 Zertifikatsvalidierung äußern sich als Ablehnungen der Authentifizierung ohne offensichtliche Ursache. Überprüfen Sie Folgendes in dieser Reihenfolge: Ablauf des Zertifikats sowohl auf dem Client als auch auf dem RADIUS-Server; Zeitabweichung 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 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 hat.

Eine nicht funktionierende VLAN-Zuweisung deutet in der Regel auf eine Diskrepanz zwischen den RADIUS-Attributwerten und den auf der Wireless-Infrastruktur konfigurierten VLAN-IDs hin. Bestätigen Sie, dass Tunnel-Type auf VLAN (Wert 13) eingestellt ist, 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.

Fehlgeschlagenes EAP-TLS bei BYOD-Geräten deutet in der Regel 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 das Gerät kürzlich synchronisiert wurde.

ROI und geschäftliche Auswirkungen

Der Wechsel zu Cloud RADIUS bringt messbare betriebliche Einsparungen. Lokales RADIUS erfordert mindestens zwei Server für Hochverfügbarkeit, fortlaufendes Betriebssystem-Patching, Zertifikatsmanagement und die Zeit 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 eines Cloud RADIUS-Abonnements.

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

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

Umfangreichere Analysen. Plattformen wie die WiFi Analytics von Purple bieten 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 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) und 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 Betreiber im Bereich Transport und Einrichtungen im Gesundheitswesen -Sektor, bei denen die Netzwerkverfügbarkeit betriebskritisch ist, 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 Live-Standorten, wobei im Jahr 2024 440 Millionen Logins verarbeitet wurden (interne Daten von Purple, 2024).

Weitere Informationen zu verwandten Themen finden Sie unter 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)

A networking protocol defined in RFC 2865 that provides centralised Authentication, Authorisation, and Accounting (AAA) management for users connecting to a network service. The RADIUS server acts as the decision engine between your access points and your identity directory.

Every enterprise WPA2-Enterprise or WPA3-Enterprise WiFi network depends on a RADIUS server. Without it, IEEE 802.1X authentication does not function.

RADIUS as a Service (RADIUSaaS)

A cloud-hosted RADIUS implementation delivered as a managed service. The provider maintains the infrastructure, patching, high availability, and identity provider integrations. You configure authentication policies and point your access points to the cloud RADIUS IPs.

RADIUSaaS eliminates the need for on-premise NPS or FreeRADIUS servers, removing the associated hardware, OS patching, and specialist maintenance overhead.

IEEE 802.1X

An IEEE standard for port-based Network Access Control. It defines the three-party authentication model: the supplicant (client device), the authenticator (access point or switch), and the authentication server (RADIUS server). The authenticator blocks all traffic until the RADIUS server grants access.

The foundational standard for enterprise WiFi authentication. WPA2-Enterprise and WPA3-Enterprise both rely on 802.1X.

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

An authentication method defined in RFC 5216 that uses digital certificates on both the RADIUS server and the client device for mutual authentication. Neither party sends a password. The client presents its certificate; the server validates it against the directory in real time.

The gold standard for enterprise WiFi security. Eliminates credential theft, phishing, and password-related helpdesk overhead. Required for PCI DSS compliance on cardholder data networks.

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

An authentication method that creates an encrypted TLS tunnel and then sends the user's username and password through it. Vulnerable to Evil Twin attacks if the client does not strictly validate the RADIUS server certificate.

The legacy default for enterprise WiFi. Still widely deployed but should be migrated to EAP-TLS in all new and existing deployments where possible.

Microsoft Entra ID

Microsoft's cloud-based identity and access management service, formerly known as Azure Active Directory (Azure AD). Manages user identities, group memberships, device compliance, and Conditional Access policies.

The primary identity source for Cloud RADIUS in Microsoft-centric environments. Cloud RADIUS providers connect to Entra ID via Microsoft Graph API.

Google Secure LDAP

A managed service available on Cloud Identity Premium and Google Workspace Enterprise editions that provides a traditional LDAP interface to Google's cloud directory. RADIUS servers connect to ldap.google.com on port 636 using client certificates.

The primary integration path for connecting a Cloud RADIUS server to Google Workspace. Google does not offer a native RADIUS service, so Secure LDAP acts as the bridge.

PKI (Public Key Infrastructure)

The set of roles, policies, hardware, software, and procedures needed to create, manage, distribute, use, store, and revoke digital certificates. A PKI is required to issue the client and server certificates used in EAP-TLS authentication.

Cloud-native PKI options from RADIUS vendors or Microsoft (Cloud PKI) eliminate the need for on-premise Active Directory Certificate Services (ADCS).

SCEP (Simple Certificate Enrollment Protocol)

A protocol that enables devices to request and receive digital certificates from a Certificate Authority automatically. Used by Microsoft Intune and Google Admin Console to deploy client certificates to managed devices without user interaction.

SCEP profiles in Intune are the mechanism by which corporate devices silently receive the client certificates needed for EAP-TLS authentication.

Dynamic VLAN assignment

A RADIUS feature that returns VLAN assignment attributes (Tunnel-Type, Tunnel-Medium-Type, Tunnel-Private-Group-Id) to the access point based on the authenticated user's directory group membership. The AP places the client on the specified VLAN automatically.

Enables granular network segmentation without manual VLAN configuration per device. Staff in different roles or departments land on different network segments, limiting lateral movement and supporting PCI DSS segmentation requirements.

Ausgearbeitete Beispiele

A 200-room hotel is migrating its back-of-house staff network from an ageing on-premise NPS server to a cloud-native solution. The hotel has recently moved to Microsoft Entra ID and Microsoft 365 E5. Staff devices are Windows laptops managed by Intune. The wireless infrastructure is Cisco Meraki. The hotel needs staff to connect automatically without password prompts, and needs instant revocation when a member of staff leaves.

Deploy a Cloud RADIUS solution with Entra ID integration. Step 1: grant the Cloud RADIUS provider Microsoft Graph API permissions (User.Read.All, GroupMember.Read.All, Device.Read.All) in the Entra ID tenant. Step 2: in Intune, create a Trusted Certificate profile with the Cloud RADIUS Root CA and deploy it to the 'All Corporate Devices' group. Step 3: create a SCEP Certificate profile with Subject Name CN={{UserPrincipalName}} and deploy it to the same group. Step 4: configure the Cloud RADIUS authentication policy: allow access if certificate is issued by [Trusted CA] AND user is member of [Hotel-Staff-WiFi] Entra ID group AND device is Intune-compliant. Step 5: in Cisco Meraki dashboard, add the Cloud RADIUS primary and secondary IPs as RADIUS servers on the back-of-house SSID. Set RADIUS timeout to 5 seconds. Step 6: in Intune, create a WPA3-Enterprise WiFi profile for the back-of-house SSID, specifying EAP-TLS and linking the SCEP certificate profile. Deploy to the 'All Corporate Devices' group. Devices silently receive the certificate and WiFi profile on next Intune sync and connect automatically. When a staff member leaves, disabling their Entra ID account immediately revokes network access at all sites.

Kommentar des Prüfers: This approach eliminates the on-premise NPS dependency entirely. EAP-TLS removes the phishing vector of credential-based authentication. Intune automates certificate lifecycle management, removing the manual overhead that caused the previous NPS deployment to fall behind on certificate renewals. The Entra ID group policy means that when HR disables an account, network access is revoked in real time - no manual RADIUS policy update required. The Cisco Meraki integration is straightforward: Cloud RADIUS is hardware-agnostic and works with any 802.1X-capable infrastructure.

A retail chain with 50 stores uses Google Workspace and manages a fleet of 500 Chromebooks used by store associates for inventory and point-of-sale operations. They currently use a shared WPA2 PSK for the store operations network, which creates a security risk when devices are lost or stolen. They want to move to 802.1X authentication without deploying local servers at each store. Their wireless infrastructure is HPE Aruba.

Deploy a Cloud RADIUS solution with Google Workspace integration via Google Secure LDAP. Step 1: in Google Admin Console, navigate to Apps, then LDAP, and add a new LDAP client for the Cloud RADIUS service. Configure read permissions for user information and group membership. Download the generated client certificate and key. Step 2: configure the Cloud RADIUS service with the Google Secure LDAP credentials. Step 3: configure a cloud PKI to issue certificates to the Chromebooks. In Google Admin Console, navigate to Devices, then Networks, then Certificates, and upload the Root CA. Configure the certificate issuance profile and apply it to the Store-Associates Organisational Unit. Step 4: in Google Admin Console, create a WPA3-Enterprise WiFi profile for the store operations SSID. Set EAP-TLS, link the Root CA, and apply to the Store-Associates OU. Chromebooks receive the certificate and WiFi profile on next Admin Console sync. Step 5: in HPE Aruba Central, configure the store operations SSID with WPA3-Enterprise and add the Cloud RADIUS primary and secondary IPs. Set RADIUS timeout to 5 seconds. Configure dynamic VLAN assignment to place store associates on VLAN 20 (store operations) based on their Google Workspace group membership. When a Chromebook is lost or stolen, removing it from the Store-Associates OU immediately revokes its network access.

Kommentar des Prüfers: This deployment eliminates the shared PSK risk. A lost or stolen Chromebook with a shared PSK gives an attacker persistent network access until the PSK is rotated across all 50 stores. With EAP-TLS, the certificate on the lost device can be revoked immediately. The Google Secure LDAP integration is the correct path for Google Workspace environments - it provides a stable, standards-based interface that the Cloud RADIUS service can query without requiring a custom API integration. Dynamic VLAN assignment ensures store associates land on the correct network segment, supporting PCI DSS network segmentation requirements for retail environments.

Übungsfragen

Q1. Your organisation is migrating from on-premise Active Directory to Microsoft Entra ID. You currently use PEAP-MSCHAPv2 for WiFi authentication on 300 corporate laptops managed by Intune. You have Microsoft 365 E5 licensing. What is the most secure and operationally efficient path to migrate WiFi authentication to a cloud-native architecture?

Hinweis: Consider the vulnerabilities of credential-based authentication, the capabilities of Microsoft Intune for certificate deployment, and the need to avoid on-premise infrastructure dependencies.

Musterlösung anzeigen

Deploy a Cloud RADIUS solution with Entra ID integration. Use Microsoft Intune to deploy a Trusted Certificate profile (Root CA) and a SCEP Certificate profile to the 300 laptops. Configure the Cloud RADIUS authentication policy to require a valid certificate from the trusted CA and membership of the Corporate-WiFi-Users Entra ID group. Create a WPA3-Enterprise WiFi profile in Intune specifying EAP-TLS and link the SCEP certificate profile. Devices silently receive the certificate and WiFi configuration on next Intune sync. This eliminates PEAP-MSCHAPv2 credential theft risk, removes the on-premise NPS dependency, and provides instant revocation when an Entra ID account is disabled.

Q2. A user at your hotel reports they cannot connect to the back-of-house staff WiFi after returning from a two-week holiday. Other staff are connecting without issue. The network uses EAP-TLS with certificates deployed via Intune. What are the three most likely causes, in order of likelihood?

Hinweis: EAP-TLS relies on time-sensitive cryptographic assets and real-time directory lookups.

Musterlösung anzeigen

The user's client certificate has expired. Certificates have a defined validity period, and if the device was offline during the renewal window, the SCEP profile may not have renewed it. Check the certificate expiry date in the Intune device certificate store. 2. The device's system clock is significantly out of sync (clock skew), causing certificate validation to fail. EAP-TLS validates certificate timestamps; a clock more than five minutes out of sync will cause authentication failures. 3. The user's Entra ID account was placed in a different group during their absence (for example, moved from active staff to a different OU), and the RADIUS authentication policy no longer matches their group membership. Check the user's group memberships in Entra ID against the RADIUS policy.

Q3. You are the IT manager for a retail chain with 80 stores. You use Google Workspace and manage 400 Chromebooks via Google Admin Console. You want to replace the current shared WPA2 PSK on the store operations network with 802.1X authentication. You have no on-premise servers at any store location. What architecture do you deploy, and what is the primary security benefit over the current PSK approach?

Hinweis: Consider what happens when a Chromebook is lost or stolen under each authentication model.

Musterlösung anzeigen

Deploy a Cloud RADIUS service with Google Secure LDAP integration. Configure a cloud PKI to issue certificates to the Chromebooks. In Google Admin Console, deploy the Root CA and a SCEP client certificate profile to the Store-Associates Organisational Unit. Create a WPA3-Enterprise WiFi profile specifying EAP-TLS and deploy it to the same OU. Configure HPE Aruba (or equivalent) access points at each store to point to the Cloud RADIUS service. The primary security benefit: under the current shared PSK, a lost or stolen Chromebook retains WiFi access until the PSK is rotated across all 80 stores - a disruptive, time-consuming process. With EAP-TLS, removing the device from the Store-Associates OU in Google Admin Console immediately revokes its certificate and network access, with no impact on any other device.

Q4. During a Cloud RADIUS deployment, you configure the SSID on Cisco Meraki access points and deploy the Intune WiFi profile to a pilot group of 20 devices. None of the devices can connect. The Intune device status shows the certificate and WiFi profile as successfully deployed. What is the first thing you check?

Hinweis: The most common cause of initial deployment failure is not a configuration error in the RADIUS policy or the certificate.

Musterlösung anzeigen

Check that UDP ports 1812 and 1813 are open outbound from the Cisco Meraki access points (or the Meraki cloud infrastructure) to the Cloud RADIUS server IP addresses. Blocked firewall ports are the leading cause of initial deployment failure. The fact that certificates and WiFi profiles are successfully deployed rules out Intune configuration issues. The next checks are: RADIUS shared secret mismatch between Meraki and the Cloud RADIUS service; RADIUS timeout set too low (increase to at least 5 seconds); and whether the Cloud RADIUS server IPs are correctly entered in the Meraki SSID configuration.

Weiterlesen in dieser Reihe

The Security Benefits of RADIUS as a Service for Hybrid Workforces

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-Premise-RADIUS-Infrastrukturen durch einen cloudbasierten 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.

How to Implement 802.1X Authentication with Cloud RADIUS

Dieser technische Leitfaden bietet einen umfassenden Rahmen für die Implementierung der 802.1X-Authentifizierung mit Cloud RADIUS in verteilten Unternehmensumgebungen. 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 der lokalen Infrastruktur zu eliminieren.

What is Cloud RADIUS? A Comprehensive Guide to RADIUS as a Service

Dieser umfassende Leitfaden beleuchtet Cloud RADIUS (RADIUS as a Service) und beschreibt dessen Architektur, EAP-Methoden und Implementierungsstrategien. Er bietet IT-Führungskräften umsetzbare Einblicke in die Migration von lokalen Servern zu einem skalierbaren, sicheren und konformen Cloud-basierten Authentifizierungsmodell.