Microsoft Entra 與 MDM 的整合

適用於: ✅ Windows 11, ✅ Windows 10

Microsoft Entra ID 是全球最大的企業雲端身份管理服務。組織利用它存取 Microsoft 365 及來自 Microsoft 及第三方軟體即服務（SaaS) vendor） (商業應用。許多對組織使用者的豐富 Windows 體驗 (如商店存取或作業系統狀態漫遊) 將 Microsoft Entra ID 作為底層身份基礎架構。 Windows 與 Microsoft Entra ID 整合，允許裝置註冊於 Microsoft Entra ID，並以整合流程) 裝置管理 (MDM 註冊。

一旦裝置註冊到 MDM，MDM 會：

能強制遵守組織政策、新增或移除應用程式等功能。
可以在 Microsoft Entra ID 中報告裝置的合規狀況。
可允許符合政策的裝置存取由 Microsoft Entra ID 保護的組織資源或應用程式。

為了支持這些豐富的 MDM 體驗，MDM 廠商可以整合 Microsoft Entra ID。

整合 MDM 註冊與使用者體驗

有幾種方式可以將您的裝置連接到 Microsoft Entra ID：

在每種情況下，Microsoft Entra 都會驗證使用者與裝置。它提供一個經過驗證的獨特裝置識別碼，可用於 MDM 註冊。註冊流程提供 MDM 服務透過網頁檢視呈現自身 UI 的機會。 MDM 廠商應利用介面來呈現 TOU) (使用條款，這對於公司自有裝置與自帶裝置 (自帶裝置) 裝置可能有所不同。 MDM 廠商也可以利用網頁檢視來渲染更多 UI 元素，例如請求一次性 PIN 碼。

在 Windows 10 中，開箱即用的網頁檢視預設為全螢幕，讓 MDM 廠商能打造無縫的端對端使用者體驗。然而，在 Windows 11 中，網頁檢視是在 iframe 內渲染的。整合 Microsoft Entra ID 的 MDM 廠商必須尊重 Windows 設計指引。此步驟包括使用響應式網頁設計並遵守 Windows 無障礙指引。例如，加入與導航邏輯正確接線的前進與後退按鈕。更多細節將在本文後面提供。

若要在 ADFS) Microsoft Entra 帳戶 (Active Directory Federated Services 進行Microsoft Entra註冊，您必須在 ADFS 服務中啟用內聯網密碼驗證。欲了解更多資訊，請參閱「使用 AD FS 配置 Microsoft Entra 多重身份驗證作為認證提供者」。

一旦使用者在 Windows 上新增 Microsoft Entra 帳號並在 MDM 註冊，註冊可以透過設定>帳號>存取工作或學校來管理。 Microsoft Entra join 用於組織情境或 BYOD 情境的裝置管理方式類似。

注意

使用者無法透過 Access 工作或學校使用者介面移除裝置註冊，因為管理權限綁定於 Microsoft Entra ID 或工作帳號。

參與 Microsoft Entra 整合註冊的 MDM 端點

Microsoft Entra MDM 註冊是一個兩步驟的流程：

顯示使用條款並取得使用者同意：此同意是一種被動流程，使用者在瀏覽器控制 (網頁檢視) 中被導向至 MDM 使用條款的網址。
裝置註冊：此步驟為主動流程，Windows OMA DM 代理呼叫 MDM 服務以註冊裝置。

為了支援 Microsoft Entra 註冊，MDM 廠商必須架設並公開使用條款端點與 MDM 註冊端點。

使用條款端點：使用此端點告知使用者組織如何控制裝置。 使用條款頁面負責在正式註冊階段開始前收集用戶同意。

重要的是要了解使用條款流程對 Windows 和 Microsoft Entra ID 來說是一個「不透明的盒子」。整個網頁視圖會被重新導向到使用條款網址。用戶在批准或拒絕條款後，應被重新導向回去。此設計允許 MDM 廠商針對不同情境自訂使用條款。例如，BYOD 與組織自有裝置會施加不同層級的控制。或者，實施基於使用者/群組的目標鎖定，例如某些地區的使用者可能有更嚴格的裝置管理政策。

使用條款端點可實作更多商業邏輯，例如收集 IT 提供的一次性 PIN 碼以控制裝置註冊。然而，MDM 廠商不得使用使用條款流程來收集使用者憑證，這可能會降低使用者體驗。其實不需要，因為 MDM 整合的一部分確保 MDM 服務能理解 Microsoft Entra ID 發出的令牌。
MDM 註冊端點：使用者接受使用條款後，裝置會註冊於 Microsoft Entra ID。自動 MDM 註冊開始。

下圖說明了實際入學過程中的高層次流程。該裝置首先註冊為 Microsoft Entra ID。此過程會為裝置指派一個獨特的裝置識別碼，並讓裝置能夠以Microsoft Entra ID (裝置認證) 進行自我驗證。接著，裝置會被註冊管理給 MDM。此步驟呼叫註冊端點，並請求使用者與裝置的註冊。此時，使用者已透過 Microsoft Entra ID 進行認證，裝置也已註冊並驗證。這些資訊以登錄端所呈現的存取權杖形式，提供給 MDM 使用。

MDM 預期會利用這些關於裝置的資訊 (裝置 ID) ，透過 Microsoft 圖形 API向Microsoft Entra ID回報裝置合規情況。本文後面將提供報告裝置合規性的範例。

讓 MDM 成為 Microsoft Entra ID 的可靠方

要參與前一節所述的整合註冊流程，MDM 必須消耗由 Microsoft Entra ID 發行的存取權杖。為了回報符合 Microsoft Entra ID，MDM 必須向 Microsoft Entra ID 進行驗證，並取得以存取權杖形式授權，才能調用 Microsoft 圖形 API。

雲端 MDM

雲端 MDM 是一種提供雲端裝置管理功能的 SaaS 應用程式。這是一個多租戶應用程式。此應用程式在 MDM 廠商的家租戶中以 Microsoft Entra ID 註冊。當 IT 管理員決定使用此 MDM 解決方案時，該應用程式的實例會在客戶租戶中顯示。

MDM 廠商必須先在其家租戶註冊應用程式，並將其標記為多租戶應用程式。欲了解更多如何將多租戶應用程式加入 Microsoft Entra ID，請參閱 GitHub 上的「整合一個使用多租戶整合模式驗證使用者與呼叫Microsoft Graph 的應用程式」 (SaaS) 程式碼範例。

注意

對於 MDM 供應商，如果你沒有現有的 Microsoft Entra 租戶並管理 Microsoft Entra 訂閱，請依照以下逐步指南操作：

快速入門：在 Microsoft Entra ID 建立新租戶以設定租戶。
將 Azure 訂閱連結或新增給你的 Microsoft Entra 租戶以新增訂閱，並透過 Azure 入口網站管理。

MDM 應用程式使用金鑰向 Microsoft Entra ID 請求存取權杖。這些金鑰由 MDM 供應商的租戶管理，個別客戶無法看到。同一金鑰也被多租戶 MDM 應用程式用來以 Microsoft Entra ID 驗證自己，該地址位於受管理裝置所屬的客戶租戶中。

注意

所有 MDM 應用程式必須實作 Microsoft Entra v2 令牌，我們才能認證整合有效。由於 Microsoft Entra 應用程式平台的變動，使用 Microsoft Entra v2 令牌已成為硬性要求。欲了解更多資訊，請參閱 Microsoft 身分識別平台存取權杖。

本地 MDM

本地的 MDM 應用程式與雲端 MDM 不同。它是一個單一租戶應用程式，只存在於客戶的租戶中。客戶必須直接在自己的租戶中新增應用程式。此外，每個本地 MDM 應用程式的實例都必須分別註冊，並擁有獨立的 Microsoft Entra ID 認證金鑰。

若要將本地 MDM 應用程式加入租戶，請使用 Microsoft Entra 服務，特別是在行動性 (MDM 和 MAM) >新增應用程式> 建立您自己的應用程式。管理員可以設定註冊所需的網址及使用條款。

警告

自 2026 年 7 月 1 日起，所有使用此 Entra Portal 流程建立的新本地 MDM 應用程式，將預設接收 v2.0 存取權杖，作為向 MDM 應用程式提交的請求一部分。因此，您的本地 MDM 產品的受眾 (aud 聲稱) 驗證邏輯必須接受其 appId。此變更不會影響 7 月 1 日前建立的任何現有本地 MDM 應用程式。

您的本地 MDM 產品必須提供設定體驗，管理員可以提供用戶端 ID（也稱為應用程式 ID) ） (，以及該 MDM 應用程式在目錄中設定的金鑰。你可以用這個客戶端 ID 和金鑰向 Microsoft Entra ID 請求憑證，當回報裝置合規狀況時。

欲了解更多關於使用 Microsoft Entra ID 註冊應用程式的資訊，請參閱《在 Microsoft Entra ID 註冊應用程式的基本說明》。

金鑰管理與安全指引

你的 MDM 服務使用的應用程式金鑰是敏感資源。它們應該受到保護，並定期翻轉以提升安全性。您的 MDM 服務取得的存取權杖用於呼叫 Microsoft 圖形 API 是持有人權杖，應加以保護以避免未經授權的洩露。

有關安全最佳實務，請參閱 Microsoft Azure 安全基礎。

對於雲端 MDM，你可以將應用程式金鑰轉接過去，而不需要客戶介入。所有客戶租戶之間都有一組金鑰，由 MDM 廠商在其 Microsoft Entra 租戶中管理。

對於本地 MDM，Microsoft Entra 的認證金鑰存放在客戶租戶內，且客戶管理員必須將金鑰轉存。為提升安全性，請向客戶提供有關翻滾及保護鑰匙的指引。

將您的 MDM 應用程式發佈至 Microsoft Entra 應用程式圖庫

IT 管理員使用 Microsoft Entra 應用程式圖庫，為組織新增 MDM 供使用。應用程式庫是一個豐富的商店，收錄超過 2400 款與 Microsoft Entra ID 整合的 SaaS 應用程式。

將雲端 MDM 加入應用程式圖庫

注意

如果您的 MDM 應用程式是雲端且需要啟用多租戶 MDM 應用程式，您應該與 Microsoft Entra 工程團隊合作

要發佈您的應用程式，請提交請求，在 Microsoft Entra 應用程式庫中發布您的應用程式

下表顯示在 Microsoft Entra 應用程式圖庫建立條目的所需資訊。

項目	描述
應用程式識別碼	你在租戶內設定的 MDM 應用程式的客戶端 ID。這個 ID 是你多租戶應用程式的唯一識別碼。
發行者	一個用來識別應用程式發佈者的字串。
應用程式網址	這是你應用程式登陸頁面的網址，管理員可以在那裡取得更多關於 MDM 應用程式的資訊，並包含你應用程式登陸頁的連結。這個網址並未用於實際的註冊。
描述	請簡要說明您的 MDM 應用程式，字元必須不超過 255 個字元。
圖示	一組用於 MDM 應用程式的標誌圖示。尺寸：45 X 45、150 X 122、214 X 215

將本地 MDM 加入應用程式庫

在應用程式庫中新增本地 MDM 並無特殊要求。管理員有一個通用的條目可以把應用程式加入他們的租戶。

然而，本地 MDM 的金鑰管理則有所不同。您必須取得客戶 (租戶內分配給 MDM 應用程式的客戶 ID、應用程式 ID) 及金鑰。 ID 與金鑰取得授權以存取 Microsoft 圖形 API 並報告裝置合規狀況。

佈景主題

MDM 在整合註冊過程中渲染的頁面必須使用 Windows 範本 (下載 Windows 範本與 CSS 檔案 (1.1.4) ) 。這些範本對於 Microsoft Entra 加入體驗中的 OOBE 註冊非常重要，因為所有頁面都是端對邊的 HTML 頁面。避免複製範本，因為按鈕位置很難調整正確。

有三種明顯的情境：

MDM 註冊作為 Microsoft Entra join 在 Windows OOBE 中的一部分。
MDM 註冊作為 Microsoft Entra 加入的一部分，從設定中進行 Windows OOBE 後。
在個人裝置上新增Microsoft工作帳號時， (BYOD) 的 MDM 註冊。

這些情境支援 Windows Pro、Enterprise 和 Education。

Microsoft 提供的 CSS 檔案包含版本資訊，我們建議您使用最新版本。 Windows 用戶端裝置、OOBE及後OOBE體驗分別有獨立的CSS檔案。下載 Windows 範本和 CSS 檔案 (1.1.4) 。

Windows 10的話，可以用oobe-desktop.css
Windows 11的話，可以用oobe-light.css

主題運用

MDM 頁面必須依照所顯示的情境遵循預先定義的主題。例如，如果 CXH-HOSTHTTP 標頭是 FRX，這是 OBE 情境，那麼頁面必須支援帶有藍色背景的深色主題，該主題使用 WinJS 檔案 Ui-dark.css 版本 4.0 和 oobe-desktop.css ver 1.0.4。

CXH-HOST (HTTP 標頭)	案例	背景主題	WinJS	情境 CSS
FRX	OOBE	深色主題 + 藍色背景	檔案名稱：Ui-dark.css	檔案名稱：oobe-dekstop.css
莫塞特	環境/體外經驗後	淺色佈景主題	檔案名稱：Ui-light.css	檔案名稱：settings-desktop.css

使用條款協定語意

MDM 伺服器負責主機使用條款端點。在 Microsoft Entra 加入協定流程中，Windows 會對此端點進行整頁重定向。此重定向使 MDM 能顯示適用的條款與條件。它允許使用者接受或拒絕與註冊相關的條款。使用者接受條款後，MDM 會重新導向 Windows，讓註冊程序繼續。

重新導向至使用條款端點

此重定向是一整頁的重定向，指向由 MDM 託管的使用者條款端點。這裡有一個範例網址，。 https://fabrikam.contosomdm.com/TermsOfUse

查詢字串中傳遞的參數如下：

項目	描述
redirect_uri	使用者接受或拒絕使用條款後，使用者會被重新導向至此網址。
客戶端請求識別碼	一個用於關聯日誌以進行診斷與除錯目的的 GUID。使用此參數記錄或追蹤註冊請求的狀態，以協助找出故障的根本原因。
API 版本	指定客戶端所請求的協定版本。此數值提供了支援協定版本修訂的機制。
mode	當 mode=azureadjoin 時，指定裝置為組織擁有。這個參數在 BYOD 裝置上沒有。

存取權杖

Microsoft Entra ID 會發出持有人存取權杖。該憑證會被傳遞到HTTP請求的授權標頭中。以下是典型的格式：

授權：持有者 CI6MTQxmCF5xgu6yYcmV9ng6vhQfaJYw...

Windows 傳遞給使用條款端點的存取權杖預期包含以下聲明：

項目	描述
物件識別碼	對應已認證使用者的使用者物件識別碼。
UPN	包含用戶主體名稱 (驗證使用者的 UPN) 的主張。
TID	代表租戶身份證的索賠。在前面的例子中，是 Fabrikam。
資源	一個經過消毒的 URL，代表 MDM 應用程式。範例： `https://fabrikam.contosomdm.com`

注意

存取權杖中沒有裝置 ID 聲明，因為裝置目前可能還沒註冊。

要取得使用者的群組成員清單，可以使用 Microsoft 圖形 API。

這裡有一個範例網址：

https://fabrikam.contosomdm.com/TermsOfUse?redirect_uri=ms-appx-web://ContosoMdm/ToUResponse&client-request-id=34be581c-6ebd-49d6-a4e1-150eff4b7213&api-version=1.0
Authorization: Bearer eyJ0eXAiOi

MDM 預期會驗證存取權杖的簽名，以確保該憑證是由 Microsoft Entra ID 發出，且收件人是合適的。

使用條款內容

MDM 可在顯示使用條款內容前，視需要進行其他重定向。適當的使用條款內容應 (Windows) 回傳給來電者，以便透過瀏覽器控制項顯示給最終使用者。

使用條款內容應包含以下按鈕：

接受 - 使用者接受使用條款並繼續註冊。
拒絕 ——使用者拒絕並停止註冊流程。

使用條款內容必須與此過程中呈現的其他頁面所使用的主題一致。

使用條款端點處理邏輯

此時，使用者會進入 OOBE 期間顯示的使用條款頁面，或是設定體驗中的頁面。使用者在頁面上有以下選項：

使用者點擊接受按鈕 - MDM 必須重新導向到由 redirect_uri 參數指定的 URI。預期會有以下查詢字串參數：
- IsAccepted - 此布林值是必需的，且必須設為 true。
- OpaqueBlob - 使用者接受時的必要參數。 MDM 可能會利用這個 blob 向註冊端提供部分資訊。此處保留的值在註冊端點保持不變。 MDM 可能會使用此參數進行相關性分析。
- 這裡有一個重定向的範例—— ms-appx-web://MyApp1/ToUResponse?OpaqueBlob=value&IsAccepted=true
使用者點擊拒絕按鈕 ——MDM 必須重新導向到redirect_uri中指定的 URI。預期會有以下查詢字串參數：
- IsAccepted - 此布林值是必需的，且必須設為 false。如果使用者跳過使用條款，這個選項同樣適用。
- OpaqueBlob - 這個參數不被預期會使用。註冊會被停止，並向使用者顯示錯誤訊息。

使用者在新增 Microsoft 工作帳號到裝置時，會跳過使用條款。不過，他們無法在 Microsoft Entra 加入過程中跳過這個步驟。在 Microsoft Entra 加入流程中不要顯示拒絕按鈕。如果管理員為 Microsoft Entra 加入設定，使用者無法拒絕 MDM 註冊。

我們建議你在這個重定向回應中，將查詢字串中的 client-request-id 參數作為其中一部分。

使用條款錯誤處理

若在使用條款處理過程中發生錯誤，MDM 可在其重定向請求回 Windows 時回傳兩個參數—— error 一個與 error_description 參數。網址應該是編碼的，內容 error_description 應該是英文純文字。這段文字對最終使用者來說是看不到的。所以，文本的本地化 error_description 不是問題。

以下是網址格式：

HTTP/1.1 302
Location:
<redirect_uri>?error=access_denied&error_description=Access%20is%20denied%2E

Example:
HTTP/1.1 302
Location: ms-appx-web://App1/ToUResponse?error=access_denied&error_description=Access%20is%20denied%2E

下表顯示錯誤代碼。

原因	HTTP 狀態	錯誤	描述
API 版本	302	invalid_request	非支援版本
租戶或使用者資料缺失，或未符合裝置註冊所需的其他必要條件	302	unauthorized_client	未經授權使用者或租戶
Microsoft Entra token validation failed	302	unauthorized_client	unauthorized_client
內部服務錯誤	302	server_error	內部服務錯誤

使用 Microsoft Entra ID 的註冊協議

有了 Azure 整合的 MDM 註冊，沒有發現階段，發現 URL 會直接從 Azure 傳給系統。下表顯示傳統與 Azure 註冊的比較。

細節	傳統 MDM 註冊方式	Microsoft Entra加入 (組織擁有的裝置)	Microsoft Entra ID 會新增一個工作帳號 (使用者擁有的裝置)
利用電子郵件地址取得 MDM 發現 URL 的 MDM 自動發現	註冊	不適用 Discovery URL provisioned in Azure
使用 MDM 發現網址	註冊報名續約機器人	註冊報名續約機器人	註冊報名續約機器人
是否必須註冊 MDM？	是	是	否使用者可以拒絕。
認證類型	內部部署聯邦憑證	聯邦	聯邦
註冊政策服務網址	所有授權 (可選)	所有授權 (可選)	所有授權 (可選)
EnrollmentServiceURL	所有 (授權)	所有認證 ()	所有認證 ()
EnrollmentServiceURL 包含作業系統版本、作業系統平台及 MDM 發現網址所提供的其他屬性	強烈建議	強烈建議	強烈建議
使用的認證服務網址	聯邦認證 ()	跳過	跳過
二元安全令牌	依 MDM 自訂	Microsoft Entra ID 已發行的令牌	Microsoft Entra ID 已發行的令牌
註冊類型	完整	裝置	完整
註冊證書類型	使用者憑證	裝置憑證	使用者憑證
註冊憑證儲存	我的/使用者	我的/系統	我的/使用者
CSR 主題名稱	使用者主體名稱	裝置識別碼	使用者主體名稱
EnrollmentData 使用條款二進位 blob 作為 AdditionalContext for EnrollmentServiceURL	不支援	支援	支援
註冊期間可存取的CSP	Windows 10 支援： - DMClient - 憑證商店 - RootCATrustedCertificates - ClientCertificateInstall - 企業現代應用管理 - 工作護照 - 政策 - W7 應用

使用 Microsoft Entra ID 的管理協定

有兩種不同的 MDM 註冊類型與 Microsoft Entra ID 整合，並使用 Microsoft Entra 的使用者與裝置識別碼。依註冊類型，MDM 服務可能需要管理單一使用者或多位使用者。

Microsoft Entra 加入裝置的多重使用者管理

在此情境中，MDM 註冊適用於所有登入 Microsoft Entra 加入裝置的 Microsoft Entra 使用者——稱此登錄類型為裝置註冊或多使用者註冊。管理伺服器可以判定使用者身份，決定該使用者的目標政策，並將相應的政策傳送給裝置。為了讓管理伺服器識別目前已登入裝置的使用者，OMA DMClient 使用 Microsoft Entra 使用者憑證。每個管理工作階段都包含一個額外的 HTTP 標頭，該標頭包含 Microsoft Entra 使用者令牌。這些資訊會提供在發送給管理伺服器的 DM 套件中。然而，在某些情況下，Microsoft Entra 使用者憑證並未被傳送到管理伺服器。其中一個情境發生在 Microsoft Entra 加入過程中 MDM 註冊完成後立即發生。在 Microsoft Entra 加入程序完成且 Microsoft Entra 使用者登入機器之前，Microsoft Entra 使用者令牌無法用於 OMA-DM 程序。通常，MDM 註冊會在 Microsoft Entra 使用者登入機器前完成，且初始管理會話中不包含 Microsoft Entra 使用者憑證。管理伺服器應該檢查權杖是否遺失，並只在此類情況下傳送裝置政策。另一個可能導致 Microsoft Entra 令牌遺失的原因是當訪客登入裝置時。
在裝置上新增工作帳號及 MDM 註冊：

在此情境中，MDM 註冊適用於最初新增工作帳號並註冊裝置的單一使用者。在此註冊類型中，管理伺服器可忽略管理會話中可能傳送的 Microsoft Entra 令牌。無論 Microsoft Entra 令牌是否存在，管理伺服器都會將使用者與裝置的政策同時傳送給裝置。
評估 Microsoft Entra 用戶憑證：

Microsoft Entra 憑證以以下格式顯示在 HTTP 授權標頭中：
```
Authorization:Bearer <Azure AD User Token Inserted here>
```
Microsoft Entra 代幣中可能存在更多主張，例如：
- 使用者 - 使用者目前登入
- Device compliance - value set the MDM service in Azure
- 裝置識別碼 - 識別正在簽入的裝置
- 租用戶識別碼
Microsoft Entra ID發行的存取權杖是 JSON 網頁權杖 (JWT) 。 Windows 會向 MDM 註冊端點提供有效的 JWT 令牌以啟動註冊程序。有幾種評估代幣的選項：
- 使用 WIF 的 JWT 令牌處理擴充功能來驗證存取權杖內容並擷取使用所需的權利要求。欲了解更多資訊，請參閱 JwtSecurityTokenHandler 類別。
- 請參閱 Microsoft Entra 認證程式碼範例，取得使用存取權杖的範例。舉例可參見 NativeClient-DotNet。

Device Alert 1224 for Microsoft Entra user token

當 DM 會話開始且有 Microsoft Entra 使用者登入時，會發出警示。警報會以OMA私訊包#1發送。以下是範例：

Alert Type: com.microsoft/MDM/AADUserToken

Alert sample:
<SyncBody>
 <Alert>
  <CmdID>1</CmdID>
  <Data>1224</Data>
  <Item>
   <Meta>
    <Type xmlns= "syncml:metinf ">com.microsoft/MDM/AADUserToken</Type>
   </Meta>
   <Data>UserToken inserted here</Data>
  </Item>
 </Alert>
 ... other XML tags ...
</SyncBody>

透過輪詢判斷使用者何時登入

通知會發送到 DM 套件 #1 中的 MDM 伺服器。

警報類型 - com.microsoft/MDM/LoginStatus
警報格式 - chr
警示資料 - 提供目前活躍登入使用者的登入狀態資訊。
- 已登入且擁有 Microsoft Entra 帳號的使用者 - 預設文字：user。
- 未登入 Microsoft Entra 帳號的使用者 - 預設文字：其他人。
- 無活躍使用者 - 預設文字：無

這裡提供一個範例。

<SyncBody>
 <Alert>
  <CmdID>1</CmdID>
  <Data>1224</Data>
  <Item>
   <Meta>
    <Type xmlns= "syncml:metinf ">com.microsoft/MDM/LoginStatus</Type>
   </Meta>
   <Data>user</Data>
  </Item>
 </Alert>
 ... other XML tags ...
</SyncBody>

Report device compliance to Microsoft Entra ID

一旦裝置註冊管理 MDM，IT 管理員設定的組織政策就會被強制執行。 MDM 會評估裝置是否符合已設定的政策，然後回報給 Microsoft Entra ID。本節介紹您可以用來向 Microsoft Entra ID 報告裝置合規狀態的圖形 API 呼叫。

關於如何使用 OAuth 2.0 client_credentials授權類型取得存取權杖的範例，請參見 Daemon_CertificateCredential-DotNet。

雲端 MDM - 如果你的產品是雲端多租戶 MDM 服務，租戶內的服務會設定一個單一金鑰。要取得授權，請使用此金鑰以 Microsoft Entra ID 驗證 MDM 服務。
本地 MDM-若您的產品為本地 MDM，客戶必須使用用於 Microsoft Entra ID 認證的金鑰來設定您的產品。這種金鑰配置是因為你的 MDM 產品的每個本地實例都有不同的租戶專屬金鑰。因此，您可能需要在 MDM 產品中公開一個設定體驗，讓管理員能夠指定用於 Microsoft Entra ID 認證的金鑰。

使用 Microsoft 圖形 API

以下範例 REST API 呼叫說明 MDM 如何使用 Microsoft 圖形 API 來回報受管理裝置的合規狀態。

注意

此 API 僅適用於 Windows 裝置上核准的 MDM 應用程式。

Sample Graph API Request:

PATCH https://graph.windows.net/contoso.com/devices/db7ab579-3759-4492-a03f-655ca7f52ae1?api-version=beta HTTP/1.1
Authorization: Bearer eyJ0eXAiO.........
Accept: application/json
Content-Type: application/json
{  "isManaged":true,
   "isCompliant":true
}

其中：

contoso.com - 此值為裝置已加入目錄的Microsoft Entra租戶名稱。
db7ab579-3759-4492-a03f-655ca7f52ae1 - 此值為將合規資訊回報至 Microsoft Entra ID 的裝置識別碼。
eyJ0eXAiO......... - 這個值是授權MDM呼叫Microsoft Microsoft Entra ID圖形 API的持有人存取權杖，授權MDM使用。存取權杖會被放在請求的 HTTP 授權標頭中。
isManaged 與 isCompliant - 這些布林屬性表示合規狀態。
api-version -使用此參數指定所請求的圖 API 版本。

回應：

成功 - HTTP 204 無內容。
失敗/錯誤 - 找不到 HTTP 404。若找不到指定的裝置或租戶，可能會回傳此錯誤。

從 Microsoft Entra 加入取消註冊時的資料遺失

當使用者透過 Microsoft Entra join 註冊 MDM 後，解除連接時，不會有警告說使用者會失去 Windows 資訊保護 (進行中的) 資料。斷線訊息並不表示正在進行中的資料遺失。

AADJ 退學。

錯誤碼

代碼	識別碼	錯誤訊息
0x80180001	“idErrorServerConnectivity”， // MENROLL_E_DEVICE_MESSAGE_FORMAT_ERROR	與伺服器通訊時發生錯誤。你可以再試一次，或是聯絡系統管理員並提供錯誤代碼 {0}
0x80180002	「idErrorAuthenticationFailure」，// MENROLL_E_DEVICE_AUTHENTICATION_ERROR	你的帳號或裝置驗證時出了問題。你可以再試一次，或是聯絡你的系統管理員並提供錯誤代碼 {0}。
0x80180003	「idErrorAuthorizationFailure」，// MENROLL_E_DEVICE_AUTHORIZATION_ERROR	此用戶未被授權註冊。你可以再試一次，或是聯絡你的系統管理員並提供錯誤代碼 {0}。
0x80180004	「idErrorMDMCertificateError」， // MENROLL_E_DEVICE_CERTIFCATEREQUEST_ERROR	有個證書錯誤。你可以再試一次，或是聯絡你的系統管理員並提供錯誤代碼 {0}。
0x80180005	“idErrorServerConnectivity”， // MENROLL_E_DEVICE_CONFIGMGRSERVER_ERROR	與伺服器通訊時發生錯誤。你可以再試一次，或是聯絡系統管理員並提供錯誤代碼 {0}
0x80180006	“idErrorServerConnectivity”， // MENROLL_E_DEVICE_CONFIGMGRSERVER_ERROR	與伺服器通訊時發生錯誤。你可以再試一次，或是聯絡系統管理員並提供錯誤代碼 {0}
0x80180007	“idErrorAuthenticationFailure”， // MENROLL_E_DEVICE_INVALIDSECURITY_ERROR	你的帳號或裝置驗證時出了問題。你可以再試一次，或是聯絡你的系統管理員並提供錯誤代碼 {0}。
0x80180008	“idErrorServerConnectivity”， // MENROLL_E_DEVICE_UNKNOWN_ERROR	與伺服器通訊時發生錯誤。你可以再試一次，或是聯絡系統管理員並提供錯誤代碼 {0}
0x80180009	「idErrorAlreadyInProgress」，// MENROLL_E_ENROLLMENT_IN_PROGRESS	另一筆報名正在進行中。你可以再試一次，或是聯絡你的系統管理員並提供錯誤代碼 {0}。
0x8018000A	「idErrorMDMAlreadyEnrolled」， // MENROLL_E_DEVICE_ALREADY_ENROLLED	這個裝置已經註冊了。你可以聯絡系統管理員並提供錯誤代碼 {0}。
0x8018000D	“idErrorMDMCertificateError”， // MENROLL_E_DISCOVERY_SEC_CERT_DATE_INVALID	有個證書錯誤。你可以再試一次，或是聯絡你的系統管理員並提供錯誤代碼 {0}。
0x8018000E	「idErrorAuthenticationFailure」，// MENROLL_E_PASSWORD_NEEDED	你的帳號或裝置驗證時出了問題。你可以再試一次，或是聯絡你的系統管理員並提供錯誤代碼 {0}。
0x8018000F	「idErrorAuthenticationFailure」，// MENROLL_E_WAB_ERROR	你的帳號或裝置驗證時出了問題。你可以再試一次，或是聯絡你的系統管理員並提供錯誤代碼 {0}。
0x80180010	“idErrorServerConnectivity”， // MENROLL_E_CONNECTIVITY	與伺服器通訊時發生錯誤。你可以再試一次，或是聯絡系統管理員並提供錯誤代碼 {0}
0x80180012	「idErrorMDMCertificateError」，// MENROLL_E_INVALIDSSLCERT	有個證書錯誤。你可以再試一次，或是聯絡你的系統管理員並提供錯誤代碼 {0}。
0x80180013	「idErrorDeviceLimit」，// MENROLL_E_DEVICECAPREACHED	看起來這個帳號的裝置或使用者太多了。請聯絡你的系統管理員並提供錯誤代碼 {0}。
0x80180014	「idErrorMDMNotSupported」，// MENROLL_E_DEVICENOTSUPPORTED	此功能不被支援。請聯絡你的系統管理員並提供錯誤代碼 {0}。
0x80180015	“idErrorMDMNotSupported”， // MENROLL_E_NOTSUPPORTED	此功能不被支援。請聯絡你的系統管理員並提供錯誤代碼 {0}。
0x80180016	「idErrorMDMRenewalRejected」， // MENROLL_E_NOTELIGIBLETORENEW	伺服器未接受該請求。你可以再試一次，或是聯絡你的系統管理員並提供錯誤代碼 {0}。
0x80180017	「idErrorMDMAccountMaintenance」，// MENROLL_E_INMAINTENANCE	服務正在維護中。你可以之後再試一次，或是聯絡你的系統管理員並提供錯誤代碼 {0}。
0x80180018	「idErrorMDMLicenseError」，// MENROLL_E_USERLICENSE	你的駕照出了錯。你可以再試一次，或是聯絡你的系統管理員並提供錯誤代碼 {0}。
0x80180019	“idErrorInvalidServerConfig”， // MENROLL_E_ENROLLMENTDATAINVALID	看起來伺服器設定不正確。你可以再試一次，或是聯絡你的系統管理員並提供錯誤代碼 {0}。
「拒絕使用條款」	「idErrorRejectedTermsOfUse」	您的組織要求您同意使用條款。請再試一次，或向你的客服人員詢問更多資訊。
0x801c0001	“idErrorServerConnectivity”， // DSREG_E_DEVICE_MESSAGE_FORMAT_ERROR	與伺服器通訊時發生錯誤。你可以再試一次，或是聯絡系統管理員並提供錯誤代碼 {0}
0x801c0002	“idErrorAuthenticationFailure”， // DSREG_E_DEVICE_AUTHENTICATION_ERROR	你的帳號或裝置驗證時出了問題。你可以再試一次，或是聯絡你的系統管理員並提供錯誤代碼 {0}。
0x801c0003	「idErrorAuthorizationFailure」，// DSREG_E_DEVICE_AUTHORIZATION_ERROR	此用戶未被授權註冊。你可以再試一次，或是聯絡你的系統管理員並提供錯誤代碼 {0}。
0x801c0006	“idErrorServerConnectivity”， // DSREG_E_DEVICE_INTERNALSERVICE_ERROR	與伺服器通訊時發生錯誤。你可以再試一次，或是聯絡系統管理員並提供錯誤代碼 {0}
0x801c000B	“idErrorUntrustedServer”， // DSREG_E_DISCOVERY_REDIRECTION_NOT_TRUSTED	被聯絡的伺服器不值得信任。請聯絡你的系統管理員並提供錯誤代碼 {0}。
0x801c000C	“idErrorServerConnectivity”， // DSREG_E_DISCOVERY_FAILED	與伺服器通訊時發生錯誤。你可以再試一次，或是聯絡系統管理員並提供錯誤代碼 {0}
0x801c000E	「idErrorDeviceLimit」，// DSREG_E_DEVICE_REGISTRATION_QUOTA_EXCCEEDED	看起來這個帳號的裝置或使用者太多了。請聯絡你的系統管理員並提供錯誤代碼 {0}。
0x801c000F	“idErrorDeviceRequiresReboot”， // DSREG_E_DEVICE_REQUIRES_REBOOT	完成裝置註冊需重新啟動。
0x801c0010	“idErrorInvalidCertificate”， // DSREG_E_DEVICE_AIK_VALIDATION_ERROR	看起來你的證書無效。請聯絡你的系統管理員並提供錯誤代碼 {0}。
0x801c0011	「idErrorAuthenticationFailure」，// DSREG_E_DEVICE_ATTESTATION_ERROR	你的帳號或裝置驗證時出了問題。你可以再試一次，或是聯絡你的系統管理員並提供錯誤代碼 {0}。
0x801c0012	“idErrorServerConnectivity”， // DSREG_E_DISCOVERY_BAD_MESSAGE_ERROR	與伺服器通訊時發生錯誤。你可以再試一次，或是聯絡系統管理員並提供錯誤代碼 {0}
0x801c0013	“idErrorAuthenticationFailure”， // DSREG_E_TENANTID_NOT_FOUND	你的帳號或裝置驗證時出了問題。你可以再試一次，或是聯絡你的系統管理員並提供錯誤代碼 {0}。
0x801c0014	「idErrorAuthenticationFailure」，// DSREG_E_USERSID_NOT_FOUND	你的帳號或裝置驗證時出了問題。你可以再試一次，或是聯絡你的系統管理員並提供錯誤代碼 {0}。

意見反應

此頁面對您有幫助嗎？

Last updated on 2026-05-11