Okta 與 RADIUS：將您的身分識別提供者擴充至 WiFi 驗證
本指南為以 Okta 為核心的企業 IT 管理員提供完整的技術參考，協助其使用 Okta RADIUS 代理程式將雲端身分識別提供者擴充至 WiFi 驗證。內容涵蓋完整的驗證架構、MFA 強制執行的權衡、透過 RADIUS 屬性對應進行動態 VLAN 分配，以及在基於密碼的 EAP-TTLS 與基於憑證的 EAP-TLS 之間的關鍵決策。場域營運商與企業 IT 團隊將可獲得實用的部署指南、來自旅宿業與零售業的真實案例研究，以及將 Okta RADIUS 與專屬訪客 WiFi 解決方案整合的清晰框架。
Video overview
收聽此指南
查看播客逐字稿
核心系列的一部分：企業 WiFi 安全指南 →
Okta RADIUS WiFi architecture and sizing advisor
Model your enterprise identity infrastructure, device endpoints, and authentication protocols to generate an 802.1X deployment blueprint, timeout guidelines, and network configuration checklist.
Cloud RADIUS with Okta Directory Sync and EAP-TLS
- Configure Cloud RADIUS tenant and establish OAuth 2.0 API connection to your Okta organization.
- Add wireless controller management IP addresses as authorised network access clients (NAS) in Cloud RADIUS.
- Configure 802.1X SSID security settings with Cloud RADIUS primary and secondary IP addresses and shared secrets.
- Configure RADIUS Return Attributes: Tunnel-Type (64 = VLAN), Tunnel-Medium-Type (65 = 802), and Tunnel-Private-Group-ID (81 = target VLAN tag) mapped from Okta groups.
- Wireless controller RADIUS timeout can remain at standard enterprise default of 5 seconds with 3 retries.
執行摘要
對於管理分散式場域（從連鎖飯店到體育場）的企業 IT 團隊而言，將網路存取控制與雲端身分識別提供者進行統一，是邁向零信任（Zero Trust）的關鍵步驟。Okta RADIUS 代理程式彌補了現代雲端身分識別與傳統 802.1X WiFi 基礎架構之間的差距，使企業能夠淘汰用於網路驗證的舊型地端 RADIUS 伺服器和 Active Directory 基礎架構。
本指南詳細介紹如何部署 Okta RADIUS 代理程式以進行企業級 WiFi 驗證，內容涵蓋代理架構、MFA 強制執行機制，以及基於密碼的 EAP-TTLS 與基於憑證的 EAP-TLS 之間的權衡。此外，本指南還針對如何將 Okta 群組成員身分對應至 RADIUS 屬性以進行動態 VLAN 分配提供實用的指導，此功能直接支援 PCI-DSS 網路區隔合規要求。透過將用於員工驗證的 Okta 與 Guest WiFi 解決方案相結合，場域營運商無需重複建置身分識別基礎架構，即可實現統一、安全且合規的存取層。
技術深度剖析
Okta RADIUS 代理程式的運作原理
Okta RADIUS 代理程式是一個輕量級的系統服務，在網路存取伺服器（NAS） - 例如無線基地台（WAP）或無線區域網路控制器（WLC） - 與 Okta 雲端之間扮演代理程式的角色。它通常部署在內部部署或雲端 VPC 內的 Windows 或 Windows 伺服器上，並在初始安裝後完全由 Okta 管理主控台（Okta Admin Console）進行管理。
驗證流程遵循標準的 802.1X 代理模式。使用者的裝置（要求端）連線至企業級 SSID 並提供憑證。WAP 或 WLC（驗證端）透過 UDP 連接埠 1812 將 RADIUS Access-Request 轉發給 Okta RADIUS 代理程式。該代理程式透過 HTTPS API 呼叫，將此請求安全地通道化傳輸至 Okta 雲端，Okta 的原則引擎在此根據其使用者目錄和任何已設定的登入原則來評估憑證。如果驗證成功，代理程式會向驗證端傳回 RADIUS Access-Accept 訊息，並可選擇性地包含用於授權的 RADIUS 屬性（例如 VLAN 分配）。如果需要 MFA，代理程式會向用戶端傳送 RADIUS Access-Challenge，在傳回最終決定之前要求進行第二因素驗證。
這種代理模式意味著 Okta RADIUS 代理程式不需要在本地儲存使用者憑證。所有的驗證邏輯、原則評估和稽核記錄皆在 Okta 雲端中進行，為管理員提供了一個單一窗口，以跨雲端應用程式和網路存取進行身分識別治理。### 支援的 EAP 協定與關鍵限制
Okta RADIUS 代理程式的一個基本架構限制是其依賴密碼驗證協定 (PAP) 進行主要驗證。雖然 PAP 在內層以純文字傳輸密碼，但這已被外層可延伸驗證協定 (EAP) 的 TLS 隧道所封裝並保護。支援的外層協定為 EAP-TTLS (以 PAP 作為內層方法) 和 EAP-GTC。如需深入比較 EAP 方法，請參閱 Comparativa de métodos EAP: PEAP, EAP-TLS, EAP-TTLS y EAP-FAST 參考指南。
關鍵在於，不支援 PEAP-MSCHAPv2。這是 Windows 用戶端和許多舊版企業環境的預設 802.1X 協定。從傳統 NPS/Active Directory RADIUS 設定遷移的組織，必須重新設定其用戶端 supplicant 以使用 EAP-TTLS 搭配 PAP - 這種變更通常需要透過 MDM 或群組原則推播無線設定檔。未能考慮到這一點是 Okta RADIUS 部署失敗最常見的原因。
完全依賴雙向憑證驗證的 EAP-TLS，也無法由 Okta RADIUS 代理程式原生支援。需要 EAP-TLS 的組織必須部署專用的 PKI 或雲端 RADIUS 解決方案，並透過 SAML 或 OIDC 將其與作為 IdP 的 Okta 整合，而不是直接使用 Okta RADIUS 代理程式。
在 WiFi 連線中強制執行 MFA
Okta RADIUS 代理程式支援 WiFi 存取的 MFA，但它帶來了使用者體驗上的挑戰，在部署前必須仔細考慮。當觸發 MFA 原則時，代理程式會向用戶端傳送 RADIUS Access-Challenge。Okta 支援 RADIUS 應用程式的多種要素：
| MFA 要素 | PAP | EAP-TTLS | 備註 |
|---|---|---|---|
| Okta Verify 推播 | 支援 | 支援 | 頻外傳送；使用者在行動裝置上點擊「核准」 |
| TOTP (Okta Verify / Google Auth) | 支援 | 支援 | 使用者將 OTP 附加至密碼後方 (例如 Pass123,456789) |
| 簡訊 / 電子郵件 / 語音 | 支援 | 支援 | 使用者先傳送觸發字串 (SMS、EMAIL、CALL) |
| Duo 推播 / 簡訊 / 密碼 | 支援 | 支援 | EAP-TTLS 僅限 Duo 密碼 |
| YubiKey / U2F / Windows Hello | 不支援 | 不支援 | 硬體權杖與 RADIUS 協定不相容 |
實際的限制在於漫遊。在 旅宿餐飲 環境中，房務人員的平板電腦在每次排班期間可能會在存取點之間漫遊數十次，每次都會觸發重新驗證。在每次漫遊時都要求推播通知核准，在營運上是無法維持的。對於一般員工 WiFi，強密碼原則結合 Okta 的裝置信任和網路區域原則，通常比主動的 MFA 提示更受青睞。WiFi 上的 MFA 應保留給管理用 SSID 或高權限存取場景。
基於密碼與基於憑證的驗證
在企業 WiFi 部署中，選擇使用基於密碼的 RADIUS（透過 Okta RADIUS 代理程式）還是基於憑證的 EAP-TLS，是最具影響力的決定之一。這些折衷方案不僅僅關乎安全性，還涉及部署複雜性、裝置管理成熟度以及營運開銷。
透過 Okta RADIUS 代理程式進行基於密碼的驗證，為統一識別身分提供了一條快速途徑。如果您的組織已在 Okta 中管理使用者，則部署可在數小時內完成，而無需數週。無需建置 PKI，無需發派憑證，也不依賴 MDM。其折衷之處在於密碼仍是主要的憑證，且由於缺乏相互驗證，用戶端無法透過加密方式驗證網路的身分 - 這在面臨高風險的環境中，是邪惡雙生仔攻擊（Evil Twin Attacks）的溫床。
基於憑證的 EAP-TLS 則將密碼完全從 WiFi 驗證公式中排除。用戶端出示裝置憑證，而 RADIUS 伺服器則出示伺服器憑證，以提供雙向驗證。這是 WPA3-Enterprise 網路上 IEEE 802.1X 的推薦做法，特別是在受 PCI-DSS 或 NCSC Cyber Essentials 等規範約束的環境中。其前提是必須具備運作正常的 PKI - 無論是地端的 Microsoft ADCS 部署還是雲端 PKI 服務 - 以及能夠將憑證發派至所有託管端點的 MDM 平台。對於擁有數百台託管 POS 裝置的 零售 環境而言，這項投資非常值得。而對於以 BYOD 為主或需要快速部署的環境，搭配 EAP-TTLS 的 Okta RADIUS 是最務實的選擇。
用於動態 VLAN 分配的 RADIUS 屬性對應
動態 VLAN 分配是 Okta RADIUS 整合發揮最具體營運價值的地方。藉由將 Okta 群組成員資格對應至 RADIUS 屬性，網路管理員可以實施基於角色的網路分段，而無需針對每個裝置或每個位置維護個別的 VLAN 策略。
Okta 會使用以下三種屬性之一，在 RADIUS Access-Accept 訊息中傳遞群組成員資格資料，這些屬性可在 Okta 應用程式的高級 RADIUS 設定中進行設定：
- Attribute 11 (Filter-Id)：包含群組名稱的字串屬性。廣受各家廠商支援。
- Attribute 25 (Class)：用於授權的非透明屬性。受 Cisco ISE、Aruba ClearPass 和 Fortinet 支援。
- Attribute 26 (Vendor-Specific)：允許使用特定廠商的子屬性，以進行更精細的控制。
網路控制器（WLC、NAC 設備）會在所選屬性中接收 Okta 群組名稱，並將其對應至 VLAN 分配所需的標準 RADIUS 通道屬性：
| RADIUS 屬性 | 值 | 用途 |
|---|---|---|
| 64 (Tunnel-Type) | 13 (VLAN) | 指定 VLAN 通道傳輸 |
| 65 (Tunnel-Medium-Type) | 6 (802) | 指定 IEEE 802 媒體 |
| 81 (Tunnel-Private-Group-ID) | 例如：40 |
目標 VLAN ID |
例如，Okta 群組 Retail-POS-Staff 中的使用者會在 Access-Accept 中收到傳回的 Class: Retail-POS-Staff。WLC 策略會將此對應至 Tunnel-Private-Group-ID: 40，並將裝置置於 VLAN 40 - 即隔離的 POS 網路中。而在 Store-Management 中的使用者則會被置於 VLAN 50。此邏輯是在網路邊緣執行，而非在 Okta 中，但它完全由 Okta 群組成員資格所驅動。
對於您的特定設置有任何疑問嗎？
我們的團隊與超過 80,000 個場域的場域營運商、IT 經理和網路工程師合作。立即預約 20 分鐘的通話，我們將向您展示其他與您相似的用戶是如何解決此問題的。
實作指南
步驟 1：部署 Okta RADIUS Agent（高可用性）
在至少兩台伺服器上部署 Okta RADIUS agent - 無論是地端還是雲端 VPC - 以確保高可用性。單一 Agent 部署具有重大風險：如果伺服器因修補程式而無法使用或發生故障，整個環境中的所有 802.1X WiFi 驗證都將失敗。請設定您的 WLC 或 NAC 裝置，以在兩個 Agent 之間對 RADIUS 請求進行負載平衡。
在安裝過程中，Agent 會提示輸入 Okta 管理員登入資訊，以授權 Agent 並將其連結至 Okta 租戶。授權完成後，該 Agent 將顯示在 Okta 管理主控台中的 Settings > Downloads > RADIUS Agent Status，您可以在此監控其健康狀況與連線狀態。
步驟 2：在 Okta 中設定 RADIUS 應用程式
- 在 Okta 管理主控台中，導覽至 Applications > Applications，並在應用程式目錄中搜尋 RADIUS Application。
- 新增此應用程式，為其指定一個具描述性的名稱（例如：
Corporate-WiFi-Staff），然後按一下 Next。 - 在 Sign On 索引標籤下，設定 RADIUS Port（預設為 1812），並產生一個至少 32 個字元的強型、隨機產生的 Shared Secret。
- 在 Advanced RADIUS Settings 下，如果您打算支援在密碼後附加 TOTP，請啟用 Accept password and security token in the same login request。
- 選擇性啟用 Permit Automatic Push for Okta Verify Enrolled Users，以實現無縫的推播式 MFA。
- 將應用程式分配給代表您員工的相關 Okta 群組。
步驟 3：設定基於群組的 VLAN 分配
- 在 RADIUS 應用程式的 Sign On 設定中，按一下 Advanced RADIUS Settings 區段中的 Edit。
- 勾選 Include groups in RADIUS response。
- 選擇 RADIUS 屬性：Aruba 和 Cisco 環境建議使用 25 Class；Fortinet 及其他環境則建議使用 11 Filter-Id。
- 新增要包含的特定 Okta 群組名稱（例如：
Retail-POS-Staff、Store-Management、IT-Admins）。 - 在您的 WLC 或 NAC 裝置上，建立將每個群組名稱對應至相應 VLAN 通道屬性的強制執行策略。
步驟 4：設定用戶端 Supplicants
因為不支援 PEAP-MSCHAPv2，用戶端裝置必須設定為將 EAP-TTLS 搭配 PAP 作為內部方法。請透過您的 MDM 平台（例如 Microsoft Intune、Jamf Pro）或透過 Windows 網域加入裝置的群組原則物件 (GPO) 來部署無線網路設定檔。該設定檔應指定：
- SSID：您的企業 SSID 名稱
- 安全性：WPA2-Enterprise 或 WPA3-Enterprise
- EAP 方法：EAP-TTLS
- 內部驗證：PAP
- 伺服器憑證驗證：已啟用（綁定到您的 RADIUS 代理程式伺服器憑證 CN）
步驟 5：設定 RADIUS 逾時
將您 WLC 上的 RADIUS 逾時時間從預設的 3 - 5 秒增加到 30 - 60 秒。如果使用 MFA 推播通知，這一點至關重要，因為使用者必須有足夠的時間在裝置上核准通知，然後 WLC 才會放棄該驗證嘗試。
最佳實踐
部署 Okta RADIUS 進行 WiFi 驗證非常簡單，但幾項營運最佳實踐可以將彈性的實際執行部署與脆弱的概念驗證區分開來。
在 SSID 層級分割訪客和員工流量。 Okta RADIUS 是一項員工身分識別工具。對於訪客和臨時存取，請部署專用的 Captive Portal 解決方案。這可以防止 Okta 授權成本隨訪客數量增加而擴展，並確保職責的乾淨分離。Purple 企業客戶可以在不同的 SSID 上部署 Guest WiFi，同時在同一個實體基礎架構上使用 Okta RADIUS 進行員工驗證。
在複雜的原則環境中使用 NAC 設備。 如果您的環境除了使用者身分外，還需要根據裝置狀態、MAC 地址篩選或憑證狀態進行條件式存取，請部署中介 NAC 設備（Aruba ClearPass、Cisco ISE 或 Portnox）來將請求代理到 Okta RADIUS 代理程式。NAC 設備可以使用 Okta 代理程式本身無法產生的額外通道屬性來豐富 RADIUS 回應。
透過 Okta 系統記錄進行監控。 每次驗證事件（成功、失敗、MFA 挑戰和因素類型）都會記錄在 Okta 系統記錄中。為您的 SIEM 設定記錄串流，以便對驗證異常進行即時警示。這對於受稽核要求約束的 醫療保健 和公營部門組織特別有價值。
定期輪替共用密鑰。 Okta RADIUS 應用程式與您的 NAS 之間的共用密鑰是關鍵的安全認證。實施輪替排程（建議每季一次），並同時更新 Okta 應用程式和 WLC/NAC 設定。
限制 RADIUS 服務地址。 在 Okta RADIUS 代理程式設定中，限制允許發送 RADIUS 請求的 IP 地址。這可以防止未經授權的 NAS 裝置嘗試對您的 Okta 租戶進行驗證。
如需瞭解更廣泛的網路架構背景指南，請參閱 The Core SD WAN Benefits for Modern Businesses 以及 Wireless Access Points Definition Your Ultimate 2026 Guide。
疑難排解與風險緩釋
下表總結了在 Okta RADIUS WiFi 部署中，最常見的失敗模式及其建議的緩釋措施。
| 失敗模式 | 根本原因 | 緩釋措施 |
|---|---|---|
| 身分驗證逾時 | WLC RADIUS 逾時時間太短，不足以回應 Okta API 或 MFA | 將 WLC RADIUS 逾時時間增加至 30 - 60 秒 |
| Windows 用戶端遭到拒絕 | Windows 預設使用 PEAP-MSCHAPv2，而此協定會被 Okta RADIUS 拒絕 | 透過 MDM 或 GPO 推送 EAP-TTLS/PAP 無線設定檔 |
| 使用者位於錯誤的 VLAN | Okta 群組名稱不相符，或 WLC 上缺少通道屬性 | 驗證 WLC 是否將 Class/Filter-Id 對應至 Tunnel-Private-Group-ID；檢查 Okta 系統記錄 |
| 代理程式無法連線 | 伺服器離線、API 權杖過期，或防火牆阻擋了往 Okta 的 HTTPS 流量 | 部署備援代理程式；在 Okta 管理主控台中監控代理程式狀態；驗證連外 HTTPS |
| 未傳送 MFA 推播 | 使用者未註冊 Okta Verify，或行動裝置離線 | 強制執行 Okta Verify 註冊原則；考慮將 TOTP 作為備份方案 |
| 憑證驗證錯誤 | 用戶端無法驗證 RADIUS 伺服器憑證 | 在用戶端無線設定檔中鎖定伺服器憑證 CN；確保 CA 鏈結受信任 |
| 未傳送 VLAN 屬性 | Okta 群組未包含在 RADIUS 回應設定中 | 驗證群組是否已列在進階 RADIUS 設定中；確認使用者為 Okta 中該群組的成員 |
對於網路運作時間至關重要的 Transport 和公共部門環境，請實作合成監控，以定期對 RADIUS 身分驗證進行端到端的測試，並在使用者受到影響之前，針對失敗情況發出警示。
投資報酬率與商業效益
採用 Okta RADIUS WiFi 身分驗證的商業論證奠基於三大支柱：營運效率、安全性評估提升以及合規準備度。
**營運效率：**將 WiFi 身分驗證整合至 Okta 中，即可消除在各個場域或站點維護獨立在地 RADIUS 基礎架構（NPS 伺服器、本機 AD）的需求。對於擁有 50 家物業的連鎖飯店而言，這代表能顯著降低每個站點的基礎架構成本和 IT 支援開銷。使用者佈建與取消佈建變得一氣呵成：將使用者加入正確的 Okta 群組，即可同時授予應用程式存取權限與對應的 WiFi VLAN 存取權限。當員工離職時，停用其 Okta 帳戶便會立即撤銷其在所有站點的 WiFi 存取權限。
**安全性態勢。**以每位使用者的 802.1X 驗證取代共用的 PSK WiFi 密碼，可消除憑證共用——這是內部威脅和未授權存取的常見管道。結合動態 VLAN 分配，這在網路層落實了最小權限原則。Okta 系統記錄提供每個 WiFi 驗證事件完整、防篡改的稽核軌跡，這對於事件回應至關重要。
**合規準備。**PCI DSS 4.0 要求 8.3 規定所有非主控台的管理員存取權限皆須配備 MFA。要求 1.3 則規定持卡人資料環境與其他網路之間必須進行網路分段。採用群組型 VLAN 分配的 Okta RADIUS 直接滿足了這兩項要求。針對 GDPR 合規性，Okta 系統記錄提供了展示對個人資料處理系統進行適當技術控制所需的存取記錄。對於部署 現代化餐旅業 WiFi 方案 的場域而言，這種將身分識別與網路存取整合的統一方法，已日益成為企業採購的必要條件。
完成此整合的組織通常表示，與 WiFi 相關的 IT 支援工單減少了（密碼重設請求和 VLAN 設定錯誤事件減少），且安全性稽核分數有顯著提升。部署和設定 Okta RADIUS 代理程式的投資 - 對於單一站點部署而言，通常以天數而非週數來衡量 - 可帶來持續的營運成本節省，並在分佈式資產中產生加乘效果。
關鍵定義
Okta RADIUS Agent
一種輕量級的內部部署或雲端託管代理服務，可將來自網路基礎架構（存取點、WLC）的 RADIUS 驗證請求轉換為 Okta API 呼叫，從而使 Okta 雲端能夠作為 802.1X WiFi 的驗證後端。
IT 團隊在部署由 Okta 支援的企業級 WiFi 驗證時會遇到此元件。它是連通傳統基於 RADIUS 的網路基礎架構與現代雲端身分識別之間的關鍵橋梁元件。
802.1X
一項用於基於連接埠的網路存取控制 (NAC) 的 IEEE 標準，定義了用於有線與無線網路的驗證框架。它使用可延伸驗證通訊協定 (EAP) 在使用者用戶端（裝置）、驗證器（AP/交換器）與驗證伺服器 (RADIUS) 之間傳遞驗證憑證。
802.1X 是企業級 WiFi 安全性的基礎。任何使用 WPA2-Enterprise 或 WPA3-Enterprise 的部署皆使用 802.1X。IT 團隊必須了解三方模型（使用者用戶端、驗證器、驗證伺服器），以排除連線問題。
EAP-TTLS (Extensible Authentication Protocol - Tunnelled Transport Layer Security)
一種 EAP 方法，僅使用伺服器端憑證建立 TLS 通道，然後在通道內傳遞較簡單的內部驗證通訊協定（例如 PAP）。這可保護內部憑證免受竊聽，同時僅需部署伺服器端的憑證基礎架構。
搭配 PAP 的 EAP-TTLS 是 Okta RADIUS WiFi 驗證的推薦通訊協定。它比單純的 PAP 更安全，且不需要用戶端憑證，因此非常適合 BYOD 與混合裝置環境。
EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)
一種使用雙向憑證式驗證的 EAP 方法 - 用戶端和伺服器都會出示數位憑證。它是最安全的 802.1X 方法，提供抗網路釣魚、無密碼的驗證。
EAP-TLS 是託管企業裝置環境的金標。它需要 PKI 基礎架構和 MDM 進行憑證派送。Okta RADIUS 代理程式原生不支援 EAP-TLS；需要專門的雲端 PKI 或 RADIUS 服務。
PAP (Password Authentication Protocol)
一種以純文字傳送使用者名稱和密碼的簡單驗證協定。在 802.1X 的上下文中，PAP 被用作 EAP-TTLS 通道內部的內部驗證方法，其中外部 TLS 層提供加密。
PAP 是 Okta RADIUS 代理程式支援的主要驗證機制。IT 團隊必須瞭解單獨使用 PAP 是不安全的，但當伺服器憑證得到正確驗證時，在 EAP-TTLS 內部使用 PAP 對於企業 WiFi 來說是可以接受的。
Dynamic VLAN Assignment
一種網路存取控制技術，RADIUS 伺服器在 Access-Accept 訊息中傳回 VLAN 指派屬性，使無線控制器或交換器根據用戶端的識別身份或群組成員資格，將通過驗證的用戶端置於特定的 VLAN 中，而非靜態的每個 SSID VLAN。
Dynamic VLAN assignment 對於多角色環境中的網路分段至關重要（例如：將 POS 終端機與一般員工裝置分開）。它是透過在 Access-Accept 訊息中傳回 RADIUS 屬性 64、65 和 81 來設定的。
RADIUS Attribute 25 (Class)
一種標準 RADIUS 屬性，用於將任意授權資料從驗證伺服器傳遞給 NAS。Okta 使用此屬性將 Okta 群組成員資格資訊傳回給無線控制器，然後無線控制器可用於 VLAN 指派或存取原則決策。
設定基於 Okta 群組的 VLAN 指派之 IT 團隊將設定 WLC 讀取 Class 屬性值並將其對應至 VLAN ID。要使用的確切屬性（11、25 或 26）取決於 WLC 廠商的說明文件。
NAS (Network Access Server)
在 RADIUS 術語中，NAS 是接收使用者連線要求並將其轉發給 RADIUS 伺服器進行驗證的網路裝置。在 WiFi 部署中，NAS 通常是無線存取點或無線區域網路控制器。
在 802.1X 模型中，NAS 是驗證器。IT 團隊必須為 NAS 設定 RADIUS 伺服器 IP 位址、連接埠和共用金鑰。NAS IP 位址應加入 Okta RADIUS 代理程式服務位址篩選設定的允許清單中。
Shared Secret
一種預先共用的密碼，用於在 NAS (WLC/AP) 和 RADIUS 伺服器 (Okta RADIUS 代理程式) 之間驗證 RADIUS 訊息。它用於計算 Message-Authenticator 雜湊值，以驗證 RADIUS 封包的完整性。
在 Okta RADIUS 應用程式設定和 WLC/NAC RADIUS 伺服器項目上，共用金鑰必須完全相同。它應該至少有 32 個字元、隨機產生，並定期輪替。不匹配是 RADIUS 驗證失敗的常見原因。
MFA Challenge (RADIUS Access-Challenge)
當需要額外的驗證要素時，由驗證伺服器發送給 NAS 的 RADIUS 訊息類型。NAS 將挑戰轉發給用戶端，用戶端必須回應適當的要素（例如：OTP、推送核准）才能完成驗證。
Access-Challenge 機制是 Okta 透過 RADIUS 強制執行 MFA 的方式。IT 團隊必須確保 WLC 支援挑戰 - 回應交換，並且 RADIUS 逾時時間足夠長，以便使用者完成 MFA 步驟。
範例
一家擁有 150 家物業的連鎖飯店目前在每個物業使用地端 NPS 伺服器進行 802.1X 員工 WiFi 驗證。每台 NPS 伺服器都已加入本地的 Active Directory 網域。IT 團隊希望將身分識別管理集中在 Okta 中，並消除各物業的 NPS 基礎架構。他們該如何進行此項遷移？
建議的方法是採用分階段遷移，將 Okta RADIUS 代理程式部署在集中的雲端 VPC 中，而不是部署在每個物業。階段 1：在與大多數物業相同區域的雲端 VPC（例如 AWS 或 Azure）中部署兩個 Okta RADIUS 代理程式執行個體。將代理程式設定為接聽 UDP 1812。階段 2：針對每個物業，在 WLC 上將 Okta RADIUS 代理程式 IP 新增為次要 RADIUS 伺服器，並保留現有的 NPS 作為主要伺服器。這允許在不中斷即時驗證的情況下進行平行運作與測試。階段 3：將使用者從本地 AD 遷移到 Okta。最初使用 Okta 的 AD 代理程式來同步現有帳戶，然後逐步轉移到以 Okta 作為授權來源。階段 4：針對每個物業，將 WLC 設定為使用 EAP-TTLS/PAP，並透過 MDM 將新的無線設定檔推送到員工裝置。階段 5：確認所有裝置都使用 EAP-TTLS 後，將 WLC RADIUS 優先順序切換為以 Okta 代理程式為主要，並停用 NPS 伺服器。設定 Okta 群組（Front-Desk、Housekeeping、F&B、Management、IT-Admins），並使用 Attribute 25 (Class) 啟用基於群組的 VLAN 分配。將每個群組對應到 WLC 上相應的 VLAN。將 WLC RADIUS 逾時時間增加到 45 秒，以容納 Okta API 延遲。
一家擁有 320 家門市的全國連鎖零售商需要為其員工 WiFi 實現 PCI DSS 4.0 合規。門市員工使用手持裝置進行庫存管理，並有另一套獨立的裝置處理 POS 交易。該連鎖店使用 Okta 進行所有員工身分識別。他們如何使用 Okta RADIUS 實作 VLAN 分段，以滿足 PCI DSS 網路分段要求？
建立三個 Okta 群組：POS-Staff（適用於操作 POS 終端機的員工）、Inventory-Staff（適用於倉庫與店面工作夥伴）以及 Store-Management。在 Okta RADIUS 應用程式中，啟用「在 RADIUS 回應中包含群組」並選擇 Attribute 25 (Class)。將這三個群組全部加入回應設定中。在每間分店的無線控制器上（或透過雲端 WLC 進行集中管理），建立三條強制執行原則：(1) 若 Class = POS-Staff，則指派 Tunnel-Private-Group-ID = 40（此為 POS VLAN，屬於 PCI DSS 規範範圍，並設有防火牆規則限制僅能存取付款處理商）。(2) 若 Class = Inventory-Staff，則指派 Tunnel-Private-Group-ID = 50（此為庫存 VLAN，不屬於 PCI 規範範圍）。(3) 若 Class = Store-Management，則指派 Tunnel-Private-Group-ID = 60（此為管理 VLAN，可存取商店管理系統）。使用 POS-Staff 群組中之使用者憑證進行連線的裝置，會自動被分配至 VLAN 40。若店面工作夥伴的角色發生變更，只要更新其 Okta 群組成員資格，即可在下次連線時立即變更其 VLAN 分配，無需重新設定 WLC。請在網路分段架構圖中記錄 Okta 群組與 VLAN 的對應關係，以供 PCI DSS QSA 稽核使用。
練習題
Q1. 一間中型會議中心使用 Okta 進行所有員工身分識別管理。他們希望使用現有的 Cisco Meraki 存取點，為員工部署 802.1X WiFi。他們的 Windows 筆記型電腦是透過 Microsoft Intune 進行管理。IT 經理希望針對所有 WiFi 連線強制執行 Okta Verify 推送 MFA。他們必須完成哪三個最關鍵的設定步驟？若遺漏任何步驟，最可能發生的失敗模式為何？
提示：請考慮 Okta RADIUS 與 Windows 預設值之間的 EAP 協定相容性、RADIUS 逾時設定以及用戶端無線設定檔設定。
查看標準答案
三個關鍵步驟為：(1) 透過 Intune 部署無線設定檔，將 Windows 用戶端設定為使用 EAP-TTLS 並以 PAP 作為內部方法 - Windows 預設為 PEAP-MSCHAPv2，Okta RADIUS 代理程式並不支援此方法，這會導致所有驗證嘗試皆被拒絕。(2) 將 Cisco Meraki RADIUS 逾時時間從預設的 5 秒增加到至少 45 - 60 秒 - 若不進行此設定，在使用者來得及核准 Okta Verify 推送通知之前，驗證要求就會逾時。(3) 在 Okta RADIUS 應用程式的「進階 RADIUS 設定」中啟用「允許為已註冊 Okta Verify 的使用者進行自動推送」 - 若不進行此設定，系統可能會提示使用者手動選擇其 MFA 因素，而不會收到自動推送。如果遺漏步驟 1，最可能的失敗模式是所有 Windows 裝置發生完全驗證失敗。如果遺漏步驟 2，對於需要超過 5 秒才能核准推送的使用者，驗證將會間歇性失敗。如果遺漏步驟 3，使用者將會遇到令人困惑的驗證提示，而無法體驗無縫的推送通知。
Q2. 某大型零售連鎖店的安全小組指出，他們目前的 Okta RADIUS WiFi 部署僅使用單一 RADIUS 代理程式伺服器。在最近的一次修補期間，該伺服器離線了 45 分鐘，導致所有 80 家門市的 WiFi 驗證失敗。IT 小組應該實施哪些架構變更來防止這種情況？代理程式的兩種部署選項為何？
提示：請同時考慮代理程式部署拓撲以及支援備援所需的 WLC 設定。
查看標準答案
IT 小組應至少部署兩個 Okta RADIUS 代理程式執行個體，並將每家門市的 WLC 設定為同時使用這兩個代理程式。有兩種部署選項：選項 A (集中式雲端 VM) - 在雲端 VPC (例如 AWS 或 Azure) 中部署這兩個代理程式，最好是在不同的可用區域中。每家門市的 WLC 皆指向這兩個雲端 IP，一個作為主要，另一個作為次要 (或啟用負載平衡)。這可將每家門市的基礎設施降至最低，但會引入對 WAN 的依賴。選項 B (內部部署備援對) - 在中央資料中心或主機代管設施部署兩台代理程式伺服器，並由 WLC 使用 RADIUS 容錯移轉。在 WLC 上，將主要 RADIUS 伺服器設定為代理程式 1，將次要伺服器設定為代理程式 2，容錯移轉逾時設定為 3 - 5 秒。若 WLC 廠商支援，請啟用「無回應伺服器偵測」(Dead Server Detection)。此外，IT 小組應在 Okta Admin Console 中設定健康狀況監控，並在代理程式離線時設定告警。對於擁有本機伺服器的門市，本機代理程式可作為第三重後備，以應對 WAN 中斷的彈性需求。
Q3. 某企業組織正在評估是否要搭配使用 Okta RADIUS 代理程式與 EAP-TTLS/PAP，或是為其企業 WiFi 投資可用於 EAP-TLS 的雲端 PKI 解決方案。他們有 2,000 台已註冊於 Microsoft Intune 的託管 Windows 和 macOS 裝置，且必須遵守 PCI DSS 4.0。推薦的方法為何？主要的安全性依據為何？
提示：請考慮 PCI DSS 要求、裝置管理成熟度 (所有裝置皆已加入 MDM) 以及每種驗證方法的安全性屬性。
查看標準答案
最推薦的方法是投資部署結合雲端 PKI 解決方案的 EAP-TLS。其主要的安全依據在於雙向驗證：EAP-TLS 要求用戶端與 RADIUS 伺服器雙方都必須出示數位憑證，這意味著裝置以密碼學方式向網路證明其身分，而網路也向裝置證明其身分。這消除了惡意雙胞胎攻擊（即惡意 AP 冒充企業 SSID）的風險，並將密碼完全從 WiFi 驗證公式中移除，從而消除了憑證遭竊取與網路釣魚等攻擊管道。針對 PCI DSS 4.0，EAP-TLS 透過憑證型驗證隱性地滿足了要求 8.3（針對非主控台管理員存取的 MFA），並且支援 WPA3-Enterprise 192-bit 模式（要求 4.2.1 的強密碼學）。其前提條件 - 將所有 2,000 台裝置註冊至 Intune - 已經達成，這使得透過 Intune SCEP 設定檔分發憑證變得非常簡單。雖然搭配 EAP-TTLS/PAP 的 Okta RADIUS 代理程式在 PKI 建置期間可作為可接受的過渡方案，但考量到 PCI DSS 範圍和完全託管的裝置資產，EAP-TLS 才是正確的長期架構。對雲端 PKI 服務的額外投資（通常為每台裝置每年 3 到 8 美元）因安全性的提升以及憑證管理維護成本的降低而顯得非常合理。
常見問題
Can I connect Okta directly to enterprise WiFi without an intermediate RADIUS server?
No. Enterprise wireless access points and controllers authenticate clients using the 802.1X protocol, which relies on RADIUS (Remote Authentication Dial-In User Service). Because Okta is a cloud identity provider operating over REST APIs and SAML or OIDC, it cannot speak the RADIUS protocol directly over UDP ports 1812 and 1813. You must deploy either the on-premises Okta RADIUS Server Agent or a cloud RADIUS service that translates network authentication requests into Okta API calls.
What is the difference between the on-premises Okta RADIUS agent and Cloud RADIUS?
The Okta RADIUS agent is a service that you host on an internal Windows or Linux virtual machine. It receives RADIUS requests from your wireless controllers and proxies them to the Okta API. Cloud RADIUS is a fully hosted, multi-region cloud service that requires zero on-premises virtual machines, offers native PKI integration for EAP-TLS client certificates, and scales globally with automated failover.
Which EAP authentication protocol should be used with the Okta RADIUS agent?
Okta recommends EAP-TTLS (Tunneled Transport Layer Security) with PAP as the inner authentication method when using the Okta RADIUS agent. EAP-TTLS establishes an encrypted TLS tunnel using a server-side certificate on the RADIUS agent, protecting user credentials in transit while allowing Okta to validate passwords directly against its cloud directory without requiring client-side certificates.
How does dynamic VLAN assignment work between Okta and wireless controllers?
Dynamic VLAN assignment allows your wireless LAN controller to place users onto specific network segments based on their Okta group membership. During 802.1X authentication, the RADIUS server returns standard attributes in the Access-Accept response: Tunnel-Type (Attribute 64 = VLAN), Tunnel-Medium-Type (Attribute 65 = 802), and Tunnel-Private-Group-ID (Attribute 81 = VLAN ID or name). Your controller assigns the client to that VLAN tag upon connection.
What RADIUS timeout settings are required when using Okta Verify push MFA for WiFi?
Standard RADIUS timeouts of 3 to 5 seconds are too short for interactive push notifications, causing the wireless controller to drop connections before the user can approve the prompt on their phone. When enabling Okta Verify push notifications for WiFi access, increase your wireless controller RADIUS retransmission timeout to at least 30 to 60 seconds and set retry attempts to 1 or 2 to avoid duplicate push notifications.
繼續閱讀本系列
Sophos Firewall 與訪客 WiFi：使用 Purple 設定 captive portal
了解 Purple 的雲端訪客 WiFi 如何透過標準外部 captive portal 與 RADIUS，與 Sophos Firewall 及其存取點搭配運作，以及可在何處確認支援與尋找步驟。
Aruba Central 與 Purple WiFi：雲端管理整合
一份全面的技術參考指南，說明如何將 Aruba Central 與 Purple 的雲端託管訪客 WiFi 智慧平台整合。本指南涵蓋架構、外部 Captive Portal 與 RADIUS 的逐步設定，以及適用於企業 IT 團隊的多站點部署策略。
Microsoft Entra ID (Azure AD) WiFi 驗證：企業整合指南
本技術指南為網路工程師、IT 架構師及系統管理員提供將 Microsoft Entra ID（前稱 Azure AD）與企業級 802.1X WiFi 基礎架構整合的權威藍圖。了解如何淘汰地端 RADIUS 伺服器、透過 Microsoft Intune SCEP 和 Cloud PKI 部署無密碼 EAP-TLS 憑證，並利用 Entra ID 安全性群組自動進行動態 VLAN 指派。
對於您的特定設置有任何疑問嗎？
我們的團隊與超過 80,000 個場域的場域營運商、IT 經理和網路工程師合作。立即預約 20 分鐘的通話，我們將向您展示其他與您相似的用戶是如何解決此問題的。