將 RADIUS as a Service 與雲端目錄（Azure AD 和 Google Workspace）整合
本技術參考指南詳細介紹了如何將 RADIUS as a Service 與雲端目錄（Microsoft Entra ID 和 Google Workspace）整合，以進行企業級 WiFi 驗證。內容涵蓋從地端 NPS 到雲端原生 RADIUS 的架構轉變、基於憑證的 EAP-TLS 驗證部署，以及在旅宿業、零售業和公共部門環境中保障無線存取安全的營運最佳實踐。對於已投入雲端身分識別的 IT 經理和網路架構師，本指南彌合了目錄管理與實體網路安全之間的鴻溝。
收聽此指南
查看播客逐字稿
執行摘要
對於已投入雲端身分識別生態系統的現代企業而言，將雲端目錄與實體無線網路連接起來是至關重要的安全任務。在歷史上，WiFi 驗證依賴於地端 Active Directory 網域服務和 Windows 網路原則伺服器（NPS）。隨著組織遷移到 Microsoft Entra ID 和 Google Workspace，該地端驗證技術堆疊便成為一種負擔——維護成本高、難以擴充，且與零信任安全模型不相容。
RADIUS as a Service (RADIUSaaS) 改變了這一局面。雲端託管的 RADIUS 伺服器可直接與您的雲端目錄整合，即時驗證驗證請求，並將存取決策傳回給您的存取點——無需地端伺服器、無需修補週期，且無單一故障點。結合基於 EAP-TLS 憑證的驗證，此架構消除了認證資訊遭竊的風險，支援 PCI DSS 和 GDPR 合規性，並為各個站點的員工提供無縫體驗。
本指南涵蓋了地端 NPS 與雲端原生 RADIUS 之間的架構決策、透過 Microsoft Intune 和 Google 管理主控台部署 EAP-TLS，以及在飯店、零售物業、體育場和公共部門場所保障無線存取安全的營運最佳實踐。如需更廣泛的網路存取控制介紹，請參閱 您的網路存取控制系統指南 。
技術深探：架構與標準
RADIUS 和 IEEE 802.1X 的角色
安全企業 WiFi 的基礎是 IEEE 802.1X 標準，它提供了基於連接埠的網路存取控制。當用戶端裝置（申請者）嘗試連線到 WPA2-Enterprise 或 WPA3-Enterprise 網路時，無線存取點（驗證器）會封鎖除 EAP（可延伸驗證協定）封包以外的所有流量。AP 將這些封包轉發給 RADIUS 伺服器。RADIUS 伺服器對照目錄服務驗證身分，並傳回 Access-Accept 或 Access-Reject 訊息。只有在那個時候，AP 才會授予網路存取權限。
這種由申請者、驗證器、驗證伺服器組成的三方模型是企業無線安全的基石，並在 IEEE 802.1X 中進行了定義。自推出以來，它並未發生根本性的改變。改變的是 RADIUS 伺服器的所在地以及它與目錄的通訊方式。
雲端原生 RADIUS 架構
雲端原生 RADIUS 架構消除了對地端 NPS 或 FreeRADIUS 伺服器的需求。第三方 Cloud RADIUS 供應商透過 Microsoft Graph API 直接與 Microsoft Entra ID 整合，或透過 Google Secure LDAP 或 SAML/OAuth 與 Google Workspace 整合。驗證完全在雲端進行。這符合零信任網路存取原則，並顯著減少了營運開銷。
下表比較了兩種主要的架構方法：
| 維度 | 混合地端 (NPS) | 雲端原生 (RADIUSaaS) |
|---|---|---|
| 基礎設施 | 需要 Windows Server VM 或裸機 | 無地端伺服器 |
| 身分識別來源 | 透過 LDAP/Kerberos 的 AD DS | 透過 API 的 Entra ID 或 Google Workspace |
| 憑證授權單位 | 地端 ADCS + Intune 連接器 | 來自廠商或 Microsoft 的 Cloud PKI |
| 高可用性 | 手動 HA 和負載平衡 | 由供應商自動調整規模 |
| 設定時間 | 數天至數週 | 數小時 |
| 最適合 | 混合 AD、舊版裝置 | 雲端優先、MDM 管理的組織 |
| 營運複雜度 | 初始和持續複雜度較高 | 較低的營運開銷 |
EAP-TLS 與 PEAP-MSCHAPv2：關鍵抉擇
EAP 方法的選擇是此部署中單一最具影響力的安全決策。PEAP-MSCHAPv2 依賴使用者輸入其網域認證資訊。這容易受到認證資訊遭竊和中間人攻擊的影響。如果用戶端裝置未嚴格驗證 RADIUS 伺服器憑證（許多裝置預設不驗證），攻擊者就可以部署帶有您 SSID 的惡意存取點，攔截 EAP 交握並擷取認證資訊。這就是邪惡雙生（Evil Twin）攻擊，且已有詳盡的文獻記載。
EAP-TLS (傳輸層安全) 使用安裝在用戶端裝置上的數位憑證進行雙向驗證。用戶端和伺服器都透過密碼學方式證明自己的身分。無需輸入或竊取密碼。在 Microsoft 環境中，憑證會透過 Microsoft Intune 使用 SCEP (簡單憑證註冊協定) 或 PKCS 設定檔靜默部署。這是所有新部署的推薦途徑，對於符合 PCI DSS v4.0（關於強式驗證的要求 8.3）和 GDPR 資料保護義務至關重要。
Google Workspace：架構上的差異
Microsoft Entra ID 和 Google Workspace 在 RADIUS 整合方面有一個重要區別。Microsoft NPS 與 Active Directory 原生整合，而 Cloud RADIUS 供應商透過 Microsoft Graph API 連線至 Entra ID。然而，Google 不提供原生 RADIUS 服務。您始終需要一個中介。
Google Secure LDAP 是主要的整合途徑。它適用於 Cloud Identity Premium 和 Google Workspace Enterprise 版本，為您的雲端目錄提供傳統的 LDAP 介面。您的 Cloud RADIUS 伺服器使用 Google 產生的用戶端憑證，透過連接埠 636 連線至 ldap.google.com為您進行驗證。從該點開始，RADIUS 伺服器會查詢 Google 的目錄以驗證認證資訊或群組成員資格，就像查詢地端 Active Directory 一樣。
另一種替代路徑是使用基於 SAML 的整合，其中 Cloud RADIUS 供應商在 Google 管理控制台（Google Admin Console）中註冊為 SAML 應用程式，並在驗證時執行 OAuth 查詢，以即時驗證使用者的身分和群組成員資格。
實作指南
使用 EAP-TLS 實作 RADIUSaaS 需要協調身分識別、裝置管理和網路基礎架構。以下五階段方法適用於 Microsoft Entra ID 和 Google Workspace 環境。
第一階段：準備身分識別與裝置管理基礎架構
針對 Microsoft Entra ID：驗證您的租戶是否擁有 Microsoft 365 E3/E5 或 Enterprise Mobility + Security (EMS) E3/E5 授權。這包括 Microsoft Intune 和條件式存取（Conditional Access）。若沒有 Intune，就無法進行自動化憑證部署。
針對 Google Workspace：確認您擁有 Cloud Identity Premium 或 Google Workspace Enterprise 以存取 Google Secure LDAP。如果您計劃在受管理的 Chromebook 上使用 EAP-TLS，請確保 Google 管理控制台已設定為管理裝置憑證。
建立您的公開金鑰基礎建設（PKI）。對於新部署，強烈建議使用由您的 Cloud RADIUS 廠商提供的雲端原生 PKI。其他替代方案包括 Microsoft Cloud PKI（隨 Intune Suite 授權提供）或透過 Microsoft Intune 憑證連接器（Certificate Connector）連接的現有地端 ADCS 部署。
第二階段：設定憑證部署
Microsoft Intune 路徑：在 Intune 系統管理中心，建立信任的憑證（Trusted Certificate）組態設定檔。上傳根 CA 憑證並將其部署到您的目標裝置群組。這可確保用戶端裝置在 TLS 握手期間信任 RADIUS 伺服器出示的憑證。接下來，建立 SCEP 憑證設定檔。對於基於使用者的驗證，將主體名稱（Subject Name）設定為 CN={{UserPrincipalName}}。對於基於裝置的驗證，請使用 CN={{DeviceName}}。將主體替代名稱（Subject Alternative Name）設定為包含使用者主體名稱（User Principal Name）或裝置 ID。
Google 管理控制台路徑：導覽至「裝置」，然後是「網路」，接著是「憑證」。上傳您的根 CA。設定憑證發行機制——可以是支援與 Google Workspace 進行 SCEP 整合的雲端 PKI，或是將請求代理至地端 Microsoft 憑證授權單位（Certificate Authority）的 Google Cloud Certificate Connector。將根 CA 和用戶端憑證設定檔部署到相應的組織單位（Organisational Units）。
第三階段：設定 Cloud RADIUS 整合
在您的目錄租戶中授予您的 Cloud RADIUS 供應商所需的 API 權限。對於 Entra ID，這需要至少透過 Microsoft Graph API 取得 User.Read.All 和 GroupMember.Read.All。某些供應商還需要 Device.Read.All 以進行裝置合規性檢查。對於透過 Secure LDAP 的 Google Workspace，請從 Google 管理控制台下載用戶端憑證和金鑰，並將其安裝在 RADIUS 服務上。
在 Cloud RADIUS 管理入口網站中定義您的驗證原則。企業環境中結構良好的原則範例：「如果憑證由 [Trusted CA] 發行，且使用者是 [Corporate-WiFi-Users] 群組的成員，且裝置在 Intune 中被標記為合規，則允許存取。」這會同時強制執行身分識別、群組成員資格和裝置健康狀況。
第四階段：設定無線基礎架構
在您的無線區域網路控制器或雲端管理儀表板（Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 或 Fortinet）中，將 Cloud RADIUS 伺服器 IP 位址和共用秘密新增為 RADIUS 驗證伺服器。設定主要和次要伺服器以實現備援。將 RADIUS 逾時設定為至少五秒，以因應雲端來回延遲。
建立一個設定為 WPA2-Enterprise 或 WPA3-Enterprise 的新 SSID。對於 旅宿業 部署，請確保企業 SSID 與任何 訪客 WiFi 網路位於不同的 VLAN 上。對於 零售業 環境，請考慮僅在後勤區域部署企業 SSID。
第五階段：透過 MDM 部署 WiFi 設定檔
Microsoft Intune：建立 WiFi 組態設定檔。將 SSID 設定為與您的基礎架構設定完全一致。選擇 WPA2-Enterprise 或 WPA3-Enterprise。在 EAP 設定下，選擇 EAP-TLS。將 SCEP 憑證設定檔連結為用戶端憑證，並指定信任的根 CA 設定檔。將此 WiFi 設定檔指派給接收憑證設定檔的相同裝置群組。裝置會在下一次 Intune 同步期間，在背景自動接收憑證和 WiFi 設定。
Google 管理控制台：導覽至「裝置」，然後是「網路」，接著是「Wi-Fi」。建立新的 WiFi 網路設定檔。設定 SSID、選擇 WPA3-Enterprise、選擇 EAP-TLS，並將信任的根 CA 憑證推送到裝置。將此設定檔套用至您的組織單位。Chromebook 將在背景安全地自動連線。
最佳做法
在所有新部署中強制執行 EAP-TLS。 請勿使用 PEAP-MSCHAPv2 部署新網路。其安全性風險已有詳盡記錄，且使用現代 MDM 工具的移轉路徑非常簡單直接。
強制執行嚴格的伺服器憑證驗證。 如果您必須針對舊型裝置使用 PEAP，請將裝置設定為驗證 RADIUS 伺服器的憑證。在 Intune WiFi 設定檔和 Google 管理控制台 WiFi 設定檔中，有一個欄位可用於指定伺服器驗證的信任 CA。請勿將此欄位留空。這單一的設定決定，就是安全部署與易受攻擊部署之間的關鍵差異。
透過動態 VLAN 指派進行網路分割。 使用您的 RADIUS 伺服器檢查使用者在 Entra ID 或 Google Workspace 中的群組成員資格，並動態地將他們指派到不同的 VLAN。RADIUS 伺服器會傳回 Tunnel-Private-Group-Id 屬性傳遞給無線基地台，進而將用戶端分配到正確的 VLAN。這能在發生資安入侵時限制橫向移動，並支援 PCI DSS 網路分段要求。
區隔企業與訪客驗證。 針對企業託管裝置使用 EAP-TLS。針對 BYOD 和訪客裝置，則使用結合單一登入 (SSO) 的 Captive Portal。嘗試在非託管裝置上手動設定 EAP-TLS 會產生過多的支援開銷。Purple 的 Guest WiFi 平台可獨立處理訪客上網引導，保持員工與訪客流量的乾淨區隔。
主動監控憑證過期。 在憑證過期前 90 天、30 天和 7 天設定監控與告警。如果您的 RADIUS 伺服器憑證過期，所有裝置將同時失去連線。在您的 PKI 支援的情況下，請實施自動更新。
測試 RADIUS 逾時設定。 Cloud RADIUS 會引入地端 NPS 所沒有的網路來回延遲。請將無線基地台上的 RADIUS 逾時時間設定為至少 5 秒。預設配置中常見的 2 秒逾時會導致間歇性的驗證失敗。
疑難排解與風險緩釋
防火牆連接埠受阻是初始部署失敗的首要原因。RADIUS 驗證需要從您的無線基礎架構向外連線至 Cloud RADIUS 服務的 UDP 連接埠 1812。RADIUS 計費則需要 UDP 連接埠 1813。在進行任何其他疑難排解之前，請先確認這些連接埠已開放。
憑證驗證失敗表現為無明顯原因的驗證遭拒。請依序檢查以下項目：用戶端與 RADIUS 伺服器上的憑證是否過期；用戶端裝置與 RADIUS 伺服器之間的時鐘偏差（EAP-TLS 依賴精確的時間同步）；以及根憑證授權單位 (Root CA) 憑證是否已透過 MDM 成功部署到裝置。
群組成員資格未強制執行是 RADIUS 策略參照 Entra ID 或 Google Workspace 群組時常見的問題。請驗證 Cloud RADIUS 供應商是否具有讀取群組成員資格的正確 API 權限。在 Entra ID 中，確認服務主體具有 GroupMember.Read.All。在 Google Workspace 中，確認 Secure LDAP 用戶端具有讀取群組資訊的權限。
VLAN 分配無法運作通常表示 RADIUS 屬性值與無線基礎架構上設定的 VLAN ID 不符。確認 Tunnel-Type 設定為 VLAN（值 13）、Tunnel-Medium-Type 設定為 802（值 6），且 Tunnel-Private-Group-Id 與交換器或控制器上設定的 VLAN ID 相符。
BYOD 裝置 EAP-TLS 失敗通常表示用戶端憑證未成功部署。對於由 Intune 託管的裝置，請檢查 Intune 系統管理中心中的裝置憑證存放區。對於由 Google 託管的 Chromebook，請驗證憑證設定檔是否已指派給正確的組織單位 (OU)，且裝置近期已進行同步。
投資報酬率與商業影響
移轉至 Cloud RADIUS 可帶來可衡量的營運成本節省。地端 RADIUS 至少需要兩台伺服器以實現高可用性，此外還需要持續的作業系統修補、憑證管理以及專業工程師的時間。單一工程師一年內花在 RADIUS 維護上的時間，通常就超過了 Cloud RADIUS 訂閱的年費。
商業效益不僅限於降低成本。透過將網路存取與已驗證的雲端身分綁定，您可以獲得：
即時停用帳戶。 在 Entra ID 或 Google Workspace 中停用使用者會立即撤銷其在所有據點的網路存取權限。沒有延遲，無需手動流程，也無須擔心離職員工仍保有 WiFi 存取權限。這直接支援了 GDPR 關於資料存取權限的義務。
更豐富的分析。 像 Purple 的 WiFi Analytics 這樣的平台能提供關於空間利用率和訪客歷程更豐富的數據。當網路存取與已驗證的身分綁定時，您將從匿名的 MAC 位址轉變為具名的已驗證使用者，這徹底提升了營運和行銷團隊所能獲得的洞察品質。
合規性證據。 EAP-TLS 驗證會產生詳細的存取記錄——誰在什麼時間、從哪個裝置、在什麼地點進行了連線。此稽核軌跡支援了 PCI DSS 規範 10（記錄與監控）以及 GDPR 的問責義務。
多據點一致性。 單一 Cloud RADIUS 服務即可透過一致的策略驗證您所有的據點，並從單一儀表板進行管理。新增一家飯店、商店或場館，只需將其無線基地台加入 RADIUS 設定中，而無需運送和設定另一台伺服器。對於管理大型資產的組織而言，這是一項顯著的營運優勢。
對於 交通運輸 營運商和 醫療保健 場館，網路正常運行時間在營運上至關重要的情況下，Cloud RADIUS 供應商通常會提供 99.999% 正常運行時間的 SLA，並內建多區域容錯移轉。Purple 在全球 80,000 多個營運場館中維持 99.999% 的正常運行時間，並在 2024 年處理了 4.4 億次登入（Purple 內部數據，2024 年）。
如需閱讀相關主題的更多資訊，請參閱 WAN 電腦定義：2026 年實用指南 與 2026 世界 WiFi 日：您的場館如何協助彌合數位落差 。
關鍵定義
RADIUS (Remote Authentication Dial-In User Service)
RFC 2865 中定義的一種網路協定，為連線到網路服務的使用者提供集中式驗證、授權和計費（AAA）管理。RADIUS 伺服器充當存取點與身分識別目錄之間的決策引擎。
每個企業級 WPA2-Enterprise 或 WPA3-Enterprise WiFi 網路都依賴 RADIUS 伺服器。沒有它，IEEE 802.1X 驗證就無法運作。
RADIUS as a Service (RADIUSaaS)
以託管服務形式提供的雲端託管 RADIUS 實作。供應商負責維護基礎設施、修補程式、高可用性以及身分識別供應商整合。您只需設定驗證原則，並將存取點指向雲端 RADIUS IP。
RADIUSaaS 消除了對地端 NPS 或 FreeRADIUS 伺服器的需求，從而免除了相關的硬體、作業系統修補和專業維護開銷。
IEEE 802.1X
一項用於基於連接埠之網路存取控制的 IEEE 標準。它定義了三方驗證模型：申請者（用戶端裝置）、驗證器（存取點或交換器）和驗證伺服器（RADIUS 伺服器）。驗證器會封鎖所有流量，直到 RADIUS 伺服器授予存取權限為止。
企業級 WiFi 驗證的基礎標準。WPA2-Enterprise 和 WPA3-Enterprise 皆依賴 802.1X。
EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)
RFC 5216 中定義的一種驗證方法，在 RADIUS 伺服器和用戶端裝置上皆使用數位憑證進行雙向驗證。雙方都不會傳送密碼。用戶端出示其憑證；伺服器即時對照目錄進行驗證。
企業級 WiFi 安全的黃金標準。消除憑證遭竊、網路釣魚以及與密碼相關的技術支援開銷。持卡人資料網路符合 PCI DSS 合規性所必需。
PEAP-MSCHAPv2 (Protected EAP - Microsoft Challenge Handshake Authentication Protocol v2)
一種先建立加密 TLS 通道，然後透過該通道傳送使用者名稱和密碼的驗證方法。如果用戶端未嚴格驗證 RADIUS 伺服器憑證，則容易受到邪惡雙生（Evil Twin）攻擊。
企業級 WiFi 的舊版預設設定。目前仍廣泛部署，但在所有全新和現有的部署中，應盡可能遷移至 EAP-TLS。
Microsoft Entra ID
Microsoft 的雲端身分識別與存取管理服務，前身為 Azure Active Directory (Azure AD)。用於管理使用者身分識別、群組成員資格、裝置合規性以及條件式存取原則。
以 Microsoft 為中心之環境中 Cloud RADIUS 的主要身分識別來源。Cloud RADIUS 供應商透過 Microsoft Graph API 連線至 Entra ID。
Google Secure LDAP
Cloud Identity Premium 和 Google Workspace Enterprise 版本中提供的一項託管服務，為 Google 的雲端目錄提供傳統的 LDAP 介面。RADIUS 伺服器使用用戶端憑證，透過連接埠 636 連線至 ldap.google.com。
將 Cloud RADIUS 伺服器連線至 Google Workspace 的主要整合途徑。Google 不提供原生 RADIUS 服務，因此 Secure LDAP 充當橋樑。
PKI (Public Key Infrastructure)
建立、管理、發行、使用、儲存和撤銷數位憑證所需的一整套角色、原則、硬體、軟體和程序。發行 EAP-TLS 驗證中使用的用戶端和伺服器憑證需要 PKI。
來自 RADIUS 廠商或 Microsoft (Cloud PKI) 的雲端原生 PKI 選項，消除了對地端 Active Directory 憑證服務 (ADCS) 的需求。
SCEP (Simple Certificate Enrollment Protocol)
一種使裝置能夠自動向憑證授權單位請求並接收數位憑證的協定。Microsoft Intune 和 Google 管理主控台使用此協定將用戶端憑證部署到受管理的裝置，無需使用者互動。
Intune 中的 SCEP 設定檔是公司裝置靜默接收 EAP-TLS 驗證所需用戶端憑證的機制。
Dynamic VLAN assignment
一種 RADIUS 功能，可根據已驗證使用者的目錄群組成員資格，將 VLAN 分配屬性（Tunnel-Type、Tunnel-Medium-Type、Tunnel-Private-Group-Id）傳回給存取點。AP 會自動將用戶端置於指定的 VLAN 中。
實現精細的網路分段，而無需為每台裝置手動設定 VLAN。不同角色或部門的員工會進入不同的網路區段，從而限制橫向移動並支援 PCI DSS 分段要求。
範例
一家擁有 200 間客房的飯店正將其後勤員工網路從老舊的地端 NPS 伺服器遷移到雲端原生解決方案。該飯店最近已移至 Microsoft Entra ID 和 Microsoft 365 E5。員工裝置是由 Intune 管理的 Windows 筆記型電腦。無線基礎設施為 Cisco Meraki。飯店需要員工在不彈出密碼提示的情況下自動連線，並在員工離職時能立即撤銷其存取權限。
部署整合 Entra ID 的 Cloud RADIUS 解決方案。步驟 1：在 Entra ID 租戶中授予 Cloud RADIUS 供應商 Microsoft Graph API 權限（User.Read.All、GroupMember.Read.All、Device.Read.All）。步驟 2：在 Intune 中，使用 Cloud RADIUS 根憑證授權單位（Root CA）建立「信任的憑證」設定檔，並將其部署到「所有公司裝置」群組。步驟 3：建立主體名稱為 CN={{UserPrincipalName}} 的 SCEP 憑證設定檔，並部署到同一個群組。步驟 4：設定 Cloud RADIUS 驗證原則：若憑證由 [信任的 CA] 發行，且使用者為 [Hotel-Staff-WiFi] Entra ID 群組的成員，且裝置符合 Intune 合規性，則允許存取。步驟 5：在 Cisco Meraki 儀表板中，將 Cloud RADIUS 的主要和次要 IP 新增為後勤 SSID 的 RADIUS 伺服器。將 RADIUS 逾時設定為 5 秒。步驟 6：在 Intune 中，為後勤 SSID 建立 WPA3-Enterprise WiFi 設定檔，指定 EAP-TLS 並連結 SCEP 憑證設定檔。部署到「所有公司裝置」群組。裝置在下一次 Intune 同步時會靜默接收憑證和 WiFi 設定檔並自動連線。當員工離職時，停用其 Entra ID 帳戶將立即撤銷其在所有站點的網路存取權限。
一家擁有 50 家門市的零售連鎖店使用 Google Workspace，並管理著 500 台 Chromebook，供門市員工進行庫存和 POS（銷售點）操作。他們目前在門市營運網路中使用共用的 WPA2 PSK，這在裝置遺失或被盜時會帶來安全風險。他們希望在不於每家門市部署本地伺服器的情況下，遷移到 802.1X 驗證。他們的無線基礎設施是 HPE Aruba。
部署透過 Google Secure LDAP 與 Google Workspace 整合的 Cloud RADIUS 解決方案。步驟 1：在 Google 管理主控台中，導覽至「應用程式」，然後選擇「LDAP」，並為 Cloud RADIUS 服務新增一個 LDAP 用戶端。設定使用者資訊和群組成員資格的讀取權限。下載產生的用戶端憑證和金鑰。步驟 2：使用 Google Secure LDAP 認證資訊設定 Cloud RADIUS 服務。步驟 3：設定雲端 PKI 以向 Chromebook 發行憑證。在 Google 管理主控台中，導覽至「裝置」，然後選擇「網路」，再選擇「憑證」，並上傳根憑證授權單位（Root CA）。設定憑證發行設定檔，並將其套用至 Store-Associates 組織單位（OU）。步驟 4：在 Google 管理主控台中，為門市營運 SSID 建立 WPA3-Enterprise WiFi 設定檔。設定 EAP-TLS、連結根憑證授權單位（Root CA），並套用至 Store-Associates OU。Chromebook 會在下一次管理主控台同步時接收憑證和 WiFi 設定檔。步驟 5：在 HPE Aruba Central 中，使用 WPA3-Enterprise 設定門市營運 SSID，並新增 Cloud RADIUS 的主要和次要 IP。將 RADIUS 逾時設定為 5 秒。設定動態 VLAN 分配，根據門市員工的 Google Workspace 群組成員資格將其分配至 VLAN 20（門市營運）。當 Chromebook 遺失或被盜時，將其從 Store-Associates OU 中移除會立即撤銷其網路存取權限。
練習題
Q1. 您的組織正在從地端 Active Directory 遷移到 Microsoft Entra ID。您目前在由 Intune 管理的 300 台公司筆記型電腦上使用 PEAP-MSCHAPv2 進行 WiFi 驗證。您擁有 Microsoft 365 E5 授權。將 WiFi 驗證遷移到雲端原生架構最安全且最具營運效率的途徑是什麼？
提示：考量基於認證資訊驗證的漏洞、Microsoft Intune 部署憑證的能力，以及避免依賴地端基礎設施的需求。
查看標準答案
部署整合 Entra ID 的 Cloud RADIUS 解決方案。使用 Microsoft Intune 向 300 台筆記型電腦部署信任的憑證設定檔（根憑證授權單位）和 SCEP 憑證設定檔。設定 Cloud RADIUS 驗證原則，要求提供來自信任 CA 的有效憑證，且必須是 Corporate-WiFi-Users Entra ID 群組的成員。在 Intune 中建立指定 EAP-TLS 的 WPA3-Enterprise WiFi 設定檔，並連結 SCEP 憑證設定檔。裝置在下一次 Intune 同步時會靜默接收憑證和 WiFi 設定。這消除了 PEAP-MSCHAPv2 認證資訊遭竊的風險，移除了對地端 NPS 的依賴，並在停用 Entra ID 帳戶時提供立即撤銷功能。
Q2. 您飯店的一名使用者反映，在休假兩週回來後，無法連線到後勤員工 WiFi。其他員工連線正常。該網路使用 EAP-TLS，並透過 Intune 部署憑證。按可能性大小排序，最可能的三個原因是什麼？
提示：EAP-TLS 依賴具時效性的密碼編譯資產和即時目錄查詢。
查看標準答案
- 使用者的用戶端憑證已過期。憑證有定義的有效期，如果裝置在更新視窗期間處於離線狀態，SCEP 設定檔可能未能將其更新。請檢查 Intune 裝置憑證存放區中的憑證到期日。2. 裝置的系統時鐘嚴重不同步（時鐘偏差），導致憑證驗證失敗。EAP-TLS 會驗證憑證時間戳記；時鐘偏差超過五分鐘將導致驗證失敗。3. 使用者在休假期間其 Entra ID 帳戶被歸入不同的群組（例如，從在職員工移至不同的 OU），且 RADIUS 驗證原則不再與其群組成員資格相符。請對照 RADIUS 原則檢查使用者在 Entra ID 中的群組成員資格。
Q3. 您是一家擁有 80 家門市的零售連鎖店的 IT 經理。您使用 Google Workspace，並透過 Google 管理主控台管理 400 台 Chromebook。您希望將門市營運網路上目前的共用 WPA2 PSK 替換為 802.1X 驗證。您在任何門市地點都沒有地端伺服器。您會部署什麼架構？與目前的 PSK 方法相比，其主要安全優勢是什麼？
提示：考量在每種驗證模型下，當 Chromebook 遺失或被盜時會發生什麼情況。
查看標準答案
部署整合 Google Secure LDAP 的 Cloud RADIUS 服務。設定雲端 PKI 以向 Chromebook 發行憑證。在 Google 管理主控台中，向 Store-Associates 組織單位（OU）部署根憑證授權單位（Root CA）和 SCEP 用戶端憑證設定檔。建立指定 EAP-TLS 的 WPA3-Enterprise WiFi 設定檔，並將其部署到同一個 OU。將每家門市的 HPE Aruba（或同等）存取點設定為指向 Cloud RADIUS 服務。主要安全優勢：在目前的共用 PSK 機制下，遺失或被盜的 Chromebook 會一直保有 WiFi 存取權限，直到所有 80 家門市 of PSK 都進行輪替（這是一個具破壞性且耗時的過程）。使用 EAP-TLS，在 Google 管理主控台中將裝置從 Store-Associates OU 中移除會立即撤銷其憑證和網路存取權限，而不會對任何其他裝置產生影響。
Q4. 在 Cloud RADIUS 部署期間，您在 Cisco Meraki 存取點上設定了 SSID，並將 Intune WiFi 設定檔部署到包含 20 台裝置的試點群組。所有裝置都無法連線。Intune 裝置狀態顯示憑證和 WiFi 設定檔已成功部署。您首先要檢查什麼？
提示：初始部署失敗最常見的原因並非 RADIUS 原則或憑證中的設定錯誤。
查看標準答案
檢查從 Cisco Meraki 存取點（或 Meraki 雲端基礎設施）到 Cloud RADIUS 伺服器 IP 位址的輸出 UDP 連接埠 1812 和 1813 是否已開放。防火牆連接埠被封鎖是初始部署失敗的首要原因。憑證和 WiFi 設定檔已成功部署的事實排除了 Intune 設定問題。接下來要檢查的是：Meraki 與 Cloud RADIUS 服務之間的 RADIUS 共用金鑰是否不相符；RADIUS 逾時設定是否過低（增加至至少 5 秒）；以及 Cloud RADIUS 伺服器 IP 是否已正確輸入到 Meraki SSID 設定中。
繼續閱讀本系列
The Security Benefits of RADIUS as a Service for Hybrid Workforces
本技術參考指南說明 RADIUS 即服務如何為分散式場域的混合工作團隊確保網路存取安全。內容涵蓋架構、安全性優勢以及部署步驟，指引如何將地端 RADIUS 基礎設施替換為雲端託管的驗證服務。本指南為飯店、連鎖零售、體育場館和公共部門機構的 IT 經理與網路架構師提供評估並於本季度執行雲端 RADIUS 遷移所需的實證。
如何使用 Cloud RADIUS 實作 802.1X 驗證
本技術參考指南提供了一個全面的架構，用於在分散式企業環境中部署結合 Cloud RADIUS 的 802.1X 驗證。本指南詳細介紹了架構、EAP 方法選擇、部署順序以及降低風險的策略，旨在確保網路存取安全，同時消除地端基礎設施的維運開銷。
從地端 RADIUS (NPS) 遷移至 RADIUS 即服務 (RADIUS as a Service)
本權威指南詳細介紹了從地端 Microsoft 網路原則伺服器 (NPS) 遷移至雲端原生 RADIUS 即服務 (RADIUS as a Service) 模型的技術架構、實作方法論和業務影響。它為 IT 主管和網路架構師提供了實用框架，以降低營運開銷、消除單一故障點，並確保分散式場域中企業驗證的安全。