跳至主要內容

什麼是 Cloud RADIUS?RADIUS-as-a-Service 的完整指南

這份完整指南深入探討了 Cloud RADIUS (RADIUS-as-a-Service),詳細說明其架構、EAP 方法與導入策略。它為 IT 決策者提供了將地端伺服器遷移到可擴展、安全且合規的雲端驗證模型的實用指南。

📖 5 分鐘閱讀📝 1,077 字數🔧 2 範例3 練習題📚 8 關鍵定義

收聽此指南

查看播客逐字稿
什麼是 Cloud RADIUS?RADIUS-as-a-Service 完整指南。 歡迎來到 Purple WiFi 智慧播客(Intelligence Podcast)。我是您的主持人,今天我們將深入剖析 Cloud RADIUS - 它是什麼、底層運作原理,以及關鍵的評估方法:如何判斷這是否為您企業本季度的正確決策。無論您是管理飯店集團、零售商場、體育場還是公共部門網路,這一期都非常適合您。 讓我們言歸正傳。 簡介與背景。 如果您曾向董事會解釋為什麼網路驗證伺服器在凌晨 2 點當機,且為何花費了 3 個小時才恢復運行,那麼您就已經了解 Cloud RADIUS 所解決的核心問題。傳統的地端 RADIUS 架構雖然強大,但帶來了龐大的營運開銷。您需要採購硬體、管理修補程式生命週期、手動架構容錯移轉,而且機房中還存在著單點故障風險。 Cloud RADIUS(或稱 RADIUS-as-a-Service)將該驗證層轉移到託管且高可用性的雲端環境中。協定本身 - 遠端使用者撥入驗證服務(Remote Authentication Dial-In User Service)- 並未改變。它仍然是 IEEE 802.1X 網路存取控制的骨幹,依然是您的存取點用來驗證誰能進入網路的機制。但在企業 IT 中,將運行該服務的基礎架構交由專業團隊託管,是一項重大的轉變。 接下來讓我們深入探討技術細節。 技術深度剖析。 RADIUS 最初在 2000 年發佈的 RFC 2865 中定義,且一直保持著極佳的耐用性。該協定採用用戶端 - 伺服器模型運作。您的網路存取設備 - 無論是 WiFi 存取點、VPN 集中器還是有線交換器 - 都扮演 RADIUS 用戶端的角色,也稱為網路存取伺服器(NAS)。當使用者嘗試連線時,NAS 會將 Access-Request 封包轉發給 RADIUS 伺服器,後者會比對使用者目錄(通常是 Active Directory、LDAP 或雲端身分識別提供者)驗證憑證,並傳回 Access-Accept 或 Access-Reject。 這是最核心的互動過程。但真正的複雜性在於其周邊運作:EAP 方法、VLAN 分配、策略執行、帳務記錄以及憑證管理。 在傳統的地端部署中,您需要在專用硬體上執行 FreeRADIUS 或 Microsoft NPS,自行管理憑證、設定容錯移轉,並維護自己的使用者資料庫同步。對於擁有專業 IT 團隊的單一站點部署來說,這尚可應付。但對於擁有 50 個據點的零售集團,或是在多個國家擁有物業的飯店集團而言,這將成為極為沉重的營運負擔。 Cloud RADIUS 將這一切抽象化。驗證邏輯、憑證基礎架構、備援機制以及原則引擎都以託管服務的形式提供。您的存取點指向雲端託管的 RADIUS 端點 - 通常是主要和次要 IP 位址 - 服務會處理背後的一切。 現在,讓我們來談談驗證方法,因為這才是技術決策的關鍵所在。 企業 WiFi 中最常見的 EAP 方法是 PEAP - Protected EAP - 它在 TLS 工作階段中建立 MSCHAPv2 通道。它受到廣泛支援,原生支援 Active Directory,並且是大多數 Windows 和 Android 裝置的預設設定。然而,PEAP 存在已知的漏洞,特別是在憑證驗證方面。如果您的用戶端裝置未設定為驗證伺服器憑證,您就會暴露於透過偽冒存取點進行憑證竊取的攻擊風險中。 EAP-TLS 是黃金標準。它使用雙向憑證驗證 - 伺服器和用戶端雙方都出示憑證 - 這完全消除了密碼攻擊面。其代價是用戶端憑證部署,這需要 PKI 基礎架構和 MDM 整合。對於託管裝置群,這絕對是正確的選擇。對於 BYOD 環境,則較為複雜。 EAP-TTLS 和 EAP-FAST 也值得了解。TTLS 在需要支援各種用戶端裝置(包括 Linux 系統)的環境中特別常見。EAP-FAST 是由 Cisco 開發的,作為 PEAP 的替代方案,它透過使用受保護的存取憑證(Protected Access Credentials)來避免對憑證驗證的依賴。 架構完善的 Cloud RADIUS 服務支援所有這些方法,並允許您設定每個 SSID 原則 - 因此您的企業 SSID 使用帶有憑證驗證的 EAP-TLS,您的員工 SSID 使用帶有 Active Directory 的 PEAP,而您的訪客網路則使用與 RADIUS 堆疊完全獨立的 Captive Portal 或社群登入流程。 說到這裡 - RADIUS 和訪客 WiFi 經常被混為一談,但它們用途不同。RADIUS 是您針對已知使用者和裝置的驗證與授權層。訪客 WiFi 通常使用 Captive Portal 流程,這完全是另一種不同的機制。例如,Purple 的平台透過獨立的身分層處理訪客驗證,擷取第一方數據並啟用行銷自動化,而 RADIUS 則處理企業和員工的網路存取控制。這些是互補而非競爭的系統。 現在,讓我們來談談「雲端託管」在實際應用中的真正含義。一個架構完善的 Cloud RADIUS 服務會在多個可用區(Availability Zones)運行,並具備自動容錯移轉功能。認證請求會在多個節點之間進行負載平衡,即使在高峰負載下,該服務也能保持低於 100 毫秒的響應時間。對於在活動期間需要處理 4 萬個並行連線的體育場來說,這種延遲和吞吐量特性至關重要。單一的本地部署伺服器根本無法與這種彈性相提並論。 從合規性的角度來看,在英國和歐盟營運的 Cloud RADIUS 提供商在處理認證日誌和使用者資料時,需要符合 GDPR 規範。對於同樣處理付款卡資料的零售和餐飲旅宿環境,PCI-DSS 針對網路分段和存取控制的要求直接相關 - RADIUS 是您控制環境的一部分,而您的評估人員(QSA)會希望看到正確設定和稽核記錄的證據。 WPA3 也值得探討。從 WPA2 到 WPA3 的過渡,為個人網路引進了對等實體同時驗證(SAE),並為企業環境引進了 WPA3-Enterprise。WPA3-Enterprise 強制要求使用 192 位元安全性模式以達到最高分類,這需要特定的 EAP 方法和加密套件。Cloud RADIUS 服務需要支援這些設定才能因應未來的需求。 實作建議與常見陷阱: 好的,讓我們進入實務階段。如果您正在評估於本季部署 Cloud RADIUS,以下是我會專注的重點。 第一,與您的身分識別提供者整合。您的 Cloud RADIUS 服務需要與您使用者實際存在的任何地方進行同步 - 無論是 Microsoft Entra ID(前身為 Azure AD)、Google Workspace、Okta,還是透過 LDAP 代理程式的本地部署 Active Directory。此整合的品質決定了您的營運開銷。原生 SAML 或 SCIM 佈建遠比手動匯入 CSV 檔更為理想。 第二,憑證管理。如果您正在部署 EAP-TLS,您需要明確了解用戶端憑證是如何發行、更新和撤銷的。最優秀的 Cloud RADIUS 服務會包含整合式 PKI,或與您現有的憑證授權單位(CA)進行乾淨的整合。憑證過期是企業 WiFi 中最常見的認證失敗原因之一 - 透過適當的自動化,這完全是可以避免的。 第三,網路設備相容性。您的存取點(AP)需要支援 RADIUS 認證 - 幾乎所有企業級 AP 都支援 - 但您需要根據 AP 廠商的實作情況,驗證您所選服務支援的特定 EAP 方法和 RADIUS 屬性。Cisco、Aruba、Juniper Mist 和 Ruckus 在處理 RADIUS 屬性和 CoA(授權變更)訊息方面都有各自的細微差異。第四,備援配置。請務必配置主用與備用 RADIUS 伺服器 IP。您的 NAS 裝置上的容錯移轉逾時設定非常重要 - 如果設得太高,當主伺服器無法連線時,使用者將會面臨 30 秒的驗證延遲。對大多數環境而言,設為 3 到 5 秒的逾時並立即進行容錯移轉才是正確的配置。 第五 - 這也是大家最容易忽略的一點 - 計費(accounting)。RADIUS 計費紀錄是您的稽核軌跡。它們會告訴您誰連線、使用哪部裝置、在什麼時間,以及連線了多久。為了符合合規性要求(特別是在醫療保健和公共部門環境中),這些紀錄需要妥善保存並可供存取。請確保您的 Cloud RADIUS 供應商為您提供計費數據的存取權限,而不僅僅是驗證日誌。 常見陷阱:共享金鑰的複雜度。您的 RADIUS 共享金鑰 - 即 NAS 與 RADIUS 伺服器之間的預先共享金鑰 - 必須既長且隨機。太短或容易被猜中的共享金鑰是個實際的攻擊媒介。請使用至少 32 個字元的隨機生成金鑰,並定期進行輪替。 另外也要注意 IP 白名單。許多 Cloud RADIUS 服務要求您將 NAS 裝置的來源 IP 加入白名單。在您的 AP 管理平台可能使用 NAT 的動態雲端環境中,這可能會導致非預期的驗證失敗。在部署之前,請先確認您網路的 NAT 行為。 快速問答。 讓我快速解答幾個我經常被問到的問題。 Cloud RADIUS 是否支援多租戶環境?是的 - 大多數企業級 Cloud RADIUS 服務都支援租戶隔離,因此託管服務供應商可以從單一平台為多個客戶執行獨立的 RADIUS 策略。 Cloud RADIUS 驗證的典型延遲是多少?對於架構完善的服務,延遲低於 100 毫秒。802.1X 交握本身會增加一些開銷,但對於大多數 EAP 方法,端到端的總驗證時間應在 500 毫秒以內。 Cloud RADIUS 是否適用於 OpenRoaming?是的。OpenRoaming - 無線寬頻聯盟(Wireless Broadband Alliance)的漫遊架構 - 其核心採用 RADIUS 聯盟。支援 Hotspot 2.0 和 OpenRoaming 的 Cloud RADIUS 服務可讓您的使用者在全球參與的網路中自動進行驗證。Purple 在其 Connect 授權下支援 OpenRoaming,在聯盟中充當身分識別供應商。 Cloud RADIUS 是否適用於高安全性環境?對於大多數企業環境,是的。對於含有機密資料或特定政府安全等級的環境,您可能需要評估託管雲端服務是否符合您特定的認證要求。 摘要與後續步驟。 總結來說:Cloud RADIUS 是一種成熟且已可投入生產環境的網路存取控制方法,在不妥協安全性或功能的前提下,免除了在地端部署 RADIUS 基礎架構的營運負擔。對於擁有多個據點的組織而言,ROI 的效益顯而易見 - 您可以省去硬體資本支出、減少 IT 管理開銷、獲得內建的備援能力,並擁有一項能隨您的資產規模擴展的服務。 關鍵的決策點在於:哪種 EAP 方法最適合您的設備群、您如何與現有的識別資訊提供者整合,以及您選擇的服務是否能提供您組織所需的合規性與稽核功能。 如果您經營飯店集團、零售連鎖店,或管理公共部門網路,我建議先從單一據點的概念驗證(PoC)開始 - 在部署到所有據點之前,確保您的 RADIUS 設定正確無誤、驗證與您的識別資訊提供者的整合,並測試驗證延遲。 如需了解更多關於 WiFi 分析、訪客網路管理,以及 Purple 的平台如何與基於 RADIUS 的驗證進行整合的資訊,請造訪 purple.ai。感謝您的收聽。

header_image.png

執行摘要

對於現代企業網路而言,傳統的本地端 RADIUS (Remote Authentication Dial-In User Service) 架構構成了重大的營運瓶頸。管理實體伺服器、修補作業系統、處理憑證授權中心以及規劃多站點備援,皆會消耗寶貴的 IT 資源。Cloud RADIUS (或 RADIUS-as-a-Service) 藉由將 IEEE 802.1X 驗證層遷移至託管且高可用性的雲端基礎架構,解決了此一難題。本指南為評估部署策略的 IT 經理、網路架構師和 CTO 提供 Cloud RADIUS 的全面技術概述。透過從高資本支出、手動維護的系統轉變為彈性且全球分佈的模型, 零售餐飲旅宿交通運輸 領域的組織得以實施強健的存取策略、達成法規遵循 (例如 PCI-DSS 和 GDPR),並與 Microsoft Entra ID 和 Google Workspace 等現代身分驗證提供者無縫整合。

技術深度解析

RADIUS 架構的演進

RADIUS 最初在 RFC 2865 中定義,其運作基於主從式架構,其中網路存取伺服器 (NAS) - 例如 WiFi 存取點或 VPN 集中器 - 會將驗證請求轉發至中央伺服器。在過去,這意味著必須在專用硬體上部署 FreeRADIUS 或 Microsoft Network Policy Server (NPS)。雖然這適用於單一站點的部署,但要在分佈式環境中擴充此架構會帶來嚴重的延遲與備援挑戰。

Cloud RADIUS 抽象化了底層基礎架構。驗證請求會被路由至全球分佈的雲端端點,確保即使在尖峰負載下,回應時間也低於 100 毫秒。這種彈性對於體育場或會議中心等高密度環境至關重要。

architecture_overview.png

EAP 方法與安全態勢

可延伸驗證協定 (EAP) 方法的選擇從根本上決定了您的安全態勢:

  • PEAP (Protected EAP): 在 TLS 工作階段中建立 MSCHAPv2 通道。雖然 PEAP 受到廣泛支援且易於與 Active Directory 整合,但若用戶端裝置未嚴格設定為驗證伺服器憑證,則容易受到惡意存取點竊取憑證的攻擊。
  • EAP-TLS 企業級的黃金標準。它需要雙向憑證驗證 - 伺服器和用戶端都必須出示有效的憑證。這完全消除了基於密碼的攻擊,但需要強大的公鑰基礎建設 (PKI) 和行動裝置管理 (MDM) 整合來進行憑證部署。
  • EAP-TTLS 和 EAP-FAST: 提供適用於需要廣泛用戶端相容性(包括舊版或 Linux 系統),或需要受保護的存取憑證 (PAC) 以繞過憑證驗證依賴性之場景的替代方案。

WPA3 與 OpenRoaming 整合

現代部署必須考慮 WPA3-Enterprise,它強制要求使用 192 位元安全性模式以達到最高安全級別,並需要特定的加密套件。此外,Cloud RADIUS 有助於參與 OpenRoaming 等聯盟架構。例如,Purple 在其 Connect 授權下擔任 OpenRoaming 的免費識別資訊提供者,可在全球參與的網路中實現無縫、安全的驗證。

實作指南

部署 Cloud RADIUS 需要有系統的方法,以確保在過渡期間實現零停機時間。

步驟 1:識別資訊提供者 (IdP) 整合

您的 Cloud RADIUS 執行個體必須與您的授權使用者目錄同步。與 Microsoft Entra ID、Google Workspace 或 Okta 進行原生 SAML 或 SCIM 撥配,比手動 LDAP 代理或 CSV 匯入更具優勢。這能確保當員工在 HR 系統中辦理離職時,其網路存取權限會立即被撤銷。

步驟 2:憑證管理策略

如果部署 EAP-TLS,請定義您的憑證生命週期。選擇包含整合式 PKI 或與您現有憑證授權單位 (CA) 無縫整合的 Cloud RADIUS 提供者。透過您的 MDM 平台(例如 Intune 或 Jamf)自動化憑證核發和撤銷,以防止因憑證過期而導致的驗證失敗。

步驟 3:網路裝置設定

設定您的 NAS 裝置(基地台、交換器)以指向主要和次要的 Cloud RADIUS IP 位址。確保共用金鑰具有密碼學上的複雜性(至少 32 個隨機字元)。調整容錯移轉逾時設定;3 到 5 秒的逾時是最理想的,可防止在主要節點無法連線時發生長時間的驗證延遲。

步驟 4:原則定義

針對每個 SSID 建立原則。例如,對企業網路強制執行 EAP-TLS,對舊版 IoT 裝置強制執行 PEAP,並隔離訪客存取。請注意,RADIUS 處理的是已知使用者;對於訪客,請部署專用的 Guest WiFi 解決方案並搭配 Captive Portal 以收集第一方數據,並與 WiFi Analytics 平台整合。如需了解更多關於訪客互動的資訊,請參閱 如何提高訪客滿意度:終極指南comparison_chart.png

最佳實踐

  • 強制執行嚴格的伺服器憑證驗證:對於 PEAP 部署,請推播群組原則或 MDM 設定檔,強制用戶端驗證 RADIUS 伺服器憑證,並將信任限制在特定的根憑證授權單位(CA)。
  • 區隔計費與驗證流量:確保主動監控並保留 RADIUS 計費資料。此稽核追蹤對於合規性報告(例如 PCI-DSS 和 HIPAA)至關重要。
  • 監控驗證延遲:高延遲通常表示路由未最佳化或 IdP 同步問題。使用監控工具追蹤從 Access-Request 到 Access-Accept 封包所需的時間。
  • 最佳化訊號與頻道規劃:可靠的驗證取決於穩定的實體層。請參閱 Understanding RSSI and Signal Strength for Optimal Channel Planning 等指南,以確保您的無線電頻率(RF)環境支援無縫的 802.1X 漫遊。

疑難排解與風險緩釋

即使使用託管服務,設定錯誤仍可能導致存取失敗。常見的失敗模式包括:

  • 憑證過期:EAP-TLS 失敗的首要原因。緩釋措施:在 CA 或伺服器憑證過期前 30 天實施自動警報。
  • 共用金鑰不相符:通常發生在新增存取點(AP)時。緩釋措施:在您的網路管理系統中標準化設定範本。
  • NAT 與 IP 允許清單問題:Cloud RADIUS 供應商通常需要 NAS IP 允許清單。如果您的分支機構使用動態 IP 或複雜的 NAT 設定,驗證請求可能會被捨棄。緩釋措施:使用靜態傳出 IP,或在必要時部署本地 RADIUS 代理伺服器。
  • IdP 同步失敗:如果雲端目錄無法與地端 AD 同步,新使用者將無法進行驗證。緩釋措施:主動監控 SCIM/LDAP 連接器狀態。

投資報酬率(ROI)與業務影響

轉換至 Cloud RADIUS 可帶來可衡量的業務價值:

  1. 降低基礎架構資本支出(Capex):無需在每個主要據點採購、上架和供電實體 RADIUS 伺服器。
  2. 降低營運開銷:IT 團隊不再需要花費數小時修補作業系統漏洞或手動管理伺服器容錯轉移。由廠商託管的更新可確保持續合規。
  3. 增強安全防護態勢:透過雲端 PKI 轉換至 EAP-TLS 可降低憑證被竊的風險,直接降低資料外洩的潛在成本。
  4. **敏捷性與擴充性:**當開設新的零售分店或飯店時,網路驗證可在幾分鐘內完成配置,而非數週。如需實用的部署策略,請參閱 企業 WiFi 架設:2026 戰術手冊

透過集中式存取控制,企業不僅能確保其安全周邊,還能釋放資深工程團隊的精力,專注於具策略性且高影響力的專案,而非耗費在維護過時的舊有基礎設施。

關鍵定義

Cloud RADIUS

一種在高度可用的雲端環境中託管 Remote Authentication Dial-In User Service 協定的託管服務,無需使用地端驗證伺服器。

由尋求減少硬體資本支出和維運開銷,同時維持安全 802.1X 網路存取的 IT 團隊進行評估。

EAP-TLS (Extensible Authentication Protocol-Transport Layer Security)

一種高度安全的驗證方法,要求用戶端和伺服器雙方都必須出示數位憑證以證明其身分。

企業網路防止基於密碼攻擊的推薦標準,部署時需要 PKI 和 MDM。

NAS (Network Access Server)

作為 RADIUS 用戶端並將使用者憑證轉發至 RADIUS 伺服器的裝置 - 例如 WiFi 存取點、交換器或 VPN 集中器。

網路工程師必須為 NAS 設定正確的 RADIUS 伺服器 IP 和共用金鑰,以啟用 802.1X 驗證。

Shared Secret (共用金鑰)

僅有 NAS 和 RADIUS 伺服器知道的加密文字字串,用於加密 RADIUS 封包並驗證傳送者的真實性。

強度不足的共用金鑰是主要的安全性漏洞;企業部署應使用長且隨機產生的字串。

SCIM (System for Cross-domain Identity Management)

一種開放標準,可在 IT 系統或雲端應用程式之間自動交換使用者身分識別資訊。

當主要 HR 或 IT 身分識別系統發生變更時,用於在 Cloud RADIUS 目錄中自動建立和刪除使用者。

OpenRoaming

由 Wireless Broadband Alliance 開發的同盟架構,允許使用者在全球範圍內自動且安全地連線至參與的 WiFi 網路。

支援 OpenRoaming 的 Cloud RADIUS 供應商(例如 Purple)允許場所為訪客提供無縫、安全的連線,而無需使用 Captive Portal。

Accounting Logs

由 RADIUS 伺服器產生的紀錄,詳細記錄使用者連線事件,包括開始時間、結束時間、傳輸的資料和分配的 IP 位址。

對於安全性稽核、疑難排解以及證明符合 PCI-DSS 和 GDPR 等架構至關重要。

Change of Authorization (CoA)

一種 RADIUS 功能,允許伺服器動態修改使用者的作用中工作階段(例如變更其 VLAN 或中斷其連線),而無需重新連線。

網路管理員用於在工作階段中立即隔離受感染的裝置或套用新的原則限制。

範例

一家擁有 200 間客房的飯店目前使用地端 Microsoft NPS,透過 PEAP 進行員工 WiFi 驗證。他們在入住尖峰時段遇到驗證逾時的問題,希望遷移到支援 EAP-TLS 的 Cloud RADIUS 以獲得更高的安全性和可靠性。IT 總監該如何規劃這次遷移的架構?

  1. 部署 Cloud RADIUS 租戶,並透過 SCIM 與飯店的 Microsoft Entra ID 進行整合,以實現自動化的使用者生命週期管理。 2. 設定 Cloud RADIUS 整合的 PKI 以核發用戶端憑證。 3. 使用現有的 MDM (例如 Intune) 將根憑證授權單位 (Root CA)、用戶端憑證以及為 EAP-TLS 設定的新 WiFi 設定檔推送到所有員工裝置。 4. 設定飯店的存取點,使其指向主要和次要的 Cloud RADIUS IP,並使用全新且複雜的 32 字元共用金鑰。 5. 在不同的 SSID 上同時執行舊的 NPS 和新的 Cloud RADIUS 進行為期兩週的過渡期,然後再將地端伺服器除役。
考官評語: 此方法透過在過渡期間運行並行 SSID 來將風險降至最低。轉用 EAP-TLS 消除了解決 PEAP 相關憑證收集的風險,而利用 MDM 進行憑證部署可確保終端使用者毫無障礙。SCIM 整合則保證了當員工離職時,其存取權限會被立即撤銷。

一家擁有 500 個據點的連線零售商需要確保其透過 WiFi 連線的銷售點 (POS) 終端機符合 PCI-DSS 合規規範。他們正在遷移到 Cloud RADIUS。需要進行哪些特定設定才能符合合規規範?

  1. 實施嚴格的網路分段:POS 終端機必須驗證至對應到隔離 VLAN 的專用、隱藏 SSID。 2. 對所有 POS 裝置強制執行 EAP-TLS 驗證,以確保雙向驗證,並防止惡意裝置加入 POS 網路。 3. 設定 Cloud RADIUS 服務,將所有帳務日誌 (Access-Accept、Access-Reject、連線時間) 保留至少一年,此為 PCI-DSS 的強制規定。 4. 確保分支機構 AP 與 Cloud RADIUS 服務之間的 RADIUS 共用金鑰每 90 天使用自動化指令碼進行輪替。
考官評語: 此解決方案直接解決了 PCI-DSS 對於邏輯分段、強效存取控制和可審計性的要求。僅依賴 MAC 位址篩選不足以達到合規標準;EAP-TLS 提供了裝置識別所需的加密證明。將帳務日誌保留在雲端可簡化 QSA 的稽核程序。

練習題

Q1. 您的組織正在從內部部署的 Active Directory 遷移到 Google Workspace。您目前使用 PEAP-MSCHAPv2 進行 WiFi 驗證。為什麼這是一個問題?推薦的解決方案是什麼?

提示:考慮 PEAP 如何針對目錄通訊協定驗證認證。

查看標準答案

PEAP-MSCHAPv2 依賴使用者密碼的 NT 雜湊值,而 Google Workspace 原生並不儲存或公開此雜湊值。推薦的解決方案是使用具有整合 PKI 的 Cloud RADIUS 供應商遷移至 EAP-TLS。Cloud RADIUS 服務可以透過 SAML/SCIM 從 Google Workspace 同步使用者身分,並使用用戶端憑證而非密碼來驗證裝置。

Q2. 分支機構報告指出,使用者在連線至 WiFi 網路時遇到 30 秒的延遲,隨後連線成功。該地區的主要 Cloud RADIUS IP 目前正在進行維護。什麼設定錯誤導致了這種延遲?

提示:查看 NAS 和 RADIUS 伺服器之間的通訊。

查看標準答案

NAS (Access Point 或 Switch) 設定的 RADIUS 伺服器逾時時間過長(例如 30 秒)。它在容錯移轉至次要伺服器之前,正在等待主要伺服器回應。逾時時間應縮短至 3 - 5 秒,以確保快速進行容錯移轉而不影響使用者體驗。

Q3. 您正在為一家醫院部署 Cloud RADIUS。安全團隊規定,即使員工知道有效的使用者名稱和密碼,也只有公司擁有的裝置才能連線至內部網路。您要如何強制執行此規定?

提示:哪種 EAP 方法可以驗證裝置的身分,而不僅僅是使用者所知道的資訊?

查看標準答案

部署 EAP-TLS。設定醫院的 MDM 解決方案,僅將唯一的用戶端憑證推送到已註冊的公司擁有裝置。設定 Cloud RADIUS 原則以拒絕任何未提供由信任的內部 PKI 簽署之有效憑證的驗證請求,從而有效封鎖 BYOD 或惡意裝置,無論其是否知道密碼。