Azure AD 與 Entra ID WiFi 驗證：整合與設定指南
本技術參考指南為 IT 經理、網路架構師和場所營運總監提供了一個實用的指引，協助其使用 RADIUS 和 802.1X 將 Microsoft Entra ID (Azure AD) 與企業 WiFi 網路進行整合。內容涵蓋了在地部署 Windows NPS 與雲端原生 RADIUS 之間的架構決策、透過 Microsoft Intune 部署憑證型 EAP-TLS 驗證，以及在旅宿、零售和公共部門環境中維護無線網路存取安全的操作最佳實踐。對於已經投資於 Microsoft 365 和 Entra ID 生態系統的組織，本指南填補了雲端身分識別管理與實體網路安全之間的鴻溝。
執行摘要
對於大量投資 Microsoft 生態系統的現代企業而言，將雲端身分識別基礎架構與實體無線網路相連結是一項關鍵的安全要務。在過去，WiFi 驗證依賴於內部部署的 Active Directory 網域服務 (AD DS) 和 Windows 網路原則伺服器 (NPS)。然而，隨著企業遷移到 Microsoft Entra ID（前身為 Azure AD）並採用零信任安全模型，傳統基於憑證的驗證方法 — PEAP-MSCHAPv2 — 已不再足夠或安全。
本指南為 IT 經理、網路架構師和場地營運總監提供實施 Azure AD WiFi 驗證的實用藍圖。我們將探討維護內部部署 NPS 與遷移到雲端原生 RADIUS 解決方案之間的架構差異。至關重要的是，我們將詳細說明如何利用 Microsoft Intune 進行憑證驗證 (EAP-TLS)，這能消除與密碼相關的漏洞，並為終端使用者提供無縫、無摩擦的體驗。無論您是管理擁有 500 間客房的飯店、零售連鎖店，還是大型公共部門部署，本指南都將協助您利用現有的 Microsoft 身分識別投資來確保無線邊緣的安全。如需更廣泛的部署模型討論，請參閱我們的 雲端 RADIUS 與內部部署 RADIUS：IT 團隊決策指南 。
技術深入探討：架構與標準
安全企業 WiFi 的基礎是 IEEE 802.1X 標準，它提供基於連接埠的網路存取控制。在以 Microsoft 為中心的環境中，將 802.1X 與 Entra ID 整合需要對三個層級進行仔細的架構規劃：無線基礎架構、驗證伺服器和身分識別目錄。
RADIUS 和 802.1X 的角色
當用戶端裝置（請求者）嘗試連線至 WPA2/WPA3-Enterprise 網路時，無線存取點（驗證者）會阻擋除了 EAP (Extensible Authentication Protocol) 封包以外的所有流量。存取點會將這些封包轉發至 RADIUS 伺服器。RADIUS 伺服器會根據目錄服務驗證使用者或裝置的身分，並傳回 Access-Accept 或 Access-Reject 訊息。這種三方模型（請求者、驗證者、驗證伺服器）是企業級無線網路安全的基石，並在我們的 Wireless Access Points Definition: Your Ultimate 2026 Guide 中有詳細說明。
Microsoft 環境的架構方法
將 Microsoft 身分識別與 WiFi 驗證整合主要有兩種架構，各自有不同的權衡：
| 維度 | 混合在地部署 (NPS) | 雲端原生 (Cloud RADIUS) |
|---|---|---|
| 基礎架構 | 需要 Windows Server VM 或實體機 | 無需在地部署伺服器 |
| 身分識別來源 | 透過 LDAP/Kerberos 連結 AD DS | 透過 API 直接連結 Entra ID |
| 憑證授權單位 | 在地部署 ADCS + Intune 連接器 | Intune Cloud PKI 或廠商 PKI |
| 擴充性 | 手動高可用性 (HA)/負載平衡 | 由服務商自動擴充 |
| 最適合 | 混合式 AD、舊型裝置 | 雲端優先、由 Intune 管理的組織 |
| 運作複雜度 | 初期與後續管理成本較高 | 較低的營運開銷 |
混合在地部署 (Windows NPS + AD DS + Azure AD Connect)： 這是傳統的方法。Windows NPS 作為 RADIUS 伺服器，對比在地部署的 Active Directory 驗證請求。為了將其連結至雲端，Azure AD Connect 會將在地部署的身分識別同步至 Entra ID。雖然此方法穩健，但如果實作 EAP-TLS，則需要維護在地部署伺服器基礎架構、管理高可用性，並部署複雜的 PKI (ADCS)。
雲端原生 (Cloud RADIUS + Entra ID + Intune)： 這種現代方法消除了對在地部署 NPS 伺服器的需求。第三方 Cloud RADIUS 服務商透過 Microsoft Graph API 直接與 Entra ID 整合。驗證完全在雲端進行。此架構符合雲端優先策略，顯著減少營運開銷，並符合零信任網路存取原則。
EAP-TLS vs. PEAP-MSCHAPv2：關鍵抉擇
選擇 EAP 方式是此部署中最重要的單一安全性決策。PEAP-MSCHAPv2 仰賴使用者輸入其網域認證。這容易遭受認證竊取和中間人攻擊，且在密碼過期時會產生不佳的使用者體驗。研究一致顯示，PEAP-MSCHAPv2 可能會因惡意存取點攻擊而遭到破解。
EAP-TLS（傳輸層安全性協定）是安全 WiFi 的業界黃金標準。它使用安裝在用戶端裝置上的數位憑證進行雙向驗證——用戶端與伺服器皆須證明其身分。無需輸入密碼，且連線具有極高的密碼學強度。在 Microsoft 環境中，憑證通常是透過 SCEP（簡單憑證登記協定）或 PKCS，並使用 Microsoft Intune 進行部署。這是所有新部署的建議路徑，且對於符合 PCI DSS（要求 8）與 GDPR 資料保護義務至關重要。
實作指南：逐步部署步驟
使用 EAP-TLS 與 Intune 實作 Entra ID WiFi 驗證，需要協調身分識別、裝置管理和網路基礎架構等多個元件。建議將下列五個階段的方法用於雲端原生部署。
階段 1：準備身分識別與裝置管理基礎架構
首先，請確認您的 Entra ID 租戶擁有適當的授權。Microsoft 365 E3/E5 或 Enterprise Mobility + Security (EMS) E3/E5 包含此部署所需的 Intune 裝置管理與條件式存取功能。若沒有 Intune，就無法進行自動化憑證部署。
接著，建立您的公開金鑰基礎架構 (PKI)。您有三個選項：由您的 Cloud RADIUS 廠商提供的雲端原生 PKI、Microsoft 專屬的 Cloud PKI（隨附於 Intune Suite 授權），或是透過 Microsoft Intune Certificate Connector 連線至 Intune 的現有內部部署 ADCS。對於新部署，強烈建議使用雲端原生 PKI，以避免對內部部署的依賴。
階段 2：設定用於憑證部署的 Intune
在 Microsoft Intune 系統管理中心，建立一個信任的憑證組態設定檔。上傳您 PKI 的根 CA 憑證，並將其部署到您的目標裝置群組。此步驟至關重要：它可確保用戶端裝置信任 RADIUS 伺服器在 TLS 握手期間提供的憑證，從而防止中間人攻擊。
接著，建立一個 SCEP 憑證設定檔（若您的 PKI 需要，亦可為 PKCS）。設定主體名稱格式——若為基於使用者的驗證，請使用 CN={{UserPrincipalName}}；若為基於裝置的驗證，請使用 CN={{DeviceName}} 或裝置序號。設定主體別名 (SAN) 以包含使用者主體名稱或裝置識別碼。將這兩個設定檔指派給適當的 Entra ID 裝置或使用者群組。
階段 3：設定 Cloud RADIUS 整合
在您的 Entra ID 租戶中，授予您的 Cloud RADIUS 供應商所需的 Microsoft Graph API 權限。該供應商至少需要 User.Read.All 與 GroupMember.Read.All 權限，以便在驗證期間確認群組成員身份。部分供應商可能還需要 Device.Read.All 權限來執行基於裝置的原則。
在 Cloud RADIUS 管理入口網站中定義您的驗證原則。一個適用於企業環境、結構完善的原則可能如下："若憑證由 [受信任的 CA] 發行，且使用者為 [Corporate-WiFi-Users] Entra ID 群組的成員，且裝置在 Intune 中被標記為合規，則允許存取。" 這種分層原則可同時強制執行身分識別與裝置健康狀況。
階段 4：設定無線基礎架構
在您的無線區域網路控制器或雲端管理儀表板（例如 Cisco Meraki、Aruba Central 或 Juniper Mist）中，將 Cloud RADIUS 伺服器 IP 位址和共用金鑰新增為 RADIUS 驗證伺服器。設定主要與次要伺服器以提供備援。將 RADIUS 逾時設定為至少 5 秒，以因應雲端往返延遲。
建立一個設定為 WPA2-Enterprise 或 WPA3-Enterprise 的新 SSID。將 RADIUS 伺服器指派給此 SSID。對於 旅宿業 部署，請確保此企業 SSID 與任何訪客網路位於不同的 VLAN。對於 零售業 環境，請考慮僅在後勤區域部署企業 SSID，以保持賣場網路的獨立。
階段 5：透過 Intune 部署 WiFi 設定檔
在 Intune 中建立 WiFi 組態設定檔。設定 SSID，使其與您在無線基礎架構上設定的內容完全一致。選取 WPA2-Enterprise 或 WPA3-Enterprise 作為安全性類型。在 EAP 設定下，選取 EAP-TLS 作為驗證方法。將 SCEP 憑證設定檔連結為用戶端憑證，並指定您在階段 2 中部署的「受信任的根 CA」設定檔。
將此 WiFi 設定檔指派給接收憑證設定檔的相同裝置群組。裝置將在下一次 Intune 同步期間靜默接收憑證與 WiFi 設定，並在進入 SSID 範圍時自動連線，無需任何使用者互動。
企業環境的最佳實踐
以下建議代表了在企業場域中部署安全、具擴充性之 Microsoft 802.1X 的產業共識。
在所有新部署中強制執行 EAP-TLS。 請勿使用 PEAP-MSCHAPv2 部署新網路。基於認證（帳密）的 WiFi 所帶來的安全風險已有詳盡記錄，且與零信任安全態勢不相容。EAP-TLS 對於符合 PCI DSS、GDPR 與 ISO 27001 規範至關重要。
自動化憑證生命週期。 確保在 Entra ID 中停用使用者或在 Intune 中淘汰裝置時，系統會自動撤銷相對應的憑證，或由 RADIUS 策略立即封鎖存取。這在人員變動頻繁的高流動率環境中尤為重要，例如 餐旅業 與 零售業 。
實施 Entra ID 條件式存取。 利用條件式存取策略來強制執行裝置合規性，以此作為網路存取的條件。要求裝置必須在 Intune 中被標記為「合規」，才能向 RADIUS 進行驗證，以確保只有已安裝修補程式且符合策略的裝置才能存取公司網路。
嚴格區隔公司網路與訪客網路。 802.1X 是專為受控的公司裝置而設計。對於訪客、承包商和 BYOD，請部署具備 Captive Portal 的專屬 訪客 WiFi 解決方案。這可以與 Entra ID B2B 整合以供承包商存取，或使用社群媒體登入和簡訊驗證供一般大眾存取。絕不允許未受控的裝置進入公司的 802.1X SSID。
針對舊版與 IoT 裝置進行規劃。 印表機、IoT 感測器和不支援憑證的舊版裝置需要採取不同的策略。對已知裝置使用 MAC 驗證旁路 (MAB)，或使用具有複雜且定期輪替之 PSK 的專屬 WPA2-Personal SSID，並隔離在專屬的 VLAN 中。例如，Purple 的 感測器 平台可以在與公司驗證基礎架構隔離的專屬 IoT VLAN 上運作。
監控驗證事件。 將 RADIUS 記錄與您的 SIEM 整合，或使用 WiFi 分析 平台來監控驗證失敗、憑證過期警告和異常存取模式。主動監控可在斷線影響營運前防患於未然。
疑難排解與風險緩釋
即使是規劃完善的部署也可能會遇到問題。以下是最常見的故障模式及其解決方案。
憑證部署失敗。 EAP-TLS 部署中最常見的問題是裝置無法從 Intune 接收憑證。這通常是由於 Intune Certificate Connector 設定錯誤（如果使用內部部署的 ADCS）、SCEP URL 不正確或裝置未與 Intune 同步所致。請務必在 Intune 管理中心驗證 Certificate Connector 的狀態，並檢查裝置同步記錄。確保 SCEP 服務帳戶在憑證授權單位 (CA) 上具有必要權限。
RADIUS 超時問題。 如果存取點無法在設定的超時時間內連線至 RADIUS 伺服器，用戶端將無法連線。請確保您的防火牆規則允許將 UDP 連接埠 1812（驗證）和 1813（帳務）輸出至 Cloud RADIUS 供應商的 IP 範圍。如果使用內部部署的 NPS，請部署至少兩個 NPS 伺服器，並將您的存取點設定為在它們之間進行容錯移轉。 **憑證信任失敗。**如果用戶端收到「未受信任的伺服器憑證」錯誤，表示「受信任的根 CA」設定檔未正確佈署至裝置。請驗證 Intune 中的設定檔指派，並檢查裝置的憑證存放區。這是剛註冊且尚未完成首次 Intune 同步的裝置常見的問題。
**適用於 Azure MFA 的 NPS 延伸模組。**雖然在技術上可以使用 NPS 延伸模組來對 WiFi 強制執行多因素驗證，但強烈建議不要將其用於主要存取。裝置在存取點之間漫遊時，每次都收到 MFA 提示的使用者體驗會造成嚴重干擾。請依賴裝置憑證提供的強驗證，並改在應用程式層強制執行 MFA。
**群組原則衝突。**在混合式環境中，設定 Windows 無線用戶端的群組原則物件 (GPO) 可能會與 Intune WiFi 設定檔發生衝突。請透過審查 MDM 註冊設定，確保 Intune 設定檔具有優先權，並在必要時針對 Intune 管理的裝置封鎖基於 GPO 的無線設定。
投資報酬率與商業影響
遷移至與 Entra ID 整合的雲端原生 RADIUS 架構，可在多個維度上提供可衡量、可量化的價值。
**減少技術支援中心工單。**在基於認證的環境中，與密碼相關的 WiFi 問題（鎖定、密碼過期、設定錯誤的 supplicant）是 IT 支援工單的主要來源。EAP-TLS 完全消除了這些問題。企業組織通常會報告，在遷移至基於憑證的驗證後，與 WiFi 相關的技術支援中心工單數量減少了 30% 到 50%。
**基礎設施成本節省。**汰換內部部署的 NPS 伺服器可降低運算成本、作業系統授權費用，以及修補和維護高可用性叢集的營運開銷。對於運行兩台 NPS 伺服器的中型組織，這可能代表每年在基礎設施和營運成本上節省 15,000 至 30,000 英鎊。
**強化安全性與合規性。**擺脫基於認證的驗證可降低認證遭竊和橫向移動的風險，進而保護敏感的企業資料。對於適用 PCI DSS 的組織，這直接解決了網路存取控制的要求。對於處理患者資料的 醫療保健 組織，它支援 DSPT 合規性。對於 運輸 營運商，它符合 NIS2 指令對網路安全的要求。
**提升使用者體驗。**無縫、自動的 WiFi 連線（無需密碼提示、無鎖定、無需手動設定）可提高生產力並減少員工的阻礙。這在配送中心、醫院病房和零售賣場等高行動性環境中尤其具有影響力。 將您的 WiFi 網路視為雲端身分策略的延伸，您就能確保安全、流暢且可隨著企業規模調整的存取體驗。如需現代企業網路 SD-WAN 整合層面的進一步指南，請參閱 現代企業的核心 SD-WAN 優勢 。針對旅宿業專屬的部署考量，請參閱 值得您賓客擁有的現代旅宿 WiFi 解決方案 。
關鍵定義
802.1X
一個用於基於連接埠的網路存取控制（PNAC）的 IEEE 標準。它為希望連接到 LAN 或 WLAN 的裝置提供驗證機制，在驗證完成前阻止未授權的存取。
阻止未授權裝置存取企業網路的基礎協定。所有 WPA2/WPA3-Enterprise 部署都依賴 802.1X。
RADIUS (Remote Authentication Dial-In User Service)
一種網路協定，為連接和使用網路服務的使用者提供集中式的驗證、授權和計費（AAA）管理。定義於 RFC 2865。
此伺服器元件負責比對目錄（Entra ID 或 AD DS）驗證憑證，並指示存取點允許或拒絕存取。
Supplicant
嘗試連接到網路的用戶端裝置（筆記型電腦、智慧型手機、IoT 裝置）。在 Windows 中，內建的無線用戶端即扮演 supplicant 的角色。
在 Intune 部署中，必須為 supplicant 設定正確的 WiFi 設定檔和用戶端憑證，才能與 RADIUS 伺服器成功通訊。
Authenticator
一種網路裝置（通常為無線存取點或網管型交換器），用於促進 supplicant 與 RADIUS 伺服器之間的驗證程序。它根據 RADIUS 的回應來執行存取控制。
存取點必須設定 RADIUS 伺服器 IP 位址和共用金鑰。它扮演中繼角色，在用戶端與 RADIUS 伺服器之間轉發 EAP 封包。
EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)
一種 EAP 方法，依賴數位憑證在用戶端與 RADIUS 伺服器之間進行雙向驗證。它定義於 RFC 5216，被認為是目前最安全的 EAP 標準之一。
適用於所有全新 Microsoft 802.1X 部署的推薦驗證方法。它完全免除了密碼，且為符合 PCI DSS 和零信任網路存取框架的必要條件。
NPS (Network Policy Server)
Microsoft 對 RADIUS 伺服器和代理程式的實作，作為 Windows Server 中的一個角色提供。NPS 可以比對 Active Directory Domain Services 驗證使用者和裝置。
Microsoft 環境中用於企業 WiFi 驗證的傳統地端解決方案。隨著向 Entra ID 遷移，許多組織正從 NPS 遷移到 Cloud RADIUS 解決方案。
SCEP (Simple Certificate Enrollment Protocol)
一種用於以可擴充且自動化的方式向網路裝置核發數位憑證的協定。定義於 RFC 8894。
Microsoft Intune 用於向受管理裝置無感部署用戶端憑證以進行 EAP-TLS WiFi 驗證的主要方法。需要與 SCEP 相容的憑證授權單位（CA）。
Microsoft Entra ID
Microsoft 的雲端身分識別與存取管理服務，前身為 Azure Active Directory。它提供使用者驗證、群組管理、條件式存取以及與數千個應用程式的整合。
現代 Microsoft 環境中的核心身分識別提供者。Cloud RADIUS 解決方案透過 Microsoft Graph API 與 Entra ID 整合，以在 WiFi 驗證期間驗證使用者和裝置身分。
Conditional Access
一項 Entra ID 功能，根據使用者身分、裝置合規狀態、位置和風險等級等訊號來強制執行存取原則。原則可要求裝置在獲得存取權限之前必須符合 Intune 合規性。
用於進階 RADIUS 部署，以確保只有合規且受管理的裝置才能驗證到企業 WiFi 網路，即使它們出示了有效的憑證也是如此。
PEAP-MSCHAPv2
受保護的 EAP 與 Microsoft 盤問交握驗證協定版本 2。一種基於憑證的 EAP 方法，使用使用者名稱和密碼進行驗證，並在 TLS 工作階段中建立通道。
許多現有 NPS 部署中使用的舊版驗證方法。它容易受到憑證竊取和中間人攻擊，在所有新部署中都應遷移至 EAP-TLS。
範例
一家擁有 200 個據點的零售連鎖店需要為店長筆記型電腦提供安全的後台 WiFi。他們目前在所有門市都使用共享的 WPA2-Personal 密碼 (PSK)，且極少更換。他們使用 Entra ID 和 Intune 進行裝置管理。他們應該如何實現無線網路安全的現代化？
該零售連鎖店應在所有 200 個據點遷移至使用 EAP-TLS 的 WPA3-Enterprise。推薦的架構是將 Cloud RADIUS 解決方案直接與他們的 Entra ID 租戶整合，從而消除在每個站點部署本地 NPS 伺服器的需求。透過 Intune，他們部署 SCEP 憑證設定檔，以向店長筆記型電腦核發唯一的裝置憑證。首先部署受信任的根 CA 設定檔，以確保裝置信任 RADIUS 伺服器。接著透過 Intune 部署 WiFi 設定設定檔，使用核發的憑證將裝置背景無感連接到新的 SSID。一旦所有裝置完成遷移，即停用舊的 PSK SSID。對於門市面向顧客的 WiFi，則由獨立的 Captive Portal 解決方案處理訪客存取，不會影響企業身分驗證基礎架構。
一家大型會議中心使用本地 Windows NPS 進行員工 WiFi 身分驗證。在大型活動期間，由於 NPS 伺服器因來自 500 多部員工裝置的並行驗證請求而載荷過重，他們經常遇到連線故障。他們也正在將其身分識別基礎架構遷移至 Entra ID。未來的推薦架構是什麼？
該會議中心應從本地 NPS 伺服器遷移至直接與 Entra ID 整合的 Cloud RADIUS 供應商。員工裝置應過渡到透過 Intune 管理的憑證型驗證 (EAP-TLS)，同時解決擴充性問題和 Entra ID 遷移需求。針對大量活動參與者，使用 Captive Portal 解決方案的獨立分段網路可處理訪客引導，而不會影響企業 RADIUS 基礎架構。這兩個網路應位於不同的 VLAN 上，並在它們之間設定適當的防火牆規則。一旦所有員工裝置成功遷移，即可停用本地 NPS 伺服器。
練習題
Q1. 貴組織正在完成從地端 Active Directory 全面移轉至僅限 Entra ID 的程序——將不再保留任何地端網域控制站。目前您使用 Windows NPS 搭配 PEAP-MSCHAPv2 進行 WiFi 驗證。針對全新的純雲端環境，最安全且營運效率最高的方法是什麼？需要哪些具體步驟？
提示：請思考 NPS 運作需要哪些條件，以及移轉後這些依賴關係是否依然存在。同時也要考量目前 EAP 方法的安全影響。
查看標準答案
最安全且高效的方法是實作與 Entra ID 直接整合的 Cloud RADIUS 解決方案，並過渡到透過 Microsoft Intune 管理的 EAP-TLS 憑證型驗證。NPS 無法直接對 Entra ID 進行驗證——它需要地端 AD DS——因此在沒有 Azure AD Connect 維持混合身分識別的情況下，它無法在移轉後繼續運作。步驟如下：(1) 選擇 Cloud RADIUS 供應商，並在 Entra ID 中授予其 Microsoft Graph API 權限。(2) 建立雲端原生 PKI 或使用 Microsoft Cloud PKI。(3) 透過 Intune 部署信任的根 CA 和 SCEP 憑證設定檔。(4) 透過 Intune 部署設定為 EAP-TLS 的 WiFi 設定檔。(5) 設定無線基礎架構上的 SSID 以使用 Cloud RADIUS 伺服器。(6) 在所有裝置移轉完成後停用 NPS。
Q2. 醫院 IT 小組希望使用 Entra ID 為其醫療推車（Windows 筆記型電腦）實作 802.1X。他們希望確保若推車遭竊，即使相關聯的使用者帳戶仍處於啟用狀態，該推車也無法連線至網路。應如何設定憑證設定檔和 RADIUS 策略以實現此目標？
提示：請思考 Intune 中使用者型憑證設定檔與裝置型憑證設定檔之間的差異，以及 RADIUS 策略如何將範圍限定於裝置身分。
查看標準答案
IT 小組應設定 Intune 以將裝置憑證（而非使用者憑證）部署至醫療推車。在 SCEP 設定檔中，主體名稱（Subject Name）應參照裝置身分（例如 CN={{DeviceName}} 或裝置序號），而非使用者 UPN。RADIUS 策略應設定為驗證裝置憑證，並比對 Entra ID 裝置物件來驗證該裝置。若推車遭竊，IT 小組可以透過 Intune 遠端抹除裝置（這會從裝置的憑證存放區中移除憑證），或在 PKI 中撤銷該特定裝置憑證。不論採取哪種動作，都會立即封鎖網路存取，且不影響任何使用者帳戶。對於醫療推車等共用裝置，此方法優於使用使用者型憑證。
Q3. 您已成功透過 Intune 為大學校園內的所有 800 台公司筆記型電腦部署了 EAP-TLS。然而，IT 部門經常引進外部承包商，他們需要網際網路存取權限以進行專案工作。這些承包商使用自己的個人或公司配發的筆記型電腦，且未註冊到您的 Intune 租戶中。在不危害公司 802.1X 網路安全的前提下，您應該如何為這些承包商提供存取權限？
提示：請記住區分託管裝置驗證與未託管裝置存取的架構原則。思考如何利用 Entra ID B2B。
查看標準答案
請勿嘗試為未託管的承包商裝置佈建 802.1X 存取權限。相反地，請部署一個由 Captive Portal 解決方案支援的獨立客用 SSID。對於擁有自己公司 Entra ID 租戶的承包商，請設定 Captive Portal 以支援 Entra ID B2B 共同作業，允許他們透過入口網站使用自己的公司認證進行驗證。對於沒有相容身分識別提供者的承包商，請使用贊助式存取工作流程，由大學工作人員核准存取要求。承包商網路應位於獨立的 VLAN 上，僅限存取網際網路，且沒有通往大學內部資源的路由。這可在為外部各方提供安全、可稽核的存取路徑之同時，維持 802.1X 公司網路的完整性。
Q4. 在部署後審查期間，您的安全性小組指出，儘管已推出 EAP-TLS，公司 WiFi 上的某些裝置仍在使用 PEAP-MSCHAPv2。調查顯示這些是 IoT 裝置——智慧顯示器、環境感測器和整批網路印表機——它們不支援憑證型驗證。應該如何處理這些裝置？
提示：請考慮不支援 EAP-TLS 的裝置有哪些可用選項，以及網路分段的重要性。
查看標準答案
不支援 EAP-TLS 的 IoT 裝置和舊型硬體不應放置於公司的 802.1X SSID 上。推薦的方法是在獨立的 VLAN 上建立專用的 IoT SSID，並搭配嚴格的防火牆規則，將通訊限制在僅限這些裝置所需的服務（例如列印伺服器、管理平台）。針對驗證，對於已知且固定 MAC 地址的裝置，請使用 MAC 驗證旁路（MAB），或使用具有複雜且定期輪替之 PSK 的 WPA2-Personal SSID。IoT VLAN 應無法存取公司檔案共用、Active Directory 或敏感的內部資源。例如，Purple 的 Sensors 平台即設計為在專用的 IoT 網路區段上運作，與公司基礎架構隔離。
繼續閱讀本系列
CommScope Ruckus 與 Purple WiFi 整合：安裝與設定指南
本技術參考指南為 CommScope Ruckus 架構與 Purple WiFi 的整合提供了權威的設定指南。其中詳細介紹了使用 Guest WiFi Captive Portal、透過 802.1X 的安全員工 WiFi，以及使用 Ruckus Dynamic PSK 的多租戶網路隔離的逐步部署步驟。
Allied Telesis 基地台與 Purple WiFi 整合
本指南提供將 Allied Telesis TQ 系列基地台與 Purple WiFi 整合的完整設定指南。內容涵蓋外部 Captive Portal 重新導向、802.1X RADIUS 驗證，以及使用私有預共用金鑰 (PPSK) 進行動態 VLAN 導向，以實現安全的多租戶部署。
Grandstream GWN Access Points 與 Purple WiFi 整合
本權威技術參考指南詳細說明如何將 Grandstream GWN Access Points 與 Purple 的 Guest WiFi 和分析平台進行整合。內容涵蓋 Grandstream Captive Portal 設定、RADIUS AAA 設定、Walled Garden 設定、具備動態 VLAN 導向的安全員工 802.1X 驗證，以及多租戶 PPSK 分段，為部署大規模訪客與員工 WiFi 的 MSP 和 IT 團隊提供具體且逐步的指引。