如何使用 Microsoft Intune 將 WiFi 憑證推送到裝置

如何使用 MICROSOFT INTUNE 將 WIFI 憑證推送到裝置 Purple 企業級 WiFi 智慧簡報 [引言與背景 — 約 1 分鐘] 歡迎回來。今天我代表企業級 WiFi 智慧平台 Purple 進行演說，本集節目將針對 Microsoft Intune 工具套件中，最實用且老實說最常被低估的功能之一進行重點簡報：用於 802.1X WiFi 驗證的自動化憑證部署。 如果您正在管理飯店物業、零售連鎖店、體育場館或公共部門的 WiFi，您一定懂我接下來要描述的痛點。您擁有數百或數千台託管裝置。您希望它們能自動、安全地連接到您的企業 WiFi，而無需使用者輸入密碼，也無需 IT 人員手動設定每台裝置。而且您希望該連線具有強大的加密性，而不僅僅是某人已經透過電子郵件發送給半個組織的共用密碼。 這正是 Intune 憑證部署所要解決的問題。在接下來的九分鐘內，我將帶您瞭解其運作原理、部署方式，以及大多數團隊在首次嘗試時會遇到的陷阱。 [技術深探 — 約 5 分鐘] 讓我們從架構開始。這裡的基礎是 IEEE 802.1X — 這是二十多年來作為企業 WiFi 安全骨幹的連接埠型網路存取控制標準。當裝置連接到您的 WiFi 時，802.1X 要求它在獲得任何網路存取權限之前先進行驗證。驗證對話在三方之間進行：裝置（稱為 supplicant 請求端）、您的 WiFi 存取點（作為驗證器），以及您的 RADIUS 伺服器（做出最終決定的驗證伺服器）。 現在，802.1X 支援多種驗證方法。最安全的是 EAP-TLS — 採用傳輸層安全協定的可延伸驗證協定。EAP-TLS 使用雙向憑證驗證：裝置出示憑證以證明其身分，而 RADIUS 伺服器也出示憑證以證明其身分。不涉及密碼。沒有可被網路釣魚竊取的憑證。這就是我們的目標。 挑戰一直以來都在於如何大規模地將這些憑證安裝到裝置上。這就是 Microsoft Intune 發揮作用的地方。 Intune 支援兩種憑證部署機制：SCEP（簡單憑證登冊協定）和 PKCS（公開金鑰加密標準）。瞭解兩者之間的差異至關重要。 使用 SCEP 時，私鑰是在裝置本身產生的。裝置會建立憑證簽署要求，透過名為 NDES（網路裝置登冊服務）的中介伺服器將其傳送至您的憑證授權單位 (CA)，然後 CA 會發行憑證並傳回。私鑰永遠不會離開裝置。這是更安全的方法，建議用於 BYOD 環境和高安全性部署。 使用 PKCS 時，憑證授權單位會產生金鑰組，並由 Intune Certificate Connector 將私鑰和憑證傳遞至裝置。這在設定上較為簡單（不需要 NDES 伺服器），但私鑰確實會經過該連接器傳輸，這是評估安全性狀況時需要考量的點。 對於大多數企業部署，我建議在 BYOD 和混合裝置環境中使用 SCEP；而在擁有同質企業專用 Windows 裝置且希望將基礎架構複雜度降至最低的環境中，則使用 PKCS。 現在，我們來談談部署順序 — 因為順序至關重要，而順序錯誤是導致部署失敗最常見的原因。 步驟一：設定您的憑證授權單位。您需要在 Active Directory 憑證服務執行個體上建立憑證範本 — 或者，如果您是完全雲端原生，Microsoft 的 Intune Cloud PKI 現已正式推出，可完全免除內部部署 CA 的需求。該範本需要正確的金鑰使用方法延伸模組：用戶端驗證是必備的。將最小金鑰大小設定為 2048 位元，如果貴組織的安全政策有要求，則設定為 4096 位元。 步驟二：部署信任的根憑證。在任何裝置能夠驗證 RADIUS 伺服器的憑證之前，它必須先信任發行該憑證的 CA。您可以在 Intune 中建立「信任的憑證」組態設定檔，上傳根 CA 憑證，並將其指派給您的裝置群組。這必須在任何 WiFi 設定檔或用戶端憑證設定檔之前送達裝置。如果順序出錯，裝置將會拒絕 RADIUS 伺服器，而您將會花上整個下午盯著 Windows 事件記錄中的事件識別碼 20271。 步驟三：部署用戶端憑證設定檔。這可以是您的 SCEP 設定檔（指向您的 NDES 伺服器 URL），或是您的 PKCS 設定檔（指向您的憑證授權單位）。主體別名（Subject Alternative Name）應包含使用者憑證的使用者主體名稱（UPN），或裝置憑證的 AAD 裝置識別碼。這個區別很重要：使用者憑證驗證已登入的使用者，而裝置憑證則驗證機器本身，這意味著裝置可以在使用者登入之前連線到 WiFi — 這對於網域加入情境和 Kiosk 部署非常有用。 步驟四：建立 WiFi 組態設定檔。在 Intune 中，這位於「裝置」>「組態設定檔」>「範本」>「Wi-Fi」。將 WiFi 類型設定為「企業級」，輸入您的 SSID，將 EAP 類型設定為「EAP-TLS」，設定伺服器信任設定（在此處引用 RADIUS 伺服器憑證名稱），並在用戶端驗證中引用您在步驟三中建立的憑證設定檔。 步驟五：將所有項目指派給正確的群組並進行驗證。將您的根憑證、用戶端憑證和 WiFi 設定檔指派給相同的裝置或使用者群組。使用 Intune 內建的報告功能來監控設定檔部署狀態。成功的部署會在裝置的組態設定檔清單中，將這三個設定檔皆顯示為「成功」。 關於 Windows Server 環境中 NPS 設定的一個關鍵點：自 2024 年初起，Microsoft 收緊了憑證對應要求。如果您在與 Azure AD 聯結的裝置上使用裝置憑證向內部部署的 NPS 進行驗證，則需要確保 Active Directory 中電腦物件上的 altSecurityIdentities 屬性已填入該憑證的指紋。這不會自動發生 — 您需要一個指令碼或工作流程來處理它，通常是在 CA 發行新憑證時觸發。 [實作建議與常見陷阱 — 約 2 分鐘] 讓我為您說明在企業部署中，我最常看到的的三個陷阱。 陷阱一：憑證鏈中斷。裝置需要信任從根 CA 到 RADIUS 伺服器憑證之憑證鏈中的每一個憑證。如果您的 RADIUS 伺服器憑證是由中繼 CA 發行的，您需要將根憑證和中繼憑證同時部署到裝置。我曾見過有些部署失敗了數週，只因為有人部署了根憑證卻沒有部署中繼憑證。 陷阱二：設定檔指派時機。Intune 設定檔不會立即套用到裝置上。在大型環境中，設定檔在指派後可能需要 15 到 30 分鐘才能傳播。請勿在建立設定檔後立即進行測試。請使用 Intune 入口網站中的「同步」按鈕強制進行簽入，然後耐心等待。此外，用戶端憑證設定檔必須在套用 WiFi 設定檔之前部署並確認 — 如果 WiFi 設定檔參照了尚不存在的憑證，該設定檔在某些平台上將會無聲無息地失敗。 陷阱三：BYOD 憑證撤銷。當裝置從 Intune 取消註冊時（例如因為員工離職或裝置遺失），您需要一個流程來撤銷憑證。如果您將 SCEP 與 ADCS 搭配使用，請正確設定憑證撤銷清單（CRL）發行點，並確保您的 RADIUS 伺服器在每次驗證時都會檢查 CRL 或 OCSP。這是 PCI DSS 等框架下的合規性要求，該框架規定在不再需要存取控制機制時，必須立即將其撤銷。 關於合規性的主題：如果您在 PCI DSS 範圍內營運（例如零售支付環境），基於憑證的 802.1X 驗證是您無線網路存取最強大的控制措施。它滿足了 PCI DSS 關於網路存取控制的要求 1.3 以及關於驗證要素的要求 8.6。請將您的憑證生命週期管理流程記錄下來，作為您合規性證據的一部分。 針對受 GDPR 規範的環境，特別是餐旅業與公共部門，企業 802.1X 網路與訪客 WiFi 網路之間的隔離至關重要。您由 Intune 管理的企業網路應位於與任何訪客或訪客網路完全獨立的 VLAN 和 SSID 上。Purple 的訪客 WiFi 平台負責處理面向訪客的部分（Captive Portal、同意書簽署、數據分析），而您由 Intune 管理的企業網路則處理員工和營運設備。這兩個網路絕不應共用驗證基礎架構。 [快速問答 — 約 1 分鐘] 讓我快速解答幾個經常出現的問題。 我可以使用 Intune Cloud PKI 代替地端 ADCS 嗎？可以。微軟於 2024 年推出的 Intune Cloud PKI 在 Azure 中提供了完全託管的 CA。它消除了 SCEP 對 NDES 伺服器的需求，並顯著簡化了連接器設定。對於全新部署或沒有現有 ADCS 基礎架構的組織，這是推薦的路徑。 這適用於 macOS 和 iOS 裝置嗎？是的。Intune 支援 Windows、iOS、iPadOS、Android 和 macOS 的憑證設定檔。設定檔類型和設定選項因平台而異，但核心架構（受信任的根憑證、用戶端憑證、WiFi 設定檔）是一致的。 BYOD 計劃中的個人裝置該如何處理？SCEP 是您的好幫手。透過 Intune 的裝置合規性原則，您可以要求裝置在核發憑證之前必須符合最低安全性標準。如果裝置不符合合規性（例如未設定螢幕鎖定、作業系統過舊），憑證將會被撤銷，並自動移除網路存取權限。 Purple 可以與此架構整合嗎？當然可以。Purple 的平台位於訪客網路端，負責處理 Captive Portal 驗證、同意書管理和數據分析。企業 802.1X 網路與 Purple 的訪客 WiFi 並行運作（相同的實體基礎架構，不同的 SSID 和 VLAN），讓您在員工連線與訪客互動之間實現完全隔離。 [總結與後續步驟 — 約 1 分鐘] 總結來說：透過 Intune 部署 WiFi 憑證是一個包含五個步驟的程序 — CA 設定、受信任的根憑證部署、用戶端憑證設定檔、WiFi 設定檔以及群組指派。針對 BYOD 和高安全性環境選擇 SCEP；針對較簡單的企業專用裝置選擇 PKCS。確保順序正確，處理好 NPS 憑證對應需求，並從第一天起就建立憑證撤銷工作流程。 商業效益顯而易見：您消除了共用的 WiFi 密碼、獲得了針對每個裝置和每個使用者的驗證記錄、滿足了 PCI DSS 和 ISO 27001 無線安全要求，並減少了在大型資產中管理 WiFi 認證資料的 IT 負擔。 如果您正在規劃部署，並希望了解 Purple 的顧客 WiFi 與分析平台如何與您的企業網路架構相結合，請造訪 purple.ai。我們針對 Azure Entra ID 整合、802.1X 架構，以及適用於餐旅、零售和公共部門環境的顧客網路設計，提供了詳細的指南。 感謝您的收聽。我們下次見。