Compatibilidad con el protocolo OMA DM

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.

    Referencia de proveedor de servicios de configuración