Compatibilidad con el protocolo OMA DM

Escrito por el en Articles
  • Artículo
  • 12/16/2021
  • 12 minutos de lectura
    • D
    • M
    • a
    • v
    • d
    • +11
¿Es útil esta página?

Gracias.

El cliente DM de OMA se comunica con el servidor a través de HTTPS y utiliza DM Sync (OMA DM v1. 2) como carga útil del mensaje. En este tema se describe la funcionalidad de DM de OMA 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 OMA DM

La siguiente tabla muestra los estándares OMA DM que utiliza Windows.

Área general Estándar OMA DM compatible
Transporte de datos y sesión
  • Sesión DM HTTPS remota iniciada por el cliente a través de SSL.
  • Sesión remota HTTPS DM a través de SSL.
  • Notificación de inicio de servidor DM remoto mediante el servicio de mensajes cortos (SMS) Push over WAP. No utilizado por la administración empresarial.
  • Arranque remoto mediante SMS Push WAP. No utilizado por la administración empresarial.
    		•
    Bootstrap XML Cliente OMA de Aprovisionamiento XML.
    Comandos de protocolo DM La siguiente lista muestra los comandos que utiliza el dispositivo. Para obtener más información sobre los elementos de comando DM de OMA, consulte «Sitio web de OMA» disponible en el sitio web de OMA.

  • Agregar (Compatible con Agregar implícito)
  • Alerta (alerta DM): El cliente de administración empresarial utiliza la alerta genérica (1226) cuando el usuario desencadena una acción de cancelación de inscripción de MDM desde el dispositivo o cuando un CSP finaliza algunas acciones asincrónicas. Device alert (1224) se utiliza para notificar al servidor algún evento desencadenado por el dispositivo.
  • Atomic: No se admite la ejecución de un comando Add seguido de Replace en el mismo nodo dentro de un elemento atomic. Los comandos atómicos y Get anidados no están permitidos y generarán código de error 500.
  • Eliminar: Elimina un nodo del árbol de DM y todo el subárbol debajo de ese nodo si existe
  • Exec: Invoca un ejecutable en el dispositivo cliente
  • Get: Recupera datos del dispositivo cliente; para los nodos interiores, los nombres de nodo secundarios en el elemento de datos se devuelven en formato codificado en URI
  • Reemplazar: Sobrescribe datos en el dispositivo cliente
  • Resultado: Devuelve los resultados de datos de un Secuencia Get command to the DM server
  • : Especifica el orden en el que se debe procesar un grupo de comandos
  • Estado: Indica el estado de finalización (éxito o error) de una operación
    Si un elemento XML que no es un comando DM OMA válido se encuentra en uno de los siguientes elementos, se devuelve el código de estado 400 para ese elemento:
  • SyncBody
  • Atomic
  • Sequence
    Si no se proporciona ningún CmdID en el comando DM, el cliente devuelve un espacio en blanco en el elemento status y el código de estado 400.
    Si los elementos atómicos están anidados, se devuelven los siguientes códigos de estado:
  • El comando atómico anidado devuelve 500.
  • El comando atómico padre devuelve 507.
    Para obtener más información sobre el comando atómico, consulte Elementos comunes del protocolo DM de OMA.
    No se admite la ejecución de un comando Add seguido de Replace en el mismo nodo dentro de un elemento atómico.
    LocURI no puede comenzar con /.
    La etiqueta Meta XML en SyncHdr es ignorada por el dispositivo.
    		•
    Objetos estándar OMA DM DevInfo

  • DevDetail
  • Objetos de cuenta OMA DM DMS (OMA DM versión 1.2)
    		•
    Seguridad
  • Autenticar el mensaje SMS de notificación de inicio de servidor DM (no utilizado por la administración empresarial)
  • Autenticación de cliente MD5 y capa de aplicación básica
  • Autenticar el servidor con credencial MD5 a nivel de aplicación
  • Integridad y autenticación de datos con HMAC a nivel de aplicación
  • Autenticación de cliente/servidor basada en certificados SSL, cifrado e integridad de datos comprobar
    		•
    Nodos En el árbol DM de OMA, se aplican las siguientes reglas para el nombre del nodo:

  • «.»puede ser 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 asterisco ( * ).
    		•
    Los archivos de aprovisionamiento El XML de aprovisionamiento debe estar bien formado y seguir la definición del Protocolo de representación SyncML] (https://go.microsoft.com/fwlink/p/?LinkId=526905).
    Si un elemento XML que no es un comando DM OMA válido está bajo SyncBody, se devuelve el código de estado 400 para ese elemento.

    Nota
    Para representar una cadena Unicode como URI, primero codifique la cadena como UTF-8. A continuación, codifique cada uno de los bytes UTF-8 utilizando codificación URI.
    Compatibilidad con WBXML Windows admite el envío y recepción de SyncML en formato XML y en formato WBXML codificado. Esto se puede configurar mediante el nodo DEFAULTENCODING bajo la característica de la 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.
    Manejo de objetos grandes En Windows 10, versión 1511, se agregó soporte de cliente para cargar objetos grandes al servidor.

    Elementos comunes del protocolo OMA DM

    Los elementos comunes son utilizados por otros tipos de elementos OMA DM. La siguiente tabla enumera los elementos comunes de DM de OMA utilizados para configurar los dispositivos. Para obtener más información sobre los elementos comunes de OMA DM, consulte «Uso de administración de dispositivos del Protocolo de representación SyncML» (OMA-SyncML-DMRepPro-V1_1_2-20030613-A) disponible en el sitio web de OMA.

    el Elemento Descripción
    Chal Especifica un desafío de autenticación. El servidor o cliente puede enviar un desafío al otro si no se dieron credenciales o credenciales inadecuadas en el mensaje de solicitud original.
    Cmd Especifica el nombre de un comando DM de OMA al que se hace referencia en un elemento de estado.
    CmdID Especifica el identificador único para un comando DM de OMA.
    CmdRef Especifica el ID del comando para el que se devuelve la información de estado o de resultados. Este elemento toma el valor del elemento CmdID del mensaje de solicitud correspondiente.
    Cred Especifica la credencial de autenticación para el creador del mensaje.
    Final Indica que el mensaje actual es el último mensaje en el paquete.
    LocName Especifica el nombre para mostrar en los elementos de destino y Origen, que se utiliza para enviar un ID de usuario para la autenticación MD5.
    LocURI Especifica la dirección de destino o ubicación de la fuente. Si la dirección contiene un carácter no alfanumérico, debe escaparse correctamente de acuerdo con el estándar de codificación de URL.
    MsgID Especifica un identificador único para un mensaje de sesión DM de OMA.
    MsgRef Especifica el ID 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 DM de OMA asociada al mensaje que contiene.

    Nota
    Si el servidor no notifica al dispositivo que admite una nueva versión (a través del nodo SyncApplicationVersion en el CSP de DMClient), el cliente devuelve el ID de sesión en entero en formato decimal. Si el servidor es compatible con la versión 2.0 de sincronización de sesiones de DM, que se utiliza en Windows 10, 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 de origen 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 de destino del mensaje de solicitud y se devuelve en el elemento Status o Results.
    VerDTD Especifica el identificador de versión mayor y menor de la especificación del protocolo de representación DM de OMA utilizado para representar el mensaje.
    VerProto Especifica el identificador de versión mayor y menor 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) consiste en una serie de comandos intercambiados entre un servidor DM y un dispositivo cliente. El servidor envía comandos que indican las operaciones que deben realizarse 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 DM corta se puede resumir de la siguiente manera:

    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 de DM se puede dividir en dos fases:

    1. Fase de configuración: En respuesta a un evento desencadenante, 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 está representada por los pasos 1, 2 y 3 de la siguiente tabla.
    2. Fase de gestión: El servidor DM está en control. Envía comandos de administración al dispositivo y el dispositivo responde. La fase dos finaliza cuando el servidor DM deja de enviar comandos y finaliza la sesión. Esta fase está representada por los pasos 3, 4 y 5 en la siguiente tabla.

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

    1. El cliente DM se invoca para devolver la llamada al servidor de administración
      Escenario Empresarial: la programación de tareas del dispositivo invoca el cliente DM.

      El servidor MO envía un mensaje de activación de servidor para invocar el cliente DM.

      El mensaje de activación incluye el ID del servidor e indica al dispositivo cliente que inicie una sesión con el servidor. El dispositivo cliente autentica el mensaje del desencadenador y verifica que el servidor esté autorizado para comunicarse con él.Escenario
      Enterprise: A la hora programada, el cliente DM se invoca periódicamente para volver a 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 SSL o a nivel de aplicación DM.

    3. El servidor DM responde a través de una conexión IP (HTTPS). El servidor envía 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 la realización de las operaciones de administración de dispositivos especificadas.

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

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

    Durante la autenticación mutua a nivel de aplicación DM de OMA, si el código de respuesta del dispositivo al elemento Cred en la solicitud del servidor es 212, no se necesita más autenticación para el resto de la sesión DM. En el caso de la autenticación MD5, se puede devolver el elemento Chal. Luego, el siguiente nonce en Chal debe usarse para el resumen MD5 cuando se inicie la siguiente sesión DM.

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

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

    Usuario dirigido vs Configuración dirigida al dispositivo

    Para los CSP y las directivas compatibles con la configuración por usuario, el servidor MDM puede enviar valores de configuración dirigidos al 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 = in 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 está conectado activamente. El servidor MDM podría enviar configuraciones específicas de usuario para CSP/directivas compatibles con configuración por usuario
    • Otros: otro inicio de sesión de usuario, 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 – no hay inicio de sesión de usuario activo. El servidor solo puede aplicar la configuración de todo el dispositivo y la configuración disponible está restringida al entorno del dispositivo (sin inicio de sesión de usuario activo).

    A continuación se muestra 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 dirigida a un usuario o a un dispositivo mediante un prefijo a la LocURL del nodo de administración, con ./ usuario para configuración dirigida al usuario, o ./ dispositivo para la configuración específica del dispositivo. De forma predeterminada, si no hay prefijo con ./o dispositivo ./ usuario, es la configuración dirigida al dispositivo.

    La siguiente LocURL 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. La siguiente tabla enumera 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 SyncML comando se completó correctamente.
    202 Aceptado para su procesamiento. Por lo general, se trata de una operación asíncrona, como una solicitud para ejecutar una ejecución remota de una aplicación.
    212 Autenticación aceptado. Normalmente, solo verá esto en respuesta al elemento SyncHdr (utilizado para la autenticación en el estándar OMA-DM). Puede ver esto si observa los registros DM de OMA, pero los CSP no suelen generar esto.
    214 Operación cancelada. El comando SyncML se completó correctamente, pero no se procesarán más comandos dentro de la sesión.
    215 No se ejecuta. Un comando no se ejecutó como resultado de la interacción del usuario para cancelar el comando.
    216 Atomic retroceder OK. Un comando estaba dentro de un elemento Atomic y Atomic falló. Este comando fue revertido con éxito.
    400 solicitud incorrecta. El comando solicitado no se pudo ejecutar debido a una sintaxis mal formada. Los CSP no suelen generar este error, sin embargo, es posible que lo vea si su SyncML está mal formado.
    401 Credenciales no válidas. El comando solicitado falló porque el solicitante debe proporcionar la autenticación adecuada. Los CSP no suelen generar este error.
    403 Prohibido. El comando solicitado falló, pero el destinatario entendió el comando solicitado.
    404 No se encontró. El objetivo solicitado no ha sido encontrado. Este código se generará si consulta un nodo que no existe.
    405 Comando no permitido. Este código de respuesta se generará si intenta escribir en un nodo de solo lectura.
    406 Opcional no disponible. Este código de respuesta se generará si intenta acceder a una propiedad que el CSP no admite.
    415 Tipo o formato no compatible. Este código de respuesta puede ser el resultado de errores de formato o análisis XML.
    418 Ya existe. Este código de respuesta se produce si intenta agregar un nodo que ya existe.
    425 Permiso Denegado. El comando solicitado falló porque el remitente no tiene los permisos de control de acceso (ACL) adecuados en el destinatario. Los errores de «acceso denegado» generalmente se traducen a este código de respuesta.
    500 error de Comando. Fallo genérico. El destinatario se encontró con una condición inesperada que le impidió cumplir con la solicitud. Este código de respuesta se producirá cuando la DPU de SyncML no pueda asignar el código de error de origen.
    507 Atomic fracasado. Una de las operaciones en un bloque Atomic falló.
    516 Atomic revertir fallado. Una operación Atomic falló y el comando no se revirtió correctamente.

    Deja una respuesta

    Tu dirección de correo electrónico no será publicada.