将 RADIUS 即服务与云目录（Azure AD 和 Google Workspace）进行集成

执行摘要

对于投资于云身份生态系统的现代企业而言，将云目录与物理无线网络连接起来是一项至关重要的安全任务。历史上，WiFi 身份验证依赖于本地 Active Directory 域服务和 Windows 网络策略服务器（NPS）。随着组织向 Microsoft Entra ID 和 Google Workspace 迁移，该本地身份验证技术栈变成了一种负担——维护成本高昂、难以扩展，且与零信任安全模型不兼容。

RADIUS 即服务（RADIUSaaS）改变了这一局面。云托管的 RADIUS 服务器直接与您的云目录集成，实时验证身份验证请求，并将访问决策返回给您的接入点——无需本地服务器，没有补丁周期，也没有单点故障。结合基于 EAP-TLS 证书的身份验证，该架构消除了凭据盗窃，支持 PCI DSS 和 GDPR 合规性，并为每个站点的员工提供无缝体验。

本指南涵盖了本地 NPS 与云原生 RADIUS 之间的架构决策、通过 Microsoft Intune 和 Google 管理控制台部署 EAP-TLS，以及在酒店、零售物业、体育场馆和公共部门场所保障无线接入安全的运营最佳实践。有关网络访问控制的更广泛介绍，请参阅 您的网络访问控制系统指南 。

技术深潜：架构与标准

RADIUS 和 IEEE 802.1X 的角色

安全企业级 WiFi 的基础是 IEEE 802.1X 标准，它提供基于端口的网络访问控制。当客户端设备（申请者）尝试连接到 WPA2-Enterprise 或 WPA3-Enterprise 网络时，无线接入点（验证者）会阻止除 EAP（可扩展身份验证协议）数据包之外的所有流量。AP 将这些数据包转发给 RADIUS 服务器。RADIUS 服务器针对目录服务验证身份，并返回 Access-Accept 或 Access-Reject 消息。只有这样，AP 才会授予网络访问权限。

这种由申请者、验证者、身份验证服务器组成的三方模型是企业无线安全的基石，并在 IEEE 802.1X 中进行了定义。自推出以来，它没有发生根本性的改变。改变的是 RADIUS 服务器所在的位置以及它与您的目录进行通信的方式。

云原生 RADIUS 架构

云原生 RADIUS 架构消除了对本地 NPS 或 FreeRADIUS 服务器的需求。第三方 Cloud RADIUS 提供商通过 Microsoft Graph API 直接与 Microsoft Entra ID 集成，或者通过 Google Secure LDAP 或 SAML/OAuth 与 Google Workspace 集成。身份验证完全在云端进行。这符合零信任网络访问原则，并显著减少了运营开销。

下表对比了两种主要的架构方法：

EAP-TLS 与 PEAP-MSCHAPv2：关键抉择

EAP 方法的选择是此部署中唯一最具影响力的安全决策。PEAP-MSCHAPv2 依赖于用户输入其域凭据。这容易受到凭据盗窃和中间人攻击的影响。如果客户端设备不严格验证 RADIUS 服务器证书——许多设备默认不验证——攻击者就可以使用您的 SSID 部署流氓接入点，拦截 EAP 握手并捕获凭据。这就是“双面恶魔”（Evil Twin）攻击，并且已有详尽的文献记录。

EAP-TLS（传输层安全）使用安装在客户端设备上的数字证书进行双向身份验证。客户端和服务器都通过加密方式证明自己的身份。无需输入或窃取密码。在 Microsoft 环境中，证书通过 Microsoft Intune 使用 SCEP（简单证书注册协议）或 PKCS 配置文件静默部署。这是所有新部署的推荐路径，并且对于满足 PCI DSS v4.0（关于强身份验证的要求 8.3）和 GDPR 数据保护义务至关重要。

Google Workspace：架构差异

在 RADIUS 集成方面，Microsoft Entra ID 和 Google Workspace 有一个重要的不同之处。Microsoft NPS 与 Active Directory 原生集成，而 Cloud RADIUS 提供商通过 Microsoft Graph API 连接到 Entra ID。然而，Google 不提供原生 RADIUS 服务。您始终需要一个中间件。

Google Secure LDAP 是主要的集成路径。它适用于 Cloud Identity Premium 和 Google Workspace Enterprise 版本，为您的云目录提供传统的 LDAP 接口。您的 Cloud RADIUS 服务器使用 Google 生成的客户端证书在端口 636 上连接到 ldap.google.com为您进行验证。从那时起，RADIUS 服务器会查询 Google 的目录以验证凭据或组群成员身份，就像查询本地 Active Directory 一样。

另一种途径是使用基于 SAML 的集成，其中 Cloud RADIUS 提供商在 Google 管理控制台（Google Admin Console）中注册为 SAML 应用程序，并在身份验证时执行 OAuth 查找，以实时验证用户的身份和组群成员身份。

实施指南

使用 EAP-TLS 实施 RADIUSaaS 需要协调身份、设备管理和网络基础设施。以下五阶段方法适用于 Microsoft Entra ID 和 Google Workspace 环境。

阶段 1：准备身份和设备管理基础设施

对于 Microsoft Entra ID：验证您的租户是否拥有 Microsoft 365 E3/E5 或 Enterprise Mobility + Security (EMS) E3/E5 许可。这包括 Microsoft Intune 和条件访问（Conditional Access）。如果没有 Intune，则无法进行自动证书部署。

对于 Google Workspace：确认您拥有 Cloud Identity Premium 或 Google Workspace Enterprise 以访问 Google Secure LDAP。如果您计划在受管理的 Chromebook 上使用 EAP-TLS，请确保 Google 管理控制台已配置为管理设备证书。

建立您的公钥基础设施（PKI）。对于新部署，强烈建议使用由您的 Cloud RADIUS 供应商提供的云原生 PKI。其他选择包括 Microsoft Cloud PKI（随 Intune Suite 许可提供）或通过 Microsoft Intune 证书连接器（Microsoft Intune Certificate Connector）连接的现有本地 ADCS 部署。

阶段 2：配置证书部署

Microsoft Intune 途径：在 Intune 管理中心，创建一个**受信任的证书（Trusted Certificate）**配置文件。上传根 CA 证书并将其部署到您的目标设备组。这可确保客户端设备在 TLS 握手期间信任 RADIUS 服务器出示的证书。接下来，创建一个 SCEP 证书配置文件。对于基于用户的身份验证，将使用者名称（Subject Name）设置为 CN={{UserPrincipalName}}。对于基于设备的身份验证，使用 CN={{DeviceName}}。将使用者替代名称（Subject Alternative Name）设置为包含用户主体名称（User Principal Name）或设备 ID。

Google 管理控制台途径：导航至“设备”（Devices），然后是“网络”（Networks），再到“证书”（Certificates）。上传您的根 CA。配置证书颁发机制——可以是支持与 Google Workspace 进行 SCEP 集成的云 PKI，也可以是将请求代理到本地 Microsoft 证书颁发机构的 Google Cloud 证书连接器（Google Cloud Certificate Connector）。将根 CA 和客户端证书配置文件部署到相应的组织单位（Organisational Units）。

阶段 3：配置 Cloud RADIUS 集成

在您的目录租户中授予您的 Cloud RADIUS 提供商所需的 API 权限。对于 Entra ID，这需要至少通过 Microsoft Graph API 获得 User.Read.All 和 GroupMember.Read.All 权限。某些提供商还需要 Device.Read.All 以进行设备合规性检查。对于通过 Secure LDAP 的 Google Workspace，从 Google 管理控制台下载客户端证书 and 密钥，并将其安装在 RADIUS 服务上。

在 Cloud RADIUS 管理门户中定义您的身份验证策略。企业环境的一个结构良好的策略示例：“如果证书由 [Trusted CA] 颁发，且用户是 [Corporate-WiFi-Users] 组的成员，且设备在 Intune 中被标记为合规，则允许访问。”这同时强制执行了身份、组群成员身份和设备健康状况。

阶段 4：配置无线基础设施

在您的无线局域网控制器或云管理仪表板（Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 或 Fortinet）中，将 Cloud RADIUS 服务器 IP 地址和共享密钥添加为 RADIUS 身份验证服务器。配置主服务器和备用服务器以实现冗余。将 RADIUS 超时设置为至少五秒，以适应云端往返延迟。

创建一个配置为 WPA2-Enterprise 或 WPA3-Enterprise 的新 SSID。对于 酒店 部署，确保企业 SSID 与任何 访客 WiFi 网络位于不同的 VLAN 上。对于 零售 环境，考虑仅在后勤区域部署企业 SSID。

阶段 5：通过 MDM 部署 WiFi 配置文件

Microsoft Intune：创建一个 WiFi 配置配置文件。设置 SSID 以与您的基础设施配置完全匹配。选择 WPA2-Enterprise 或 WPA3-Enterprise。在 EAP 设置下，选择 EAP-TLS。将 SCEP 证书配置文件链接为客户端证书，并指定受信任的根 CA 配置文件。将此 WiFi 配置文件分配给接收证书配置文件的相同设备组。设备在下一次 Intune 同步期间会静默接收证书和 WiFi 配置。

Google 管理控制台：导航至“设备”（Devices），然后是“网络”（Networks），再到“Wi-Fi”。创建一个新的 WiFi 网络配置文件。设置 SSID，选择 WPA3-Enterprise，选择 EAP-TLS，并将受信任的根 CA 证书推送到设备。将此配置文件应用到您的组织单位。Chromebook 将静默且安全地连接。

最佳实践

在所有新部署中强制执行 EAP-TLS。 不要使用 PEAP-MSCHAPv2 部署新网络。安全风险已有详尽记录，且使用现代 MDM 工具的迁移路径非常简单。

强制执行严格的服务器证书验证。 如果您必须对旧设备使用 PEAP，请配置设备以验证 RADIUS 服务器的证书。在 Intune WiFi 配置文件和 Google 管理控制台 WiFi 配置文件中，有一个字段用于指定用于服务器验证的受信任 CA。请勿将其留空。这一个配置决定就是安全部署与易受攻击部署之间的区别。

通过动态 VLAN 分配对您的网络进行细分。 使用您的 RADIUS 服务器检查用户在 Entra ID 或 Google Workspace 中的组群成员身份，并动态地将他们分配到不同的 VLAN。RADIUS 服务器返回 Tunnel-Private-Group-Id 属性发送到接入点，从而将客户端分配到正确的 VLAN。这限制了在发生入侵时的横向移动，并支持 PCI DSS 网络分段要求。

隔离企业和访客认证。 对企业托管设备使用 EAP-TLS。对 BYOD 和访客设备使用带有单点登录（SSO）的 Captive Portal。尝试在非托管设备上手动配置 EAP-TLS 会带来过多的支持开销。Purple 的 Guest WiFi 平台独立处理访客入网，保持员工和访客流量的清晰隔离。

主动监控证书过期。 在证书过期前 90 天、30 天和 7 天设置监控和告警。如果您的 RADIUS 服务器证书过期，所有设备将同时失去连接。在您的 PKI 支持的情况下，实现自动更新。

测试 RADIUS 超时设置。 与本地 NPS 相比，Cloud RADIUS 会引入网络往返延迟。请将接入点上的 RADIUS 超时时间设置为至少 5 秒。默认配置中常见的 2 秒超时会导致间歇性认证失败。

故障排除与风险缓解

防火墙端口受阻 是导致初始部署失败的主要原因。RADIUS 认证需要从您的无线基础设施向 Cloud RADIUS 服务开放 UDP 端口 1812 出站。RADIUS 计费需要 UDP 端口 1813。在进行任何其他故障排除之前，请确认这些端口已开放。

证书验证失败 表现为无明显原因的认证拒绝。请按顺序检查以下内容：客户端和 RADIUS 服务器上的证书是否过期；客户端设备与 RADIUS 服务器之间的时钟偏差（EAP-TLS 依赖于精准的时间同步）；以及根证书（Root CA）是否已通过 MDM 成功部署到设备。

组会员资格未生效 是 RADIUS 策略引用 Entra ID 或 Google Workspace 组时的常见问题。请验证 Cloud RADIUS 提供商是否拥有读取组会员资格的正确 API 权限。在 Entra ID 中，确认服务主体拥有 GroupMember.Read.All 权限。在 Google Workspace 中，确认安全 LDAP 客户端拥有读取组信息的权限。

VLAN 分配不工作 通常表明 RADIUS 属性值与无线基础设施上配置的 VLAN ID 不匹配。确认 Tunnel-Type 设置为 VLAN（值 13），Tunnel-Medium-Type 设置为 802（值 6），且 Tunnel-Private-Group-Id 与交换机或控制器上配置的 VLAN ID 相匹配。

BYOD 设备 EAP-TLS 失败 通常表明客户端证书未成功部署。对于 Intune 托管的设备，请检查 Intune 管理中心内的设备证书存储。对于 Google 托管的 Chromebook，请验证证书配置文件是否已分配给正确的组织单位（Organisational Unit），以及设备最近是否进行了同步。

投资回报率（ROI）与业务影响

迁移到 Cloud RADIUS 可以带来可衡量的运营成本节省。本地 RADIUS 至少需要两台服务器以实现高可用性，此外还需要持续的操作系统补丁升级、证书管理以及专业工程师的时间。单个工程师一年内花在 RADIUS 维护上的时间成本，通常会超过 Cloud RADIUS 订阅的年费。

商业价值不仅限于降低成本。通过将网络访问与经过验证的云身份绑定，您可以获得：

即时注销。 在 Entra ID 或 Google Workspace 中禁用用户会立即撤销其在所有站点的网络访问权限。没有延迟，无需手动流程，也无前员工保留 WiFi 访问权限的风险。这直接支持了 GDPR 关于数据访问权限的义务。

更丰富的分析。 当网络访问与经过身份验证的身份绑定时，像 Purple 的 WiFi Analytics 这样的平台可以提供关于空间利用率和访客动线的更丰富数据。您将从匿名的 MAC 地址转变为具名的、经过身份验证的用户，这彻底提升了运营和营销团队所能获得的洞察质量。

合规性证据。 EAP-TLS 认证会生成详细的访问日志——谁在什么时间、什么地点、通过什么设备进行了连接。此审计追踪支持 PCI DSS 要求 10（日志记录与监控）以及 GDPR 的问责义务。

多站点一致性。 单个 Cloud RADIUS 服务可以使用一致的策略对您的所有站点进行认证，并从一个仪表板进行管理。增加新的酒店、门店或场所意味着只需将其接入点添加到 RADIUS 配置中，而无需运输和配置另一台服务器。对于管理大型资产的组织来说，这是一个巨大的运营优势。

对于 交通 运营商和 医疗保健 场所，网络正常运行时间在运营中至关重要的，Cloud RADIUS 提供商通常会提供 99.999% 的正常运行时间 SLA，并内置多区域故障转移。Purple 在全球 80,000 多个活跃场所中实现了 99.999% 的正常运行时间，并在 2024 年处理了 4.4 亿次登录（Purple 内部数据，2024 年）。

如需阅读有关相关主题的更多信息，请参阅 WAN 计算机定义：2026 年实用指南 和 2026 年世界 WiFi 日：您的场所如何帮助缩小数字鸿沟 。