透過 SCEP 與 PKCS 進行 Microsoft Intune WiFi 憑證部署

執行摘要

對於企業場所——無論是繁忙的 飯店業 環境、多據點的 零售業 營運，或是現代企業園區——仰賴預先共用金鑰或基本 Captive Portal 來提供員工 WiFi 是一種安全漏洞和營運瓶頸。現代網路架構要求使用 EAP-TLS 的 802.1X 驗證，確保每個裝置在存取網路前都經過加密驗證。

然而，挑戰在於散發：如何將唯一的用戶端憑證部署到數千台 Windows、iOS 和 Android 裝置，而不讓您的技術支援部門淹沒在支援工單中？Microsoft Intune 透過自動化憑證生命週期管理來解決這個問題。藉由運用 SCEP（Simple Certificate Enrollment Protocol）或 PKCS（Public Key Cryptography Standards）憑證設定檔，IT 團隊可以將受信任的根憑證和用戶端憑證以無提示方式推送至受管理的端點。

本指南為 Intune WiFi 憑證部署提供明確的架構藍圖和逐步實作策略。我們將探討 SCEP 與 PKCS 之間的關鍵差異，詳細說明成功部署所需的確切順序，並概述實際的風險降低策略，以確保您的 Guest WiFi 和企業網路保持安全且高效能。

收聽配套的播客簡報：

技術深入探討：SCEP 與 PKCS

在設計您的 Intune WiFi 憑證部署策略時，第一個架構決策就是選擇憑證傳遞機制。Intune 支援 SCEP 和 PKCS，但它們的運作方式有根本上的不同。

SCEP (Simple Certificate Enrollment Protocol)

SCEP 是企業裝置註冊的業界標準。在 SCEP 工作流程中，Intune 服務指示端點產生自己的私密/公開金鑰對。然後裝置會建立憑證簽署要求（CSR），並透過網路裝置註冊服務（NDES）伺服器將其傳送至您的憑證授權單位（CA）。CA 會簽署該要求並將公開憑證傳回給裝置。

SCEP 的關鍵安全優勢在於私密金鑰永遠不會離開裝置。它在本地產生，儲存在裝置的安全隔離區（例如 Windows 上的 TPM 或 iOS 上的 Secure Enclave）中，且絕不會透過網路傳輸。這使得 SCEP 成為 802.1X 驗證的強烈建議方法。

PKCS (Public Key Cryptography Standards)

相反地，使用 PKCS 時，憑證授權單位會集中產生公開和私密金鑰。然後 Microsoft Intune Certificate Connector 會安全地匯出此金鑰對，並將其推送至目標裝置。

雖然 PKCS 無需部署和維護 NDES 伺服器——簡化了基礎架構佔用空間——但它因為私密金鑰會透過網路傳輸而帶來了理論上的安全風險。PKCS 通常更適合需要金鑰託管的使用案例，例如 S/MIME 電子郵件加密，而不是網路驗證。

實作指南：部署順序

要成功設定用於 802.1X 的 Intune WiFi 設定檔，需要嚴格遵循特定的部署順序。Intune 設定檔的相依性規定，必須先建立信任，才能設定驗證。

步驟 1：部署受信任的根憑證設定檔

在任何裝置可以要求用戶端憑證或信任您的 RADIUS 伺服器之前，它必須信任核發的憑證授權單位。

1. 將您的根 CA 憑證（以及任何中繼 CA 憑證）匯出為 .cer 檔案。
2. 在 Microsoft Endpoint Manager 系統管理中心中，瀏覽至 裝置 > 設定檔 > 建立設定檔。
3. 選取目標平台（例如 Windows 10 及更新版本），並選擇 受信任的憑證 設定檔類型。
4. 上傳 .cer 檔案，並將此設定檔部署至您的目標裝置群組。

經驗法則：始終將所有相關設定檔的目標鎖定相同的群組（使用者或裝置），以防止部署不相符。

步驟 2：設定 SCEP 憑證設定檔

一旦建立信任，設定 SCEP 設定檔以指示裝置如何取得其用戶端憑證。

1. 建立新的設定設定檔，並選取 SCEP 憑證。
2. 設定 主體名稱格式。對於使用者驅動的驗證，CN={{UserPrincipalName}} 是標準格式。對於裝置驗證，使用 CN={{AAD_Device_ID}}。
3. 設定 金鑰用途 為 數位簽章 和 金鑰編密。
4. 在 延伸金鑰用途 下方，指定 用戶端驗證 (OID: 1.3.6.1.5.5.7.3.2)。
5. 將此設定檔連結至在步驟 1 中建立的受信任根憑證設定檔。
6. 提供您的 NDES 伺服器的外部 URL。

步驟 3：部署 802.1X WiFi 設定檔

最後一步是推送將憑證與網路 SSID 關聯起來的 WiFi 設定。

1. 建立一個 Wi-Fi 設定設定檔。
2. 輸入與您的無線存取點所廣播完全相同的 網路名稱 (SSID)。
3. 選取 WPA2-Enterprise 或 WPA3-Enterprise 作為安全類型。
4. 將 EAP 類型 設定為 EAP-TLS。
5. 在驗證設定中，選取在步驟 2 中建立的 SCEP 憑證設定檔作為用戶端驗證憑證。
6. 指定用於伺服器驗證的受信任根憑證，以確保裝置僅連線至您合法的 RADIUS 伺服器。

最佳做法與業界標準

實作 Intune WiFi 憑證部署時，請遵循以下廠商中立的最佳做法，以確保合規性和可靠性。

NDES 伺服器放置與安全性

NDES 伺服器必須可從網際網路存取，以便遠端裝置在抵達現場之前佈建憑證。然而，直接將內部伺服器公開至網際網路是一項重大的安全風險。

**建議：**使用 Azure AD Application Proxy 發佈 NDES URL。這可提供安全的遠端存取，無需開啟入埠防火牆連接埠，並可讓您將條件式存取原則套用至註冊流程。

RADIUS 與 CRL 檢查

憑證部署只是安全方程式的一半；撤銷功能同樣至關重要。如果員工被解僱，若其用戶端憑證仍然有效，且 RADIUS 伺服器並未嚴格檢查憑證撤銷清單 (CRL)，則停用其 Active Directory 帳戶可能無法立即撤銷其 WiFi 存取權。

**建議：**設定您的網路原則伺服器 (NPS) 或 RADIUS 伺服器以強制執行嚴格的 CRL 檢查。確保您的 CRL 發佈點 (CDP) 具有高可用性；如果 RADIUS 伺服器無法連線到 CRL，驗證將會失敗，導致大規模中斷。

如需更多有關安全網路設計的深入見解，請考慮檢閱 現代企業的核心 SD WAN 優勢。

疑難排解與風險降低

即使經過周詳的規劃，憑證部署仍可能遇到問題。以下是一些常見的失敗模式和緩解策略。

問題：WiFi 設定檔無法套用

**症狀：**裝置收到受信任的根憑證和 SCEP 憑證，但 WiFi 設定檔在 Intune 中顯示為「錯誤」或「不適用」。

**根本原因：**這幾乎總是因為群組目標不符所造成。如果 SCEP 設定檔指派給使用者群組，但 WiFi 設定檔指派給裝置群組，Intune 就無法解析相依性。

**緩解措施：**稽核您的指派。確保受信任的根憑證、SCEP 和 WiFi 設定檔全都部署到完全相同的 Azure AD 群組。

問題：NDES 403 禁止錯誤

**症狀：**裝置無法擷取 SCEP 憑證，且 NDES IIS 記錄顯示 HTTP 403 錯誤。

**根本原因：**Intune Certificate Connector 服務帳戶在憑證範本上缺少必要的權限，或是您防火牆上的 URL 篩選封鎖了 SCEP 所使用的特定查詢字串參數。

**緩解措施：**確認連接器帳戶在 CA 範本上具有「讀取」和「註冊」權限。檢查防火牆記錄，確保包含 ?operation=GetCACaps 的 URL 未被封鎖。

投資報酬率與業務影響

轉換至 Microsoft Intune 802.1X 憑證部署，可在安全性和營運方面帶來可衡量的回報。

1. **減少技術支援工單：**基於密碼的 WiFi 會產生大量的支援工單（密碼過期、鎖定、輸入錯誤）。基於憑證的驗證對使用者而言是看不見的，通常可將 WiFi 相關的技術支援量減少 70-80%。
2. **強化的安全態勢：**EAP-TLS 消除了憑據收集和中間人 (MitM) 攻擊的風險。這對於符合 PCI DSS 和 GDPR 等架構的規範至關重要，特別是在 醫療保健 和零售環境中。
3. **無縫上線：**對於同時管理大量 Apple 裝置和 Windows 裝置的組織，將 Intune 與現有的 MDM 工作流程整合（請參閱我們的指南：Jamf 與 RADIUS：Apple 裝置機群的基於憑證的 WiFi 驗證），可確保從第一天起就提供統一、零接觸的佈建體驗。