Azure AD 和 Entra ID WiFi 身份验证：集成与配置指南

执行摘要

对于在微软生态系统中投入巨大的现代企业而言，将云身份基础设施与物理无线网络连接起来是一项至关重要的安全要务。历史上，WiFi 身份验证依赖于本地的 Active Directory 域服务 (AD DS) 和 Windows 网络策略服务器 (NPS)。然而，随着组织迁移到 Microsoft Entra ID（前身为 Azure AD）并采用零信任安全模型，传统的基于凭据的身份验证方法——PEAP-MSCHAPv2——已不再足够或安全。

本指南为 IT 经理、网络架构师和场所运营总监提供了实施 Azure AD WiFi 身份验证 的实用路线图。我们探讨了维护本地 NPS 足迹与迁移至云原生 RADIUS 解决方案之间的架构差异。关键的是，我们详细说明了如何利用 Microsoft Intune 进行基于证书的身份验证（EAP-TLS），这消除了与密码相关的漏洞，并为最终用户提供了无缝、无摩擦的体验。无论您是管理一家 500 间客房的酒店、一个零售连锁店，还是大型公共部门部署，本指南都将帮助您利用现有的 Microsoft 身份投资来保护您的无线边缘。有关部署模型的更广泛讨论，请参阅我们的 云 RADIUS 与本地 RADIUS：IT 团队决策指南 。

技术深度解析：架构与标准

安全企业 WiFi 的基础是 IEEE 802.1X 标准，它提供了基于端口的网络访问控制。在 Microsoft 中心化的环境中，将 802.1X 与 Entra ID 集成需要跨三个层面进行仔细的架构规划：无线基础设施、身份验证服务器和身份目录。

RADIUS 和 802.1X 的角色

当客户端设备（请求者）尝试连接到 WPA2/WPA3-企业网络时，无线接入点（认证器）会阻止除 EAP（可扩展身份验证协议）数据包之外的所有流量。接入点将这些数据包转发到 RADIUS 服务器。RADIUS 服务器根据目录服务验证用户或设备的身份，并返回 Access-Accept 或 Access-Reject 消息。这种三方模型——请求者、认证器、身份验证服务器——是企业无线安全的基石，在我们的 无线接入点定义：您的 2026 终极指南 中有详细描述。

Microsoft 环境的架构方法

将 Microsoft 身份与 WiFi 身份验证集成有两种主要架构，各有不同的取舍：

混合本地 (Windows NPS + AD DS + Azure AD Connect)： 这是传统方法。Windows NPS 充当 RADIUS 服务器，根据本地 Active Directory 对请求进行身份验证。为了将其链接到云，Azure AD Connect 将本地身份同步到 Entra ID。虽然这种方法稳健，但需要维护本地服务器基础设施、管理高可用性，并在实施 EAP-TLS 时部署复杂的 PKI (ADCS)。

云原生 (Cloud RADIUS + Entra ID + Intune)： 这种现代方法消除了对本地 NPS 服务器的需求。第三方 Cloud RADIUS 提供商通过 Microsoft Graph API 直接与 Entra ID 集成。身份验证完全在云中进行。这种架构符合云优先战略，显著降低了运营开销，并与零信任网络访问原则保持一致。

EAP-TLS 对比 PEAP-MSCHAPv2：关键选择

EAP 方法的选择是此部署中最重大的安全决策。PEAP-MSCHAPv2 依赖于用户输入其域凭据。这容易受到凭据盗窃、中间人攻击，并且在密码过期时会造成糟糕的用户体验。研究一致表明，PEAP-MSCHAPv2 可以通过恶意接入点攻击被攻破。

EAP-TLS（传输层安全）是安全 WiFi 的行业黄金标准。它使用安装在客户端设备上的数字证书进行相互身份验证——客户端和服务器都证明自己的身份。没有密码需要输入，连接具有加密强度。在 Microsoft 环境中，证书通常使用 Microsoft Intune 通过 SCEP（简单证书注册协议）或 PKCS 进行部署。这是所有新部署的推荐路径，对于符合 PCI DSS（要求 8）和 GDPR 数据保护义务至关重要。

实施指南：分步部署

使用 EAP-TLS 和 Intune 实现 Entra ID WiFi 身份验证需要协调身份、设备管理和网络基础设施中的多个组件。推荐采用以下五阶段方法进行云原生部署。

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

首先验证您的 Entra ID 租户是否具有适当的许可。Microsoft 365 E3/E5 或企业移动性 + 安全性 (EMS) E3/E5 包含此部署所需的 Intune 设备管理和条件访问功能。没有 Intune，无法进行自动证书部署。

接下来，建立您的公钥基础设施 (PKI)。您有三种选择：由您的 Cloud RADIUS 供应商提供的云原生 PKI、Microsoft 自己的 Cloud PKI（随 Intune Suite 许可证提供），或通过 Microsoft Intune 证书连接器连接到 Intune 的现有本地 ADCS 部署。对于新部署，强烈建议使用云原生 PKI，以避免本地依赖。

第 2 阶段：配置 Intune 进行证书部署

在 Microsoft Intune 管理中心内，创建一个 受信任的证书 配置文件。上传您 PKI 的根 CA 证书，并将其部署到您的目标设备组。此步骤至关重要：它确保客户端设备在 TLS 握手期间信任 RADIUS 服务器提供的证书，防止中间人攻击。

接下来，创建一个 SCEP 证书 配置文件（或根据您的 PKI 要求使用 PKCS）。配置使用者名称格式——对于基于用户的身份验证，使用 CN={{UserPrincipalName}}；对于基于设备的身份验证，使用 CN={{DeviceName}} 或设备序列号。设置使用者备用名称 (SAN) 以包含用户主体名称或设备 ID。将这两个配置文件分配给相应的 Entra ID 设备或用户组。

第 3 阶段：配置 Cloud RADIUS 集成

在您的 Entra ID 租户中授予您的 Cloud RADIUS 提供商必要的 Microsoft Graph API 权限。至少，提供商需要 User.Read.All 和 GroupMember.Read.All 来在身份验证期间验证组成员资格。一些提供商还需要 Device.Read.All 用于基于设备的策略。

在 Cloud RADIUS 管理门户中，定义您的身份验证策略。针对公司环境，一个结构良好的策略可能为：*允许访问，条件是证书由 [受信任的 CA] 颁发，且用户是 [Corporate-WiFi-Users] Entra ID 组的成员，且设备在 Intune 中标记为合规。*这种分层策略同时强制执行身份和设备健康状况。

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

在您的无线 LAN 控制器或云管理仪表板（如 Cisco Meraki、Aruba Central 或 Juniper Mist）中，将 Cloud RADIUS 服务器的 IP 地址和共享机密添加为 RADIUS 身份验证服务器。配置主服务器和辅助服务器以实现冗余。将 RADIUS 超时设置为至少 5 秒，以适应云往返延迟。

创建一个新的 SSID，配置为 WPA2-企业或 WPA3-企业。将 RADIUS 服务器分配给此 SSID。对于 酒店业 部署，确保此企业 SSID 与任何访客网络位于不同的 VLAN 上。对于 零售 环境，考虑仅在后场区域部署企业 SSID，保持销售楼面网络分离。

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

在 Intune 中创建一个 WiFi 配置文件。将 SSID 设置为与您在无线基础设施上配置的完全匹配。选择 WPA2-企业 或 WPA3-企业 作为安全类型。在 EAP 设置下，选择 EAP-TLS 作为身份验证方法。将 SCEP 证书配置文件链接为客户端证书，并指定您在第 2 阶段部署的受信任根 CA 配置文件。

将此 WiFi 配置文件分配给接收证书配置文件的相同设备组。设备将在下一次 Intune 同步时静默接收证书和 WiFi 配置，并在 SSID 范围内时自动连接——无需用户交互。

企业环境最佳实践

以下建议代表了在企业场所进行安全、可扩展的 Microsoft 802.1X 部署的行业共识。

在所有新部署中强制使用 EAP-TLS。 不要使用 PEAP-MSCHAPv2 部署新网络。基于凭据的 WiFi 的安全风险有详细记录，且与零信任安全姿态不相容。EAP-TLS 对于符合 PCI DSS、GDPR 和 ISO 27001 至关重要。

自动管理证书生命周期。 确保当用户在 Entra ID 中被禁用或设备在 Intune 中被淘汰时，相应的证书被自动吊销，或者 RADIUS 策略立即阻止访问。这在人员流动频繁的环境中尤为重要，例如 酒店业 和 零售 。

实施 Entra ID 条件访问。 利用条件访问策略强制要求设备合规作为网络访问的条件。在设备能够对 RADIUS 进行身份验证之前，要求设备在 Intune 中被标记为“合规”，确保只有已打补丁、策略合规的设备才能访问公司网络。

严格分割公司网络和访客网络。 802.1X 专为受管理的公司设备设计。对于访客、承包商和 BYOD，实施专用的 访客 WiFi 解决方案，并配备 Captive Portal。这可以与 Entra ID B2B 集成以实现承包商访问，或使用社交登录和短信验证实现一般公众访问。绝不允许非受管理设备接入公司 802.1X SSID。

为旧设备和物联网设备制定计划。 打印机、物联网传感器和无法支持证书的旧设备需要单独的策略。对已知设备使用 MAC 认证旁路 (MAB)，或使用一个带有复杂、定期轮换预共享密钥 (PSK) 的专用 WPA2-个人 SSID，并在专用 VLAN 上隔离。例如，Purple 的 Sensors 平台可以在独立于公司身份验证基础设施的专用物联网 VLAN 上运行。

监控身份验证事件。 将 RADIUS 日志与您的 SIEM 集成，或使用 WiFi 分析 平台监控身份验证失败、证书过期警告和异常访问模式。主动监控可在影响运营之前防止中断。

故障排除与风险缓解

即使是策划良好的部署也会遇到问题。以下是最常见的故障模式及其解决方案。

证书部署失败。 EAP-TLS 部署中最常见的问题是设备无法从 Intune 接收证书。这通常是由于 Intune 证书连接器配置错误（如果使用本地 ADCS）、SCEP URL 不正确或设备未与 Intune 同步所致。始终在 Intune 管理中心检查证书连接器状态，并查看设备同步日志。确保 SCEP 服务帐户在 CA 上具有所需权限。

RADIUS 超时问题。 如果接入点无法在配置的超时时间内到达 RADIUS 服务器，客户端将无法连接。确保您的防火墙规则允许 UDP 端口 1812（身份验证）和 1813（计费）出站到 Cloud RADIUS 提供商的 IP 范围。如果使用本地 NPS，至少部署两台 NPS 服务器，并配置您的接入点在它们之间进行故障转移。

证书信任失败。 如果客户端收到“不受信任的服务器证书”错误，则受信任根 CA 配置文件未正确部署到设备。验证 Intune 中的配置文件分配，并检查设备的证书存储。这是新注册设备尚未完成首次 Intune 同步时的常见问题。

用于 Azure MFA 的 NPS 扩展。 虽然技术上可以使用 NPS 扩展对 WiFi 强制实施多因素身份验证，但强烈不建议用于主要访问。设备每次在接入点之间漫游时收到 MFA 提示的用户体验非常具有破坏性。应依赖设备证书提供的强身份验证，并在应用程序层强制实施 MFA。

组策略冲突。 在混合环境中，配置 Windows 无线客户端的组策略对象 (GPO) 可能与 Intune WiFi 配置文件冲突。通过检查 MDM 注册设置，在必要时阻止对受 Intune 管理设备应用基于 GPO 的无线配置，确保 Intune 配置文件优先。

投资回报率与业务影响

迁移至与 Entra ID 集成的云原生 RADIUS 架构可在多个维度上提供可衡量的、量化的价值。

减少帮助台工单。 与密码相关的 WiFi 问题——锁定、密码过期、请求者配置错误——是基于凭据的环境中 IT 支持工单的重要来源。EAP-TLS 完全消除了这些问题。组织在迁移到基于证书的身份验证后，通常报告 WiFi 相关的帮助台工作量减少 30-50%。

基础设施成本节约。 停用本地 NPS 服务器可减少计算成本、操作系统许可费用以及修补和维护高可用性集群的运营开销。对于一个运行两台 NPS 服务器的中型组织来说，这每年可节省 15,000–30,000 英镑的基础设施和运营成本。

增强的安全姿态与合规性。 摆脱基于凭据的身份验证可减轻凭据盗窃和横向移动的风险，保护敏感的公司数据。对于受 PCI DSS 约束的组织，这直接解决了网络访问控制要求。对于处理患者数据的 医疗保健 组织，它支持 DSPT 合规性。对于 交通 运营商，它符合 NIS2 指令对网络安全的网络要求。

改善用户体验。 无缝、自动的 WiFi 连接——无需密码提示、无需锁定、无需手动配置——可提高员工生产力并减少摩擦。这在配送中心、医院病房和零售卖场等高流动性环境中尤为有影响力。

将您的 WiFi 网络视为云身份策略的延伸，可确保安全、无摩擦的访问随组织扩展。有关现代企业网络 SD-WAN 集成方面的进一步指导，请参见 现代企业的核心 SD-WAN 优势 。有关酒店业特定部署注意事项，请参阅 您的客人应得的现代酒店 WiFi 解决方案 。