Microsoft Entra ID (Azure AD) WiFi 驗證：企業整合指南

執行摘要

隨著企業 IT 部門將企業身分識別從地端的 Active Directory 網域服務 (AD DS) 遷移至 Microsoft Entra ID (前稱為 Azure Active Directory)，網路架構師面臨了一個根本性的網路挑戰：Microsoft Entra ID 不支援原生 RADIUS 協定驗證。

傳統的企業無線網路依賴採用 PEAP-MSCHAPv2 的 IEEE 802.1X，查詢地端 Windows Server 網路原則伺服器 (NPS) 執行個體，以針對本機網域控制站驗證 NT LAN Manager (NTLM) 密碼雜湊。雲端原生的 Entra ID 不會公開 LDAP (TCP 389) 或 RADIUS (UDP 1812) 監聽連接埠，也不會為僅限雲端的帳戶儲存純文字或可逆的 NTLM 密碼雜湊。

為了使用 Microsoft Entra ID 保護企業 WiFi 的安全，企業必須將其存取層現代化。本技術指南概述了將 Entra ID 連接到企業無線網路的三種經證實的架構模式：

1. 透過 Microsoft Cloud PKI 與 SCEP 的雲端原生 EAP-TLS (推薦)：透過 Microsoft Intune 部署的無密碼雙向憑證驗證。
2. 具備 Entra ID OAuth / SCIM 目錄同步的 Cloud RADIUS：查詢 Microsoft Graph API 的託管式雲端驗證服務。
3. 具備 Azure MFA 擴充功能的地端混合 NPS：適用於保留本機 Active Directory 基礎架構環境的橋接架構。

架構比較：Entra ID WiFi 驗證方法

在選擇整合路徑之前，請評估每個模型的技術能力、安全性狀況和管理需求：

+----------------------------------------------------------------------------------------------------+
|                               Microsoft Entra ID WiFi 架構矩陣                                     |
+----------------------------------------------------------------------------------------------------+
| 方法                 | 協定     | 憑證類型         | 地端設備佔用          | 安全等級 (0-100)      |
+----------------------+----------+------------------+-----------------------+-----------------------+
| 1. Intune SCEP PKI   | EAP-TLS  | X.509 數位 CA    | 零 (100% 雲端)        | 98/100 (零信任)       |
| 2. Cloud RADIUS API  | EAP-TTLS | Entra ID / SCIM  | 零 (100% 雲端)        | 88/100 (企業級)       |
| 3. 混合 NPS + MFA    | PEAPv0   | 使用者名稱/密碼  | Windows Server & NDES | 68/100 (傳統風險)     |
| 4. Captive Portal SSO| HTTPS/OIDC| Entra ID OAuth  | 零 (100% 雲端)        | 85/100 (訪客/BYOD)    |
+----------------------+----------+------------------+-----------------------+-----------------------+

方法 1：透過 Microsoft Intune SCEP 的雲端原生 EAP-TLS (推薦)

憑證型 EAP-TLS (RFC 5216) 代表了企業級無線安全性的黃金標準。藉由向託管的終端裝置核發唯一的數位憑證，企業可以消除共享密碼、防範憑證收割的網路釣魚活動，並符合 NIST SP 800-207 零信任架構 標準。

+------------------+          +------------------------+          +------------------------+
|     託管裝置      |          |       無線基地台       |          |     雲端 RADIUS 伺服器 |
| (Win 11 / macOS) |          | (Cisco / Meraki/ Aruba)|          |       (多重區域)       |
+------------------+          +------------------------+          +------------------------+
         |                                |                                    |
         | 1. 802.1X EAP-TLS 關聯         |                                    |
         |------------------------------->|                                    |
         |                                | 2. RADIUS Access-Request (UDP 1812)|
         |                                |----------------------------------->|
         |                                |                                    | 3. 驗證憑證鏈
         |                                |                                    |    與查詢 Graph API
         |                                |                                    |    以獲取帳戶狀態
         |                                | 4. RADIUS Access-Accept            |
         |                                |    (RFC 2868 VLAN 屬性)            |
         |                                |<-----------------------------------|
         | 5. 802.11 四向交握             |                                    |
         |<------------------------------>|                                    |
         |                                |                                    |
  [ 加密工作階段已建立 (WPA3-Enterprise 192-bit) ]

Intune SCEP 部署工作流程

1. 憑證授權單位設定：在 Microsoft Intune 中使用 Microsoft Cloud PKI 或整合的雲端憑證授權單位 (例如 SCEPman、EZCA 或 Cloud RADIUS PKI) 建立核發 CA。
2. 信任的憑證設定檔：將根 CA 和中介 CA 公開憑證部署到所有目標 Windows 11、macOS、iOS 和 Android 裝置群組。
3. SCEP 設定檔配置：
   • 憑證類型：使用者或裝置憑證。
   • 主旨名稱格式：CN={{UserName}},OU=WiFi,DC=enterprise,DC=com
   • 主旨替代名稱 (SAN)：UserPrincipalName = {{UserPrincipalName}} 和 DNS = {{AADDeviceId}}
   • 金鑰用途：數位簽章、金鑰編密。
   • 金鑰存放區提供者 (KSP)：首選 TPM (強制執行硬體支援的私鑰)。
4. WiFi 設定檔配置：
   • WiFi 類型：企業級。
   • EAP 類型：EAP-TLS。
   • 伺服器信任：選取已部署的信任根 CA 憑證。
   • 伺服器名稱：輸入 Cloud RADIUS 伺服器的完整網域名稱 (FQDN)（例如 radius.purple.ai）。
   • 驗證身分：使用者或機器憑證。

方法 2：搭配 Entra ID OAuth 與 SCIM 目錄同步的 Cloud RADIUS

對於尋求集中式目錄管理且不需管理私有 CA 的企業組織，Cloud RADIUS 在無線控制器與 Microsoft Graph API 之間提供了一個託管橋樑。

Cloud RADIUS 如何與 Microsoft Entra ID 整合

+--------------------+        +--------------------+        +--------------------+
|  Enterprise WLC /  |        | Cloud RADIUS Engine|        | Microsoft Entra ID |
|   Access Points    |        | (Purple Platform)  |        |  (Graph REST API)  |
+--------------------+        +--------------------+        +--------------------+
          |                             |                             |
          |  1. RADIUS Access-Request   |                             |
          |     (User: alex@corp.com)   |                             |
          |---------------------------->|                             |
          |                             |  2. Graph API Query         |
          |                             |     (Check user enabled,    |
          |                             |      group memberships,     |
          |                             |      conditional access)    |
          |                             |---------------------------->|
          |                             |                             |
          |                             |  3. JSON Response           |
          |                             |     (Status: Active,        |
          |                             |      Groups: [SG-Finance])  |
          |                             |<----------------------------|
          |                             |                             |
          |  4. RADIUS Access-Accept    |                             |
          |     (VLAN ID: 40)           |                             |
          |<----------------------------|                             |

Cloud RADIUS 的核心優勢

• 零地端硬體：無需採購實體伺服器、Windows Server 授權，也免去年度作業系統修補程式維護。
• 即時目錄同步：若員工離職或在 Entra ID 中被停用，其在所有全球據點的無線網路存取權限將立即被撤銷。
• 多區域備援：Anycast IP 路由會將驗證請求轉發至延遲最低的地理資料中心，並具備自動容錯移轉功能。

透過 Entra ID 安全群組進行動態 VLAN 指派

動態 VLAN 指派允許網路管理員廣播單一企業 SSID，同時根據使用者角色和部門隸屬關係，自動將裝置分配到隔離的網路區段中。

+-----------------------------------------------------------------------------------+
|                         Microsoft Entra ID 安全性群組                             |
+-----------------------------------------------------------------------------------+
       |                                |                                   |
       v                                v                                   v
[ SG-WiFi-Executive ]          [ SG-WiFi-Engineering ]            [ SG-WiFi-Contractors ]
       |                                |                                   |
       v                                v                                   v
[ Cloud RADIUS 原則 ]          [ Cloud RADIUS 原則 ]              [ Cloud RADIUS 原則 ]
       |                                |                                   |
       v                                v                                   v
 RADIUS RFC 2868:               RADIUS RFC 2868:                   RADIUS RFC 2868:
 • Tunnel-Type = 13 (VLAN)      • Tunnel-Type = 13 (VLAN)          • Tunnel-Type = 13 (VLAN)
 • Tunnel-Medium-Type = 6       • Tunnel-Medium-Type = 6           • Tunnel-Medium-Type = 6
 • Group-ID = "10"              • Group-ID = "20"                  • Group-ID = "30"
       |                                |                                   |
       v                                v                                   v
 (企業主管 VLAN 10)             (工程部門子網段 VLAN 20)            (承包商 DMZ VLAN 30)

必要的 RADIUS 標準屬性 (RFC 2868)

當 Cloud RADIUS 伺服器核准驗證請求時，它會在 Access-Accept 封包中包含三個標準屬性：

適用於訪客、BYOD 與承包商的 Captive Portal 單一登入 (SSO)

對於訪客、廠商以及未受管理的員工個人裝置 (BYOD)，部署 802.1X 憑證通常不切實際。在這些情境中，透過 SAML 2.0 或 OpenID Connect (OIDC) 與 Microsoft Entra ID 整合的雲端託管 Captive Portal 可提供安全且具備稽核功能的上網引導流程。

+--------------------+        +--------------------+        +--------------------+
|    訪客 / BYOD     |        | Purple Captive     |        | Microsoft Entra ID |
|       瀏覽器       |        | Splash Portal      |        |     登入閘道       |
+--------------------+        +--------------------+        +--------------------+
          |                             |                             |
          | 1. HTTP 網頁請求            |                             |
          |---------------------------->|                             |
          | 2. 重新導向至 Splash Page   |                             |
          |<----------------------------|                             |
          |                             |                             |
          | 3. 點擊 "使用 M365 登入"    |                             |
          |---------------------------->|                             |
          | 4. SAML / OAuth 驗證請求    |                             |
          |    (login.microsoftonline.com)                            |
          |---------------------------------------------------------->|
          |                                                           |
          | 5. 多重要素驗證 (MFA) 挑戰與身分驗證 (Entra ID)             |
          |<--------------------------------------------------------->|
          |                                                           |
          | 6. 核發 SAML 聲明 / ID 權杖                               |
          |<----------------------------------------------------------|
          |                                                           |
          | 7. 傳送 POST 權杖至 Splash Engine                         |
          |---------------------------->|                             |
          |                             | 8. 在 WLC 上授權 MAC        |
          | 9. 允許存取網際網路         |<----------------------------|
          |<----------------------------|

Captive Portal 單一登入 (SSO) 的安全性優勢

• 強制執行條件式存取：在授予網路存取權限之前，要求進行 Microsoft Entra ID 多重要素驗證 (MFA) 並接受使用條款。
• 自動到期：根據訪客身分設定檔自動限制訪客存取時間 (例如 8 小時)。
• 稽核記錄：保留不可變更的連線記錄，將實體 MAC 位址與企業 Microsoft Entra ID 電子郵件地址建立關聯，以利進行合規性稽核。

強化企業級 WiFi 安全性：WPA3-Enterprise 192 位元模式

設定 Microsoft Entra ID WiFi 驗證時，網路架構師應配置 WPA3-Enterprise，以防止複雜的空中無線攻擊媒介：

• 192 位元安全性模式 (CNSA 套件)：實作 256 位元伽羅瓦/計數器模式協定 (GCMP-256) 加密與 384 位元 HMAC-SHA-384 金鑰衍生。
• 保護管理框架 (PMF / IEEE 802.11w)：防止惡意行為者偽造基地台的 MAC 位址來發送虛假的解除驗證與解除關聯框架。
• 淘汰舊型密碼：完全淘汰 WEP、TKIP 及未強化的 WPA2-TKIP 套件。

排除 Entra ID 802.1X WiFi 驗證失敗問題

當用戶端裝置無法進行驗證時，請參閱此系統化診斷指南：

1. EAP-TLS 握手失敗：未知的 CA 或憑證不受信任

• 故障症狀：用戶端無法連線；RADIUS 記錄顯示 TLS Alert: unknown_ca (48)。
• 根本原因：用戶端裝置不信任 RADIUS 伺服器憑證，或 RADIUS 伺服器缺少簽發用戶端憑證的 Root CA。
• 解決步驟：
  1. 確認 Intune 信任的憑證設定檔已將 Root CA 部署至用戶端裝置。
  2. 在 Intune WiFi 設定檔中，驗證 Server Names 白名單中的伺服器名稱是否與 RADIUS 伺服器憑證的通用名稱 (CN) 或主體替代名稱 (SAN) 完全一致。
  3. 確保完整的憑證鏈（Root CA + 中繼 CA）已匯入 Cloud RADIUS 憑證信任存放區。

2. RADIUS Access-Reject：使用者帳戶已停用或群組成員身份不符

• 故障症狀：RADIUS 伺服器收到請求，但傳回 Access-Reject 並顯示錯誤 User account not found or disabled。
• 根本原因：該使用者帳戶在 Microsoft Entra ID 中已被停用，或者該使用者並非授權的 Entra 安全性群組成員。
• 解決步驟：
  1. 在 Microsoft Entra 系統管理中心 (entra.microsoft.com) 檢查使用者物件，以驗證帳戶狀態是否為啟用。
  2. 驗證 Entra ID 中的 Cloud RADIUS 企業應用程式權限（User.Read.All、GroupMember.Read.All）。
  3. 如果使用者是最近才加入新的安全性群組，請檢查目錄同步延遲。

3. 動態 VLAN 指派未生效

• 故障症狀：驗證成功，但用戶端仍保留在預設的原生 VLAN，而非指派的部門 VLAN。
• 根本原因：無線區域網路控制器 (WLC) 未啟用 AAA 覆寫 (AAA Override)，或交換器 Trunk 連接埠缺少目標 VLAN ID。
• 解決步驟：
  1. 在 Cisco Catalyst / Aruba 控制器上，於 WLAN 設定中啟用 AAA Override 與 Allow Dynamic VLANs。
  2. 驗證連接到存取點的交換器連接埠在 802.1Q trunk 上允許所有動態 VLAN ID (switchport trunk allowed vlan add 10,20,30,40)。
  3. 確認 RADIUS 傳回所有三個必要屬性：Tunnel-Type = 13、Tunnel-Medium-Type = 6 且 Tunnel-Private-Group-ID = <VLAN_ID>。

總結與後續步驟

將 Microsoft Entra ID 與企業級 WiFi 整合，可建立一個具備彈性且無密碼的網路存取層。透過將 Microsoft Intune SCEP 憑證管理 與 Cloud RADIUS 及動態 VLAN 指派相結合，IT 組織不僅能加強零信任安全架構，更能免除本地部署基礎設施的債務負擔。

對於需要同時管理大量訪客、承包商或 BYOD 裝置以及公司資產設備的組織，Purple 可在所有主要企業級無線硬體廠商之間，提供即用型雲端 WiFi 存取管理、原生 Entra ID SAML/OAuth Captive Portal 單一登入以及即時網路分析。