共用方式為


Microsoft與 MDM 整合

Microsoft Entra ID 是全世界最大的企業雲端身分識別管理服務。 組織會使用它來存取 Microsoft 365 和來自 Microsoft 和第三方軟體即服務的 365 和商務應用程式, (SaaS) 廠商。 許多適用於組織用戶的豐富 Windows 體驗, (例如市集存取或 OS 狀態漫遊) 使用 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 註冊和 UX

有數種方式可將裝置連線至 Microsoft Entra ID:

在每個案例中,Microsoft Entra 會驗證用戶和裝置。 它提供可用於 MDM 註冊的已驗證唯一裝置識別碼。 註冊流程讓 MDM 服務有機會使用 Web 檢視轉譯自己的 UI。 MDM 廠商應該使用UI來轉譯使用規定 (TOU) ,這對於公司擁有和攜帶您自己的裝置 (BYOD) 裝置而言可能不同。 MDM 廠商也可以使用 Web 檢視來轉譯更多 UI 元素,例如要求一次性 PIN。

在 Windows 10 中,現成案例期間的網頁檢視預設會顯示為全螢幕,讓 MDM 廠商能夠建立順暢的邊緣對邊緣用戶體驗。 不過,在 Windows 11 中,網頁檢視會在 iframe 內轉譯。 與 Microsoft Entra ID 整合的 MDM 廠商必須遵守 Windows 設計指導方針。 此步驟包括使用回應式 Web 設計,以及遵守 Windows 輔助功能指導方針。 例如,包含正確連線到導覽邏輯的向前和返回按鈕。 本文稍後會提供更多詳細數據。

若要讓 Microsoft Entra 註冊適用於 Active Directory 同盟服務 (AD FS) 支援的 Microsoft Entra 帳戶,您必須在 ADFS 服務上啟用內部網路的密碼驗證。 如需詳細資訊, 請參閱使用AD FS將 Microsoft Entra 多重要素驗證設定為驗證提供者

一旦使用者將 Microsoft Entra 帳戶新增至 Windows 並在 MDM 中註冊之後,即可透過>設定帳戶>存取公司或學校來管理註冊。 針對組織案例或 BYOD 案例Microsoft加入的裝置管理很類似。

注意

用戶無法透過 Access 公司或學校 使用者介面移除裝置註冊,因為管理系結至 Microsoft Entra ID 或工作帳戶。

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

Microsoft Entra MDM 註冊是兩個步驟的程式:

  1. 顯示使用規定並收集使用者同意:此同意是被動流程,使用者會在瀏覽器控件中重新導向, (網頁檢視) 至 MDM 使用規定 URL。
  2. 註冊裝置:此步驟是 Windows OMA DM 代理程式呼叫 MDM 服務以註冊裝置的作用中流程。

若要支援Microsoft註冊,MDM 廠商必須裝載並公開 使用規定端點MDM 註冊端點

  • 使用規定端點:使用此端點來通知使用者其組織可以控制其裝置的方式。 [ 使用規定 ] 頁面負責在實際註冊階段開始之前收集使用者的同意。

    請務必瞭解使用規定流程是 Windows 的「不透明方塊」,並Microsoft Entra ID。 整個 Web 檢視會重新導向至使用規定 URL。 核准或拒絕條款之後,應該將使用者重新導向回來。 此設計可讓 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 會以宣告的形式提供這項資訊。

    Microsoft註冊流程

    MDM 應該會在使用 Microsoft Graph API 向 Microsoft Entra ID 回報裝置合規性時,使用 裝置 (裝置標識碼) 的相關信息。 本文稍後會提供報告裝置合規性的範例。

讓 MDM 成為 Microsoft Entra ID 的可靠合作物件

若要參與上一節所述的整合式註冊流程,MDM 必須取用 Microsoft Entra ID 所簽發的存取令牌。 若要報告與 Microsoft Entra ID 的相容性,MDM 必須向 Microsoft Entra ID 進行驗證,並取得存取令牌形式的授權,以允許其叫 用 Microsoft Graph API

雲端式 MDM

雲端式 MDM 是一種 SaaS 應用程式,可在雲端中提供裝置管理功能。 它是多租用戶應用程式。 此應用程式會在 MDM 廠商的主租使用者中向 Microsoft Entra ID 註冊。 當 IT 系統管理員決定使用此 MDM 解決方案時,此應用程式的實例會顯示在客戶的租使用者中。

MDM 廠商必須先在其主租用戶中註冊應用程式,並將它標示為多租用戶應用程式。 如需如何將多租使用者應用程式新增至 Microsoft Entra ID 的詳細資訊,請參閱在 GitHub 上 使用多租使用者整合模式 (SaaS) 程式代碼範例,整合可驗證使用者和呼叫 Microsoft Graph 的應用程式。

注意

針對 MDM 提供者,如果您沒有現有的 Microsoft Entra 租使用者具有您管理的 Microsoft Entra 訂用帳戶,請遵循下列逐步指南:

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 下) >新增應用程式>建立您自己的應用程式。 系統管理員可以設定註冊所需的 URL 和使用規定。

您的內部部署 MDM 產品必須公開設定體驗,讓系統管理員可以提供用戶端識別碼、應用程式識別碼,以及其目錄中為該 MDM 應用程式設定的金鑰。 您可以使用此用戶端標識碼和密鑰,在報告裝置合規性時,向 Microsoft Entra ID 要求令牌。

如需使用 Microsoft Entra ID 註冊應用程式的詳細資訊,請參閱在 Microsoft Entra ID 中註冊應用程式的基本概念

金鑰管理和安全性指導方針

MDM 服務所使用的應用程式金鑰是敏感性資源。 它們應該受到保護並定期變數,以提升安全性。 MDM 服務用來呼叫 Microsoft Graph API 的存取令牌是持有人令牌,應受到保護以避免未經授權的洩漏。

如需安全性最佳做法, 請參閱 Microsoft Azure Security Essentials

針對雲端式 MDM,您可以變換應用程式金鑰,而不需要客戶互動。 MDM 廠商在其Microsoft Entra 租使用者中管理的所有客戶租使用者上,都有一組單一密鑰。

針對內部部署 MDM,Microsoft Entra 驗證金鑰位於客戶租使用者內,而且客戶的系統管理員必須變換密鑰。 若要改善安全性,請為客戶提供有關變換和保護密鑰的指引。

IT 系統管理員會使用 Microsoft Entra 應用連結庫來新增 MDM 供其組織使用。 應用程式資源庫是一個豐富的存放區,其中包含超過 2400 個與 Microsoft Entra ID 整合的 SaaS 應用程式。

注意

如果您的 MDM 應用程式是以雲端為基礎,而且必須啟用為多租使用者 MDM 應用程式,您應該與 Microsoft Entra 工程小組合作

若要發佈您的應用程式, 請在 Microsoft Entra 應用連結庫中提交發佈應用程式的要求

下表顯示在 Microsoft Entra 應用連結庫中建立專案的必要資訊。

項目 描述
應用程式識別碼 您在租使用者內設定之 MDM 應用程式的用戶端識別碼。 此標識碼是多租使用者應用程式的唯一標識碼。
發行者 識別應用程式發行者的字串。
應用程式 URL 應用程式登陸頁面的 URL,您的系統管理員可以在其中取得 MDM 應用程式的詳細資訊,並包含應用程式登陸頁面的連結。 此 URL 不會用於實際註冊。
描述 MDM 應用程式的簡短描述,必須低於 255 個字元。
圖示 MDM 應用程式的一組標誌圖示。 維度:45 X 45、150 X 122、214 X 215

將內部部署 MDM 新增至應用連結庫沒有特殊需求。 系統管理員有一個一般專案可將應用程式新增至其租使用者。

不過,內部部署 MDM 的金鑰管理不同。 您必須取得用戶端識別碼 (應用程式識別碼) ,以及指派給客戶租使用者內 MDM 應用程式的金鑰。 標識符和金鑰會取得存取 Microsoft Graph API 並報告裝置合規性的授權。

佈景主題

MDM 在整合式註冊程式中轉譯的頁面必須使用 Windows 範本 (將 Windows 範本和 CSS 檔案下載 (1.1.4) ) 。 這些範本對於 OOBE 中所有頁面都是邊緣對邊緣 HTML 頁面的 Microsoft Entra Join 體驗期間的註冊而言很重要。 請避免複製範本,因為很難正確放置按鈕。

有三個不同的案例:

  1. 在 Windows OOBE 中Microsoft加入的 MDM 註冊。
  2. MDM 註冊會在 Windows OOBE 從 [ 設定] 之後Microsoft加入。
  3. 在 BYOD) (個人裝置上新增Microsoft工作帳戶的一部分進行 MDM 註冊。

這些案例支援 Windows 專業版、企業版和教育版。

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

  • 針對 Windows 10,請使用 oobe-desktop.css
  • 針對 Windows 11,請使用 oobe-light.css

使用主題

根據顯示的案例,MDM 頁面必須遵守預先定義的主題。 例如,如果 CXH-HOSTHTTP 標頭是 OOBE 案例的 FRX,則頁面必須支援藍色背景色彩的深色主題,其使用 WinJS 檔案Ui-dark.css 4.0 版,oobe-desktop.css 1.0.4 版。

CXH-HOST (HTTP 標頭) 案例 背景主題 WinJS 案例 CSS
FRX OOBE 深色主題 + 藍色背景色彩 檔名:Ui-dark.css 檔名:oobe-dekstop.css
MOSET 設定/後 OOBE 淺色佈景主題 檔名:Ui-light.css 檔名:settings-desktop.css

使用規定通訊協定語意

MDM 伺服器會裝載 使用規定 端點。 在Microsoft加入通訊協定流程期間,Windows 會執行全頁重新導向至此端點。 此重新導向可讓 MDM 顯示適用的條款和條件。 它可讓使用者接受或拒絕與註冊相關聯的條款。 在使用者接受條款之後,MDM 會重新導向回 Windows,讓註冊程式繼續進行。

重新導向至使用規定端點

此重新導向是重新導向至 MDM 所裝載之用戶條款端點的完整頁面。 以下是範例 URL。 https://fabrikam.contosomdm.com/TermsOfUse

下列參數會在查詢字串中傳遞:

項目 描述
redirect_uri 在使用者接受或拒絕使用規定之後,用戶會重新導向至此 URL。
client-request-id 用來將記錄相互關聯以進行診斷和偵錯的 GUID。 使用此參數來記錄或追蹤註冊要求的狀態,以協助找出失敗的根本原因。
api-version 指定用戶端要求的通訊協定版本。 此值提供一個機制來支援通訊協定的版本修訂。
mode 指定當mode=azureadjoin時,裝置為組織所擁有。 BYOD 裝置不存在此參數。

存取權杖

Microsoft Entra ID 會發出持有人存取令牌。 令牌會在 HTTP 要求的授權標頭中傳遞。 以下是一般格式:

授權:持有人 CI6MTQxmCF5xgu6yYcmV9ng6vhQfaJYw...

在 Windows 傳遞至使用規定端點的存取令牌中,預期會有下列宣告:

項目 描述
物件標識碼 對應至已驗證使用者之用戶物件的標識碼。
UPN 包含已驗證使用者 UPN) (用戶主體名稱的宣告。
TID 表示租使用者之租用戶標識碼的宣告。 在上一個範例中,它是 Fabrikam。
資源 代表 MDM 應用程式的已清理 URL。 例: https://fabrikam.contosomdm.com

注意

存取令牌中沒有裝置標識碼宣告,因為目前可能尚未註冊裝置。

若要擷取使用者的群組成員資格清單,您可以使用 Microsoft Graph API

以下是範例 URL:

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加入程序期間略過它。 請勿在 Microsoft Entra Join 程式中顯示拒絕按鈕。 如果系統管理員為 Microsoft Entra join 設定,使用者就無法拒絕 MDM 註冊。

建議您在查詢字串中傳送 client-request-id 參數,作為此重新導向回應的一部分。

使用規定錯誤處理

如果在使用規定處理期間發生錯誤,MDM 可以傳回兩個errorerror_description參數 - 和 參數在其重新導向要求中傳回 Windows。 URL 應進行編碼,且 的內容 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-version 302 invalid_request 不支援的版本
租使用者或用戶數據遺失,或不符合裝置註冊的其他必要條件 302 unauthorized_client 未經授權的使用者或租使用者
Microsoft令牌驗證失敗 302 unauthorized_client unauthorized_client
內部服務錯誤 302 server_error 內部服務錯誤

具有 Microsoft Entra ID 的註冊通訊協定

使用 Azure 整合式 MDM 註冊時,沒有探索階段,探索 URL 會直接從 Azure 傳遞至系統。 下表顯示傳統與 Azure 註冊之間的比較。

細節 傳統 MDM 註冊 Microsoft加入 (組織擁有的裝置) Microsoft Entra ID 會在使用者擁有的裝置 (新增工作帳戶)
使用電子郵件位址擷取 MDM 探索 URL 的 MDM 自動探索 註冊 不適用
在 Azure 中布建的探索 URL
使用 MDM 探索 URL 註冊
註冊更新
ROBO
註冊
註冊更新
ROBO
註冊
註冊更新
ROBO
是否需要 MDM 註冊?
用戶可以拒絕。
驗證類型 OnPremise
聯邦
憑證
聯邦 聯邦
EnrollmentPolicyServiceURL 選擇性 (所有驗證) 選擇性 (所有驗證) 選擇性 (所有驗證)
EnrollmentServiceURL 所有驗證 (必要) 使用 (所有驗證) 使用 (所有驗證)
EnrollmentServiceURL 包含 OS 版本、OS 平臺,以及 MDM 探索 URL 所提供的其他屬性 強烈建議 強烈建議 強烈建議
使用的 AuthenticationServiceURL 使用 (同盟驗證)
BinarySecurityToken 每個 MDM 自定義 Microsoft發出的 Entra ID 令牌 Microsoft發出的 Entra ID 令牌
EnrollmentType 完整 裝置 完整
已註冊的憑證類型 用戶憑證 裝置憑證 用戶憑證
已註冊的證書存儲 我的/使用者 My/System 我的/使用者
CSR 主體名稱 使用者主體名稱 裝置標識碼 使用者主體名稱
EnrollmentData 使用二進位 Blob 作為 EnrollmentServiceURL 的 AdditionalContext 不支援 支援 支援
註冊期間可存取的 CSP Windows 10 支援:
- DMClient
- CertificateStore
- RootCATrustedCertificates
- ClientCertificateInstall
- EnterpriseModernAppManagement
- PassportForWork
-政策
- w7 APPLICATION

具有 Microsoft Entra ID 的管理通訊協定

有兩種不同的 MDM 註冊類型可與 Microsoft Entra ID 整合,並使用 Microsoft Entra 使用者和裝置身分識別。 根據註冊類型,MDM 服務可能需要管理單一使用者或多個使用者。

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

    在此案例中,MDM 註冊會套用至每個登入已加入 Microsoft Entra 裝置的 Microsoft Entra 使用者 - 呼叫此註冊類型為裝置註冊或多用戶註冊。 管理伺服器可以判斷使用者身分識別、判斷此使用者的目標原則,以及將對應的原則傳送至裝置。 為了允許管理伺服器識別登入裝置的目前使用者,OMA DM 用戶端會使用 Microsoft Entra 使用者令牌。 每個管理會話都包含額外的 HTTP 標頭,其中包含 Microsoft Entra 使用者令牌。 此資訊會在傳送至管理伺服器的 DM 套件中提供。 不過,在某些情況下,Microsoft Entra 使用者令牌不會傳送至管理伺服器。 在Microsoft加入程序期間,MDM 註冊完成之後,就會立即發生這類案例。 在 Microsoft Entra join 程式完成並Microsoft Entra 使用者登入計算機之前,Microsoft OMA-DM 程式無法使用 Entra 使用者令牌。 一般而言,MDM 註冊會在Microsoft Entra 使用者登入計算機之前完成,且初始管理會話不包含 Microsoft Entra 使用者令牌。 管理伺服器應該檢查令牌是否遺失,在這種情況下只傳送裝置原則。 OMA-DM 承載中遺漏 Microsoft Entra 令牌的另一個可能原因是來賓登入裝置時。

  • 將工作帳戶和 MDM 註冊新增至裝置

    在此案例中,MDM 註冊適用於最初新增其工作帳戶並註冊裝置的單一使用者。 在此註冊類型中,管理伺服器可以忽略可能在管理會話期間傳送的Microsoft Entra 令牌。 不論Microsoft令牌存在或遺失,管理伺服器都會將使用者和裝置原則傳送至裝置。

  • 評估 Microsoft Entra 使用者令牌

    Microsoft Entra 令牌的 HTTP 授權標頭格式如下:

    Authorization:Bearer <Azure AD User Token Inserted here>
    

    Microsoft Entra 令牌中可能會出現更多宣告,例如:

    • 使用者 - 使用者目前已登入
    • 裝置合規性 - 將 MDM 服務設定為 Azure 的值
    • 裝置標識碼 - 識別正在簽入的裝置
    • 租用戶識別碼

    Microsoft Entra ID 所簽發的存取令牌是 JSON Web 令牌, (JWT) 。 Windows 會向 MDM 註冊端點出示有效的 JWT 令牌,以開始註冊程式。 有幾個選項可用來評估令牌:

    • 使用 WIF 的 JWT 令牌處理程式延伸模組來驗證存取令牌的內容,並擷取使用所需的宣告。 如需詳細資訊,請 參閱 JwtSecurityTokenHandler 類別
    • 請參閱 Microsoft Entra 驗證程式代碼範例,以取得使用存取令牌的範例。 如需範例,請參閱 NativeClient-DotNet

Microsoft Entra 使用者令牌的裝置警示 1224

當 DM 作業階段啟動且有Microsoft Entra 使用者登入時,就會傳送警示。 警示會以 OMA DM 套件 #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 帳戶的登入使用者 - 預先定義的文字:使用者。
    • 沒有 Microsoft Entra 帳戶預先定義文字的登入使用者:其他使用者。
    • 沒有作用中的使用者 - 預先定義的文字:none

這裡提供一個範例。

<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>

向 Microsoft Entra ID 報告裝置合規性

向 MDM 註冊裝置以進行管理之後,IT 系統管理員所設定的組織原則就會在裝置上強制執行。 MDM 會評估裝置是否符合已設定的原則,然後將它回報給 Microsoft Entra ID。 本節涵蓋 Graph API 呼叫,您可以用來向 Microsoft Entra ID 報告裝置合規性狀態。

如需說明 MDM 如何使用 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 Graph 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......... - 此值是由 Microsoft Entra ID 簽發給 MDM 的持有人存取令牌,可授權 MDM 呼叫 Microsoft Graph API。 存取令牌會放在要求的 HTTP 授權標頭中。
  • isManagedisCompliant - 這些布爾值屬性表示合規性狀態。
  • api-version - 使用此參數來指定所要求的圖形 API 版本。

回應:

  • 成功 - 沒有內容的 HTTP 204。
  • 失敗/錯誤 - 找不到 HTTP 404。 如果找不到指定的裝置或租使用者,可能會傳回此錯誤。

從 Microsoft Entra join 取消註冊期間的數據遺失

當使用者透過 Microsoft Entra join 註冊到 MDM,然後中斷註冊的連線時,不會有任何警告指出用戶會遺失 Windows 資訊保護 (WIP) 數據。 中斷連線訊息不會指出 WIP 資料遺失。

aadj unenrollment.

錯誤碼

代碼 識別碼 錯誤訊息
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}連絡您的系統管理員。
“rejectedTermsOfUse” “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}連絡您的系統管理員。