Microsoft Entra与 MDM 的集成
Microsoft Entra ID是世界上最大的企业云标识管理服务。 组织使用它从 Microsoft 和第三方软件即服务访问 Microsoft 365 和业务应用程序， (SaaS) 供应商。 许多适用于组织用户的丰富 Windows 体验 (（例如存储访问或 OS 状态漫游）) 使用Microsoft Entra ID作为基础标识基础结构。 Windows 与Microsoft Entra ID集成，允许在Microsoft Entra ID中注册设备，并在集成流中注册到 MDM 中。
在 MDM 中注册设备后，MDM：
- 可以强制遵守组织策略、添加或删除应用等。
- 可以在Microsoft Entra ID中报告设备的符合性。
- 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 中，现成方案期间的 Web 视图默认显示为全屏，使 MDM 供应商能够创建无缝的边缘到边缘用户体验。 但是，在Windows 11 Web 视图在 iframe 中呈现。 与 Microsoft Entra ID集成的 MDM 供应商必须尊重 Windows 设计准则。 此步骤包括使用响应式 Web 设计和遵循 Windows 辅助功能准则。 例如，包括正确连接到导航逻辑的前进和后退按钮。 本文稍后会提供更多详细信息。
若要Microsoft Entra注册适用于 Active Directory 联合服务 (AD FS) 支持的Microsoft Entra帐户，必须在 ADFS 服务上为 Intranet 启用密码身份验证。 有关详细信息，请参阅 使用 AD FS 将 Azure MFA 配置为身份验证提供程序。
将Microsoft Entra帐户添加到 Windows 并在 MDM 中注册后，可以通过设置>帐户>访问工作或学校来管理注册。 对于组织方案或 BYOD 方案，Microsoft Entra联接的设备管理是类似的。
注意
用户无法通过 Access 工作或学校用户界面删除设备注册，因为管理绑定到Microsoft Entra ID或工作帐户。
集成注册中涉及Microsoft Entra MDM 终结点
Microsoft Entra MDM 注册是一个两步过程：
- 显示使用条款并收集用户同意：此同意是一种被动流程，在该流程中，用户被重定向到浏览器控件 (webview) MDM 使用条款的 URL。
- 注册设备：此步骤是 Windows OMA DM 代理调用 MDM 服务来注册设备的活动流。
若要支持Microsoft Entra注册，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 图形 API向Microsoft Entra ID报告设备符合性时，MDM 应使用有关设备 (设备 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) >添加应用程序>创建自己的应用程序下。 管理员可以为注册和使用条款配置所需的 URL。
本地 MDM 产品必须公开配置体验，管理员可以提供客户端 ID、应用 ID 和目录中为该 MDM 应用程序配置的密钥。 报告设备符合性时，可以使用此客户端 ID 和密钥从Microsoft Entra ID请求令牌。
有关使用 Microsoft Entra ID 注册应用程序的详细信息，请参阅在 Microsoft Entra ID 中注册应用程序的基础知识。
密钥管理和安全准则
MDM 服务使用的应用程序密钥是敏感资源。 为了提高安全性，应定期保护并滚动更新它们。 MDM 服务获取的用于调用 Microsoft 图形 API的访问令牌是持有者令牌，应受到保护，以避免未经授权的泄露。
有关安全最佳做法，请参阅 Microsoft Azure Security Essentials。
对于基于云的 MDM，无需客户交互即可滚动更新应用程序密钥。 在其Microsoft Entra租户中，MDM 供应商管理的所有客户租户都有一组密钥。
对于本地 MDM，Microsoft Entra身份验证密钥位于客户租户中，并且客户的管理员必须滚动更新密钥。 若要提高安全性，请为客户提供有关滚动更新和保护密钥的指导。
将 MDM 应用发布到Microsoft Entra应用库
IT 管理员使用 Microsoft Entra 应用库添加 MDM 供其组织使用。 应用库是一个丰富的存储，包含 2400 多个与 Microsoft Entra ID 集成的 SaaS 应用程序。
将基于云的 MDM 添加到应用库
注意
如果 MDM 应用程序是基于云的，并且需要作为多租户 MDM 应用程序启用，则应与 Microsoft Entra 工程团队合作
若要发布应用程序，请在应用程序库中提交Microsoft Entra发布应用程序的请求
下表显示了在 Microsoft Entra 应用库中创建条目所需的信息。
| 项目 | 描述 |
|---|---|
| 应用程序 ID | 在租户中配置的 MDM 应用的客户端 ID。 此 ID 是多租户应用的唯一标识符。 |
| 发布者 | 标识应用的发布者的字符串。 |
| 应用程序 URL | 应用登陆页的 URL，管理员可在其中获取有关 MDM 应用的详细信息，并包含指向应用登陆页面的链接。 此 URL 不用于实际注册。 |
| Description | MDM 应用的简要说明，其长度必须低于 255 个字符。 |
| 图标 | MDM 应用的一组徽标图标。 尺寸：45 X 45、150 X 122、214 X 215 |
将本地 MDM 添加到应用库
将本地 MDM 添加到应用库没有特殊要求。 管理员可通过一个通用条目将应用添加到其租户。
但是，本地 MDM 的密钥管理有所不同。 必须获取客户端 ID (应用 ID) ，以及分配给客户租户中的 MDM 应用的密钥。 ID 和密钥获取访问 Microsoft 图形 API和报告设备符合性的授权。
主题
MDM 在集成注册过程中呈现的页面必须使用 Windows 模板 (下载 Windows 模板和 CSS 文件 (1.1.4) ) 。 在 OOBE 的Microsoft Entra加入体验期间，这些模板对于注册非常重要，因为 OOBE 的所有页面都是边缘到边缘的 HTML 页面。 避免复制模板，因为很难正确放置按钮。
有三种不同的方案：
- 在 Windows OOBE 中加入Microsoft Entra MDM 注册。
- 在 Windows OOBE 从“设置”之后，作为加入Microsoft Entra一部分的 MDM 注册。
- 在个人设备上添加 Microsoft 工作帐户时，MDM 注册 (BYOD) 。
这些方案支持 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 标头是 FRX（这是 OOBE 方案），则页面必须支持具有蓝色背景色的深色主题，该主题使用 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 Entra联接协议流期间，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 传递到使用条款终结点的访问令牌中应存在以下声明：
| 项目 | 描述 |
|---|---|
| 对象 ID | 与经过身份验证的用户对应的用户对象的标识符。 |
| Upn | 一个声明，其中包含经过身份验证的用户 (UPN) 的用户主体名称。 |
| TID | 表示租户的租户 ID 的声明。 在上面的示例中，它是 Fabrikam。 |
| 资源 | 表示 MDM 应用程序的净化 URL。 示例：https://fabrikam.contosomdm.com |
注意
访问令牌中没有设备 ID 声明，因为目前可能尚未注册设备。
若要检索用户的组成员身份列表，可以使用 Microsoft 图形 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 Entra加入过程中，他们无法跳过它。 不要在Microsoft Entra加入过程中显示拒绝按钮。 如果管理员为Microsoft Entra加入配置，则用户无法拒绝 MDM 注册。
建议将此重定向响应的一部分发送到查询字符串中的 client-request-id 参数。
使用条款错误处理
如果在使用条款处理过程中发生错误，MDM 可以返回两个errorerror_description参数 -- 和 参数在其重定向请求中返回 Windows。 应对 URL 进行编码，并且 的内容 error_description 应为英文纯文本。 此文本对最终用户不可见。 因此，文本本地化 error_description 不是问题。
URL 格式如下：
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 Entra令牌验证失败 | 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 自动发现 | 注册 | 不适用 Azure 中预配的发现 URL |
|
| 使用 MDM 发现 URL | 注册 注册续订 机器人 |
注册 注册续订 机器人 |
注册 注册续订 机器人 |
| 是否需要 MDM 注册？ | 是 | 是 | 否 用户可以拒绝。 |
| 身份验证类型 | OnPremise 联邦 证书 |
联邦 | 联邦 |
| EnrollmentPolicyServiceURL | 可选 (所有身份验证) | 可选 (所有身份验证) | 可选 (所有身份验证) |
| EnrollmentServiceURL | 需要 (所有身份验证) | 使用 (所有身份验证) | 使用 (所有身份验证) |
| EnrollmentServiceURL 包括 OS 版本、OS 平台和 MDM 发现 URL 提供的其他属性 | 强烈建议 | 强烈建议 | 强烈建议 |
| 使用的 AuthenticationServiceURL | 已 (联合身份验证) | 跳 | 跳 |
| BinarySecurityToken | 每个 MDM 自定义 | Microsoft Entra ID颁发的令牌 | Microsoft Entra ID颁发的令牌 |
| EnrollmentType | 完整 | 设备 | 完整 |
| 已注册的证书类型 | 用户证书 | 设备证书 | 用户证书 |
| 已注册的证书存储 | 我的/用户 | My/System | 我的/用户 |
| CSR 使用者名称 | 用户主体名称 | 设备 ID | 用户主体名称 |
| 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用户令牌不会发送到管理服务器。 在加入过程中，在 MDM 注册完成Microsoft Entra后，会立即发生此类情况。 在完成Microsoft Entra加入过程并Microsoft Entra用户登录到计算机之前，Microsoft Entra用户令牌不适用于 OMA-DM 进程。 通常，MDM 注册在用户登录到计算机之前Microsoft Entra完成，初始管理会话不包含Microsoft Entra用户令牌。 如果缺少令牌，管理服务器应检查，并且在这种情况下仅发送设备策略。 OMA-DM 有效负载中缺少Microsoft Entra令牌的另一个可能原因是来宾登录到设备。
将工作帐户和 MDM 注册添加到设备：
在此方案中，MDM 注册适用于最初添加其工作帐户并注册了设备的单个用户。 在此注册类型中，管理服务器可以忽略Microsoft Entra令牌，这些令牌可能在管理会话期间发送。 无论Microsoft Entra令牌是否存在还是缺失，管理服务器都向设备发送用户和设备策略。
评估Microsoft Entra用户令牌：
Microsoft Entra令牌位于 HTTP 授权标头中，格式如下：
Authorization:Bearer <Azure AD User Token Inserted here>Microsoft Entra 令牌中可能存在更多声明，例如：
- 用户 - 用户当前已登录
- 设备符合性 - 将 MDM 服务设置为 Azure 的值
- 设备 ID - 标识正在签入的设备
- 租户 ID
Microsoft Entra ID颁发的访问令牌是 JWT) (JSON Web 令牌。 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帐户的已登录用户-预定义文本：其他用户。
- 无活动用户 - 预定义文本：无
下面提供了一个示例。
<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。 本部分介绍可用于向Microsoft Entra ID报告设备符合性状态的图形 API调用。
有关演示 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 图形 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 图形 API。 访问令牌放置在请求的 HTTP 授权标头中。
- isManaged 和 isCompliant - 这些布尔属性指示符合性状态。
- api-version - 使用此参数可指定要请求的图形 API 版本。
响应：
- 成功 - 无内容的 HTTP 204。
- 失败/错误 - 找不到 HTTP 404。 如果找不到指定的设备或租户，可能会返回此错误。
从Microsoft Entra联接取消注册期间丢失数据
如果用户通过Microsoft Entra联接注册到 MDM，然后断开注册连接，则不会警告用户丢失 Windows 信息保护 (WIP) 数据。 断开连接消息不指示 WIP 数据丢失。
错误代码
| 代码 | ID | 错误消息 |
|---|---|---|
| 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}联系系统管理员。 |
反馈
即将发布：在整个 2024 年，我们将逐步淘汰作为内容反馈机制的“GitHub 问题”，并将其取代为新的反馈系统。 有关详细信息，请参阅：https://aka.ms/ContentUserFeedback。
提交和查看相关反馈