Поддержка протокола OMA DM

• Применяется к:

  ✅ Windows 11, ✅ Windows 10

Клиент OMA DM взаимодействует с сервером по протоколу HTTPS и использует синхронизацию DM (OMA DM версии 1.2) в качестве полезных данных сообщения. В этой статье описаны функциональные возможности OMA DM, поддерживаемые клиентом DM в целом. Полное описание протокола OMA DM версии 1.2 можно найти на веб-сайте OMA.

Стандарты OMA DM

В следующей таблице показаны стандарты OMA DM, которые используются в Windows.

Общая область	Поддерживаемый стандарт OMA DM
Передача данных и сеанс	Инициированный клиентом удаленный сеанс HTTPS DM по протоколу TLS/SSL. Удаленный сеанс HTTPS DM по протоколу TLS/SSL. Уведомление об инициировании удаленного сервера DM с помощью службы отправки коротких сообщений (SMS) WAP. Не используется управлением предприятия. Удаленная начальная загрузка с помощью WAP Push over SMS. Не используется управлением предприятия.
XML-код начальной загрузки	XML-файл подготовки клиента OMA.
Команды протокола DM	В следующем списке показаны команды, используемые устройством. Дополнительные сведения об элементах команд OMA DM см. на веб-сайте OMA. Добавить (поддерживается неявное добавление) Оповещение (оповещение DM). Универсальное оповещение (1226) используется клиентом управления предприятием, когда пользователь активирует действие отмены регистрации MDM с устройства или когда CSP завершает некоторые асинхронные действия. Оповещение устройства (1224) используется для уведомления сервера о событии, активировавшем устройство. Атомарный. Выполнение команды Добавить с последующей заменой на том же узле в атомарном элементе не поддерживается. Вложенные команды Atomic и Get не допускаются и создают код ошибки 500. Удалить. Удаляет узел из дерева dm и все поддерево под этим узлом, если оно существует. Exec: вызывает исполняемый файл на клиентском устройстве. Получение: извлекает данные с клиентского устройства; для внутренних узлов имена дочерних узлов в элементе Data возвращаются в формате, закодированном URI. Заменить: перезаписывает данные на клиентском устройстве Результат. Возвращает результаты данных команды Get на сервер DM. Последовательность: указывает порядок обработки группы команд. Состояние: указывает состояние завершения (успешно или неудачно) операции. Если XML-элемент, который не является допустимой командой OMA DM, находится в одном из следующих элементов, для этого элемента возвращается код состояния 400: SyncBody Атомной Последовательности Если cmdID не указан в команде DM, клиент возвращает пустое значение в элементе status и коде состояния 400. Если элементы Atomic вложены, возвращаются следующие коды состояния: Вложенная команда Atomic возвращает значение 500. Родительская команда Atomic возвращает значение 507. Дополнительные сведения о команде Atomic см. в разделе Общие элементы протокола OMA DM. Выполнение команды Добавить, за которой следует заменить на том же узле в элементе Atomic, не поддерживается. LocURI не может начинаться с /. Мета-XML-тег в SyncHdr игнорируется устройством.
Стандартные объекты OMA DM	DevInfo DevDetail Объекты учетной записи DMS OMA DM (OMA DM версии 1.2)
Безопасность	SMS-сообщение об уведомлении о начале аутентификации сервера DM (не используется управлением предприятия) Проверка подлинности клиента MD5 на уровне приложений уровня "Базовый" и проверки подлинности клиента MD5 Проверка подлинности сервера с помощью учетных данных MD5 на уровне приложения Целостность данных и проверка подлинности с помощью HMAC на уровне приложения Проверка подлинности, шифрование и целостность данных на основе сертификатов tls/SSL на основе клиента или сервера проверка
Узлов	В дереве OMA DM для имени узла применяются следующие правила: "." может быть частью имени узла. Имя узла не может быть пустым. Имя узла не может быть только символом звездочки (*).
Файлы подготовки	Xml-код подготовки должен быть правильно сформирован и соответствовать определению в протоколе представления SyncML. Если XML-элемент, который не является допустимой командой OMA DM, находится в разделе SyncBody, для этого элемента возвращается код состояния 400. Примечание Чтобы представить строку Юникода в виде URI, сначала закодируйте строку как UTF-8. Затем закодируйте каждый из байтов UTF-8 с помощью кодировки URI.
Поддержка WBXML	Windows поддерживает отправку и получение SyncML как в формате XML, так и в закодированном формате WBXML. Эту двухформатную поддержку можно настроить с помощью узла DEFAULTENCODING в характеристике приложения w7 во время регистрации. Дополнительные сведения о кодировке WBXML см. в разделе 8 спецификации протокола представления SyncML .
Обработка больших объектов	В Windows 10 добавлена поддержка клиентом отправки больших объектов на сервер.

Общие элементы протокола OMA DM

Общие элементы используются другими типами элементов DM OMA. В следующей таблице перечислены общие элементы OMA DM, используемые для настройки устройств. Дополнительные сведения об общих элементах OMA DM см. в разделе Использование протокола представления SyncML Управление устройствами (OMA-SyncML-DMRepPro-V1_1_2-20030613-A), доступном на веб-сайте OMA.

Элемент	Описание
Чал	Указывает запрос проверки подлинности. Сервер или клиент может отправить запрос другому, если в исходном сообщении запроса не были предоставлены учетные данные или неадекватные учетные данные.
Cmd	Указывает имя команды OMA DM, на которое ссылается элемент Status.
CmdID	Задает уникальный идентификатор для команды OMA DM.
CmdRef	Указывает идентификатор команды, для которой возвращаются сведения о состоянии или результатах. Этот элемент принимает значение элемента CmdID соответствующего сообщения запроса.
Cred	Указывает учетные данные проверки подлинности для инициатора сообщения.
Окончательный	Указывает, что текущее сообщение является последним сообщением в пакете.
LocName	Указывает отображаемое имя в элементах Target и Source, используемых для отправки идентификатора пользователя для проверки подлинности MD5.
LocURI	Указывает адрес целевого или исходного расположения. Если адрес содержит небуквенно-цифровой символ, его необходимо правильно экранировать в соответствии со стандартом кодирования URL-адресов.
MsgID	Задает уникальный идентификатор для сообщения сеанса OMA DM.
MsgRef	Указывает идентификатор соответствующего сообщения запроса. Этот элемент принимает значение элемента MsgID сообщения запроса.
RespURI	Указывает универсальный код ресурса (URI), который получатель должен использовать при отправке ответа на это сообщение.
Sessionid	Указывает идентификатор сеанса OMA DM, связанного с содержащим сообщением. Если сервер не уведомляет устройство о том, что оно поддерживает новую версию (через узел SyncApplicationVersion в dmClient CSP), клиент возвращает SessionID в целочисленном формате в десятичном формате. Если сервер поддерживает синхронизацию сеансов DM версии 2.0, которая используется в Windows, клиент устройства возвращает 2 байта.
Источник	Указывает адрес источника сообщения.
SourceRef	Указывает источник соответствующего сообщения запроса. Этот элемент принимает значение элемента Source сообщения запроса и возвращается в элементе Status или Results.
Target	Указывает адрес узла в дереве DM, который является целевым объектом команды OMA DM.
TargetRef	Указывает целевой адрес в соответствующем сообщении запроса. Этот элемент принимает значение элемента target сообщения запроса и возвращается в элементе Status или Results.
VerDTD	Указывает основной и дополнительный идентификаторы версий спецификации протокола представления OMA DM, используемого для представления сообщения.
VerProto	Указывает основной и дополнительный идентификаторы версий спецификации протокола OMA DM, используемой с сообщением.

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

Сеанс Управление устройствами (DM) состоит из ряда команд, обменивается между сервером dm и клиентским устройством. Сервер отправляет команды, указывающие на операции, которые необходимо выполнить в дереве управления клиентского устройства. Клиент отвечает, отправляя команды, содержащие результаты и все запрошенные сведения о состоянии.

Короткий сеанс интеллектуальной работы можно свести к следующим значениям:

Сервер отправляет команду Get клиентскому устройству для получения содержимого одного из узлов дерева управления. Устройство выполняет операцию и отвечает командой Result, содержащей запрошенное содержимое.

Сеанс dm можно разделить на два этапа:

1. Этап установки. В ответ на событие триггера клиентское устройство отправляет инициирующее сообщение на сервер DM. Для обмена данными об устройстве и сервере требуется проверка подлинности и сведения об устройстве. Этот этап представлен шагами 1, 2 и 3.
2. Этап управления: сервер dm находится под контролем. Он отправляет на устройство команды управления, и устройство отвечает. Этап 2 завершается, когда сервер dm server прекращает отправку команд и завершает сеанс. Этот этап представлен шагами 3, 4 и 5.

В следующих сведениях показана последовательность событий во время типичного сеанса dm.

1. Клиент DM вызывается для обратного вызова сервера управления
   
   Корпоративный сценарий. Расписание задач устройства вызывает клиент dm.

   Mo-сервер отправляет сообщение триггера сервера для вызова клиента dm.

   Сообщение триггера содержит идентификатор сервера и сообщает клиентскому устройству, что нужно инициировать сеанс с сервером. Клиентское устройство выполняет проверку подлинности сообщения триггера и проверяет, имеет ли сервер право взаимодействовать с ним.
   
   Корпоративный сценарий. В запланированное время клиент DM периодически вызывается для обратного вызова сервера управления предприятия по протоколу HTTPS.

2. Устройство отправляет сообщение через IP-подключение для запуска сеанса.

   Это сообщение содержит сведения об устройстве и учетные данные. Клиент и сервер выполняют взаимную проверку подлинности через канал TLS/SSL или на уровне приложения dm.

3. Сервер интеллектуальной службы отвечает через IP-подключение (HTTPS). Сервер отправляет начальные команды управления устройствами, если таковые есть.

4. Устройство реагирует на команды управления сервером. Это сообщение содержит результаты выполнения указанных операций управления устройствами.

5. Сервер интеллектуальной службы завершает сеанс или отправляет другую команду. Сеанс интеллектуальной службы завершается или повторяется шаг 4.

Номера шагов не представляют идентификационные номера сообщений (MsgID). Все сообщения с сервера должны иметь уникальный идентификатор MsgID в рамках сеанса, начиная с 1 для первого сообщения и увеличиваясь на 1 для каждого дополнительного сообщения. Дополнительные сведения о протоколе MsgID и OMA SyncML см. в разделе Протокол представления Управление устройствами OMA (DM_RepPro-V1_2-20070209-A).

При взаимной проверке подлинности на уровне приложения OMA DM, если код ответа устройства на элемент Cred в серверном запросе равен 212, дальнейшая проверка подлинности не требуется для оставшейся части сеанса интеллектуальной проверки подлинности. Если выполняется проверка подлинности MD5, Chal можно вернуть элемент . Затем при запуске следующего сеанса интеллектуальной разработки для дайджеста MD5 необходимо использовать следующий параметр nonce in Chal .

Если запрос содержит учетные данные, а код ответа на запрос равен 200, эти же учетные данные должны быть отправлены в следующем запросе. Chal Если элемент включен и требуется проверка подлинности MD5, создается новый дайджест с помощью следующего nonce через элемент для следующего Chal запроса.

Дополнительные сведения о проверке подлинности клиента Basic или MD5, проверке подлинности сервера MD5, хэсе MD5 и MD5 nonce см. в спецификации безопасности Управление устройствами OMA-TS-DM_Security-V1_2_1-20080617-A), обработке кода ответа проверки подлинности и пошаговые примеры в OMA Управление устройствами Спецификация протокола (OMA-TS-DM_Protocol-V1_2_1-20080617-A), доступная на веб-сайте OMA.

Целевая конфигурация для пользователей и устройств

Для поставщиков служб конфигурации и политик, поддерживающих конфигурацию каждого пользователя, сервер MDM может отправлять целевые значения параметров пользователя на устройство, на которое активно входит зарегистрированный в MDM пользователь. Устройство уведомляет сервер о состоянии входа с помощью оповещения устройства (1224) с типом оповещения = в DM pkg#1.

Часть данных этого оповещения может быть одной из следующих строк:

• Пользователь: пользователь, зарегистрировав устройство, активно вошел в систему. Сервер MDM может отправлять конфигурацию для конкретных пользователей для поставщиков служб или политик, поддерживающих конфигурацию каждого пользователя.
• Другие: вход другого пользователя, но у него нет учетной записи MDM. Сервер может применять только конфигурацию на уровне устройства, например, конфигурация применяется ко всем пользователям на устройстве.
• Нет: активный вход пользователя отсутствует. Сервер может применять только конфигурацию на уровне устройства, а доступная конфигурация ограничена средой устройства (без активного входа пользователя).

Ниже приведен пример оповещения.

<Alert>
    <CmdID>1</CmdID>
    <Data>1224</Data>
    <Item>
        <Meta>
            <Type xmlns="syncml:metinf">com.microsoft/MDM/LoginStatus</Type>
            <Format xmlns="syncml:metinf">chr</Format>
        </Meta>
        <Data>user</Data>
    </Item>
</Alert>

Сервер уведомляет устройство о том, является ли оно конфигурацией, ориентированной на пользователя или устройством, с помощью префикса LocURL узла управления, с ./user для конфигурации, ориентированной на пользователей, или ./device для конфигурации, ориентированной на устройство. По умолчанию, если нет префикса с ./device или ./user, это конфигурация, предназначенная для устройства.

В следующем LocURL показана конфигурация узла CSP для каждого пользователя: ./user/vendor/MSFT/EnterpriseModernAppManagement/AppInstallation/<PackageFamilyName>/StoreInstall

В следующем LocURL показана конфигурация узла CSP для каждого устройства: ./device/vendor/MSFT/RemoteWipe/DoWipe

Коды состояния ответов SyncML

При использовании SyncML в OMA DM возвращаются стандартные коды состояния ответа. В следующей таблице перечислены распространенные коды состояния ответов SyncML, которые вы, вероятно, увидите. Дополнительные сведения о кодах состояния ответов SyncML см. в разделе 10 спецификации протокола представления SyncML .

Код состояния	Описание
200	Команда SyncML успешно завершена.
202	Принято к обработке. Этот код обозначает асинхронную операцию, например запрос на выполнение удаленного выполнения приложения.
212	Проверка подлинности принята. Обычно этот код отображается только в ответ на элемент SyncHdr (используется для проверки подлинности в стандарте OMA-DM). Вы можете увидеть этот код, если посмотрите на журналы dm OMA, но поставщики служб конфигурации обычно не создают этот код.
214	Операция отменена. Команда SyncML успешно завершена, но больше команды не обрабатываются в сеансе.
215	Не выполняется. Команда не была выполнена в результате взаимодействия с пользователем для отмены команды.
216	Atomic откат ОК. Команда находилась внутри Atomic элемента и Atomic завершилась сбоем. Эта команда успешно выполнена.
400	Неправильный запрос. Не удалось выполнить запрошенную команду из-за неправильного синтаксиса. Поставщики служб конфигурации обычно не создают эту ошибку, однако вы можете увидеть ее, если ваш SyncML имеет неправильный формат.
401	Недопустимые учетные данные. Сбой запрошенной команды, так как инициатор запроса должен обеспечить правильную проверку подлинности. Поставщики служб конфигурации обычно не создают эту ошибку.
403	Запрещено. Запрошенная команда завершилась ошибкой, но получатель понял запрошенную команду.
404	Не найдено. Запрошенный целевой объект не найден. Этот код создается, если вы запрашиваете узел, который не существует.
405	Команда не разрешена. Этот код ответа создается при попытке записи на узел, доступный только для чтения.
406	Необязательная функция не поддерживается. Этот код ответа создается при попытке получить доступ к свойству, которое не поддерживает поставщик служб CSP.
415	Неподдерживаемый тип или формат. Этот код ответа может быть результатом ошибок синтаксического анализа или форматирования XML.
418	Уже существует. Этот код ответа возникает при попытке добавить узел, который уже существует.
425	Отказано в разрешении. Запрошенная команда завершилась ошибкой, так как у отправителя нет достаточных разрешений на управление доступом (ACL) для получателя. Ошибки "Доступ запрещен" обычно переводятся в этот код ответа.
500	Сбой команды. Универсальный сбой. Получатель столкнулся с непредвиденным условием, которое помешало ему выполнить запрос. Этот код ответа возникает, когда DPU SyncML не может сопоставить исходный код ошибки.
507	Atomic Сбой при. Сбой одной из операций в блоке Atomic .
516	Atomic Сбой отката. Операция Atomic завершилась сбоем, и команда не была успешно выполнена.

Связанные статьи

Справочник по поставщикам служб конфигурации