Интеграция Azure Active Directory с помощью MDM

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

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

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

Для поддержки этих широких возможностей с помощью своего продукта MDM поставщики MDM могут интегрироваться с Azure AD. В этой статье описаны необходимые действия.

Подключение к Azure AD

Несколько способов подключения устройств:

Для корпоративных устройств:

  • Присоединение Windows к традиционному домену Active Directory
  • Присоединение Windows к Azure AD

Для личных устройств (BYOD):

  • Добавление рабочей учетной записи Майкрософт в Windows

Присоединение к Azure AD

Устройства, принадлежащие компании, традиционно присоединяются к локальная служба Active Directory домену организации. Этими устройствами можно управлять с помощью групповая политика или программного обеспечения для управления компьютером, например Майкрософт Configuration Manager. В Windows 10 также можно управлять присоединенными к домену устройствами с помощью MDM.

Windows 10 представляет новый способ настройки и развертывания устройств Windows, принадлежащих организации. Этот механизм называется Azure AD join. Как и традиционное присоединение к домену, Azure AD join позволяет устройствам стать известными и управляемыми организацией. Однако при Azure AD присоединении Windows выполняет проверку подлинности для Azure AD вместо проверки подлинности на контроллере домена.

Azure AD Присоединение также позволяет автоматически регистрировать устройства компании и управлять ими с помощью MDM. Кроме того, Azure AD join можно выполнить на купленных в магазине компьютерах в режиме запуска (OOBE), что помогает организациям оптимизировать развертывание устройств. Администратор может потребовать, чтобы пользователи, принадлежащие к одной или нескольким группам, регистрили свои устройства для управления с помощью MDM. Если пользователь настроен на требование автоматической регистрации во время Azure AD присоединения, эта регистрация становится обязательным шагом для настройки Windows. Если регистрация MDM завершается сбоем, устройство не будет присоединено к Azure AD.

Важно.

Каждому пользователю, включенной для автоматической регистрации MDM в Azure AD Join, должна быть назначена действительная лицензия Azure Active Directory Premium.

Сценарий BYOD

Windows 10 также представляет более простой способ настройки личных устройств для доступа к рабочим приложениям и ресурсам. Пользователи могут добавить свою рабочую учетную запись Майкрософт в Windows и получить более простой и безопасный доступ к приложениям и ресурсам организации. Во время этого процесса Azure AD определяет, настроила ли организация MDM. В этом случае Windows пытается зарегистрировать устройство в MDM в рамках потока "добавление учетной записи". В случае BYOD пользователи могут отклонить условия использования MDM. Устройство не зарегистрировано в MDM, и доступ к ресурсам организации обычно ограничен.

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

Два Azure AD сценариях регистрации MDM:

  • Присоединение устройства к Azure AD для устройств, принадлежащих компании
  • Добавление рабочей учетной записи на личное устройство (BYOD)

В обоих сценариях Azure AD проверяет подлинность пользователя и устройства. Он предоставляет проверенный уникальный идентификатор устройства, который можно использовать для регистрации MDM.

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

В встроенном сценарии веб-представление является 100 % полноэкранным, что дает поставщику MDM возможность рисовать интерфейс от края до края. С великой силой приходит большая ответственность! Важно, чтобы поставщики MDM, которые интегрируются с Azure AD соблюдали рекомендации по проектированию Windows. Этот шаг включает использование адаптивного веб-дизайна и соблюдение рекомендаций по специальным возможностям Windows. Например, включите кнопки вперед и назад, которые правильно подключены к логике навигации. Дополнительные сведения см. далее в этой статье.

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

Когда у пользователя есть учетная запись Azure AD, добавленная в Windows и зарегистрированная в MDM, регистрация может управляться с помощью параметра Учетные>записи Рабочий>доступ. Управление устройствами Azure AD присоединение для сценариев организации или BYOD аналогично.

Примечание.

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

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

Azure AD регистрация MDM состоит из двух этапов:

  1. Отображение условий использования и получение согласия пользователя.

    Это согласие является пассивным потоком, в котором пользователь перенаправляется в элементе управления браузера (webview) на URL-адрес Условий использования MDM.

  2. Зарегистрируйте устройство.

    Этот шаг является активным потоком, в котором агент Windows OMA DM вызывает службу MDM для регистрации устройства.

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

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

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

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

Конечная точка регистрации MDM После того как пользователи примут условия использования, устройство регистрируется в Azure AD. Начинается автоматическая регистрация MDM.

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

поток регистрации azure ad.

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

Сделайте MDM надежной стороной Azure AD

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

Добавление облачной MDM

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

Поставщик MDM должен сначала зарегистрировать приложение в своем домашнем клиенте и пометить его как мультитенантное приложение. Ниже приведен пример кода из GitHub, в который показано, как добавить мультитенантные приложения в Azure AD WepApp-WebAPI-MultiTenant-OpenIdConnect-DotNet.

Примечание.

Если у поставщика MDM нет существующего клиента Azure AD с управляемой подпиской на Azure AD, выполните пошаговые инструкции в статье Добавление клиента Azure AD и Azure AD подписки, чтобы настроить клиент, добавить подписку и управлять ею с помощью портала Azure.

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

Примечание.

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

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

  1. Войдите на портал управления Azure с помощью учетной записи администратора в домашнем клиенте.

  2. В области навигации слева выберите Active Directory.

  3. Выберите клиент каталога, в котором требуется зарегистрировать приложение.

    Убедитесь, что вы вошли в домашний клиент.

  4. Перейдите на вкладку Приложения .

  5. В ящике нажмите кнопку Добавить.

  6. Выберите Добавить приложение, разрабатываемое моей организацией.

  7. Введите понятное имя приложения, например ContosoMDM, выберите Веб-приложение и или Веб-API, а затем нажмите кнопку Далее.

  8. Введите URL-адрес входа для службы MDM.

  9. В поле Идентификатор приложения введите https://<your_tenant_name>/ContosoMDM, а затем нажмите кнопку ОК.

  10. Оставаясь в портал Azure, выберите вкладку Настройка приложения.

  11. Пометьте приложение как мультитенантное.

  12. Найдите значение идентификатора клиента и скопируйте его.

    Этот идентификатор понадобится позже при настройке приложения. Этот идентификатор клиента используется при получении маркеров доступа и добавлении приложений в коллекцию приложений Azure AD.

  13. Создайте ключ для приложения и скопируйте его.

    Этот ключ необходим для вызова Майкрософт API Graph, чтобы сообщить о соответствии устройств. Эти сведения рассматриваются в следующем разделе.

Дополнительные сведения о регистрации примера приложения с помощью Azure AD см. в разделе Действия по регистрации веб-API TodoListService в NativeClient-DotNet.

Добавление локальной mdm

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

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

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

Дополнительные сведения о регистрации приложений с помощью Azure AD см. в статье Основные сведения о регистрации приложения в Azure AD.

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

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

Рекомендации по обеспечению безопасности см. в статье Основные сведения о безопасности Windows Azure.

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

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

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

На следующем рисунке показано, как приложения MDM отображаются в коллекции приложений Azure.

Azure AD добавляет приложение для mdm.

Примечание.

Если ваше приложение MDM является облачным и должно быть включено как мультитенантное приложение MDM, обратитесь к группе разработчиков Azure AD.

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

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

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

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

Темы

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

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

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

Эти сценарии поддерживают windows Client Pro, Enterprise и Education.

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

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

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

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

CXH-HOST (ЗАГОЛОВОК HTTP) Сценарий Фоновая тема Winjs CSS сценария
FRX OOBE Темная тема + синий цвет фона Имя файла: Ui-dark.css Имя файла: oobe-dekstop.css
МОСЕТ Параметры/после запуска при первом включении Светлая тема Имя файла: Ui-light.css Имя файла: settings-desktop.css

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

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

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

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

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

Элемент Описание
redirect_uri После того как пользователь примет или отклонит условия использования, пользователь перенаправляется на этот URL-адрес.
client-request-id GUID, используемый для корреляции журналов в целях диагностики и отладки. Используйте этот параметр для регистрации или трассировки состояния запроса на регистрацию, чтобы помочь найти основную причину сбоев.
версия api Указывает версию протокола, запрошенную клиентом. Это значение предоставляет механизм для поддержки версий протокола.
mode Указывает, что устройство принадлежит организации, если mode=azureadjoin. Этот параметр отсутствует для устройств BYOD.

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

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

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

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

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

Примечание.

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

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

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

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 — этот параметр не будет использоваться. Регистрация останавливается с сообщением об ошибке, отображаемом пользователю.

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

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

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

Если во время обработки условий использования возникает ошибка, MDM может вернуть два параметра : ошибку и error_description параметр в запросе перенаправления обратно в Windows. URL-адрес должен быть закодирован, а содержимое 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 несанкционированный пользователь или клиент
Сбой проверки маркера Azure AD 302 unauthorized_client unauthorized_client
внутренняя ошибка службы 302 server_error внутренняя ошибка службы

Протокол регистрации с Azure AD

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

Детали Традиционная регистрация MDM присоединение к Azure AD (устройство, принадлежающее организации) Azure AD добавляет рабочую учетную запись (устройство, принадлежающее пользователю)
Автоматическое обнаружение MDM с помощью адреса электронной почты для получения URL-адреса обнаружения MDM регистрация; Неприменимо
URL-адрес обнаружения, подготовленный в Azure
Использует URL-адрес обнаружения MDM регистрация;
Продление регистрации
РОБО
регистрация;
Продление регистрации
РОБО
регистрация;
Продление регистрации
РОБО
Требуется ли регистрация MDM? Да Да Нет
Пользователь может отклонить.
Тип проверки подлинности OnPremise
Федеративного
Сертификат
Федеративного Федеративного
EnrollmentPolicyServiceURL Необязательно (все проверки подлинности) Необязательно (все проверки подлинности) Необязательно (все проверки подлинности)
EnrollmentServiceURL Обязательный (все проверки подлинности) Используется (все проверки подлинности) Используется (все проверки подлинности)
EnrollmentServiceURL включает версию ОС, платформу ОС и другие атрибуты, предоставляемые URL-адресом обнаружения MDM. Настоятельно рекомендуется Настоятельно рекомендуется Настоятельно рекомендуется
Используется AuthenticationServiceURL Используется (федеративная проверка подлинности) Пропущен Пропущен
BinarySecurityToken Пользовательская на MDM Azure AD выданный токен Azure AD выданный токен
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

Протокол управления с Azure AD

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

Управление несколькими пользователями для устройств, присоединенных к Azure AD. В этом сценарии регистрация MDM применяется к каждому пользователю Azure AD, который входит в устройство, присоединенное к Azure AD. Этот тип регистрации называется регистрацией устройства или многопользовательской регистрацией. Сервер управления может определить удостоверение пользователя, определить, какие политики предназначены для этого пользователя, и отправить соответствующие политики на устройство. Чтобы разрешить серверу управления идентифицировать текущего пользователя, вошедшего в систему на устройстве, клиент OMA DM использует маркеры пользователя Azure AD. Каждый сеанс управления содержит дополнительный заголовок HTTP, содержащий маркер пользователя Azure AD. Эти сведения предоставляются в пакете dm, отправляемом на сервер управления. Однако в некоторых случаях Azure AD маркер пользователя не отправляется на сервер управления. Один из таких сценариев происходит сразу после завершения регистрации MDM во время Azure AD процесса присоединения. Пока Azure AD процесс присоединения не будет завершен и Azure AD пользователь не войдет на компьютер, Azure AD маркер пользователя не будет доступен для процесса OMA-DM. Как правило, регистрация MDM завершается до Azure AD входа пользователя на компьютер, а начальный сеанс управления не содержит маркер пользователя Azure AD. Сервер управления должен проверить, отсутствует ли маркер, и отправлять политики устройств только в этом случае. Другой возможной причиной отсутствия маркера Azure AD в полезных данных OMA-DM является вход гостевого пользователя на устройство.

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

Оценка маркеров пользователей Azure AD. Маркер Azure AD находится в заголовке HTTP Authorization в следующем формате:

Authorization:Bearer <Azure AD User Token Inserted here>

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

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

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

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

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

Оповещение отправляется при запуске сеанса интеллектуального анализа данных и Azure AD пользователь вошел в систему. Оповещение отправляется в OMA DM pkg#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>

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

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

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

Сообщить о соответствии устройств Azure AD

После регистрации устройства в MDM для управления на нем применяются политики организации, настроенные ИТ-администратором. Соответствие устройства настроенным политикам оценивается MDM, а затем сообщается Azure AD. В этом разделе рассматривается API Graph вызов, который можно использовать для отправки Azure AD сведений о состоянии соответствия устройств.

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

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

Использование Майкрософт API Graph

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

Примечание.

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

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

Ответ:

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

Потеря данных во время отмены регистрации из присоединения к Azure Active Directory

Когда пользователь регистрируется в MDM через присоединение к Azure Active Directory, а затем отключает регистрацию, нет никаких предупреждений о том, что пользователь потеряет данные 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}ошибки .