Интеграция Microsoft Entra с MDM

Microsoft Entra ID — это крупнейшая в мире корпоративная служба управления облачными удостоверениями. Он используется организациями для доступа к Microsoft 365 и бизнес-приложениям от корпорации Майкрософт и сторонних поставщиков программного обеспечения как услуги (SaaS). Многие возможности Windows для пользователей организации (например, доступ к хранилищу или перемещение состояния ОС) используют Идентификатор Microsoft Entra в качестве базовой инфраструктуры удостоверений. Windows интегрируется с Microsoft Entra ID, позволяя зарегистрировать устройства в Microsoft Entra ID и зарегистрировать их в управлении мобильными устройствами (MDM) в интегрированном потоке.

После регистрации устройства в MDM:

• Может обеспечить соответствие политикам организации, добавлять или удалять приложения и т. д.
• Может сообщить о соответствии устройства идентификатору Microsoft Entra.
• Может разрешить доступ к ресурсам организации или приложениям, защищенным идентификатором Microsoft Entra, для устройств, соответствующих политикам.

Для поддержки этих расширенных возможностей в своем продукте MDM поставщики MDM могут интегрироваться с Microsoft Entra ID.

Интеграция регистрации MDM и пользовательского интерфейса

Существует несколько способов подключения устройств к Идентификатору Microsoft Entra:

• Присоединение устройства к Идентификатору Microsoft Entra
• Присоединение устройства к локальной службе AD и идентификатору Microsoft Entra
• Добавление рабочей учетной записи Майкрософт в Windows

В каждом сценарии Microsoft Entra проверяет подлинность пользователя и устройства. Он предоставляет проверенный уникальный идентификатор устройства, который можно использовать для регистрации MDM. Поток регистрации предоставляет службе MDM возможность отрисовки собственного пользовательского интерфейса с помощью веб-представления. Поставщики MDM должны использовать пользовательский интерфейс для отображения условий использования (TOU), которые могут отличаться для устройств, принадлежащих компании и byOD. Поставщики MDM также могут использовать веб-представление для отображения дополнительных элементов пользовательского интерфейса, таких как запрос одноразового ПИН-кода.

В Windows 10 веб-представление во время стандартного сценария по умолчанию отображается в полноэкранном режиме, предоставляя поставщикам MDM возможность создания простого взаимодействия с пользователем. Однако в Windows 11 веб-представление отображается в iframe. Важно, чтобы поставщики MDM, которые интегрируются с Microsoft Entra ID, соблюдали рекомендации по проектированию Windows. Этот шаг включает использование адаптивного веб-дизайна и соблюдение рекомендаций по специальным возможностям Windows. Например, включите кнопки вперед и назад, которые правильно подключены к логике навигации. Дополнительные сведения см. далее в этой статье.

Чтобы регистрация Microsoft Entra работала для учетной записи Microsoft Entra с поддержкой федерации Active Directory (AD FS), необходимо включить проверку подлинности по паролю для интрасети в службе ADFS. Дополнительные сведения см. в разделе Настройка многофакторной проверки подлинности Microsoft Entra в качестве поставщика проверки подлинности с помощью AD FS.

После того как у пользователя есть учетная запись Microsoft Entra, добавленная в Windows и зарегистрированная в MDM, регистрация может управляться с помощью параметров Учетные>>записиДоступ к рабочей или учебной программе. Управление устройствами присоединения к Microsoft Entra для сценариев организации или BYOD аналогично.

Конечные точки MDM, участвующие в интегрированной регистрации Microsoft Entra

Регистрация Microsoft Entra MDM состоит из двух этапов:

1. Отображение условий использования и получение согласия пользователя. Это согласие является пассивным потоком, в котором пользователь перенаправляется в элементе управления браузера (webview) на URL-адрес условий использования MDM.
2. Регистрация устройства. Этот шаг является активным потоком, в котором агент Windows OMA DM вызывает службу MDM для регистрации устройства.

Для поддержки регистрации Microsoft Entra поставщики MDM должны разместить и предоставить конечную точку условий использования и конечную точку регистрации MDM.

• Конечная точка условий использования. Используйте эту конечную точку для информирования пользователей о способах, которыми их организация может управлять устройством. Страница "Условия использования " отвечает за сбор согласия пользователя до начала фактического этапа регистрации.

  Важно понимать, что поток условий использования является "непрозрачным полем" для Windows и идентификатора Microsoft Entra. Все веб-представление перенаправляется на URL-адрес условий использования. Пользователь должен быть перенаправлен обратно после утверждения или отклонения Условий. Такая конструкция позволяет поставщику MDM настраивать условия использования для различных сценариев. Например, различные уровни управления применяются к устройствам BYOD и устройствам, принадлежащим организации. Или реализуйте нацеливание на основе пользователей или групп, например пользователи в определенных географических регионах могут иметь более строгие политики управления устройствами.

  Конечная точка "Условия использования" позволяет реализовать дополнительную бизнес-логику, например собирать одноразовый ПИН-код, предоставляемый ИТ-службой для управления регистрацией устройств. Однако поставщики MDM не должны использовать поток условий использования для сбора учетных данных пользователя, что может привести к ухудшению взаимодействия с пользователем. Это не требуется, так как часть интеграции MDM гарантирует, что служба MDM может понимать маркеры, выданные идентификатором Microsoft Entra.

• Конечная точка регистрации MDM. После того как пользователи примут условия использования, устройство регистрируется в идентификаторе Microsoft Entra. Начинается автоматическая регистрация MDM.

  На следующей схеме показан поток высокого уровня, участвующий в фактическом процессе регистрации. Устройство сначала регистрируется с идентификатором Microsoft Entra. Этот процесс присваивает устройству уникальный идентификатор и предоставляет устройству возможность проверки подлинности с помощью Идентификатора Microsoft Entra (проверка подлинности устройства). Затем устройство регистрируется для управления с помощью MDM. Этот шаг вызывает конечную точку регистрации и запрашивает регистрацию для пользователя и устройства. На этом этапе пользователь прошел проверку подлинности, а устройство зарегистрировано и прошло проверку подлинности с помощью идентификатора Microsoft Entra. Эти сведения доступны MDM в виде утверждений в маркере доступа, представленном в конечной точке регистрации.

  

  Ожидается, что MDM будет использовать эти сведения об устройстве (идентификатор устройства) при отправке сведений о соответствии устройства обратно в Идентификатор Microsoft Entra с помощью API Microsoft Graph. Пример отчетности о соответствии устройств приведен далее в этой статье.

Сделайте MDM надежной стороной Microsoft Entra ID

Для участия в интегрированном потоке регистрации, описанном в предыдущем разделе, MDM должна использовать маркеры доступа, выданные идентификатором Microsoft Entra. Чтобы сообщить о соответствии требованиям Идентификатора Microsoft Entra, MDM должен пройти проверку подлинности на microsoft Entra ID и получить авторизацию в виде маркера доступа, который позволяет ему вызывать API Microsoft Graph.

Облачные MDM

Облачный MDM — это приложение SaaS, которое предоставляет возможности управления устройствами в облаке. Это мультитенантное приложение. Это приложение зарегистрировано с идентификатором Microsoft Entra в домашнем клиенте поставщика MDM. Когда ИТ-администратор решает использовать это решение MDM, экземпляр этого приложения становится видимым в клиенте клиента.

Поставщик MDM должен сначала зарегистрировать приложение в своем домашнем клиенте и пометить его как мультитенантное приложение. Дополнительные сведения о добавлении мультитенантных приложений в Microsoft Entra ID см. в статье Интеграция приложения, которое проверяет подлинность пользователей и вызывает Microsoft Graph с помощью шаблона интеграции с мультитенантными пользователями (SaaS) на сайте GitHub.

Приложение MDM использует ключи для запроса маркеров доступа из Идентификатора Microsoft Entra. Эти ключи управляются в клиенте поставщика MDM и не видны отдельным клиентам. Тот же ключ используется мультитенантным приложением MDM для проверки подлинности с помощью идентификатора Microsoft Entra в клиенте клиента, к которому принадлежит управляемое устройство.

Локальное управление мобильными устройствами

Локальное приложение MDM отличается от облачного MDM. Это однотенантное приложение, которое уникально присутствует в клиенте клиента клиента. Клиенты должны добавить приложение непосредственно в свой клиент. Кроме того, каждый экземпляр локального приложения MDM должен быть зарегистрирован отдельно и иметь отдельный ключ для проверки подлинности с идентификатором Microsoft Entra.

Чтобы добавить локальное приложение MDM в клиент, используйте службу Microsoft Entra, в частности в разделе Мобильность (MDM и MAM)>Добавление приложения>Создание собственного приложения. Администраторы могут настроить необходимые URL-адреса для регистрации и условий использования.

Локальный продукт MDM должен предоставлять интерфейс конфигурации, в котором администраторы могут указать идентификатор клиента, идентификатор приложения и ключ, настроенный в каталоге для этого приложения MDM. Этот идентификатор клиента и ключ можно использовать для запроса маркеров из Идентификатора Microsoft Entra при отправке отчетов о соответствии устройств.

Дополнительные сведения о регистрации приложений с помощью Идентификатора Microsoft Entra см. в разделе Основные сведения о регистрации приложения в Microsoft Entra ID.

Рекомендации по управлению ключами и безопасности

Ключи приложений, используемые службой MDM, являются конфиденциальным ресурсом. Для повышения безопасности их следует периодически защищать и переворавывать. Маркеры доступа, полученные службой MDM для вызова API Microsoft Graph, являются маркерами носителя и должны быть защищены, чтобы избежать несанкционированного раскрытия.

Рекомендации по обеспечению безопасности см. в статье Microsoft Azure Security Essentials.

Для облачных MDM можно переворачивать ключи приложений, не требуя взаимодействия с клиентом. Существует единый набор ключей для всех клиентов, управляемых поставщиком MDM в клиенте Microsoft Entra.

Для локального MDM ключи проверки подлинности Microsoft Entra находятся в клиенте клиента, и администратор клиента должен перевернуть ключи. Чтобы повысить безопасность, предоставьте клиентам рекомендации по перемещению и защите ключей.

Публикация приложения MDM в коллекции приложений Microsoft Entra

ИТ-администраторы используют коллекцию приложений Microsoft Entra, чтобы добавить MDM для использования своей организацией. Коллекция приложений — это многофункциональный магазин с более чем 2400 приложениями SaaS, интегрированными с Microsoft Entra ID.

Добавление облачных MDM в коллекцию приложений

Чтобы опубликовать приложение, отправьте запрос на публикацию приложения в коллекции приложений Microsoft Entra.

В следующей таблице приведены необходимые сведения для создания записи в коллекции приложений Microsoft Entra.

Добавление локальной среды MDM в коллекцию приложений

Особых требований к добавлению локального MDM в коллекцию приложений нет. Администраторы могут добавить приложение в клиент.

Однако управление ключами отличается для локальных MDM. Необходимо получить идентификатор клиента (идентификатор приложения) и ключ, назначенный приложению MDM в клиенте клиента. Идентификатор и ключ получают авторизацию для доступа к API Microsoft Graph и отчета о соответствии устройств.

Темы

Страницы, отображаемые MDM в процессе интегрированной регистрации, должны использовать шаблоны Windows (скачать шаблоны Windows и CSS-файлы (1.1.4)). Эти шаблоны важны для регистрации во время присоединения к Microsoft Entra в OOBE, где все страницы являются html-страницами от края до края. Избегайте копирования шаблонов, так как трудно правильно установить расположение кнопки.

Существует три отдельных сценария:

1. Регистрация MDM в рамках присоединения к Microsoft Entra в windows OOBE.
2. Регистрация MDM в рамках присоединения к Microsoft Entra после запуска windows OOBE из параметров.
3. Регистрация MDM в рамках добавления рабочей учетной записи Майкрософт на личном устройстве (BYOD).

Эти сценарии поддерживают Windows Pro, Корпоративная и Для образовательных учреждений.

Css-файлы, предоставляемые корпорацией Майкрософт, содержат сведения о версии, и мы рекомендуем использовать последнюю версию. Существуют отдельные CSS-файлы для клиентских устройств Windows, OOBE и интерфейсов после запуска. Скачайте шаблоны Windows и файлы CSS (1.1.4).

• Для Windows 10 используйте oobe-desktop.css
• Для Windows 11 используйте oobe-light.css

Использование тем

Страница MDM должна соответствовать предопределенной теме в зависимости от отображаемого сценария. Например, если заголовок CXH-HOSTHTTP является FRX, который является сценарием запуска, то страница должна поддерживать темную тему с синим цветом фона, который использует файл WinJS Ui-dark.css версии 4.0 и oobe-desktop.css версии 1.0.4.

Семантика протокола условий использования

На сервере MDM размещается конечная точка условий использования . Во время потока протокола присоединения Microsoft Entra Windows выполняет полностраничные перенаправления на эту конечную точку. Это перенаправление позволяет MDM отображать применимые условия. Это позволяет пользователю принять или отклонить условия, связанные с регистрацией. После того как пользователь примет условия, MDM перенаправляется обратно в Windows для продолжения процесса регистрации.

Перенаправление на конечную точку условий использования

Это перенаправление является полностраничной перенаправлением в конечную точку "Условия пользователя", размещенную в MDM. Ниже приведен пример URL-адреса https://fabrikam.contosomdm.com/TermsOfUse.

В строке запроса передаются следующие параметры:

Маркер доступа

Идентификатор Microsoft Entra выдает маркер доступа носителя. Маркер передается в заголовке авторизации HTTP-запроса. Вот типичный формат:

Авторизация: носитель CI6MTQxmCF5xgu6yYcmV9ng6vhQfaJYw...

В маркере доступа, передаваемом Windows в конечную точку Условий использования, ожидаются следующие утверждения:

Чтобы получить список членства в группах для пользователя, можно использовать API Microsoft Graph.

Ниже приведен пример 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 и что получатель подходит.

Содержимое условий использования

MDM может выполнять другие дополнительные перенаправления по мере необходимости перед отображением содержимого Условий использования для пользователя. Соответствующее содержимое условий использования должно быть возвращено вызывающему объекту (Windows), чтобы его можно было отобразить для конечного пользователя в элементе управления браузера.

Содержимое условий использования должно содержать следующие кнопки:

• Принять — пользователь принимает условия использования и продолжает регистрацию.
• Отклонить — пользователь отклоняет и останавливает процесс регистрации.

Содержимое Условий использования должно соответствовать теме, используемой для других страниц, отображаемых в ходе этого процесса.

Логика обработки конечной точки условий использования

На этом этапе пользователь находится на странице Условий использования, отображаемой во время запуска запуска или из интерфейса параметров. У пользователя есть следующие параметры на странице:

• Пользователь нажимает кнопку Принять . MDM должен перенаправляться на URI, указанный параметром redirect_uri во входящем запросе. Ожидаются следующие параметры строки запроса:
  • IsAccepted — это логическое значение является обязательным и должно иметь значение true.
  • OpaqueBlob — обязательный параметр, если пользователь принимает. MDM может использовать этот большой двоичный объект, чтобы сделать некоторые сведения доступными для конечной точки регистрации. Сохраненное здесь значение становится доступным без изменений в конечной точке регистрации. MDM может использовать этот параметр для корреляции.
  • Ниже приведен пример перенаправления. ms-appx-web://MyApp1/ToUResponse?OpaqueBlob=value&IsAccepted=true
• Пользователь нажимает кнопку Отклонить . MDM должен перенаправляться на URI, указанный в redirect_uri во входящем запросе. Ожидаются следующие параметры строки запроса:
  • IsAccepted — это логическое значение является обязательным и должно иметь значение false. Этот параметр также применяется, если пользователь пропустил условия использования.
  • OpaqueBlob — этот параметр не будет использоваться. Регистрация останавливается с сообщением об ошибке, отображаемом пользователю.

Пользователи пропускают условия использования при добавлении рабочей учетной записи Майкрософт на свое устройство. Однако они не могут пропустить его во время процесса присоединения к Microsoft Entra. Не показывать кнопку "Отклонить" в процессе присоединения к Microsoft Entra. Пользователь не может отклонить регистрацию MDM, если администратор настроен для присоединения к Microsoft Entra.

Мы рекомендуем отправлять параметры client-request-id в строке запроса в рамках этого ответа перенаправления.

Обработка ошибок условий использования

Если во время обработки условий использования возникает ошибка, MDM может вернуть два параметра — параметр error и в error_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

В следующей таблице показаны коды ошибок.

Протокол регистрации с идентификатором Microsoft Entra

При регистрации, интегрированной в Azure MDM, этап обнаружения не выполняется, и URL-адрес обнаружения передается в систему напрямую из Azure. В следующей таблице показано сравнение традиционных регистраций и регистраций Azure.

Протокол управления с идентификатором Microsoft Entra

Существует два разных типа регистрации 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. Сервер управления должен проверить, отсутствует ли маркер, и отправлять политики устройств только в этом случае. Другой возможной причиной отсутствия маркера Microsoft Entra в полезных данных OMA-DM является вход гостя на устройство.

• Добавление рабочей учетной записи и регистрации MDM на устройство:

  В этом сценарии регистрация MDM применяется к одному пользователю, который изначально добавил свою рабочую учетную запись и зарегистрировал устройство. В этом типе регистрации сервер управления может игнорировать маркеры Microsoft Entra, которые могут быть отправлены во время сеанса управления. Независимо от того, присутствует ли маркер Microsoft Entra или отсутствует, сервер управления отправляет на устройство политики пользователей и устройств.

• Оценка маркеров пользователей Microsoft Entra:

  Токен Microsoft Entra находится в заголовке HTTP Authorization в следующем формате:

  Authorization:Bearer <Azure AD User Token Inserted here>
  

  В маркере Microsoft Entra могут присутствовать другие утверждения, например:

  • Пользователь — пользователь, вошедший в систему
  • Соответствие устройств — для службы MDM задано значение Azure.
  • Идентификатор устройства — идентифицирует устройство, которое выполняется при регистрации.
  • Идентификатор клиента

  Маркеры доступа, выданные идентификатором Microsoft Entra, являются веб-токенами JSON (JWT). Windows предоставляет допустимый токен JWT конечной точке регистрации MDM, чтобы начать процесс регистрации. Существует несколько вариантов оценки маркеров:

  • Используйте расширение JWT Token Handler для WIF, чтобы проверить содержимое маркера доступа и извлечь утверждения, необходимые для использования. Дополнительные сведения см. в разделе Класс JwtSecurityTokenHandler.
  • Ознакомьтесь с примерами кода проверки подлинности Microsoft Entra, чтобы получить пример для работы с маркерами доступа. Пример см. в разделе NativeClient-DotNet.

Оповещение устройства 1224 для маркера пользователя Microsoft Entra

Оповещение отправляется при запуске сеанса интеллектуального анализа данных и вошедшего в систему пользователя Microsoft Entra. Оповещение отправляется в пакете OMA DM No1. Вот пример.

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>

Определение времени входа пользователя с помощью опроса

Оповещение отправляется на сервер MDM в пакете DM 1.

• Тип оповещения — com.microsoft/MDM/LoginStatus
• Формат оповещений — chr
• Данные оповещений — укажите сведения о состоянии входа для текущего активного пользователя, выполнившего вход.
  • Пользователь, выполнивший вход с учетной записью Microsoft Entra, — предопределенный текст: user.
  • Вошедшего пользователя без учетной записи 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 для управления на нем применяются политики организации, настроенные ИТ-администратором. MDM оценивает соответствие устройства настроенным политикам, а затем передает его в Microsoft Entra ID. В этом разделе рассматривается вызов API Graph, который можно использовать для передачи сведений о состоянии соответствия устройств идентификатору Microsoft Entra.

Пример, демонстрирующий, как MDM может получить маркер доступа с помощью OAuth 2.0 client_credentials типа предоставления, см. в разделе Daemon_CertificateCredential-DotNet.

• Облачные MDM . Если ваш продукт является облачной мультитенантной службой MDM, у вас есть один ключ, настроенный для службы в клиенте. Чтобы получить авторизацию, используйте этот ключ для проверки подлинности службы MDM с помощью идентификатора Microsoft Entra.
• Локальная среда MDM . Если ваш продукт является локальным MDM, клиенты должны настроить его с помощью ключа, используемого для проверки подлинности с помощью идентификатора Microsoft Entra. Эта конфигурация ключа связана с тем, что каждый локальный экземпляр вашего продукта MDM имеет отдельный ключ, зависящий от клиента. Таким образом, может потребоваться предоставить в продукте MDM интерфейс конфигурации, позволяющий администраторам указать ключ, используемый для проверки подлинности с помощью идентификатора Microsoft Entra.

Использование API Microsoft Graph

В следующем примере вызова REST API показано, как MDM может использовать API Microsoft Graph для отчета о состоянии соответствия управляемого устройства.

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.
• eyJ0eXAiO......... . Это значение представляет собой маркер доступа носителя, выданный идентификатором Microsoft Entra для MDM, который разрешает MDM вызывать API Microsoft Graph. Маркер доступа помещается в заголовок авторизации HTTP запроса.
• isManaged и isCompliant — эти логические атрибуты указывают на состояние соответствия.
• api-version — используйте этот параметр, чтобы указать, какая версия API graph запрашивается.

Ответ:

• Успешно — HTTP 204 без содержимого.
• Сбой или ошибка — HTTP 404 не найден. Эта ошибка может быть возвращена, если не удается найти указанное устройство или клиент.

Потеря данных во время отмены регистрации от присоединения к Microsoft Entra

Когда пользователь регистрируется в MDM через присоединение к Microsoft Entra, а затем отключает регистрацию, нет никаких предупреждений о том, что пользователь потеряет данные Windows Information Protection (WIP). Сообщение об отключении не указывает на потерю данных WIP.

Коды ошибок