如何設定 Azure Entra ID (Azure AD) 進行 WiFi 驗證
本權威指南詳細介紹了整合 Azure Entra ID 與 802.1X 以進行企業級 WiFi 驗證的架構、實作步驟和商業影響。它為網路架構師和 IT 經理提供了實用的部署策略，以零信任、基於憑證的網路存取取代舊有的 PSK。
收聽此指南
查看播客逐字稿
執行摘要
對於管理複雜環境（從大型 餐旅服務業 場所到動態的 零售 空間）的 CTO 和網路架構師而言，保護企業網路的安全已不再僅僅是強密碼的問題。傳統的預共用金鑰 (PSK) 和基本的憑證驗證，在根本上與現代零信任架構不相容。
本指南詳細介紹了如何過渡到與 Azure Entra ID（前身為 Azure AD）直接整合的 802.1X 憑證式 WiFi 驗證。透過轉向 EAP-TLS（可延伸驗證通訊協定安全傳輸層保障），企業可以消除與憑證竊取相關的風險、透過行動裝置管理 (MDM) 自動進行裝置註冊，並確保只有合規、受管理的裝置才能存取敏感的企業 VLAN。我們將探討技術架構、部署步驟，以及這種企業安全態勢如何與 Purple 等平台管理的訪客網路策略平行運作。
技術深度剖析
從憑證到數位憑證的轉變
歷史上，企業 WiFi 依賴 PEAP-MSCHAPv2，需要使用者輸入其網域憑證。然而，由於其容易受到中間人 (AiTM) 攻擊，Microsoft 正積極淘汰憑證式驗證。目前的業界標準是 EAP-TLS，它使用雙向憑證驗證。
在 EAP-TLS 部署中，RADIUS 伺服器和用戶端裝置都會出示數位憑證。如果裝置缺乏由您的受信任憑證授權單位 (CA) 核發的有效憑證，RADIUS 伺服器甚至會在裝置取得 IP 地址之前，就拒絕該連線。
架構橋樑：RADIUS 與 Entra ID
Azure Entra ID 是一個使用 SAML 和 OIDC 等現代通訊協定的雲端身分識別提供者 (IdP)；它原生並不支援無線存取點 (WAP) 所使用的 RADIUS 通訊協定。為了彌補這一差距，網路架構師必須部署一個能夠與 Entra ID 通訊的 RADIUS 伺服器。這通常透過以下方式實現：
- 雲端 RADIUS 解決方案：專為此目的建置的平台（例如 SecureW2、SCEPman 或 Portnox），透過 API 與 Entra ID 和 Intune 直接整合。
- 地端網路原則伺服器 (NPS)：使用 Azure MFA 擴充功能，儘管與雲端原生 RADIUS 相比，這越來越被視為一種過時的方法。
實作指南
部署 Azure Entra ID 進行 WiFi 驗證需要協調身分識別、裝置管理以及網路基礎架構團隊。
步驟 1：建立公開金鑰基礎建設 (PKI)
您必須建立 CA 來核發用戶端與伺服器憑證。在雲端優先的環境中，這通常是透過簡單憑證登錄協定 (SCEP) 與 Microsoft Intune 整合的雲端 PKI。
步驟 2：設定 RADIUS 伺服器
部署您的 RADIUS 基礎架構並將其綁定至您的 Entra ID 租戶。RADIUS 伺服器需要自己的伺服器憑證（受您的用戶端裝置信任），以便在 EAP 握手期間證明其身分。
步驟 3：透過 Intune 部署 MDM 設定檔
請勿依賴使用者手動設定其 WiFi 設定。使用 Intune 推送包含以下內容的完整 WiFi 設定檔：
- 信任的根 CA 憑證。
- 用以要求用戶端憑證的 SCEP 設定檔。
- WiFi 設定本身，明確定義 SSID 和 RADIUS 基礎架構的確切伺服器名稱，以防止邪惡雙生 (Evil Twin) 攻擊。
步驟 4：設定無線區域網路控制器 (WLC)
設定您的存取點或 WLC 以使用 WPA2/WPA3-Enterprise (802.1X)。將驗證與計費流量指向您新的 RADIUS 伺服器 IP 位址，並設定共用的 RADIUS 密鑰。
> 「設定 802.1X 時，請確保 WLC 上的 RADIUS 逾時值足夠因應雲端憑證驗證的延遲，通常會從 2 秒增加到 5 秒。」[1]
最佳實踐
- 隔離企業與訪客流量：企業裝置應使用與 Entra ID 綁定的 802.1X。訪客裝置應使用帶有 Captive Portal 的開放式 SSID。若要獲得強健的訪客存取與分析功能，請利用 Guest WiFi 解決方案。這可確保完全隔離不受信任的流量。
- 謹慎實施 MAC 驗證繞過 (MAB)：IoT 裝置與舊型硬體（例如 運輸 樞紐中的舊型掃描器）通常無法支援 802.1X。請使用 MAB 或專用 PSK 將這些裝置放置在獨立的 SSID 上，並透過嚴格的 ACL 限制其網路存取。
- 優先處理憑證撤銷：確保您的憑證撤銷清單 (CRL) 或線上憑證狀態協定 (OCSP) 端點具有高可用性。如果 RADIUS 伺服器無法驗證撤銷狀態，驗證將會失敗。
疑難排解與風險緩釋
當部署失敗時，極少是雲端 IdP 的問題。常見的失敗模式包括：
- 時鐘偏差：EAP-TLS 對時間極為敏感。確保所有基礎架構元件（特別是 WLC 和 RADIUS 伺服器）皆透過 NTP 進行同步。
- Intune 同步延遲：當註冊新裝置時，核發 SCEP 憑證與裝置嘗試連線可能需要一些時間。請在新手引導期間規劃此延遲時間。
- Radius 伺服器名稱不符：若 Intune WiFi 設定檔中定義的伺服器名稱與 RADIUS 伺服器憑證上的通用名稱 (CN) 或主體替代名稱 (SAN) 未完全一致，用戶端將會靜默中斷連線，以防止惡意 AP 的攻擊。
如需更多關於保護基礎設施安全的深入分析，請參閱我們的指南： 如何利用強大的 DNS 與安全性保護您的網路 。
投資報酬率與商業影響
轉移至 Azure Entra ID WiFi 驗證可帶來顯著的效益：
- 減少技術支援支出：消除基於密碼的驗證可大幅減少與密碼鎖定和 WiFi 憑證更新相關的支援工單。
- 加速合規進程：EAP-TLS 提供 PCI DSS 和 ISO 27001 等框架所需的密碼學身分證明，這對於 醫療保健 和零售環境至關重要。
- 自動化離職流程：當員工離職時，在 Entra ID 中停用其帳戶會立即撤銷其在所有地點的網路存取權限，從而降低內部威脅。
藉由保護企業核心網路，IT 團隊可以專注於創造營收的計畫，例如利用 WiFi Analytics 來了解訪客行為並提升參與度。
參考資料
[1] Microsoft Learn. (2023). Secure Wi-Fi access with Intune and EAP-TLS.
關鍵定義
802.1X
一個用於基於連接埠之網路存取控制的 IEEE 標準，要求裝置在獲得 LAN 或 WLAN 存取權限之前進行驗證。
這是讓企業級 WiFi 安全的核心通訊協定，超越了簡單的共享密碼。
EAP-TLS
採取傳輸層安全性的可延伸驗證協定。一種要求用戶端和伺服器端雙方皆具備數位憑證的驗證方法。
被認為是最安全的 WiFi 驗證方法，可防止憑證遭竊取和中間人（AiTM）攻擊。
RADIUS
遠端使用者撥入驗證服務。一種提供集中式驗證、授權和計費（AAA）的網路協定。
您的無線基地台（Access Point）用來詢問驗證伺服器「我應該讓這個裝置加入網路嗎？」的通訊協定。
SCEP
簡單憑證註冊協定。一種用於安全地向網路裝置發行憑證的協定。
由 Intune 等 MDM 平台使用，以背景無聲方式請求用戶端憑證，並將其安裝到公司筆記型電腦和手機上。
MAC Authentication Bypass (MAB)
一種根據裝置的 MAC 位址而非使用者名稱或憑證來授予網路存取權限的方法。
用作舊型裝置（如舊印表機或物聯網感測器）的備用方案，這些裝置缺乏執行 802.1X 交握的軟體。
Evil Twin Attack
偽裝成合法公司 SSID 的惡意無線基地台，旨在攔截流量或竊取憑證。
EAP-TLS 可減輕此威脅，因為用戶端裝置被設定為僅信任合法公司 RADIUS 伺服器的特定憑證。
Supplicant
終端裝置上的軟體用戶端（例如 Windows WiFi 管理員），負責處理 802.1X 驗證程序。
IT 團隊必須透過 MDM 設定要求者，以確保其安全運作，且不會提示使用者接受不受信任的伺服器憑證。
Conditional Access
評估訊號（使用者、位置、裝置合規性）以做出存取決策的 Azure Entra ID 原則。
現代 Cloud RADIUS 解決方案可在 WiFi 交握期間檢查條件式存取，如果 Intune 將裝置標記為不合規，則拒絕其網路存取。
範例
一家擁有 500 個據點的零售連鎖店需要保護用於庫存管理的後台 iPad。目前，他們在所有門市都使用單一共享的 PSK。他們應該如何移轉到 Azure Entra ID 驗證？
- 將所有 iPad 註冊到 Microsoft Intune 中。
- 部署與企業 Entra ID 租戶整合的 Cloud RADIUS 解決方案。
- 設定 Intune 以向每台 iPad 部署 SCEP 憑證。
- 透過 Intune 推送 WiFi 設定檔，設定 iPad 使用 EAP-TLS 連線到 "Corporate-BOH" SSID，並驗證 Cloud RADIUS 伺服器的憑證。
- 更新所有 500 家門市的 Meraki/Aruba 存取點，使其指向 "Corporate-BOH" SSID 的 Cloud RADIUS IP 位址。
- 分階段推出：啟用新的 SSID，透過 Intune 報告驗證 iPad 連線，然後停用舊有的 PSK SSID。
某大學校園正從地端 Active Directory 移轉到 Azure Entra ID。他們有數千台學生的 BYOD（攜帶自有裝置）筆記型電腦，目前使用 PEAP-MSCHAPv2（使用者名稱和密碼）進行連線。他們如何在雲端優先的 Entra ID 環境中處理 BYOD？
- 部署註冊入口網站（例如 SecureW2 JoinNow 或類似的 BYOD 註冊工具）。
- 學生連線到開放的 "Onboarding" SSID，系統會將其重新導向至該入口網站。
- 入口網站提示學生向 Azure Entra ID 進行驗證（使用其大學電子郵件和 MFA）。
- 驗證成功後，入口網站會產生一個唯一的用戶端憑證，並自動為學生的裝置設定 EAP-TLS。
- 裝置隨後會使用新憑證自動連線到安全的 "Edu-Secure" SSID。
練習題
Q1. 您的組織正在遷移到 Azure Entra ID 和 Intune。您目前使用 PEAP-MSCHAPv2 進行 WiFi。安全團隊要求 WiFi 驗證必須具備防範憑證遭竊的防禦能力。您應該部署哪種 EAP 方法？
提示：哪種方法完全依賴憑證而非密碼？
查看標準答案
您應該部署 EAP-TLS。EAP-TLS 使用雙向憑證驗證，這意味著用戶端裝置必須出示由您的 PKI 核發的有效憑證。因為它不使用密碼，所以能高度防範憑證遭竊和對手在中途攻擊（Adversary-in-the-Middle）。
Q2. 透過 Intune 部署 EAP-TLS 後，使用者回報無法連線至 WiFi。查看 RADIUS 記錄時，您發現「憑證撤銷檢查失敗」（Certificate Revocation Check Failed）。最可能的可能原因是什麼？
提示：RADIUS 伺服器必須與哪個基礎架構進行通訊，以驗證憑證未遭篡改或撤銷？
查看標準答案
RADIUS 伺服器無法存取您的憑證授權單位（CA）的憑證撤銷清單（CRL）或 OCSP 端點。請確保防火牆允許 RADIUS 伺服器輸出存取用戶端憑證中指定的 HTTP URL。
Q3. 一家醫院需要將 50 台舊型心率監視器連接到網路。這些裝置僅支援 WPA2-Personal（預共用金鑰），且無法註冊至 Intune。在維持公司筆記型電腦的 Entra ID 802.1X 部署的同時，您應如何保護這些裝置的安全？
提示：不要在同一個 SSID 上混合使用不同的驗證類型。
查看標準答案
為醫療 IoT 裝置建立專用的獨立 SSID。使用強大、唯一的預共用金鑰（或您的網路廠商支援的 Identity PSK/iPSK）或 MAC 驗證旁路（MAB）。至關重要的是，將此 SSID 放置在高度受限的 VLAN 上，並設定嚴格的存取控制清單（ACL），僅允許監視器與其特定的醫療伺服器通訊，阻斷所有其他橫向網路存取。
繼續閱讀本系列
各大廠商的 Per-Device PSK 比較：iPSK、DPSK、MPSK 與 PPSK（以及 WPA3 支援）
針對 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Extreme、Fortinet 和 Ubiquiti UniFi 的 per-device PSK 實作進行全面比較。了解 WPA3-SAE 如何影響 per-device 金鑰策略，以及何時該部署過渡模式或轉移至 802.1X。
Captive Portal 驗證方式比較
本權威技術參考指南評估了五種核心 Captive Portal 驗證方式在架構、營運及合規性方面的權衡。它為網路架構師、IT 總監和行銷經理提供了所需的量化數據與決策框架，以在企業場域中平衡訪客登入摩擦與數據收集需求。
什麼是 MAC 位址驗證？何時該使用以及何時該避免使用
本權威技術參考指南涵蓋企業 WiFi 環境中的 MAC 位址驗證 — 說明基於 RADIUS 的 MAC 驗證在 Layer 2 的運作方式、其固有的安全性漏洞（包括 MAC 欺騙以及作業系統層級 MAC 隨機化的影響），以及其作為管理 IoT 和無螢幕（headless）裝置有效工具的具體營運情境。本指南為餐飲旅宿、零售、醫療保健和公共場所的 IT 經理與網路架構師提供具體可行的部署指引，並包含實際案例、決策框架，以及與 Purple 的顧客 WiFi 和分析平台的整合情境。