Поделиться через


Интеграция 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 проверяет подлинность пользователя и устройства. Он предоставляет проверенный уникальный идентификатор устройства, который можно использовать для регистрации 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 аналогично.

Примечание.

Пользователи не могут удалить регистрацию устройства с помощью рабочего или учебного пользовательского интерфейса Access, так как управление привязано к идентификатору Microsoft Entra или рабочей учетной записи.

Конечные точки 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 в виде утверждений в маркере доступа, представленном в конечной точке регистрации.

    Поток регистрации Microsoft Entra

    Ожидается, что 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 с управляемой подпиской Microsoft Entra, следуйте этим пошаговым руководствам:

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

Примечание.

Все приложения MDM должны реализовать токены Microsoft Entra версии 2, прежде чем мы сертифицируем, что интеграция работает. Из-за изменений в платформе приложений Microsoft Entra использование токенов Microsoft Entra версии 2 является жестким требованием. Дополнительные сведения см. в разделе Маркеры доступа платформы удостоверений Майкрософт.

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

Локальное приложение 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 находятся в клиенте клиента, и администратор клиента должен перевернуть ключи. Чтобы повысить безопасность, предоставьте клиентам рекомендации по перемещению и защите ключей.

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

Примечание.

Обратитесь к группе разработчиков Microsoft Entra, если ваше приложение MDM основано на облаке и должно быть включено как мультитенантное приложение MDM.

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

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

Элемент Описание
Идентификатор приложения Идентификатор клиента приложения MDM, настроенного в клиенте. Этот идентификатор является уникальным идентификатором мультитенантного приложения.
Издатель Строка, идентифицирующая издателя приложения.
URL-адрес приложения URL-адрес целевой страницы приложения, где администраторы могут получить дополнительные сведения о приложении MDM и содержит ссылку на целевую страницу приложения. Этот URL-адрес не используется для фактической регистрации.
Описание Краткое описание приложения MDM, которое должно содержать не более 255 символов.
Значки Набор значков с логотипами для приложения MDM. Размеры: 45 x 45, 150 x 122, 214 x 215

Особых требований к добавлению локального 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.

CXH-HOST (ЗАГОЛОВОК HTTP) Сценарий Фоновая тема WinJS CSS сценария
FRX OOBE Темная тема + синий цвет фона Имя файла: Ui-dark.css Имя файла: oobe-dekstop.css
MOSET Параметры/после запуска при первом включении Светлая тема Имя файла: 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 Указывает версию протокола, запрошенную клиентом. Это значение предоставляет механизм для поддержки версий протокола.
mode Указывает, что устройство принадлежит организации, если mode=azureadjoin. Этот параметр отсутствует для устройств BYOD.

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

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

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

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

Элемент Описание
Идентификатор объекта Идентификатор объекта пользователя, соответствующего пользователю, прошедшему проверку подлинности.
Имя участника-пользователя Утверждение, содержащее имя участника-пользователя (UPN) пользователя, прошедшего проверку подлинности.
TID Утверждение, представляющее идентификатор клиента. В предыдущем примере это Fabrikam.
Ресурс Дезинфицируемый URL-адрес, представляющий приложение MDM. Пример: https://fabrikam.contosomdm.com

Примечание.

В маркере доступа нет утверждения идентификатора устройства, так как в настоящее время устройство еще не зарегистрировано.

Чтобы получить список членства в группах для пользователя, можно использовать 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

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

Причина Состояние HTTP Ошибка Описание
версия api 302 invalid_request неподдерживаемая версия
Данные клиента или пользователя отсутствуют или не выполняются другие необходимые условия для регистрации устройств 302 unauthorized_client несанкционированный пользователь или клиент
Сбой проверки маркера Microsoft Entra 302 unauthorized_client unauthorized_client
внутренняя ошибка службы 302 server_error внутренняя ошибка службы

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

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

Подробность Традиционная регистрация MDM Присоединение к Microsoft Entra (устройство, принадлежающее организации) Идентификатор Microsoft Entra добавляет рабочую учетную запись (устройство, принадлежающее пользователю)
Автоматическое обнаружение MDM с помощью адреса электронной почты для получения URL-адреса обнаружения MDM регистрация; Неприменимо
URL-адрес обнаружения, подготовленный в Azure
Использует URL-адрес обнаружения MDM регистрация;
Продление регистрации
ROBO
регистрация;
Продление регистрации
ROBO
регистрация;
Продление регистрации
ROBO
Требуется ли регистрация MDM? Да Да Нет
Пользователь может отклонить.
Тип проверки подлинности OnPremise
Федеративный
Сертификат
Федеративный Федеративный
EnrollmentPolicyServiceURL Необязательно (все проверки подлинности) Необязательно (все проверки подлинности) Необязательно (все проверки подлинности)
EnrollmentServiceURL Обязательный (все проверки подлинности) Используется (все проверки подлинности) Используется (все проверки подлинности)
EnrollmentServiceURL включает версию ОС, платформу ОС и другие атрибуты, предоставляемые URL-адресом обнаружения MDM. Настоятельно рекомендуется Настоятельно рекомендуется Настоятельно рекомендуется
Используется AuthenticationServiceURL Используется (федеративная проверка подлинности) Пропущен Пропущен
BinarySecurityToken Пользовательская на MDM Выданный токен идентификатора Microsoft Entra Выданный токен идентификатора Microsoft Entra
EnrollmentType Полный Устройство Полный
Тип зарегистрированного сертификата Сертификат пользователя Сертификат устройства Сертификат пользователя
Зарегистрированное хранилище сертификатов My/User My/System My/User
Имя субъекта CSR Имя участника-пользователя Идентификатор устройства Имя участника-пользователя
EnrollmentData Terms of Use binary blob as AdditionalContext for EnrollmentServiceURL Не поддерживается. Поддерживается Поддерживается
Поставщики служб конфигурации, доступные во время регистрации Поддержка Windows 10:
— DMClient
— CertificateStore
— RootCATrustedCertificates
— ClientCertificateInstall
— EnterpriseModernAppManagement
- PassportForWork
-Политика
— w7 APPLICATION

Протокол управления с идентификатором 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 для отчета о состоянии соответствия управляемого устройства.

Примечание.

Этот API применим только для утвержденных приложений MDM на устройствах Windows.

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.

отмена регистрации aadj.

Коды ошибок

Код 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}ошибки .