將 RADIUS as a Service 與雲端目錄（Azure AD 和 Google Workspace）整合

Executive summary

For modern enterprises invested in cloud identity ecosystems, bridging cloud directories with physical wireless networks is a critical security imperative. Historically, WiFi authentication relied on on-premise Active Directory Domain Services and Windows Network Policy Server (NPS). As organisations migrate to Microsoft Entra ID and Google Workspace, that on-premise authentication stack becomes a liability - costly to maintain, difficult to scale, and incompatible with zero-trust security models.

RADIUS as a Service (RADIUSaaS) changes the equation. A cloud-hosted RADIUS server integrates directly with your cloud directory, validates authentication requests in real time, and returns access decisions to your access points - with no on-premise servers, no patching cycles, and no single point of failure. Combined with EAP-TLS certificate-based authentication, this architecture eliminates credential theft, supports PCI DSS and GDPR compliance, and delivers a seamless experience for staff across every site.

This guide covers the architectural decision between on-premise NPS and cloud-native RADIUS, the deployment of EAP-TLS via Microsoft Intune and Google Admin Console, and the operational best practices for securing wireless access across hotels, retail estates, stadiums, and public-sector venues. For a broader introduction to network access control, see A Guide to Your Network Access Control System .

Technical deep-dive: architecture and standards

The role of RADIUS and IEEE 802.1X

The foundation of secure enterprise WiFi is the IEEE 802.1X standard, which provides port-based network access control. When a client device (the supplicant) attempts to connect to a WPA2-Enterprise or WPA3-Enterprise network, the Wireless Access Point (the authenticator) blocks all traffic except EAP (Extensible Authentication Protocol) packets. The AP forwards these packets to a RADIUS server. The RADIUS server validates the identity against a directory service and returns an Access-Accept or Access-Reject message. Only then does the AP grant network access.

This three-party model - supplicant, authenticator, authentication server - is the cornerstone of enterprise wireless security and is defined in IEEE 802.1X. It has not fundamentally changed since its introduction. What has changed is where the RADIUS server lives and how it communicates with your directory.

Cloud-native RADIUS architecture

A cloud-native RADIUS architecture eliminates the need for on-premise NPS or FreeRADIUS servers. A third-party Cloud RADIUS provider integrates directly with Microsoft Entra ID via Microsoft Graph API, or with Google Workspace via Google Secure LDAP or SAML/OAuth. Authentication happens entirely in the cloud. This aligns with zero-trust network access principles and significantly reduces operational overhead.

The table below compares the two primary architectural approaches:

EAP-TLS vs. PEAP-MSCHAPv2: the critical choice

The choice of EAP method is the single most consequential security decision in this deployment. PEAP-MSCHAPv2 relies on users entering their domain credentials. This is vulnerable to credential theft and man-in-the-middle attacks. If a client device does not strictly validate the RADIUS server certificate - and many do not by default - an attacker can deploy a rogue access point with your SSID, intercept the EAP handshake, and capture credentials. This is an Evil Twin attack, and it is well-documented.

EAP-TLS (Transport Layer Security) uses digital certificates installed on the client device for mutual authentication. Both the client and the server prove their identity cryptographically. There are no passwords to type or steal. In a Microsoft environment, certificates deploy silently via Microsoft Intune using SCEP (Simple Certificate Enrollment Protocol) or PKCS profiles. This is the recommended path for all new deployments and is essential for compliance with PCI DSS v4.0 (Requirement 8.3 on strong authentication) and GDPR data protection obligations.

Google Workspace: the architectural difference

Microsoft Entra ID and Google Workspace differ in one important way for RADIUS integration. Microsoft NPS integrates natively with Active Directory, and Cloud RADIUS providers connect to Entra ID via Microsoft Graph API. Google, however, does not offer a native RADIUS service. You always need an intermediary.

Google Secure LDAP is the primary integration path. 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 queries Google's directory to validate credentials or group memberships, just as it would query an on-premise Active Directory.

An alternative path uses SAML-based integration, where the Cloud RADIUS provider registers as a SAML application in Google Admin Console and performs an OAuth lookup at authentication time to verify the user's identity and group memberships in real time.

Implementation guide

Implementing RADIUSaaS with EAP-TLS requires coordinating identity, device management, and network infrastructure. The following five-phase approach applies to both Microsoft Entra ID and Google Workspace environments.

Phase 1: prepare identity and device management infrastructure

For Microsoft Entra ID: verify that your tenant has Microsoft 365 E3/E5 or Enterprise Mobility + Security (EMS) E3/E5 licensing. This includes Microsoft Intune and Conditional Access. Without Intune, automated certificate deployment is not possible.

For Google Workspace: confirm you have Cloud Identity Premium or Google Workspace Enterprise to access Google Secure LDAP. If you plan to use EAP-TLS on managed Chromebooks, ensure the Google Admin Console is configured to manage device certificates.

Establish your Public Key Infrastructure (PKI). For new deployments, a cloud-native PKI provided by your Cloud RADIUS vendor is strongly recommended. Alternatives include Microsoft Cloud PKI (available with Intune Suite licensing) or an existing on-premise ADCS deployment connected via the Microsoft Intune Certificate Connector.

Phase 2: configure certificate deployment

Microsoft Intune path: in the Intune admin centre, create a Trusted Certificate configuration profile. Upload the Root CA certificate and deploy it to your target device groups. This ensures client devices trust the certificate presented by the RADIUS server during the TLS handshake. Next, create a SCEP Certificate profile. For user-based authentication, set the Subject Name to CN={{UserPrincipalName}}. For device-based authentication, use CN={{DeviceName}}. Set the Subject Alternative Name to include the User Principal Name or device ID.

Google Admin Console path: navigate to Devices, then Networks, then Certificates. Upload your Root CA. Configure a certificate issuance mechanism - either a cloud PKI that supports SCEP integration with Google Workspace, or the Google Cloud Certificate Connector which proxies requests to an on-premise Microsoft Certificate Authority. Deploy the Root CA and client certificate profiles to the appropriate Organisational Units.

Phase 3: configure Cloud RADIUS integration

Grant your Cloud RADIUS provider the necessary API permissions in your directory tenant. For Entra ID, this requires at minimum User.Read.All and GroupMember.Read.All via Microsoft Graph API. Some providers also require Device.Read.All for device compliance checks. For Google Workspace via Secure LDAP, download the client certificate and key from Google Admin Console and install them on the RADIUS service.

Define your authentication policies within the Cloud RADIUS management portal. A well-structured policy for a corporate environment: "Allow access if the certificate is issued by [Trusted CA] AND the user is a member of the [Corporate-WiFi-Users] group AND the device is marked Compliant in Intune." This enforces identity, group membership, and device health simultaneously.

Phase 4: configure wireless infrastructure

In your wireless LAN controller or cloud management dashboard - Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, or Fortinet - add the Cloud RADIUS server IP addresses and shared secrets as RADIUS authentication servers. Configure primary and secondary servers for redundancy. Set the RADIUS timeout to a minimum of five seconds to accommodate cloud round-trip latency.

Create a new SSID configured for WPA2-Enterprise or WPA3-Enterprise. For Hospitality deployments, ensure the corporate SSID is on a separate VLAN from any Guest WiFi network. For Retail environments, consider deploying the corporate SSID only in back-of-house areas.

Phase 5: deploy WiFi profile via MDM

Microsoft Intune: create a WiFi configuration profile. Set the SSID to match your infrastructure configuration exactly. Select WPA2-Enterprise or WPA3-Enterprise. Under EAP settings, select EAP-TLS. Link the SCEP certificate profile as the client certificate and specify the Trusted Root CA profile. Assign this WiFi profile to the same device groups that received the certificate profiles. Devices silently receive the certificate and the WiFi configuration during their next Intune sync.

Google Admin Console: navigate to Devices, then Networks, then Wi-Fi. Create a new WiFi network profile. Set the SSID, select WPA3-Enterprise, choose EAP-TLS, and push the trusted Root CA certificate to the devices. Apply this profile to your Organisational Units. Chromebooks connect silently and securely.

Best practices

Mandate EAP-TLS across all new deployments. Do not deploy new networks using PEAP-MSCHAPv2. The security risks are well-documented and the migration path is straightforward with modern MDM tooling.

Enforce strict server certificate validation. If you must use PEAP for legacy devices, configure the devices to validate the RADIUS server's certificate. In the Intune WiFi profile and in the Google Admin Console WiFi profile, there is a field to specify the trusted CA for server validation. Do not leave this blank. This single configuration decision is the difference between a secure deployment and a vulnerable one.

Segment your network with dynamic VLAN assignment. Use your RADIUS server to inspect the user's group membership in Entra ID or Google Workspace and dynamically assign them to different VLANs. The RADIUS server returns the Tunnel-Private-Group-Id attribute to the access point, which places the client on the correct VLAN. This limits lateral movement in the event of a compromise and supports PCI DSS network segmentation requirements.

Separate corporate and guest authentication. Use EAP-TLS for corporate-managed devices. Use a captive portal with SSO for BYOD and guest devices. Trying to manually configure EAP-TLS on unmanaged devices creates excessive support overhead. Purple's Guest WiFi platform handles guest onboarding separately, maintaining a clean separation between staff and visitor traffic.

Monitor certificate expiry proactively. Set up monitoring and alerting at 90 days, 30 days, and seven days before certificate expiry. If your RADIUS server certificate expires, all devices lose connectivity simultaneously. Automate renewal where your PKI supports it.

Test RADIUS timeout settings. Cloud RADIUS introduces network round-trip latency that on-premise NPS does not. Set the RADIUS timeout on your access points to at least five seconds. A timeout of two seconds - common in default configurations - will cause intermittent authentication failures.

Troubleshooting and risk mitigation

Blocked firewall ports are the leading cause of initial deployment failure. RADIUS authentication requires UDP port 1812 outbound from your wireless infrastructure to the Cloud RADIUS service. RADIUS accounting requires UDP port 1813. Verify these are open before any other troubleshooting.

Certificate validation failures present as authentication rejections with no obvious cause. Check the following in order: certificate expiry on both the client and the RADIUS server; clock skew between the client device and the RADIUS server (EAP-TLS relies on accurate timekeeping); and whether the Root CA certificate has been successfully deployed to the device via MDM.

Group membership not enforcing is a common issue when RADIUS policies reference Entra ID or Google Workspace groups. Verify that the Cloud RADIUS provider has the correct API permissions to read group memberships. In Entra ID, confirm the service principal has GroupMember.Read.All. In Google Workspace, confirm the Secure LDAP client has permission to read group information.

VLAN assignment not working typically indicates a mismatch between the RADIUS attribute values and the VLAN IDs configured on the wireless infrastructure. Confirm that Tunnel-Type is set to VLAN (value 13), Tunnel-Medium-Type is set to 802 (value 6), and Tunnel-Private-Group-Id matches the VLAN ID configured on the switch or controller.

BYOD devices failing EAP-TLS usually indicates the client certificate was not successfully deployed. For Intune-managed devices, check the device's certificate store in the Intune admin centre. For Google-managed Chromebooks, verify the certificate profile is assigned to the correct Organisational Unit and that the device has synced recently.

ROI and business impact

Moving to Cloud RADIUS delivers measurable operational savings. On-premise RADIUS requires at minimum two servers for high availability, ongoing OS patching, certificate management, and specialist engineering time. A single engineer's time spent on RADIUS maintenance over a year typically exceeds the annual cost of a Cloud RADIUS subscription.

The business case extends beyond cost reduction. By tying network access to verified cloud identities, you gain:

Instant offboarding. Disabling a user in Entra ID or Google Workspace immediately revokes their network access at all sites. There is no lag, no manual process, and no risk of a former employee retaining WiFi access. This directly supports GDPR obligations around data access rights.

Richer analytics. Platforms like Purple's WiFi Analytics provide richer data on space utilisation and visitor journeys when network access is tied to authenticated identities. You move from anonymous MAC addresses to named, authenticated users, which transforms the quality of insight available to operations and marketing teams.

Compliance evidence. EAP-TLS authentication generates detailed access logs - who connected, from which device, at which location, and at what time. This audit trail supports PCI DSS Requirement 10 (logging and monitoring) and GDPR accountability obligations.

Multi-site consistency. A single Cloud RADIUS service authenticates all your sites with consistent policies, managed from one dashboard. Adding a new hotel, store, or venue means adding its access points to the RADIUS configuration - not shipping and configuring another server. For organisations managing large estates, this is a significant operational advantage.

For Transport operators and Healthcare venues where network uptime is operationally critical, Cloud RADIUS providers typically offer 99.999% uptime SLAs with multi-region failover built in. Purple operates at 99.999% uptime across 80,000+ live venues, with 440 million logins processed in 2024 (Purple internal data, 2024).

For further reading on related topics, see WAN Computer Definition: A Practical Guide for 2026 and World WiFi Day 2026: How Your Venue Can Help Bridge the Digital Divide .