iOS 與 macOS 802.1X 疑難排解：Intune、Jamf 與 Microsoft Entra ID 的部署檢查清單

Apple 裝置在 802.1X 驗證失敗主要有四個原因：WiFi 承載資料（payload）中的信任伺服器名稱或憑證錨點與 RADIUS 憑證不相符；身分憑證遺失或存在於錯誤的鑰匙圈中；macOS 設定檔執行的模式不正確，或設定檔目標鎖定了錯誤的 Entra ID 群組。您可以透過 eapolclient 和 RADIUS 記錄來確認是哪一個原因。

802.1X 驗證失敗在 iPhone 或 Mac 上呈現什麼樣的狀況？

Apple 裝置很少提供精確的錯誤訊息。症狀本身就是您的第一個線索，因此在變更任何設定檔之前，請務必精確記錄下來。

• iPhone 拒絕加入 EAP-TLS 網路，並要求輸入原本不應該需要的使用者名稱和密碼。這表示該裝置沒有可用的身分憑證，因此退回到認證提示畫面。
• Mac 顯示憑證信任對話方塊，並指名您的 RADIUS 伺服器。這代表設定檔未釘選伺服器信任，或者它允許使用者忽略不相符的狀況。
• Mac 在登入後可以連線，但在登入視窗時卻不行。 這會導致共用電腦上的網路帳號與 FileVault 解鎖失敗。
• 部分裝置可以正常運作，其他裝置卻完全找不到網路。 這通常指向群組範圍劃分問題，而非密碼學問題。
• 數個月來一切正常，卻在某天早上突然全部失敗。 這種模式幾乎總是發生在 RADIUS 憑證更新之後。

通常是什麼原因導致 iPhone 和 Mac 的 EAP-TLS 或 PEAP 失敗？

伺服器信任與 RADIUS 憑證不相符

Apple 的 WiFi 承載資料會在兩個地方釘選伺服器信任。信任的伺服器憑證名稱必須與您的 RADIUS 伺服器憑證名稱相符。信任的憑證必須包含核發它的根憑證。若其中任何一項錯誤，裝置就會停止 TLS 交握。

這就是為什麼 macOS 會要求您信任 RADIUS 憑證。如果設定檔中沒有信任錨點，Apple 就會把決定權交給鍵盤前的使用者。如果已釘選信任但發生不相符，連線則會直接靜態失敗。Intune WiFi 設定檔伺服器信任指南深入介紹了命名規則。

身分憑證遺失或存在於錯誤的鑰匙圈中

EAP-TLS 需要在裝置上安裝用戶端憑證及其私密金鑰。WiFi 承載資料必須引用該憑證，並由 SCEP 或 PKCS 承載資料遞送。在 macOS 上，裝置層級的設定檔會將憑證安裝在「系統」鑰匙圈中。使用者層級的設定檔則會將其安裝在「登入」鑰匙圈中。在裝置層級配置的網路無法存取「登入」鑰匙圈中的憑證。

macOS 系統模式、登入視窗模式與使用者模式混淆

macOS 支援三種 802.1X 情境。系統模式會在任何人登入之前，使用電腦憑證進行連線。登入視窗模式會使用在登入視窗中輸入的認證。使用者模式則只在登入後，使用與該帳號綁定的認證或憑證進行連線。請根據 Mac 需要使用網路的時間點來選擇相符的模式。

設定檔的範圍劃分至錯誤的 Entra ID 群組

Microsoft 的 Intune 說明文件指出，應將受信任的憑證、SCEP 或 PKCS 以及 WiFi 設定檔指派給相同的群組。若將一個指派給裝置群組，另一個指派給員工帳戶群組，某些裝置將只能接收到一半的鏈結。沒有主要帳戶的共用 iPad 和 Mac 永遠不會收到針對個人指派的設定檔。

針對純雲端 Entra ID 帳戶的 PEAP

PEAP-MSCHAPv2 需要可以驗證密碼的 RADIUS 伺服器。Entra ID 沒有原生的 RADIUS 服務，因此純雲端帳戶通常無法以此方式進行驗證。出於此原因，大多數 Entra ID 客戶會將 Apple 裝置轉移至 EAP-TLS。

症狀	最可能的原因	要尋找的證據	解決方法
Mac 上出現信任對話框	設定檔中沒有受信任的憑證錨點	eapolclient 顯示信任評估失敗	將 RADIUS 根憑證新增為受信任的憑證承載資料
憑證更新後無聲無息地失敗	受信任的伺服器名稱不再相符	RADIUS 顯示 EAP 工作階段開始，隨後用戶端放棄連線	在輪替之前新增新的伺服器名稱與根憑證
在 EAP-TLS 網路上出現密碼輸入提示	未傳遞身分識別憑證	鑰匙圈中沒有用戶端憑證	將 SCEP 或 PKCS 設定檔指派給與 WiFi 設定檔相同的群組
登入後可正常工作，但在登入視窗失敗	共用 Mac 上的使用者模式設定檔	憑證位於登入鑰匙圈中	在系統模式下以裝置層級重新部署
某些裝置完全看不到網路	設定檔分散在裝置和帳戶群組中	裝置的已安裝清單中缺少設定檔	將所有三個承載資料對齊指派給同一個群組
RADIUS 拒絕並指出用戶端憑證名稱	RADIUS 不信任您的發行 CA	拒絕原因提及用戶端鏈結	將發行 CA 新增至 RADIUS 信任清單中

您該如何找出是由哪個原因引起的？

請依照以下順序，從裝置端向外進行排查。

1. 確認設定檔已送達。 檢查裝置上的已安裝設定檔清單。在 Mac 上，從終端機執行 sudo profiles show 即可列出這些設定檔。
2. 確認憑證和私鑰。 在 Mac 上開啟「鑰匙圈存取」，並對照設定檔層級檢查「系統」或「登入」鑰匙圈。
3. 讀取 eapolclient 記錄。 這會告訴您裝置是否拒絕了該伺服器。
4. 讀取 RADIUS 記錄。 這會告訴您伺服器是否拒絕了該裝置。

802.1X 記錄在 macOS 上的什麼位置？

macOS 會將 802.1X 移交給名為 eapolclient 的程序。開啟「主控台」，選取該 Mac，開始串流，並將程序名稱篩選為 eapolclient。接著重現該失敗狀況。在終端機中，執行 log show --predicate 'process == "eapolclient"' --last 1h 即可提取相同的條目。

請尋找三件事：傳送的外層身分識別、呈現的伺服器憑證以及信任評估結果。此處若顯示信任失敗，代表問題出在您的 WiFi 承載資料中。若為 iPhone 或 iPad，請將其連接至 Mac 並透過「主控台」串流其記錄。

RADIUS 記錄能告訴您什麼

RADIUS 記錄是該對話的另一半內容。

• 完全沒有請求。 可能是設定檔遺失、SSID 名稱錯誤，或是裝置根本沒有連接到無線基地台。
• EAP 工作階段已啟動但未完成。 裝置拒絕了伺服器憑證。請返回信任設定。
• 明確拒絕。 伺服器拒絕了該裝置。原因通常是未受信任的用戶端鏈、未知帳戶或原則不相符。

如何在 Intune 與 Jamf 中解決此問題？

這兩個平台都會傳遞相同的三個 Apple 承載資料（payload），其差異在於作用範圍與層級的設定方式。

工作	Microsoft Intune	Jamf Pro
伺服器信任錨點	信任的憑證設定檔	設定檔中的憑證承載資料
識別憑證	SCEP 或 PKCS 憑證設定檔	SCEP 或憑證承載資料
網路設定	WiFi 設定檔（企業級）	WiFi 承載資料（行動裝置）或網路承載資料（電腦）
Mac 鑰匙圈選擇	部署通道：使用者或裝置鑰匙圈	設定檔層級：電腦或使用者
登入視窗連線	搭配電腦憑證的裝置通道	設定為登入視窗使用的電腦層級設定檔
目標指定	Entra ID 群組	智慧群組與靜態群組

Intune

檢查信任的憑證、憑證與 WiFi 設定檔是否都指向同一個 Entra ID 群組。在 macOS 上，將每個設定檔設為相同的部署通道。混合使用使用者與裝置鑰匙圈會破壞憑證參照。在 WiFi 設定檔中，將所有 RADIUS 伺服器名稱列入憑證伺服器名稱中，並選擇相符的根憑證。Microsoft 官方的部署指南中有各個欄位的詳細說明。

Jamf Pro

針對共用的 Mac，將憑證與網路承載資料建置在同一個電腦層級設定檔中。只有在每個人各自擁有專屬 Mac 時，才使用使用者層級設定檔。將識別憑證設定指向同一個設定檔中的 SCEP 或憑證承載資料。對於行動裝置，WiFi 承載資料也提供相同的受信任伺服器名稱與受信任憑證欄位。

iPhone 與 iPad 的特定注意事項

iOS 與 iPadOS 沒有登入視窗模式。常見的失敗原因為信任不相符以及遺失識別憑證。共用與無使用者的 iPad 需要指定裝置群組，否則將無法接收憑證。

實際案例分析

RADIUS 憑證更新後的 200 間客房飯店

情況： 一家擁有 200 間客房的飯店向櫃檯與房務團隊發放了由 Intune 管理的 iPhone。RADIUS 憑證更新為新的主機名稱。隔天早上，所有員工的 iPhone 都斷開了網路連線。

處理過程： 從連接的 iPhone 中取得與 eapolclient 等效的記錄，顯示裝置放棄了交握。RADIUS 記錄也證實工作階段已啟動但未完成。團隊隨後將新的主機名稱新增至憑證伺服器名稱中，並將新的根憑證分配給相同的群組。結果。 隨著每台裝置同步更新後的設定檔，裝置重新連線，當天員工 SSID 上的驗證失敗次數降至零。該團隊現在會在任何更新的一週前發布信任變更。在我們的 飯店 頁面了解飯店如何運作員工與賓客網路。

擁有共用 Mac 的議會圖書館服務

狀況。 某公共部門圖書館服務透過 Jamf Pro 運行 60 台共用 Mac。其 WiFi 設定檔為使用者層級，因此憑證會進入登入鑰匙圈。新員工完全無法登入，因為他們的網路帳戶必須先連接網路。

採取的行動。 該團隊在系統模式下以電腦層級重建了設定檔，並在系統鑰匙圈中放入了機器憑證。

結果。 Mac 在登入視窗時就能連上網路，所有 60 台電腦上的首次登入失敗情況不復存在。同樣的變更也解決了原本同樣依賴登入工作階段的夜間修補程式更新受阻問題。

要如何防止這種情況再次發生？

大多數 Apple 802.1X 斷線事件都是在變更期間自行造成的。簡短的規範幾乎可以預防所有這些問題。

• 刻意固定信任。 務必指定信任的伺服器名稱與信任的根，以便不符時能在測試中大聲報錯，而不是提示員工。
• 階段式進行憑證輪替。 在您更新 RADIUS 憑證之前，先將新的伺服器名稱與根加入設定檔中。事後再移除舊的。
• 將鏈保持在同一個群組中。 信任憑證、身分憑證與 WiFi 設定檔應始終共用同一個目標。
• 使模式與裝置相符。 共用 Mac 使用系統模式。個人指派的 Mac 可以使用使用者模式。
• 先進行試點。 將設定檔變更推送到一小群 iPhone 和 Mac，並在廣泛發布前檢查 eapolclient 與 RADIUS 記錄。
• 自動化加入、調動與離職流程。 憑證廢止應遵循目錄，而不是工單佇列。

Purple Staff WiFi 透過基於身分的網路（Identity-Based Networks）來提供此功能。我們的雲端 RADIUS 將網路存取與 Microsoft Entra ID、Okta 或 Google Workspace 連結，因此存取權限會遵循群組成員資格。Purple 與硬體無關，可在 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 與 Fortinet 上運行。Purple 通過 ISO 27001 認證，為超過 80,000 個現有場域提供服務（Purple 內部數據）。同樣的身分識別方法也適用於 零售、醫療保健 與 火車。

對於 Android 裝置群，Android 802.1X 與 EAP-TLS 排錯清單 涵蓋了對應的檢查項目。如需目錄登入，請閱讀 如何啟用單一登入。

常見問題

Purple Staff WiFi 是否適用於由 Intune 和 Jamf 管理的裝置？

是的，Purple Staff WiFi 可驗證從 Intune 或 Jamf Pro 接收其 WiFi 和憑證設定檔的 Apple 裝置。您的裝置管理平台會傳送承載資料，而 Purple 的雲端 RADIUS 則會比對 Microsoft Entra ID、Okta 或 Google Workspace 來驗證連線。您可保留現有的裝置管理工具。Purple 負責處理身分驗證，並將存取權限與群組成員身分綁定，因此當離職者的目錄帳戶被停用時，他們就會失去存取權限。

我們需要新的存取點來運行基於憑證的員工 WiFi 嗎？

不需要，Purple 與硬體無關，可直接套疊在您現有的網路之上。Purple 支援 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 與 Fortinet。您的存取點需要支援 WPA2-Enterprise 或 WPA3-Enterprise，並指向外部 RADIUS 伺服器。關於 SecurePass，請參閱我們的 Security and Hardware Compatibility 文章以瞭解 Passpoint 需求。

在 Entra ID 上，我們應該為 iPhone 和 Mac 使用 EAP-TLS 還是 PEAP？

請使用 EAP-TLS。PEAP-MSCHAPv2 需要能夠驗證密碼的 RADIUS 伺服器，而 Entra ID 沒有針對純雲端帳戶的原生 RADIUS 服務。EAP-TLS 使用 Intune 或 Jamf 自動傳送的憑證進行驗證，因此無需手動輸入密碼。這也免除了憑證提示，而憑證提示是 Apple 802.1X 技術支援工單最常見的來源之一。

我們可以在不干擾員工的情況下，從預共用金鑰進行遷移嗎？

可以，在遷移期間，您可以將新的 802.1X SSID 與您現有的預共用金鑰網路並行運作。先將信任憑證、身分憑證和 WiFi 設定檔推送至測試群組。檢查 eapolclient 和 RADIUS 紀錄，然後分階段擴大範圍。僅在 RADIUS 顯示每個裝置群組都成功通過驗證時，才停用預共用金鑰網路。

基於憑證的 WiFi 對 GDPR 和數據處理有何影響？

基於憑證的 WiFi 減少了跨網路傳輸的個人數據，因為不傳輸任何密碼。身分驗證依賴於裝置憑證和目錄群組成員身分。Purple 符合 GDPR 規範，並持有 ISO 27001、Cyber Essentials 和 B Corp 認證。您仍應在您的數據保護文件中記錄您保留的 RADIUS 紀錄及其保留期限。

SecurePass 會取代員工裝置的 802.1X 嗎？

不會，SecurePass 是為訪客設計的，而非受管管的員工裝置。它透過使用 WPA2 或 WPA3-Enterprise、在約 30 秒內安裝一次數位簽章的 WiFi 設定檔，來取代重複的 Captive Portal 登入。它與您現有的入口網站並行運作。員工裝置應使用 Staff WiFi，並搭配 Intune 或 Jamf 傳送的憑證。詳情請參閱 SecurePass FAQ。