您接手了一個位於英國的場域，那裡的企業 WiFi 密碼被印在後勤辦公室的文件夾中，並由接待處、房務部、承包商和前員工共用。訪客網絡是分開管理的，設備上網註冊依賴手動說明，而且稽核員想知道每筆連線是由哪個人授權的。與此同時，組織已將其應用程式身分移至 Microsoft Entra ID，並期望 WiFi 也能同步跟進。
這種預期是可以理解的，但其架構經常被錯誤地描述。Microsoft Entra ID 並未提供原生的 RADIUS 服務。Microsoft 官方文件的立場是，加入 Entra 的裝置無法使用基於內部部署電腦物件和憑證的 RADIUS 驗證，因此現代化設計需要依賴 EAP-TLS、Intune 發行的憑證以及獨立的 RADIUS 層 (Microsoft 的 Entra RADIUS 指南)。一旦釐清這個區別，部署的設計、測試和支援就會變得容易得多。
為什麼 Entra ID WiFi 驗證值得投入心力
共用的預先共用金鑰可能在開業時有效，但在員工離職、承包商將其複製到個人裝置，或者訪客連線到專為員工設計的網路後，該金鑰仍然保持啟用狀態。變更該金鑰會產生其自身的營運問題。每台受管理的筆記型電腦、手持裝置、收銀機、平板電腦和其他裝置都必須接收新的密碼，而且通常橫跨飯店、醫院和零售據點。
Microsoft Entra ID WiFi 驗證將信任單元從密碼轉變為身分和裝置。EAP-TLS 使用憑證支援的連線來識別授權的使用者或裝置。Intune 控制哪些受控端點會接收該憑證以及相符的 WiFi 設定檔。存取點仍然需要 RADIUS，因此 Microsoft Entra ID 是目錄和原則來源，而不是無線驗證端點。這個架構上的差距是許多簡化指南所忽略的細節。
實用規則：將 WiFi 視為綁定身分的服務：需要憑證和 Intune 範圍，絕不要貼上 Entra 的使用者名稱和密碼。
上線流程變得可重複執行。設定正確的 Intune 設定檔可以配置 SSID、信任的憑證鏈和憑證選擇，而無需要求員工輸入或共用金鑰。離職流程也獲得了明確的控制路徑。停用裝置可以觸發憑證生命週期操作，而不需要管理員到處搜尋儲存共用密碼的每個位置。
合規性方面的考量也同樣具有實際意義。英國的組織必須在共享場所和受監管的環境中，將員工、訪客、供應商和未受管理的設備進行隔離。這份專屬的 enterprise WiFi security guide 提供了實用的背景資訊，而實際的架構設計則需要明確的決策：將訪客存取與員工的 EAP-TLS 區隔開來、記錄向 RADIUS 出示的身份，並定義如何取消存取權限。
Entra 管理中心並未為此設計提供單一開關。PKI、Intune、RADIUS 原則和無線設定必須協同運作，且舊版 Apple、Windows、Android 和共用裝置可能會呈現不同的憑證或設定檔行為。這種整合工作確實存在，但它將脆弱的共用密碼替換為可在混合的英國資產中應用的可重複控制措施。
您需要準備就緒的核心建置組塊
飯店訪客網路、醫院病房或零售分店可能會在第一次憑證檢查時就宣告失敗，而存取點卻仍顯示 SSID 狀態正常。在開啟 Intune 精靈之前先定義好架構，即可避免這種混亂。以下四個元件必須在同一個識別鏈上達成一致：
- 憑證授權單位：從 Microsoft PKI、AD CS 或託管憑證提供者開始。在調整 RADIUS 原則之前，CA 必須核發具有用戶端驗證 EKU 的憑證，且 RADIUS 服務必須信任該核發鏈。
- RADIUS 層：NPS、Aruba ClearPass、Cisco ISE 或 RADIUS-as-a-Service 平台會終止來自存取點的 802.1X 交換。Entra ID 沒有原生的 RADIUS 功能。正如 Microsoft Q&A 關於 RADIUS 限制 中所述，NPS 擴充功能會將 RADIUS 要求轉換為以 Entra 為基礎的檢查，而不是將 Entra 轉變為 RADIUS 伺服器。
- Intune：Intune 提供信任的根憑證、SCEP 或 PKCS 憑證設定檔以及 WiFi 組態。其指派也控制了裝置範圍，因此未完成的設定檔不會套用到整個資產。
- 網路原則：RADIUS 必須定義成功的憑證所允許的權限。這可以是員工 VLAN、臨床區段、受限的零售網路或特定裝置的 ACL。
依依賴關係順序建置
在調整 RADIUS 之前，請先發布並驗證 CA 範本。檢查發行者、主體或 SAN、憑證鏈以及用戶端驗證 (Client Authentication) EKU。否則，當裝置沒有可用憑證時，失敗的交握看起來會像是 RF 或 SSID 故障。
信任必須是雙向的。受管理的設備必須信任簽署 RADIUS 伺服器憑證的 CA，而 RADIUS 則必須信任發行用戶端憑證的 CA。存取點需要 RADIUS 伺服器位址和共用金鑰。它們不會直接向 Entra 進行驗證。
決定策略存放位置
NPS、ClearPass 和 ISE 可以強制執行無線策略，但它們的規則模型和屬性處理方式有所不同。請選擇一個來源作為 SSID-to-VLAN 對應的單一真實來源並加以記錄，以防止 AP 儀表板與 RADIUS 規則產生衝突的結果。
一份英國公營部門的清單描述了 Entra ID 對公開金鑰驗證的支援，包括 TLS 用戶端憑證，以及同盟與雙重驗證（英國公營部門 Entra ID 清單）。該憑證模型仍取決於獨立的 PKI 和 RADIUS 元件。
透過 Intune 發行憑證並推送 WiFi 設定檔
對於受控裝置，EAP-TLS 的成功與否取決於憑證的選擇。Intune 可以在無需使用者互動的情況下傳遞設定檔，但它無法彌補缺乏正確用途、發行者或主體對應的憑證範本。
建立憑證路徑
請先部署受信任的根 CA 設定檔。使用 SCEP 時，建立一個指向 NDES 服務並使用 Intune Certificate Connector 的憑證設定檔。該設定檔應參照已發布的 SCEP 端點、正確的憑證範本，以及可防止未授權請求的挑戰機制。
憑證本身在其延伸金鑰用法中需要 用戶端驗證。決定主體和 SAN 是否識別裝置、使用者或兩者。該決定會影響 RADIUS 對應、共用裝置行為以及您稍後如何調查驗證事件。
在透過核准的工作流程產生並封裝憑證的情況下，PFX 設定檔可以發揮作用，但 SCEP 通常更容易在多樣化的託管資產中運作，因為裝置可以自行要求並更新其憑證。重點在於一致性。每個平台都必須接收 RADIUS 原則能夠識別的鏈結和憑證。
設定 WiFi 承載資料
使用完全相同的 SSID、安全性模式和 EAP 方法來建立 WiFi 設定檔。選取 EAP-TLS，將設定檔繫結至 SCEP 組態發行的憑證，並啟用伺服器憑證驗證。新增確切的 RADIUS 伺服器名稱，以確保裝置在進行信任決策時不會接受外觀相似的偽冒服務。與 Microsoft 保持一致的英國部署指南建議在 WiFi 設定檔中使用受信任的根、SCEP 用戶端憑證設定檔以及精確的 RADIUS 名稱 (英國 Entra ID WiFi 設定指南)。
導致重複失敗的欄位是憑證比對。在 Windows、macOS、iOS 和 Android 上，WiFi 設定檔必須選取由預期 CA 簽發且包含預期 EKU 的憑證。如果部署了設定檔但作業系統無法選取該憑證，裝置可能會退回到不合適的方法或拒絕連線。
將 SCEP 和 WiFi 設定檔的範圍界定在相同的試點裝置群組。檢查裝置記錄以確認憑證安裝、確認根憑證受信任，然後在變更 RADIUS 原則之前檢查選取的用戶端憑證。憑證健康狀況檢查（例如此 SSL 憑證檢查工具）可以協助驗證面向大眾的憑證端，但內部 EAP-TLS 疑難排解仍取決於裝置和 RADIUS 記錄。
將其串接至您的網路與 RADIUS 層
存取點會偵測到 802.1X 請求端，但它無法看見 Microsoft Entra ID。當裝置出示其用戶端憑證時，AP 會將 EAP 交換轉發至 RADIUS，接著 RADIUS 服務會驗證憑證鏈並套用網路策略。
通常的流程為：
- 裝置與企業 SSID 關聯。
- AP 將 EAP-TLS 流量轉發至 NPS、ClearPass、ISE 或託管的 RADIUS 服務。
- RADIUS 根據信任的發行 CA 驗證用戶端憑證。
- 原則引擎將憑證身分對應至帳戶、裝置或群組。
- RADIUS 回應指派允許的 VLAN 或存取原則。
廠商設定差異
Meraki 儀表板通常需要 RADIUS 伺服器詳細資訊、共用秘密和憑證驗證設定，並在 RADIUS 回應控制區段時使用 AAA 覆寫。Aruba 部署通常依賴 RADIUS 伺服器群組和伺服器衍生規則。Ruckus SmartZone 需要進行 AAA 設定並選取 EAP-TLS，而 Juniper Mist WLAN 範本則指向 RADIUS 叢集。UniFi 網路使用 RADIUS 設定檔，且在舊版 EAP-TTLS 與 EAP-TLS 並存時可能需要小心處理。
對於希望擁有獨立 RADIUS 層而無需運作整個伺服器平台的資產，Purple 的 RADIUS-as-a-Service 是一個託管選擇。NPS、ClearPass、ISE 和託管服務都可以適用，但它們對每個憑證屬性或原則條件的解讀不會完全相同。
| 廠商 | RADIUS 驗證伺服器 | EAP 類型 | 憑證屬性 | 常見問題 |
|---|---|---|---|---|
| Meraki | NPS、ISE、ClearPass 或託管 RADIUS | EAP-TLS | 簽發者與 SAN | AAA 覆寫可能會將有效的使用者分配到錯誤的 VLAN |
| Aruba | NPS、ClearPass、ISE 或託管 RADIUS | EAP-TLS | SAN 或 UPN | 伺服器衍生規則的順序可能會將員工傳送至訪客策略 |
| Ruckus | 連線至 SmartZone 的 RADIUS | EAP-TLS | 主體與簽發者 | 在 AAA 設定中很容易忽略 EAP 類型不相符的問題 |
| Juniper Mist | RADIUS 叢集 | EAP-TLS | SAN 或對應識別身分 | WLAN 範本可能會參照到未完成的伺服器群組 |
| UniFi | 網路應用程式 RADIUS 設定檔 | EAP-TLS 或受控舊版方法 | 憑證識別身分 | 混合的 EAP 方法可能會掩蓋實際的失敗原因 |
在 NPS 上，檢查 EAP-TLS 憑證屬性，並定義簽發者、主體或 SAN 是否提供帳戶對應。常見的錯誤是當 RADIUS 服務將 SAN 解析為 UPN 時，卻假設一般名稱是使用者名稱。這會破壞使用者對應，還可能干擾僅限裝置或共用裝置的工作流程。
在資產需要彈性的地方使用負載平衡的 RADIUS 叢集，並設定合理的每個 SSID 容錯移轉計時器。不要假設雲端 RADIUS 服務會即時執行撤銷。某些託管設備缺乏可連線的 CRL 或 OCSP 驗證，因此即使在目錄帳戶變更後，憑證可能仍會被接受。
員工 WiFi 的即時撤銷與條件式存取
棘手的問題不在於裝置是否可以註冊，而是在人資部門停用帳戶後會發生什麼情況。
Conditional Access 會評估支援的 Entra 登入。它不會干涉已建立的 802.1X 工作階段，也不會僅因為目錄狀態發生變更而將其中止。已安裝在筆記型電腦上的憑證在過期之前，或在 RADIUS 服務透過憑證撤銷檢查拒絕該憑證之前，其密碼編譯技術上依然有效。這使得撤銷機制的設計比註冊示範更加重要。
縮短憑證窗口
首要的緩解措施是縮短憑證有效期。Intune SCEP 設定檔可以發行定期更新的憑證，從而限制已除役的設備繼續出示原本有效憑證的時間。適當的期限取決於威脅模型、設備可用性以及營運容忍度。較短的有效期會增加對可靠更新機制的依賴，因此請務必測試那些經常離線或在受限網絡後方運作的設備。
第二個緩解措施是主動撤銷檢查。發布可存取的 CRL 或執行 OCSP，然後確認 RADIUS 伺服器會進行查詢。當停用檢查或 RADIUS 網路無法存取發布點時，NPS 和 ClearPass 的設定看似正常，但實際上卻忽略了撤銷檢查。
關鍵的營運衡量指標在於：目錄停用與第一個被拒絕的無線封包之間的時間差。
Intune 的停用和清除工作流程仍然很有價值，特別是對於遺失或共用的裝置，但它們不會神奇地從已關機的端點中抹除憑證。當裝置下一次接收管理指示時，憑證會因過期、撤銷或移除而變得無法使用。團隊應該記錄該空窗期，並在離職演練期間進行測試。
Entra 持續存取評估支援針對特定雲端應用程式情境進行快速的主控決策。它目前不會將 EAP-TLS 轉變為瀏覽器樣式的條件式存取交易，因此 WiFi 仍取決於憑證有效性和 RADIUS 撤銷行為。對於正在審查更廣泛驗證模型的讀者，此 Edmonton 使用者多要素驗證指南 提供了關於更強大的登入保證與網路憑證驗證有何不同的實用背景資訊。
訪客存取需要其專屬的控制平面。英國公共部門的實踐（包括 GovWifi）強調，不應強迫訪客和共用存取進入與員工相同的憑證工作流程（參見 UK Entra WiFi 整合指南）。
測試與排除常見故障模式
實驗室測試證明了一台裝置可以連線。生產環境部署則證明了錯誤的裝置無法連線、被撤銷的憑證會被拒絕，且訪客無法繼承員工的原則。
從憑證開始
針對 EAP-TLS 失敗，請在變更 AP 之前先檢查用戶端憑證。確認憑證鏈、發行者、SAN、到期日和用戶端驗證 (Client Authentication) EKU。接著檢查 WiFi 設定檔是否選取了該憑證，以及裝置是否信任 RADIUS 伺服器憑證。
SCEP 迴圈通常表示 Intune、NDES 與憑證範本之間不相符。請驗證挑戰 URL，確認 NDES 連接器帳戶具有所需的範本權限，並比較 SCEP 設定檔 URI 與已發布的 NDES URL（包括其結尾斜線）。從錯誤範本核發的憑證可能看起來像是登錄成功，但實際上卻無法用於 WiFi。
測試信任與區隔
Evil Twin 可以在憑證驗證發生之前廣播相同的 SSID。請設定伺服器憑證驗證，在 Intune WiFi 設定檔中指定預期的 RADIUS 名稱，並使用託管網絡設定，以防作業系統隨意加入仿冒的網絡。在用戶端和 AP 設備支援的情況下啟用 Protected Management Frames，並使用組織特定的 SSID，而非通用名稱。
已撤銷但仍能通過驗證的憑證通常指向 RADIUS 伺服器，而不是 Entra。請檢查是否已啟用 CRL 驗證，然後確認 RADIUS 子網路可以解析並連線到發佈點。如果使用 OCSP，請檢查逾時和回應程式的可達性，而不是假設服務正在自動進行檢查。
訪客與員工的重疊問題通常源自於原則順序。請將 EAP-TLS 員工規則置於 PSK 或基於 MAC 的訪客規則之前，然後在 RADIUS 記錄中驗證傳回的 VLAN 屬性。以錯誤的 VLAN 進行有效驗證屬於原則失敗，而非註冊失敗。
使用固定的排障順序
首次連線緩慢可能是由於憑證更新時間點、無法存取的撤銷端點，或作業系統選擇了錯誤的 SSID 所致。請勿在一開始就重新建立設定檔。
- 檢查裝置憑證： 檢查憑證鏈、EKU、簽發者、SAN 以及有效期。
- 擷取無線交換過程： 確認 AP 有將 EAP 流量轉發至指定的 RADIUS 目標。
- 讀取 RADIUS 事件記錄： 使用 NPS 記錄、ISE 事件記錄或 ClearPass 存取追蹤來識別被拒絕的屬性。
- 檢查 Intune 狀態： 確認裝置已註冊、已接收設定檔，且仍處於指定的指派群組中。
- 驗證傳回的原則： 確認員工和訪客工作階段皆取得正確的 VLAN 和 ACL。
遵循此順序可確保調查是以證據為導向。同時變更三個層級通常會隱藏原本的錯誤。
英國風格的部署檢查清單與後續步驟
請將此次部署視為一次受控的服務變更，而非一場憑證實驗。先從能代表整體環境的一小群設備開始：例如一部現代 Windows 筆記型電腦、Apple 終端設備、Android 硬體、共用設備，以及任何必須保持連線的營運設備。飯店的前台、醫院的病房和零售商店可能都使用相同的身分識別平台，但其復原需求卻可能大不相同。
部署順序
- 試行範圍界定：選擇代表性的使用者、位置和裝置類型，包括連線能力較弱或管理路徑受限的站點。
- 憑證授權單位（CA）就緒：在建立 WiFi 設定檔之前，確認核發鏈、範本權限、EKU 和撤銷端點。
- Intune 設定檔建立：將信任的根憑證、SCEP 或 PFX 憑證設定檔，以及 EAP-TLS WiFi 設定檔建立為相符的組合。
- RADIUS 整合：將 AP、共用秘密、憑證信任和身分識別對應規則新增至選定的 RADIUS 平台。
- 裝置範圍限制：將設定檔指派給試行群組，並保留舊的 SSID 作為已記錄的備用方案。
- 大規模部署：僅在憑證核發、VLAN 指派和離線測試通過後，才按站點或裝置圈擴大部署。
- 稽核頻率：審查失敗的驗證、憑證過期、撤銷可達性以及員工與訪客原則的執行結果。
- 停用 PSK：僅在支援團隊擁有經過測試的緊急存取程序且裝置資產已完成移轉後，才移除共用金鑰 SSID。
英國特定的檢查很容易被忽視。請確認 Apple BYOD 裝置透過預期的管理路徑信任核發鏈結。定義如何輪替 RADIUS 共用秘密、記錄憑證遙測資料的儲存位置以供 GDPR 審查，並使驗證記錄符合組織的 PSN 或產業特定稽核要求。醫院和共用的公共部門房產還需要一個記錄在案的斷網 SSID 或備用存取程序，以防其成為永久未受管理的網路。
根據 Microsoft 的生態系統更新（Microsoft Entra 密鑰更新），密鑰預計將在 2026 年成為 Microsoft Entra 登入的預設驗證方法。這並不代表現今的 EAP-TLS 工作可以被捨棄。密鑰解決了互動式身分登入的問題，而 WiFi 仍然需要機器可驗證的網路憑證、原則決策和 RADIUS 交換。為憑證建置的 CA、裝置管理和原則規範，仍然是下一個身分模型有用的基礎。
如果您的資產仍然依賴共用金鑰，或假設 Entra ID 可以直接回應 RADIUS 要求，請先記錄目前的 SSID、憑證授權單位、裝置群組和 RADIUS 原則。然後使用 Intune 在代表性的英國裝置上試行 EAP-TLS，在擴大範圍之前測試撤銷功能，並將訪客存取與員工身分分開。
Purple 提供雲端 RADIUS 與基於身分識別的 WiFi 平台，可將支援 Entra ID 的員工存取權限與跨混合廠商設備的網路原則相互連結。請造訪 Purple，評估其憑證等級的員工 WiFi 和訪客存取功能如何融入您的英國部署計劃。
