您接管了一个英国的项目资产，其企业 WiFi 密码打印在后台办公室的文件夹中，由前台、保洁、承包商和前员工共享。访客网络是单独管理的，设备引导上线依赖于手动指令，并且审计员想知道是哪个人授权了每次连接。与此同时，该组织已将其应用身份迁移到 Microsoft Entra ID，并希望 WiFi 也能同步跟进。
这种期望是可以理解的，但其架构经常被错误地描述。Microsoft Entra ID 并不提供原生的 RADIUS 服务。微软官方文档中的立场是，加入 Entra 的设备无法使用基于本地计算机对象和证书的 RADIUS 身份验证，因此现代设计需要依赖 EAP-TLS、Intune 颁发的证书以及独立的 RADIUS 层 (微软的 Entra RADIUS 指南)。一旦明确了这一区别，部署的设计、测试和维护就会变得容易得多。
为什么基于 Entra ID WiFi 认证值得付出努力
共享的预共享密钥可能在开业时有效，但在员工离职、承包商将其复制到个人设备或访客访问了专为员工准备的网络之后，该密钥仍然处于活动状态。更改该密钥本身就会带来运维问题。每一台受管笔记本电脑、手持终端、收银机、平板电脑和其他设备都必须接收新密钥，这通常涉及多家酒店、医院和零售网点。
Microsoft Entra ID WiFi 身份验证将信任单位从密码转变为身份和设备。 EAP-TLS 使用基于证书的连接来识别授权用户或设备。Intune 控制哪些托管终端接收该证书和匹配的 WiFi 配置文件。接入点仍然需要 RADIUS，因此 Microsoft Entra ID 是目录和策略源，而不是无线身份验证终端。这一架构差距是许多简化指南中忽略的细节。
实用规则：将 WiFi 视为绑定身份的服务：要求证书和 Intune 范围，绝不使用直接复制粘贴的 Entra 用户名和密码。
入职流程变得可重复。配置正确的 Intune 配置文件可以配置 SSID、受信任的证书链和证书选择，而无需员工输入或共享密钥。离职流程也获得了一个明确的控制路径。停用设备可以触发证书生命周期操作，而无需管理员到处寻找存储共享密码的每一个位置。
合规性案例同样具有实际意义。英国企业必须在共享场所和受监管的环境中，将员工、访客、供应商和未管理设备进行隔离。一份专门的 enterprise WiFi security guide 提供了有用的背景信息，而生产设计需要明确的决策：将访客访问与员工 EAP-TLS 分开，记录向 RADIUS 提供的身份，并定义如何删除访问权限。
Entra 管理中心并未为此设计提供单一开关。PKI、Intune、RADIUS 策略和无线设置必须协同工作，且旧版 Apple、Windows、Android 和共享设备可能会表现出不同的证书或配置文件行为。这一集成工作是实实在在的，但它用一个可在英国混合环境中应用的可重复控制，取代了脆弱的共享密钥。
您需要就位的核心构建块
酒店访客网络、医院病房或零售分店可能会在第一次证书检查时就宣告失败，而接入点却仍报告 SSID 状态健康。在打开 Intune 向导之前先定义好架构，以避免这种混乱。四个组件必须在同一个身份链上达成一致：
- 证书颁发机构：从 Microsoft PKI、AD CS 或托管证书提供商开始。在调整 RADIUS 策略之前，CA 必须签发带有客户端身份验证 EKU 的证书，且 RADIUS 服务必须信任该签发链。
- RADIUS 层：NPS、Aruba ClearPass、Cisco ISE 或 RADIUS-as-a-Service 平台负责终止来自接入点的 802.1X 交换。Microsoft Entra ID 没有原生的 RADIUS 功能。NPS 扩展将 RADIUS 请求调整为基于 Entra 的检查，而不是将 Entra 变成 RADIUS 服务器，正如 Microsoft Q&A 关于 RADIUS 限制 中所解释的那样。
- Intune：Intune 交付受信任的根、SCEP 或 PKCS 证书配置文件以及 WiFi 配置。它的分配还控制设备范围，因此未完成的配置文件不会波及整个资产。
- 网络策略：RADIUS 必须定义成功的证书允许什么。这可以是一个员工 VLAN、一个临床细分网络、一个受限的零售网络或一个特定于设备的 ACL。
按依赖顺序构建
在调整 RADIUS 之前发布并验证 CA 模板。检查颁发者、使用者或 SAN、证书链以及客户端身份验证 EKU。否则，当设备没有可用的证书时，握手失败可能会看起来像射频或 SSID 故障。
信任必须是双向的。托管设备信任对 RADIUS 服务器证书进行签名的 CA，而 RADIUS 信任颁发客户端证书的 CA。接入点需要 RADIUS 服务器地址和共享密钥。它们不直接针对 Entra 进行身份验证。
确定策略驻留位置
NPS、ClearPass 和 ISE 都可以执行无线策略，但它们的规则模型和属性处理方式有所不同。选择一个 SSID 到 VLAN 映射的单一事实来源，记录下来，并防止 AP 控制面板与 RADIUS 规则产生冲突的结果。
英国公共部门的一份清单描述了 Entra ID 对公钥身份验证（包括 TLS 客户端证书）以及联合身份验证和双因素身份验证的支持（英国公共部门 Entra ID 清单）。该证书模型仍然依赖于独立的 PKI 和 RADIUS 组件。
通过 Intune 颁发证书和推送 WiFi 配置文件
对于托管设备，EAP-TLS 的成功与否取决于证书选择。Intune 可以在无需用户干预的情况下交付配置文件，但它无法弥补缺少正确用途、颁发者或主体映射的证书模板。
建立证书路径
首先部署受信任的根 CA 配置文件。对于 SCEP，创建一个指向 NDES 服务并使用 Intune 证书连接器的证书配置文件。该配置文件应引用已发布的 SCEP 终结点、正确的证书模板以及防止未经授权请求的挑战机制。
证书本身在其增强型密钥用法中需要 客户端身份验证。决定使用者和 SAN 是识别设备、用户还是两者兼有。该决定会影响 RADIUS 映射、共享设备行为以及您稍后如何调查身份验证事件。
在通过批准的工作流生成和打包证书的情况下，PFX 配置文件可以正常工作，但在多样化的托管设备群中，SCEP 通常更容易运行，因为设备可以自行请求和更新其证书。重点在于一致性。每个平台都必须接收一个 RADIUS 策略能够识别的证书链和证书。
配置 WiFi 负载
使用精确的 SSID、安全模式和 EAP 方法创建 WiFi 配置文件。选择 EAP-TLS，将配置文件绑定到通过 SCEP 配置颁发的证书，并启用服务器证书验证。添加确切的 RADIUS 服务器名称，以便设备在信任决策过程中不会接受类似的欺骗服务。符合微软标准的英国部署指南建议在 WiFi 配置文件中配置受信任的根证书、SCEP 客户端证书配置文件以及精确的 RADIUS 名称 (英国 Entra ID WiFi 设置指南)。
导致反复失败的领域是证书匹配。在 Windows、macOS、iOS 和 Android 上，WiFi 配置文件必须选择由预期的 CA 颁发且包含所需 EKU 的证书。如果配置文件已部署但操作系统无法选择该证书，设备可能会回退到不合适的方法或拒绝连接。
将 SCEP 和 WiFi 配置文件范围限定在相同的试点设备组中。检查设备日志以确认证书安装，确认根证书受信任，然后在更改 RADIUS 策略之前检查选定的客户端证书。证书健康检查（例如此 SSL 证书检查工具）可以帮助验证面向公众的证书端，但内部 EAP-TLS 故障排除仍取决于设备和 RADIUS 日志。
将其连接到您的网络和 RADIUS 层
接入点只能看到 802.1X 客户端。它看不到 Entra ID。设备出示其客户端证书，AP 将 EAP 交换转发给 RADIUS，然后 RADIUS 服务验证证书链并应用网络策略。
通常的流程是：
- 设备与企业 SSID 关联。
- AP 将 EAP-TLS 流量转发给 NPS、ClearPass、ISE 或托管 RADIUS 服务。
- RADIUS 根据受信任的发证 CA 验证客户端证书。
- 策略引擎将证书身份映射到账户、设备或组。
- RADIUS 响应分配允许的 VLAN 或访问策略。
厂商配置差异
Meraki 仪表板通常需要 RADIUS 服务器详细信息、共享密钥和证书验证设置，并在 RADIUS 响应控制分段时使用 AAA 覆盖。Aruba 部署通常依赖于 RADIUS 服务器组和服务器派生规则。Ruckus SmartZone 需要选择 EAP-TLS 的 AAA 配置，而 Juniper Mist WLAN 模板则指向 RADIUS 集群。UniFi Network 使用 RADIUS 配置文件，并且在传统 EAP-TTLS 与 EAP-TLS 并存时可能需要谨慎处理。
對於希望拥有独立 RADIUS 层而无需运行完整服务器平台的设备群，Purple 的 RADIUS-as-a-Service 是一种托管选择。NPS、ClearPass、ISE 和托管服务都可以匹配，但它们对每个证书属性或策略条件的解释并非完全相同。
| 厂商 | RADIUS 认证服务器 | EAP 类型 | 证书属性 | 常见陷阱 |
|---|---|---|---|---|
| Meraki | NPS, ISE, ClearPass 或托管 RADIUS | EAP-TLS | 颁发者和 SAN | AAA 覆盖可能会将有效用户分配到错误的 VLAN |
| Aruba | NPS, ClearPass, ISE 或托管 RADIUS | EAP-TLS | SAN 或 UPN | 服务器衍生规则顺序可能会将员工引导至访客策略 |
| Ruckus | 连接到 SmartZone 的 RADIUS | EAP-TLS | 使用者和颁发者 | 在 AAA 设置中很容易忽略 EAP 类型不匹配的问题 |
| Juniper Mist | RADIUS 集群 | EAP-TLS | SAN 或映射标识 | WLAN 模板可能会引用不完整的服务器组 |
| UniFi | 网络应用程序 RADIUS 配置文件 | EAP-TLS 或受控的传统方法 | 证书标识 | 混合的 EAP 方法可能会掩盖实际的失败原因 |
在 NPS 上，检查 EAP-TLS 证书属性，并定义是由颁发者、使用者还是 SAN 提供账户映射。常见的错误是，当 RADIUS 服务将 SAN 解析为 UPN 时，假定通用名称是用户名。这会破坏用户映射，还可能干扰仅限设备或共享设备的工作流。
在设备群需要高可用性的地方，使用负载均衡的 RADIUS 集群，并设置合理的每个 SSID 故障转移定时器。不要假设云 RADIUS 服务会实时强制执行吊销。一些托管设备缺乏可访问的 CRL 或 OCSP 验证，因此即使在目录账户发生变更后，证书可能仍被接受。
员工 WiFi 的即时吊销与条件访问
困难的问题不在于设备是否可以注册。而是在人力资源部门禁用账户后会发生什么。
条件访问评估支持的 Entra 登录。它不会强行接入已建立的 802.1X 会话并仅因为目录状态发生变化而将其终止。已安装在笔记本电脑上的证书在过期前，或在 RADIUS 服务通过证书吊销检查拒绝它之前，可以一直保持密码学上的有效性。这使得吊销设计比注册演示更加重要。
缩短证书窗口
第一种缓解措施是缩短证书有效期。Intune SCEP 配置文件可以颁发定期更新的证书，从而限制已停用设备继续提供原本有效凭据的时间。合适的窗口取决于威胁模型、设备可用性和操作容差。较短的有效期会增加对可靠更新的依赖，因此请测试长时间处于离线状态或在受限网络后运行的设备。
第二种缓解措施是主动吊销检查。发布可访问的 CRL 或运行 OCSP，然后确认 RADIUS 服务器对其进行查询。如果由于检查被禁用或分发点无法从 RADIUS 网络访问，NPS 和 ClearPass 配置可能会在忽略吊销的同时显示为健康状态。
关键的运维衡量指标是目录禁用与第一个被拒绝的无线数据包之间的时间差。
Intune 的停用和擦除工作流仍然很有价值，特别是对于丢失或共享的设备，但它们并不能神奇地从已关机的终端中擦除证书。当设备下一次接收管理指令时，证书会因过期、吊销或删除而变得不可用。团队应当记录这一时间窗口，并在离职演练中进行测试。
Entra 持续访问评估支持针对特定云应用场景的快速控制决策。目前它并不能使 EAP-TLS 成为浏览器式的条件访问事务，因此 WiFi 仍取决于证书有效性和 RADIUS 吊销行为。对于正在审查更广泛身份验证模型的读者，本篇 面向埃德蒙顿用户的 MFA 指南 提供了有用的背景信息，说明了更强的登录保证与网络证书身份验证有何不同。
访客访问需要其独立的控制平面。英国公共部门的实践（包括 GovWifi）强调，访客和共享访问不应被强行纳入相同的员工证书工作流（参阅 英国 Entra WiFi 集成指南）。
测试和排除常见故障模式
实验室测试证明了一台设备可以连接。而生产环境部署则证明了错误的设备无法连接、已被吊销的证书会被拒绝，且访客无法继承员工策略。
从证书开始
对于 EAP-TLS 故障，请在更改 AP 之前检查客户端证书。确认证书链、颁发者、SAN、有效期和客户端身份验证 EKU。然后检查 WiFi 配置文件是否选择了该证书，以及设备是否信任 RADIUS 服务器证书。
SCEP 循环通常表明 Intune、NDES 与证书模板之间存在不匹配。验证挑战 URL，确认 NDES 连接器账户具有所需的模板权限，并将 SCEP 配置文件 URI 与发布的 NDES URL（包括其尾部的斜杠）进行对比。从错误的模板颁发的证书可能会显示为注册成功，但仍然无法用于 WiFi。
测试信任与隔离
在证书验证发生之前，Evil Twin 可能会广播相同的 SSID。请配置服务器证书验证，在 Intune WiFi 配置文件中指定预期的 RADIUS 名称，并使用托管网络设置，以便操作系统不会随意加入伪造的网络。在客户端和 AP 设备支持的情况下启用受保护的管理帧，并使用组织特定的 SSID 而不是通用名称。
已吊销的证书如果仍能通过身份验证，问题通常指向 RADIUS 服务器，而非 Entra。检查是否已启用 CRL 验证，然后确认 RADIUS 子网可以解析并访问分发点。如果使用 OCSP，请检查超时和响应程序的可用性，而不是假设服务正在自动检查。
访客和员工访问交叉的情况通常源于策略顺序。将 EAP-TLS 员工规则置于基于 PSK 或 MAC 的访客规则之前，然后验证 RADIUS 日志中返回的 VLAN 属性。使用错误的 VLAN 进行有效身份验证是策略失败，而不是注册失败。
使用固定的分流顺序
首次连接缓慢可能是由于证书更新时间、无法访问的吊销终结点或操作系统选择了错误的 SSID 造成的。切勿一开始就重新构建配置文件。
- 检查设备证书：检查证书链、EKU、颁发者、SAN 以及有效期。
- 捕获无线交互：确认 AP 将 EAP 流量转发到预期的 RADIUS 目标。
- 读取 RADIUS 事件日志：使用 NPS 日志、ISE 事件记录或 ClearPass 访问跟踪来识别被拒绝的属性。
- 检查 Intune 状态：确认设备已注册、接收到配置文件并保持在预期的分配组内。
- 验证返回的策略：确认员工和访客会话获得了正确的 VLAN 和 ACL。
该顺序保证了排查过程是以证据为导向的。同时更改三个层级往往会掩盖最初的故障。
适合英国本土的部署清单及后续步骤
将此次推广作为一次受控的服务变更来运行，而不是一次证书实验。从代表该项目资产的一个小型设备组开始：一台现代 Windows 笔记本电脑、Apple 终端、Android 硬件、共享设备以及任何必须保持连接的运营设备。酒店的前台、医院病房和零售商店可能都使用相同的身份平台，但有着截然不同的恢复要求。
部署顺序
- 试点范围划定：选择具有代表性的用户、位置和设备类型，包括网络连接较弱或管理路径受限的站点。
- CA 准备就绪：在创建 WiFi 配置文件之前，确认签发链、模板权限、EKU 和吊销端点。
- Intune 配置文件构建：创建受信任的根证书、SCEP 或 PFX 证书配置文件以及 EAP-TLS WiFi 配置文件作为匹配集。
- RADIUS 集成：将 AP、共享密钥、证书信任和身份映射规则添加到选定的 RADIUS 平台中。
- 设备隔离：将配置文件分配给试点组，并保留传统的 SSID 作为已记录的备用方案。
- 大规模推广：仅在证书签发、VLAN 分配和脱离测试通过后，才按站点或设备环路进行扩展。
- 审计频次：审查失败的身份验证、证书过期、吊销可达性以及员工与访客策略的结果。
- PSK 停用：仅在支持团队拥有经过测试的紧急访问流程且设备资产已完成迁移后，才删除共享密钥 SSID。
英国特定的检查很容易被忽视。确认 Apple BYOD 设备通过预期的管理路径信任颁发链。定义如何轮换 RADIUS 共享密钥，记录证书遥测数据的存储位置以供 GDPR 审查，并使身份验证日志与组织的 PSN 或特定行业审计要求保持一致。医院和共享公共部门场所还需要一个记录在案的备用 SSID 或备用访问流程，以防止其成为永久性未管理的网络。
根据微软的生态系统更新（Microsoft Entra 密钥更新），密钥（Passkeys）预计将在 2026年 成为 Microsoft Entra 登录的默认身份验证方法。但这并不会让当今的 EAP-TLS 工作变得多余。密钥解决了交互式身份登录问题，而 WiFi 仍然需要机器可验证的网络凭证、策略决策和 RADIUS 交换。为证书构建的 CA、设备管理和策略准则是下一代身份模型的重要基础。
如果您的设备群仍依赖于共享密钥或假设 Microsoft Entra ID 可以直接响应 RADIUS 请求，请先记录当前的 SSID、证书颁发机构、设备组和 RADIUS 策略。然后，在具有代表性的英国设备上使用 Intune 试点 EAP-TLS，在扩大范围之前测试吊销，并将访客访问与员工身份隔离开来。
Purple 提供基于云的 RADIUS 和基于身份的 WiFi 平台，可将基于 Microsoft Entra ID 的员工访问与混合厂商环境中的网络策略联系起来。访问 Purple，了解其证书级员工 WiFi 和访客访问功能如何契合您在英国的部署计划。
