跳至主要內容
繁體中文

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

一份針對 IT 主管的完整技術參考指南，介紹如何透過 Microsoft Intune 部署 802.1X WiFi 憑證。內容涵蓋 SCEP 與 PKCS 架構比較、實作步驟、合規性對應，以及企業環境中的實際部署情境。

📖 7 分鐘閱讀📝 344 字數🔧 2 範例❓ 3 練習題📚 8 關鍵定義

收聽此指南

查看播客逐字稿
如何使用 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）、扮演驗證者（authenticator）角色的 WiFi 存取點，以及做出最終決定的驗證伺服器 RADIUS 伺服器。 現在，802.1X 支援多種驗證方法。最安全的是 EAP-TLS - 搭配傳輸層安全性的可延伸驗證協定。EAP-TLS 使用雙向憑證驗證：裝置出示憑證以證明其身分，而 RADIUS 伺服器出示憑證以證明其身分。不涉及密碼。沒有可被釣魚的憑證資訊。這就是我們的目標。 挑戰一直在於如何大規模地將這些憑證部署到裝置上。這就是 Microsoft Intune 發揮作用的地方。 Intune 支援兩種憑證部署機制：SCEP（簡單憑證登冊協定）和 PKCS（公開金鑰密碼學標準）。瞭解兩者之間的差異至關重要。 使用 SCEP 時，私鑰是在裝置本身上產生的。裝置會建立一個憑證簽署要求，透過名為 NDES（網路裝置登冊服務）的中介伺服器將其傳送到您的憑證授權單位（CA），然後 CA 將憑證核發回去。私鑰永遠不會離開裝置。這是更安全的方法，建議用於 BYOD 環境和高安全性部署。使用 PKCS 時，憑證授權單位會產生金鑰組，並由 Intune Certificate Connector 將私鑰與憑證傳遞至裝置。這項設定較為簡單 - 不需要 NDES 伺服器 - 但私鑰確實會透過 Connector 傳輸，這是評估安全性狀況時需要考量的點。 對於大多數企業部署，我會建議在 BYOD 與混合裝置環境中使用 SCEP，而在您擁有同質的企業持有 Windows 裝置、且希望將基礎架構複雜度降至最低的環境中使用 PKCS。 現在，讓我們來談談部署順序 - 因為順序非常重要，而順序出錯是導致部署失敗最常見的原因。 步驟一：設定您的憑證授權單位。您需要在 Active Directory 憑證服務執行個體上準備憑證範本 - 或者，如果您是完全的雲端原生環境，Microsoft 的 Intune Cloud PKI 現已公開上市，可完全免除內部部署 CA 的需求。該範本需要正確的金鑰使用延伸項目：「用戶端驗證」是強制要求的。將最小金鑰大小設定為 2048 位元，如果您的組織安全性原則有要求，則設定為 4096 位元。 步驟二：部署信任的根憑證。在任何裝置可以驗證 RADIUS 伺服器的憑證之前，它必須先信任簽發該憑證的 CA。您可以在 Intune 中建立「信任的憑證」組態設定檔，上傳根 CA 憑證，並將其指派給您的裝置群組。這必須在任何 WiFi 設定檔或用戶端憑證設定檔之前送達裝置。如果順序出錯，裝置將會拒絕 RADIUS 伺服器，而您將會花費一整個下午盯著 Windows 事件檢視器中的事件 ID 20271。 步驟三：部署用戶端憑證設定檔。這可以是指向您的 NDES 伺服器 URL 的 SCEP 設定檔，或者是指向您的憑證授權單位的 PKCS 設定檔。主體別名（Subject Alternative Name）應包含用於使用者憑證的 User Principal Name，或用於裝置憑證的 AAD 裝置 ID。這個區別非常重要：使用者憑證驗證已登入的使用者，而裝置憑證則驗證機器本身，這意味著裝置可以在使用者登入之前連線至 WiFi - 這對於網域加入情境和公共資訊站（kiosk）部署非常有用。 步驟四：建立 WiFi 組態設定檔。在 Intune 中，這位於「裝置」、「組態設定檔」、「範本」、「Wi-Fi」之下。將 WiFi 類型設定為 Enterprise，輸入您的 SSID，將 EAP 類型設定為 EAP-TLS，設定伺服器信任設定 - 這是您引用 RADIUS 伺服器憑證名稱的地方 - 並針對用戶端驗證，引用您在步驟三中建立的憑證設定檔。 步驟五：將所有項目指派給正確的群組並進行驗證。將您的根憑證、用戶端憑證和 WiFi 設定檔指派給相同的裝置或使用者群組。使用 Intune 內建的報表來監控設定檔部署狀態。成功的部署會在裝置的組態設定檔清單中，將這三個設定檔全部顯示為「成功」。 關於 Windows Server 環境中 NPS 設定的一個關鍵要點：自 2024 年初起，Microsoft 收緊了憑證對應要求。如果您將裝置憑證與向地端 NPS 進行驗證的 Azure AD 已加入裝置搭配使用，則需要確保 Active Directory 中電腦物件上的 altSecurityIdentities 屬性已填入憑證的指紋。這不會自動發生 - 您需要一個腳本或工作流程來處理它，通常是在 CA 發行新憑證時觸發。 [實作建議與陷阱 - 約 2 分鐘] 讓我為您說明在企業部署中最強常見的三個陷阱。 第一個陷阱：憑證鏈中斷。裝置需要信任從根 CA 到 RADIUS 伺服器憑證鏈中的每個憑證。如果您的 RADIUS 伺服器憑證是由中介 CA 發行的，您需要將根憑證和中介憑證都部署到裝置中。我見過有些部署失敗了數週，只因為有人部署了根憑證，但沒有部署中介憑證。 第二個陷阱：設定檔指派時機。Intune 設定檔不會立即在裝置上生效。在大型環境中，設定檔在指派後可能需要 15 到 30 分鐘才能傳播。請勿在建立設定檔後立即進行測試。使用 Intune 入口網站中的「同步」按鈕來強制進行簽入，然後等待。此外，用戶端憑證設定檔必須在套用 WiFi 設定檔之前完成部署並確認 - 如果 WiFi 設定檔參照了尚不存在的憑證，則該設定檔在某些平台上將會無聲無息地失敗。 第三個陷阱：BYOD 憑證撤銷。當裝置從 Intune 取消註冊時（例如因員工離職或裝置遺失），您需要一個程序來撤銷該憑證。如果您將 SCEP 與 ADCS 搭配使用，請正確設定「憑證撤銷清單」發行點，並確保您的 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 的 guest WiFi 與分析平台如何與您的企業網路架構相結合，請造訪 purple.ai。我們針對飯店業、零售業和公共部門環境，提供了關於 Azure Entra ID 整合、802.1X 架構以及 guest 網路設計的詳細指南。 感謝您的收聽。我們下次見。

📚 核心系列的一部分：Enterprise WiFi Security Guide →

header_image.png

執行摘要

對於管理 旅宿業 、 零售業 或公共場所等大規模環境的企業 IT 領導者而言，安全的無線存取是一項基本的營運要求。仰賴共享的 PSK（預共用金鑰）或帳號/密碼驗證（PEAP-MSCHAPv2）會使網路面臨憑證遭竊、網路釣魚和合規性失效的風險。強大企業 WiFi 安全性的業界標準是採用 EAP-TLS（可延伸驗證協定傳輸層安全性）的 802.1X，這要求裝置與網路之間必須進行相互憑證驗證。

然而，以往採用 EAP-TLS 的主要障礙在於憑證生命週期管理的營運開銷。Microsoft Intune 透過自動化大規模向託管裝置派送、更新和撤銷數位憑證，解決了這個問題。

本技術文件詳細說明了透過 Microsoft Intune 推送 WiFi 憑證所需的架構、部署方法（SCEP 與 PKCS）以及實作步驟。它為網路架構師和系統工程師提供了具體可行的指引，協助其在確保企業通訊安全的同時，與訪客網路（例如由 Guest WiFi 平台管理的網路）保持嚴格隔離。

技術深入探討：架構與協定

若要有效實作憑證架構的驗證，IT 團隊必須瞭解行動裝置管理（MDM）平台、公開金鑰基礎建設（PKI）與網路存取控制層之間的互動。

802.1X 驗證框架

IEEE 802.1X 標準定義了基於連接埠的網路存取控制。在無線環境中，它會阻止裝置傳輸任何流量（EAP 驗證框架除外），直到其身份得到驗證。該架構由三個元件組成：

  1. Supplicant（用戶端）：請求網路存取的用戶端裝置（筆記型電腦、智慧型手機、平板電腦）。
  2. Authenticator（驗證器）：在驗證成功前阻擋流量的無線存取點或無線區域網路控制器。
  3. Authentication Server（驗證伺服器）：RADIUS（遠端使用者撥入驗證服務）伺服器（例如 Microsoft 網路原則伺服器 (NPS) 或 Cisco ISE），用於驗證憑證並授權存取。

EAP-TLS 與雙向驗證

EAP-TLS 是最安全的 EAP 方法，因為它需要雙向驗證。RADIUS 伺服器會向請求端出示其憑證以證明其為合法的企業網路（防止邪惡雙生攻擊），而請求端則向 RADIUS 伺服器出示其用戶端憑證以證明其為已授權的裝置或使用者。

architecture_overview.png

Intune 憑證部署機制：SCEP 與 PKCS

Microsoft Intune 支援兩種用於向裝置部署用戶端憑證的主要協定。選擇合適的機制是一項關鍵的架構決策。

簡易憑證登錄協定 (SCEP)

使用 SCEP 時，私鑰會直接在用戶端裝置上產生。裝置會建立憑證簽署要求 (CSR)，並透過 Intune 提交至網路裝置登錄服務 (NDES) 伺服器，該伺服器作為 Active Directory 憑證服務 (ADCS) 基礎架構的 Proxy。憑證授權單位 (CA) 會核發憑證，並將其傳回給裝置。

由於私鑰絕不會離開裝置，因此 SCEP 被視為高度安全，是 BYOD（攜帶自有裝置）部署與零信任架構的推薦方法。

公鑰密碼學標準 (PKCS)

使用 PKCS 時，Intune Certificate Connector 會代表裝置向 CA 要求憑證。CA 會產生公開憑證與私鑰，然後 Connector 會透過 Intune 將其安全地傳遞至裝置。

雖然 PKCS 簡化了基礎架構需求（不需要 NDES 伺服器），但私鑰會在網路中傳輸。此模式通常適用於公司擁有且完全受控的裝置群，在這些裝置群中，MDM 平台已經是高度受信任的元件。

certificate_deployment_comparison.png

實作指南：逐步部署步驟

透過 Intune 部署 WiFi 憑證需要精確的順序。未按順序部署設定檔是實作失敗最常見的原因。

步驟 1：準備公鑰基礎架構 (PKI)

無論是使用內部部署 ADCS 還是 Microsoft Cloud PKI 等雲端原生解決方案，憑證授權單位都必須設定適當的範本。

  • 金鑰用途：範本必須包含「用戶端驗證」OID (1.3.6.1.5.5.7.3.2)。
  • 金鑰大小：設定至少 2048 位元 (RSA) 的金鑰大小，以符合現代加密標準。
  • 主體名稱：對於使用者憑證，主體別名 (SAN) 應設定為使用使用者主體名稱 (UPN)。對於裝置憑證，請使用 Azure AD 裝置 ID。

步驟 2：部署信任的根憑證

在裝置可以進行驗證之前，它必須信任核發 RADIUS 伺服器憑證的 CA。

  1. 以 .cer 格式匯出根 CA 憑證（以及任何中介 CA 憑證）。
  2. 在 Intune 系統管理中心，導覽至 裝置 > 組態設定檔 > 建立設定檔。
  3. 選取平台並選擇 信任的憑證 設定檔類型。
  4. 上傳 .cer 檔案並將設定檔指派給目標裝置或使用者群組。

注意：此設定檔必須先成功套用到裝置，然後才能繼續執行後續步驟。

步驟 3：部署用戶端憑證設定檔

建立 SCEP 或 PKCS 憑證設定檔，以將身分識別憑證傳遞給 supplicant。

  1. 導覽至 裝置 > 組態設定檔 > 建立設定檔。
  2. 選取平台並選擇 SCEP 憑證 或 PKCS 憑證。
  3. 根據您的身分識別需求（使用者對比裝置）設定主旨名稱格式和 SAN。
  4. 指定金鑰儲存提供者 (KSP) - 通常是硬體備份安全性的信賴平台模組 (TPM)。
  5. 將設定檔指派給在步驟 2 中定位的相同群組。

步驟 4：設定 WiFi 設定檔

最後一個元件會將憑證與無線網路設定進行繫結。

  1. 導覽至 裝置 > 組態設定檔 > 建立設定檔。
  2. 選取平台並選擇 Wi-Fi 設定檔類型。
  3. 將 Wi-Fi 類型設定為 企業 並輸入正確的 SSID。
  4. 將 EAP 類型設定為 EAP-TLS。
  5. 在 伺服器信任 下，指定 RADIUS 伺服器憑證的確切名稱，並選取在步驟 2 中部署的信任的根憑證設定檔。
  6. 在 用戶端驗證 下，選取在步驟 3 中部署的 SCEP 或 PKCS 憑證設定檔。
  7. 將設定檔指派給目標群組。

最佳實踐與策略建議

裝置對比使用者憑證

網路架構規劃人員必須決定是要將憑證核發給裝置（電腦驗證）還是使用者（使用者驗證）。

  • 裝置憑證：允許電腦在使用者登入之前連線至 WiFi 網路。這對於初始裝置佈署、群組原則處理以及在登入畫面重設密碼至關重要。建議用於公司擁有的裝置。
  • 使用者憑證：將網路存取權與個人身分識別進行綁定。這提供了精細的稽核與角色型存取控制。建議用於 BYOD 情境。

網路分段與訪客存取

一項基本的安全原則是將企業 802.1X 網路與訪客或公共存取網路進行嚴格的邏輯隔離。Intune 管理的基礎架構應專門用於企業裝置和已驗證的員工。若要提供訪客存取權限，企業應部署一個由 Captive Portal 支援的專用 Guest WiFi SSID。這能確保未託管的裝置被隔離，同時仍允許企業透過 WiFi Analytics 平台收集訪客分析數據。若要深入瞭解如何保護這兩個區段的 DNS 基礎架構，請參閱我們的指南： Protect Your Network with Strong DNS and Security 。

解決 NPS 憑證對應需求

對於將 Microsoft Network Policy Server (NPS) 與已加入 Azure AD 裝置搭配使用的企業，Microsoft 推出了一項關鍵的設定變更。NPS 現在要求進行強功能憑證對應。

使用裝置憑證時，內部部署 Active Directory 中的電腦物件必須在其 altSecurityIdentities 屬性中填入憑證的詳細資料（通常為 X509IssuerSerialNumber）。IT 團隊必須實作排程指令碼或事件驅動工作流程，以便在 Intune 發行新憑證時更新此屬性，否則驗證將會失敗。

疑難排解與風險緩釋

當 802.1X 部署失敗時，問題幾乎總是出在憑證鏈或 Intune 設定檔順序中。

常見失敗模式

  1. 無聲 WiFi 設定檔失敗：如果 Intune WiFi 設定檔在用戶端憑證成功佈署之前套用到裝置，WiFi 設定檔通常會安裝失敗或無聲失敗。在對 WiFi 設定進行疑難排解之前，請務必先驗證裝置的個人憑證儲存區（Windows 上的 certmgr.msc）中是否存在憑證。
  2. 伺服器信任驗證錯誤：如果裝置拒絕 RADIUS 伺服器，請驗證 Intune WiFi 設定檔中指定的伺服器名稱是否與 RADIUS 伺服器憑證上的主體名稱或 SAN 完全相符。此外，確保整個憑證鏈（根憑證和中間憑證）都存在於裝置的受信任的根憑證授權單位儲存區中。
  3. 憑證撤銷清單 (CRL) 無法存取：如果 RADIUS 伺服器無法連線至憑證授權單位的 CRL 發佈點以驗證用戶端憑證的狀態，驗證將會被拒絕。請確保 CRL URL 具有高可用性，且可從 RADIUS 伺服器存取。

投資報酬率與業務影響

透過 Intune 轉換為憑證型 WiFi 驗證，可帶來顯著的營運與安全性投資報酬。

  • 風險緩釋：消除憑證收割、Pass-the-Hash 攻擊以及透過共用 PSK 進行未經授權網路存取的風險。
  • 營運效率：減少與密碼過期和 WiFi 連線問題相關的 IT 服務台支援票單。自動化的生命週期管理意味著憑證可在無需使用者介入的情況下以透明方式更新。
  • 合規性啟用：滿足嚴格的法規要求。對於零售環境，它直接滿足了 PCI DSS 對於強大無線加密與驗證的要求。對於公共部門和醫療保健機構，它符合零信任網路存取 (ZTNA) 的原則。

透過利用 Microsoft Intune 進行憑證部署，IT 團隊可以實現流暢、高度安全的無線體驗，並在背景自動運行，讓企業能專注於核心業務。

關鍵定義

802.1X

一種用於權限連接埠網路存取控制的 IEEE 標準，在裝置成功驗證之前，阻止未授權的裝置存取 LAN 或 WLAN。

在企業環境中，以企業級驗證取代共用 WiFi 密碼的基本安全性通協定。

EAP-TLS

帶有傳輸層安全性的可延伸驗證協定。一種驗證架構，要求用戶端和伺服器雙方使用數位憑證證明其身分。

在 Intune WiFi 設定檔中設定的特定協定，用於強制執行雙向憑證驗證，消除憑證被盜的風險。

SCEP

簡單憑證註冊協定。一種機制，用戶端裝置藉此產生自己的私鑰，並透過媒介伺服器向 CA 要求憑證。

BYOD 環境的首選部署方法，因為私鑰永遠不會在網路中傳輸。

PKCS

Public Key Cryptography Standards（公鑰加密標準）。在 Intune 的環境中，這是一種部署方法，由 CA 產生私鑰，並由 Intune Connector 安全地將其傳遞到裝置。

一種較簡單的部署架構，通常用於企業擁有的裝置群，因為它不需要 NDES 伺服器。

NDES

Network Device Enrolment Service（網路裝置登冊服務）。這是一個 Microsoft 伺服器角色，用作代理程式，允許在沒有網域認證的情況下執行的裝置從 Active Directory 憑證授權單位取得憑證。

在內部部署 ADCS 環境中透過 SCEP 部署憑證時，這是必要的基礎設施元件。

RADIUS

Remote Authentication Dial-In User Service（遠端使用者撥入驗證服務）。一種提供集中式驗證、授權和計費（AAA）管理的網路協定。

接收來自 WiFi 存取點的驗證請求並驗證裝置憑證的伺服器（例如 Microsoft NPS 或 Cisco ISE）。

Supplicant

終端用戶裝置（筆記型電腦、智慧型手機）上用於啟動 802.1X 驗證程序之軟體用戶端。

Intune WiFi 設定檔會設定原生 OS 的 supplicant（例如 Windows WLAN AutoConfig）以使用正確的憑證和 EAP 方法。

Certificate Revocation List (CRL)

由憑證授權單位發佈、並經過數位簽章的清單，其中包含已被撤銷且不應再被信任的憑證序號。

這對安全合規性至關重要；RADIUS 伺服器必須檢查 CRL，以確保連接的裝置未被回報遺失或遭竊。

範例

一家擁有 400 個據點的零售連鎖店正在部署公司擁有的平板電腦以進行庫存管理。這些裝置透過 Intune 進行完全管理，並已加入 Azure AD。裝置在開機後、任何特定使用者登入之前，需要立即存取網路以同步庫存資料庫。網路基礎架構使用 Cisco ISE 作為 RADIUS 伺服器。最佳的憑證部署策略是什麼？

IT 團隊應實作 PKCS 裝置憑證。

  1. 在憑證授權單位 (CA) 上設定裝置憑證範本。
  2. 透過 Intune 將根 CA 憑證部署至平板電腦。
  3. 在 Intune 中建立 PKCS 憑證設定檔，將主旨名稱格式設定為 Azure AD 裝置 ID ({{AAD_Device_ID}})。
  4. 建立指定 EAP-TLS 的企業級 WiFi 設定檔，並參照 ISE 伺服器的憑證名稱以及已部署的 PKCS 設定檔。
  5. 將所有設定檔指派給包含平板電腦的裝置群組。
考官評語： 此處適用 PKCS，因為裝置為公司所有且完全受管，從而降低了與私鑰傳輸相關的風險。裝置憑證是必需的，因為平板電腦在使用者登入之前需要網路存取。透過將目標指向 Azure AD 裝置 ID，Cisco ISE 可以驗證特定的硬體資產，並將其指派給正確的受限庫存 VLAN。

一家大型教學醫院允許醫護人員使用個人智慧型手機 (BYOD) 存取臨床排程應用程式。這些裝置透過工作設定檔註冊於 Intune 中。安全政策規定，個人裝置上不得儲存任何企業憑證，且如果裝置遭受入侵，必須立即撤銷其網路存取權限。應如何設計 WiFi 驗證？

醫院必須實作 SCEP 使用者憑證並結合 Intune 合規性政策。

  1. 部署 NDES 伺服器以向 CA 代理要求。
  2. 在 Intune 中建立 SCEP 使用者憑證設定檔，並將主體別名 (SAN) 設定為使用者主體名稱 ({{UserPrincipalName}})。
  3. 建立 Intune 合規性政策，要求最低作業系統版本、啟用螢幕鎖定且無越獄/根權限 (root)。
  4. 設定 CA 以發布高可用性的憑證撤銷清單 (CRL)。
  5. 設定 RADIUS 伺服器以在每次驗證嘗試時嚴格執行 CRL 檢查。
考官評語： 對於 BYOD，SCEP 是唯一可接受的選擇，因為私鑰是在個人裝置上產生的，無法被攔截。為了符合 HIPAA 和 GDPR 的稽核要求，必須使用使用者憑證將網路活動與特定的臨床醫生連結。關鍵組件是與 Intune 合規性政策的整合；如果裝置變得不合規，Intune 可以觸發憑證撤銷，而 RADIUS 伺服器的 CRL 檢查將立即封鎖網路存取。

練習題

Q1. 您的組織正在將企業 WiFi 從 PEAP-MSCHAPv2（使用者名稱/密碼）轉移到 EAP-TLS。在試行階段，數台 Windows 11 筆記型電腦成功接收了 Intune 設定檔，但無法連線至網路。查看 Windows 事件檢視器顯示事件 ID 20271，指出 RADIUS 伺服器憑證遭到拒絕。最可能的原因是什麼？

提示：思考雙向驗證所需的信任鏈。

查看標準答案

裝置缺少簽發 RADIUS 伺服器憑證的受信任根 CA 憑證。在 EAP-TLS 中，裝置必須驗證 RADIUS 伺服器的身分。IT 團隊必須確保包含根 CA（及任何中繼 CA）的「受信任的憑證」設定檔已透過 Intune 部署到裝置並成功安裝，然後 WiFi 設定檔才能嘗試連線。

Q2. 某公共部門場域正使用 Intune 和 PKCS 憑證為員工裝置部署 802.1X。他們還營運一個由 Guest WiFi 平台管理的獨立訪客網路。稽核員指出，如果員工的筆記型電腦失竊，該憑證在 12 個月內仍然有效。網路架構師該如何解決此風險？

提示：驗證伺服器如何得知憑證在到期前已不再有效？

查看標準答案

架構師必須實施健全的憑證撤銷流程。首先，確保 CA 將憑證撤銷清單（CRL）發佈到高可用性的發佈點。其次，設定 RADIUS 伺服器（例如 NPS），要求在每次驗證嘗試期間進行 CRL 檢查。最後，建立 Intune 營運程序，明確撤銷任何標記為遺失或遭竊之裝置的憑證，這將更新 CRL 並封鎖其網路存取。

Q3. 您正在為零售環境中的一組共享 Kiosk 裝置設計 Intune 部署。這些裝置每天都會重新啟動，且必須在任何使用者進行操作前，立即連線到企業網路以下載更新。您應該部署「使用者憑證」還是「裝置憑證」？以及應使用何種主體替代名稱（SAN）格式？

提示：思考裝置重啟後立即可用的狀態。

查看標準答案

您必須部署裝置憑證。由於資訊站（kiosk）在使用者登入前即需要網路連線，因此使用者憑證在開機時將無法使用。Intune 憑證設定檔中的主體別名（SAN）應設定為使用 Azure AD Device ID ({{AAD_Device_ID}}) 或裝置的完整網域名稱（FQDN），以便 RADIUS 伺服器驗證該特定硬體資產。

繼續閱讀本系列

為訪客與員工 WiFi 網路配置 RADIUS 驗證

本技術參考指南概述了企業訪客和員工 WiFi 網路的 RADIUS 驗證架構、配置與部署。它為網路架構師和 IT 經理提供了構建安全、可擴展的無線存取控制系統所需的確切協定、安全標準與疑難排解方法。

閱讀指南 →

Passpoint and OpenRoaming: 完整指南

本技術參考指南針對企業 WiFi 網路中的 Passpoint (Hotspot 2.0) 和 WBA OpenRoaming 架構提供全面分析。內容詳述了建立安全、無摩擦的訪客連線所需的底層驗證協定、架構元件和部署策略。網路架構師和 IT 領導者將學習如何設計、實作這些標準並進行疑難排解，以便在維持企業級安全性的同時，消除手動登入的障礙。

閱讀指南 →

如何在大專院校實施 SCEP 以實現安全的 BYOD 與網路註冊

本技術指南為網路架構師和 IT 經理提供了一個與廠商無關的藍圖，用於部署基於 SCEP 的憑證註冊，以保護大專院校校園網路的安全。它詳細介紹了如何從基於密碼的 PEAP 遷移到 802.1X EAP-TLS、自動化 BYOD 註冊，以及實施強大的 VLAN 區隔。

閱讀指南 →