Compatibilidad con el protocolo OMA DM

• Se aplica a:

  ✅ Windows 11, ✅ Windows 10

El cliente OMA DM se comunica con el servidor a través de HTTPS y usa DM Sync (OMA DM v1.2) como carga útil del mensaje. En este artículo se describe la funcionalidad de OMA DM que admite el cliente dm en general. La descripción completa del protocolo OMA DM v1.2 se puede encontrar en el sitio web de OMA.

Estándares de OMA DM

En la tabla siguiente se muestran los estándares de OMA DM que usa Windows.

Área general	Estándar de OMA DM compatible
Transporte de datos y sesión	Sesión remota HTTPS DM iniciada por el cliente a través de TLS/SSL. Sesión remota de HTTPS DM a través de TLS/SSL. Notificación de inicio del servidor DM remoto mediante WAP Push over Short Message Service (SMS). No lo usa la administración empresarial. Arranque remoto mediante WAP Push over SMS. No lo usa la administración empresarial.
XML de arranque	XML de aprovisionamiento de cliente OMA.
Comandos del protocolo DM	En la lista siguiente se muestran los comandos que usa el dispositivo. Para obtener más información sobre los elementos de comando de OMA DM, consulte "sitio web de OMA" disponible en el sitio web de OMA. Agregar (se admite agregar implícitamente) Alerta (alerta dm): el cliente de administración empresarial usa la alerta genérica (1226) cuando el usuario desencadena una acción de anulación de la inscripción de MDM desde el dispositivo o cuando un CSP finaliza algunas acciones asincrónicas. La alerta de dispositivo (1224) se usa para notificar al servidor algún evento desencadenado por el dispositivo. Atomic: no se admite la realización de un comando Add seguido de Replace en el mismo nodo dentro de un elemento atómico. No se permiten los comandos Atomic y Get anidados y generan el código de error 500. Eliminar: quita un nodo del árbol dm y todo el subárbol debajo de ese nodo si existe uno. Exec: invoca un archivo ejecutable en el dispositivo cliente Obtener: recupera datos del dispositivo cliente; para los nodos interiores, los nombres de nodo secundarios del elemento Data se devuelven en formato codificado mediante URI. Reemplazar: sobrescribe datos en el dispositivo cliente Resultado: devuelve los resultados de los datos de un comando Get al servidor DM. Secuencia: especifica el orden en el que se debe procesar un grupo de comandos. Estado: indica el estado de finalización (correcto o error) de una operación Si un elemento XML que no es un comando OMA DM válido está bajo uno de los siguientes elementos, se devuelve el código de estado 400 para ese elemento: SyncBody Atómica Secuencia Si no se proporciona ningún CmdID en el comando DM, el cliente devuelve en blanco en el elemento status y el código de estado 400. Si los elementos Atomic están anidados, se devuelven los siguientes códigos de estado: El comando atomic anidado devuelve 500. El comando atomic primario devuelve 507. Para obtener más información sobre el comando Atomic, vea Elementos comunes del protocolo OMA DM. No se admite la realización de un comando Add seguido de Replace en el mismo nodo dentro de un elemento Atomic. LocURI no puede empezar por /. El dispositivo omite la etiqueta Meta XML en SyncHdr.
Objetos estándar de OMA DM	DevInfo DevDetail Objetos de cuenta de OMA DM DMS (OMA DM versión 1.2)
Seguridad	Autenticación del mensaje SMS de notificación de inicio de servidor DM (no utilizado por la administración empresarial) Autenticación básica y de cliente MD5 de la capa de aplicación Autenticación del servidor con credenciales MD5 en el nivel de aplicación Integridad y autenticación de datos con HMAC en el nivel de aplicación Comprobación de la integridad de datos, el cifrado y la autenticación de cliente/servidor basada en certificados TLS/SSL
Nodos	En el árbol OMA DM, se aplican las reglas siguientes para el nombre del nodo: "." puede formar parte del nombre del nodo. El nombre del nodo no puede estar vacío. El nombre del nodo no puede ser solo el carácter de asterisco (*).
Aprovisionamiento de archivos	El aprovisionamiento de XML debe estar bien formado y seguir la definición del protocolo de representación SyncML. Si un elemento XML que no es un comando OMA DM válido está en SyncBody, se devuelve el código de estado 400 para ese elemento. Nota Para representar una cadena Unicode como un URI, primero codifique la cadena como UTF-8. A continuación, codifique cada uno de los bytes UTF-8 mediante la codificación URI.
Compatibilidad con WBXML	Windows admite el envío y la recepción de SyncML en formato XML y en formato WBXML codificado. Esta compatibilidad con formato dual se puede configurar mediante el nodo DEFAULTENCODING en la característica de aplicación w7 durante la inscripción. Para obtener más información sobre la codificación WBXML, consulte la sección 8 de la especificación del protocolo de representación SyncML .
Control de objetos grandes	En Windows 10, se agregó compatibilidad con el cliente para cargar objetos grandes en el servidor.

Elementos comunes del protocolo OMA DM

Otros tipos de elementos OMA DM usan elementos comunes. En la tabla siguiente se enumeran los elementos comunes de OMA DM que se usan para configurar los dispositivos. Para obtener más información sobre los elementos comunes de OMA DM, vea "SyncML Representation Protocol Administración de dispositivos Usage" (OMA-SyncML-DMRepPro-V1_1_2-20030613-A) disponible en el sitio web de OMA.

Elemento	Descripción
Chal	Especifica un desafío de autenticación. El servidor o el cliente pueden enviar un desafío al otro si no se han proporcionado credenciales o credenciales inadecuadas en el mensaje de solicitud original.
Cmd	Especifica el nombre de un comando OMA DM al que se hace referencia en un elemento Status.
CmdID	Especifica el identificador único de un comando OMA DM.
CmdRef	Especifica el identificador del comando para el que se devuelve información de estado o resultados. Este elemento toma el valor del elemento CmdID del mensaje de solicitud correspondiente.
Cred	Especifica la credencial de autenticación para el originador del mensaje.
Final	Indica que el mensaje actual es el último mensaje del paquete.
LocName	Especifica el nombre para mostrar en los elementos Target y Source, que se usan para enviar un identificador de usuario para la autenticación MD5.
LocURI	Especifica la dirección de la ubicación de destino o de origen. Si la dirección contiene un carácter no alfanumérico, debe tener un escape adecuado según el estándar de codificación de direcciones URL.
Msgid	Especifica un identificador único para un mensaje de sesión de OMA DM.
MsgRef	Especifica el identificador del mensaje de solicitud correspondiente. Este elemento toma el valor del elemento MsgID del mensaje de solicitud.
RespURI	Especifica el URI que el destinatario debe usar al enviar una respuesta a este mensaje.
SessionID	Especifica el identificador de la sesión de OMA DM asociada al mensaje contenedor. Si el servidor no notifica al dispositivo que admite una nueva versión (a través del nodo SyncApplicationVersion en el CSP DMClient), el cliente devuelve sessionID en entero en formato decimal. Si el servidor admite dm session sync versión 2.0, que se usa en Windows, el cliente del dispositivo devuelve 2 bytes.
Source	Especifica la dirección de origen del mensaje.
SourceRef	Especifica el origen del mensaje de solicitud correspondiente. Este elemento toma el valor del elemento Source del mensaje de solicitud y se devuelve en el elemento Status o Results.
Target	Especifica la dirección del nodo en el árbol DM que es el destino del comando OMA DM.
TargetRef	Especifica la dirección de destino en el mensaje de solicitud correspondiente. Este elemento toma el valor del elemento Target del mensaje de solicitud y se devuelve en el elemento Status o Results.
VerDTD	Especifica el identificador de versión principal y secundaria de la especificación del protocolo de representación OMA DM que se usa para representar el mensaje.
VerProto	Especifica el identificador de versión principal y secundaria de la especificación del protocolo OMA DM que se usa con el mensaje.

Sesión de administración de dispositivos

Una sesión de Administración de dispositivos (DM) consta de una serie de comandos intercambiados entre un servidor DM y un dispositivo cliente. El servidor envía comandos que indican las operaciones que se deben realizar en el árbol de administración del dispositivo cliente. El cliente responde enviando comandos que contienen los resultados y cualquier información de estado solicitada.

Una sesión de DM corta se puede resumir como:

Un servidor envía un comando Get a un dispositivo cliente para recuperar el contenido de uno de los nodos del árbol de administración. El dispositivo realiza la operación y responde con un comando Result que contiene el contenido solicitado.

Una sesión dm se puede dividir en dos fases:

1. Fase de instalación: en respuesta a un evento de desencadenador, un dispositivo cliente envía un mensaje de inicio a un servidor DM. El intercambio de dispositivos y servidores necesitaba autenticación e información del dispositivo. Esta fase se representa mediante los pasos 1, 2 y 3.
2. Fase de administración: el servidor DM está en control. Envía comandos de administración al dispositivo y el dispositivo responde. La fase 2 finaliza cuando el servidor DM deja de enviar comandos y finaliza la sesión. Esta fase se representa mediante los pasos 3, 4 y 5.

La siguiente información muestra la secuencia de eventos durante una sesión de DM típica.

1. El cliente DM se invoca para llamar de vuelta al servidor de administración
   
   Escenario empresarial: la programación de tareas del dispositivo invoca al cliente de DM.

   El servidor de MO envía un mensaje de desencadenador de servidor para invocar al cliente dm.

   El mensaje de desencadenador incluye el identificador de servidor e indica al dispositivo cliente que inicie una sesión con el servidor. El dispositivo cliente autentica el mensaje del desencadenador y comprueba que el servidor está autorizado para comunicarse con él.
   
   Escenario de empresa: a la hora programada, el cliente de DM se invoca periódicamente para llamar al servidor de administración empresarial a través de HTTPS.

2. El dispositivo envía un mensaje, a través de una conexión IP, para iniciar la sesión.

   Este mensaje incluye información y credenciales del dispositivo. El cliente y el servidor realizan la autenticación mutua a través de un canal TLS/SSL o en el nivel de aplicación dm.

3. El servidor DM responde a través de una conexión IP (HTTPS). El servidor envía los comandos iniciales de administración de dispositivos, si los hay.

4. El dispositivo responde a los comandos de administración del servidor. Este mensaje incluye los resultados de realizar las operaciones de administración de dispositivos especificadas.

5. El servidor DM finaliza la sesión o envía otro comando. Finaliza la sesión de DM o se repite el paso 4.

Los números de paso no representan números de identificación de mensaje (MsgID). Todos los mensajes del servidor deben tener un MsgID que sea único dentro de la sesión, empezando en 1 para el primer mensaje y aumentando en un incremento de 1 por cada mensaje adicional. Para obtener más información sobre MsgID y el protocolo OMA SyncML, vea OMA Administración de dispositivos Representation Protocol (DM_RepPro-V1_2-20070209-A).

Durante la autenticación mutua de nivel de aplicación de OMA DM, si el código de respuesta del dispositivo al elemento Cred de la solicitud de servidor es 212, no se necesita ninguna autenticación adicional para el resto de la sesión de DM. Si se produce la autenticación md5, se puede devolver el Chal elemento. A continuación, se debe usar el siguiente nonce en Chal para el resumen md5 cuando se inicia la siguiente sesión de DM.

Si una solicitud incluye credenciales y el código de respuesta a la solicitud es 200, se debe enviar la misma credencial dentro de la siguiente solicitud. Si se incluye el Chal elemento y se requiere la autenticación MD5, se crea un nuevo resumen mediante el siguiente nonce a través del elemento para la Chal siguiente solicitud.

Para obtener más información sobre la autenticación de cliente básica o MD5, la autenticación de servidor MD5, el hash MD5 y el nonce MD5, consulte la especificación de seguridad de OMA Administración de dispositivos (OMA-TS-DM_Security-V1_2_1-20080617-A), el control de código de respuesta de autenticación y ejemplos paso a paso en OMA Administración de dispositivos Especificación de protocolo (OMA-TS-DM_Protocol-V1_2_1-20080617-A), disponible en el sitio web de OMA.

Configuración de destino de usuario frente a dispositivo de destino

En el caso de los CSP y las directivas que admiten la configuración por usuario, el servidor MDM puede enviar valores de configuración de destino de usuario al dispositivo en el que un usuario inscrito en MDM haya iniciado sesión activamente. El dispositivo notifica al servidor el estado de inicio de sesión a través de una alerta de dispositivo (1224) con tipo de alerta = en DM pkg#1.

La parte de datos de esta alerta podría ser una de las siguientes cadenas:

• Usuario: el usuario que inscribió el dispositivo ha iniciado sesión activamente. El servidor MDM podría enviar una configuración específica del usuario para CSP o directivas que admiten la configuración por usuario.
• Otros: otro usuario inicia sesión, pero ese usuario no tiene una cuenta MDM. El servidor solo puede aplicar la configuración de todo el dispositivo; por ejemplo, la configuración se aplica a todos los usuarios del dispositivo.
• Ninguno: ningún usuario activo inicia sesión. El servidor solo puede aplicar la configuración de todo el dispositivo y la configuración disponible está restringida al entorno del dispositivo (no hay ningún inicio de sesión de usuario activo).

Este es un ejemplo de alerta:

<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>

El servidor notifica al dispositivo si se trata de una configuración de destino de usuario o de destino del dispositivo con un prefijo en locURL del nodo de administración, con ./user para la configuración de destino del usuario o ./device para la configuración de destino del dispositivo. De forma predeterminada, si no hay ningún prefijo con ./device o ./user, es una configuración de destino del dispositivo.

En la siguiente locURL se muestra una configuración de nodo CSP por usuario: ./user/vendor/MSFT/EnterpriseModernAppManagement/AppInstallation/<PackageFamilyName>/StoreInstall

La siguiente locURL muestra una configuración de nodo CSP por dispositivo: ./device/vendor/MSFT/RemoteWipe/DoWipe

Códigos de estado de respuesta SyncML

Cuando se usa SyncML en OMA DM, se devuelven códigos de estado de respuesta estándar. En la tabla siguiente se enumeran los códigos de estado de respuesta syncML comunes que es probable que vea. Para obtener más información sobre los códigos de estado de respuesta syncML, consulte la sección 10 de la especificación del protocolo de representación SyncML .

Código de estado	Descripción
200	El comando SyncML se completó correctamente.
202	Se acepta para su procesamiento. Este código denota una operación asincrónica, como una solicitud para ejecutar una ejecución remota de una aplicación.
212	Autenticación aceptada. Normalmente, este código solo se ve en respuesta al elemento SyncHdr (que se usa para la autenticación en el estándar OMA-DM). Es posible que vea este código si observa los registros de OMA DM, pero los CSP no suelen generar este código.
214	Operación cancelada. El comando SyncML se completó correctamente, pero no se procesan más comandos dentro de la sesión.
215	No ejecutado. Un comando no se ejecutó como resultado de la interacción del usuario para cancelar el comando.
216	Atomic revierta bien. Un comando estaba dentro de un elemento y Atomic produjo un Atomic error. Este comando se revierte correctamente.
400	Solicitud incorrecta. No se pudo realizar el comando solicitado debido a una sintaxis con formato incorrecto. Los CSP no suelen generar este error, pero es posible que lo vea si syncML tiene un formato incorrecto.
401	Credenciales no válidas. Error en el comando solicitado porque el solicitante debe proporcionar la autenticación adecuada. Los CSP no suelen generar este error.
403	Prohibido. Error en el comando solicitado, pero el destinatario entendió el comando solicitado.
404	No se encontró. No se encontró el destino solicitado. Este código se genera si consulta un nodo que no existe.
405	Comando no permitido. Este código de respuesta se genera si intenta escribir en un nodo de solo lectura.
406	No se admite la característica opcional. Este código de respuesta se genera si intenta acceder a una propiedad que el CSP no admite.
415	Tipo o formato no admitidos. Este código de respuesta puede ser el resultado de errores de análisis o formato XML.
418	Ya existe. Este código de respuesta se produce si intenta agregar un nodo que ya existe.
425	Permiso denegado. Error en el comando solicitado porque el remitente no tiene los permisos de control de acceso (ACL) adecuados en el destinatario. Los errores "Acceso denegado" suelen traducirse a este código de respuesta.
500	Error en el comando. Error genérico. El destinatario encontró una condición inesperada, lo que impedía que cumpliera la solicitud. Este código de respuesta se produce cuando la DPU de SyncML no puede asignar el código de error de origen.
507	Atomic Fallado. Error en una de las operaciones de un Atomic bloque.
516	Atomic Error al revertir. Error en una Atomic operación y el comando no se revierte correctamente.

Artículos relacionados

Referencia de proveedor de servicios de configuración