Prise en charge du protocole OMA DM

Le client OMA DM communique avec le serveur via HTTPS et utilise DM Sync (OMA DM v1.2) comme charge utile du message. Cet article décrit les fonctionnalités OMA DM que le client DM prend en charge en général. La description complète du protocole OMA DM v1.2 est disponible sur le site web d’OMA.

Normes OMA DM

Le tableau suivant présente les normes OMA DM que Windows utilise.

Zone générale Norme OMA DM prise en charge
Transport de données et session
  • Session DM HTTPS distante initiée par le client sur TLS/SSL.
  • Session DM HTTPS distante sur TLS/SSL.
  • Notification d’initiation du serveur DM distant à l’aide du service SMS (Push over Short Message Service) WAP. Non utilisé par la gestion d’entreprise.
  • Démarrage à distance à l’aide de WAP Push over SMS. Non utilisé par la gestion d’entreprise.
    		•
    Xml d’amorçage CODE XML d’approvisionnement du client OMA.
    Commandes de protocole DM La liste suivante présente les commandes utilisées par l’appareil. Pour plus d’informations sur les éléments de commande OMA DM, consultez « site web OMA » disponible sur le site web d’OMA.
  • Add (Ajout implicite pris en charge)
  • Alerte (alerte DM) : l’alerte générique (1226) est utilisée par le client de gestion d’entreprise lorsque l’utilisateur déclenche une action de désinscription MDM à partir de l’appareil ou lorsqu’un fournisseur de solutions Cloud termine certaines actions asynchrones. L’alerte d’appareil (1224) est utilisée pour informer le serveur d’un événement déclenché par l’appareil.
  • Atomic : l’exécution d’une commande Add suivie de Replace sur le même nœud au sein d’un élément atomique n’est pas prise en charge. Les commandes Atomic et Get imbriquées ne sont pas autorisées et génèrent le code d’erreur 500.
  • Supprimer : supprime un nœud de l’arborescence DM, et l’ensemble de la sous-arborescence sous ce nœud, s’il en existe une,
  • Exec : appelle un exécutable sur l’appareil client
  • Get : récupère des données à partir de l’appareil client ; pour les nœuds intérieurs, les noms de nœuds enfants dans l’élément Data sont retournés au format encodé en URI
  • Remplacer : remplace les données sur l’appareil client
  • Résultat : retourne les résultats de données d’une commande Get au serveur DM
  • Séquence : spécifie l’ordre dans lequel un groupe de commandes doit être traité
  • État : indique la status d’achèvement (réussite ou échec) d’une opération

    Si un élément XML qui n’est pas une commande DM OMA valide se trouve sous l’un des éléments suivants, le code status 400 est retourné pour cet élément :
  • SyncBody
  • Atomique
  • Séquence

    Si aucun CmdID n’est fourni dans la commande DM, le client retourne vide dans l’élément status et le code status 400.

    Si les éléments Atomic sont imbriqués, les codes status suivants sont retournés :
  • La commande Atomic imbriquée retourne 500.
  • La commande Atomic parente retourne 507.

    Pour plus d’informations sur la commande Atomic, consultez Éléments communs du protocole DM OMA.
    L’exécution d’une commande Add suivie de Replace sur le même nœud au sein d’un élément Atomic n’est pas prise en charge.

    LocURI ne peut pas commencer par /.

    La balise Meta XML dans SyncHdr est ignorée par l’appareil.
    		•
    Objets standard DM OMA Devinfo
  • DevDetail
  • Objets de compte DMS OMA DM (OMA DM version 1.2)
    		•
    Sécurité
  • Authentification du message SMS de notification d’initiation du serveur DM (non utilisé par la gestion d’entreprise)
  • Authentification cliente de base et MD5 de la couche Application
  • Authentifier le serveur avec des informations d’identification MD5 au niveau de l’application
  • Intégrité des données et authentification avec HMAC au niveau de l’application
  • L’authentification client/serveur basée sur les certificats TLS/SSL, le chiffrement et l’intégrité des données case activée
    		•
    Nœuds Dans l’arborescence DM OMA, les règles suivantes s’appliquent au nom du nœud :
  • « . » peut faire partie du nom du nœud.
  • Le nom du nœud ne peut pas être vide.
  • Le nom du nœud ne peut pas être uniquement l’astérisque (*).
    		•
    Provisionnement des fichiers Le code XML d’approvisionnement doit être bien formé et suivre la définition dans Le protocole de représentation SyncML.

    Si un élément XML qui n’est pas une commande DM OMA valide se trouve sous SyncBody, le code status 400 est retourné pour cet élément.
    Remarque
    Pour représenter une chaîne Unicode en tant qu’URI, commencez par encoder la chaîne en UTF-8. Codez ensuite chacun des octets UTF-8 à l’aide de l’encodage URI.
    Prise en charge de WBXML Windows prend en charge l’envoi et la réception de SyncML au format XML et au format WBXML encodé. Cette prise en charge double format est configurable à l’aide du nœud DEFAULTENCODING sous la caractéristique w7 APPLICATION lors de l’inscription. Pour plus d’informations sur l’encodage WBXML, consultez la section 8 de la spécification du protocole de représentation SyncML .
    Gestion des objets volumineux Dans Windows 10, la prise en charge du client pour le chargement d’objets volumineux sur le serveur a été ajoutée.

    Éléments communs du protocole DM OMA

    Les éléments communs sont utilisés par d’autres types d’éléments DM OMA. Le tableau suivant répertorie les éléments communs OMA DM utilisés pour configurer les appareils. Pour plus d’informations sur les éléments communs d’OMA DM, consultez « SyncML Representation Protocol Gestion des appareils Usage » (OMA-SyncML-DMRepPro-V1_1_2-20030613-A) disponible sur le site web OMA.

    Élément Description
    Chal Spécifie un défi d’authentification. Le serveur ou le client peut envoyer un défi à l’autre si aucune information d’identification ou informations d’identification inadéquates n’a été donnée dans le message de demande d’origine.
    Cmd Spécifie le nom d’une commande DM OMA référencée dans un élément Status.
    CmdID Spécifie l’identificateur unique d’une commande DM OMA.
    CmdRef Spécifie l’ID de la commande pour laquelle les informations de status ou de résultats sont retournées. Cet élément prend la valeur de l’élément CmdID du message de demande correspondant.
    Cred Spécifie les informations d’identification d’authentification pour l’expéditeur du message.
    Final Indique que le message actuel est le dernier message du package.
    LocName Spécifie le nom d’affichage dans les éléments Target et Source, utilisés pour envoyer un ID utilisateur pour l’authentification MD5.
    LocURI Spécifie l’adresse de l’emplacement cible ou source. Si l’adresse contient un caractère non alphanumérique, elle doit être correctement placée dans une séquence d’échappement conformément à la norme d’encodage d’URL.
    MsgID Spécifie un identificateur unique pour un message de session DM OMA.
    MsgRef Spécifie l’ID du message de demande correspondant. Cet élément prend la valeur de l’élément MsgID du message de requête.
    RespURI Spécifie l’URI que le destinataire doit utiliser lors de l’envoi d’une réponse à ce message.
    Sessionid Spécifie l’identificateur de la session DM OMA associée au message contenant. Si le serveur n’informe pas l’appareil qu’il prend en charge une nouvelle version (par le biais du nœud SyncApplicationVersion dans le csp DMClient), le client retourne sessionID en entier au format décimal. Si le serveur prend en charge la synchronisation de session DM version 2.0, qui est utilisée dans Windows, le client d’appareil retourne 2 octets.
    Source Spécifie l’adresse source du message.
    SourceRef Spécifie la source du message de demande correspondant. Cet élément prend la valeur de l’élément Source du message de requête et est retourné dans l’élément Status ou Results.
    Target Spécifie l’adresse du nœud dans l’arborescence DM qui est la cible de la commande DM OMA.
    TargetRef Spécifie l’adresse cible dans le message de demande correspondant. Cet élément prend la valeur de l’élément Target du message de demande et est retourné dans l’élément Status ou Results.
    VerDTD Spécifie l’identificateur de version principale et mineure de la spécification du protocole de représentation DM OMA utilisée pour représenter le message.
    VerProto Spécifie l’identificateur de version principale et mineure de la spécification du protocole DM OMA utilisée avec le message.

    Session de gestion des appareils

    Une session Gestion des appareils (DM) se compose d’une série de commandes échangées entre un serveur DM et un appareil client. Le serveur envoie des commandes indiquant les opérations qui doivent être effectuées sur l’arborescence de gestion de l’appareil client. Le client répond en envoyant des commandes qui contiennent les résultats et toutes les informations status demandées.

    Une session DM courte peut être résumée comme suit :

    Un serveur envoie une commande Get à un appareil client pour récupérer le contenu de l’un des nœuds de l’arborescence de gestion. L’appareil effectue l’opération et répond avec une commande Result qui contient le contenu demandé.

    Une session DM peut être divisée en deux phases :

    1. Phase d’installation : en réponse à un événement déclencheur, un appareil client envoie un message d’initialisation à un serveur DM. L’échange d’appareils et de serveurs avait besoin d’une authentification et d’informations sur l’appareil. Cette phase est représentée par les étapes 1, 2 et 3.
    2. Phase de gestion : le serveur DM est sous contrôle. Il envoie des commandes de gestion à l’appareil et l’appareil répond. La phase 2 se termine lorsque le serveur DM cesse d’envoyer des commandes et met fin à la session. Cette phase est représentée par les étapes 3, 4 et 5.

    Les informations suivantes montrent la séquence d’événements au cours d’une session DM classique.

    1. Le client DM est appelé pour rappeler le serveur d’administration

      Scénario d’entreprise : la planification des tâches de l’appareil appelle le client DM.

      Le serveur MO envoie un message de déclencheur de serveur pour appeler le client DM.

      Le message de déclencheur inclut l’ID du serveur et indique à l’appareil client de lancer une session avec le serveur. L’appareil client authentifie le message déclencheur et vérifie que le serveur est autorisé à communiquer avec lui.

      Scénario d’entreprise : à l’heure planifiée, le client DM est appelé régulièrement pour rappeler le serveur d’administration d’entreprise via HTTPS.

    2. L’appareil envoie un message, via une connexion IP, pour lancer la session.

      Ce message inclut des informations d’identification et des informations d’identification sur l’appareil. Le client et le serveur effectuent une authentification mutuelle sur un canal TLS/SSL ou au niveau de l’application DM.

    3. Le serveur DM répond via une connexion IP (HTTPS). Le serveur envoie les commandes de gestion des appareils initiales, le cas échéant.

    4. L’appareil répond aux commandes de gestion du serveur. Ce message inclut les résultats de l’exécution des opérations de gestion des appareils spécifiées.

    5. Le serveur DM met fin à la session ou envoie une autre commande. La session DM se termine ou l’étape 4 est répétée.

    Les numéros d’étape ne représentent pas les numéros d’identification des messages (MsgID). Tous les messages du serveur doivent avoir un MsgID unique dans la session, commençant à 1 pour le premier message et augmentant d’un incrément de 1 pour chaque message supplémentaire. Pour plus d’informations sur MsgID et le protocole OMA SyncML, consultez OMA Gestion des appareils Representation Protocol (DM_RepPro-V1_2-20070209-A).

    Lors de l’authentification mutuelle au niveau de l’application OMA DM, si le code de réponse de l’appareil à l’élément Cred dans la demande de serveur est 212, aucune authentification supplémentaire n’est nécessaire pour le reste de la session DM. Si l’authentification MD5 se produit, l’élément Chal peut être retourné. Ensuite, le nonce Chal suivant doit être utilisé pour la synthèse MD5 lorsque la session DM suivante est démarrée.

    Si une demande inclut des informations d’identification et que le code de réponse à la demande est 200, les mêmes informations d’identification doivent être envoyées dans la requête suivante. Si l’élément Chal est inclus et que l’authentification MD5 est requise, une nouvelle synthèse est créée en utilisant le nonce suivant via l’élément pour la Chal requête suivante.

    Pour plus d’informations sur l’authentification cliente De base ou MD5, Authentification du serveur MD5, hachage MD5 et nonce MD5. Consultez la spécification OMA Gestion des appareils Security (OMA-TS-DM_Security-V1_2_1-20080617-A), la gestion du code de réponse d’authentification et les exemples pas à pas dans spécification du protocole OMA Gestion des appareils (OMA-TS-DM_Protocol-V1_2_1-20080617-A), disponibles à partir du site web de l’OMA.

    Configuration ciblée par l’utilisateur et la configuration ciblée par l’appareil

    Pour les csp et les stratégies qui prennent en charge la configuration par utilisateur, le serveur MDM peut envoyer des valeurs de paramètres ciblés à l’utilisateur à l’appareil auquel un utilisateur inscrit à GPM est activement connecté. L’appareil avertit le serveur de l’status de connexion via une alerte d’appareil (1224) avec le type d’alerte = dans DM pkg#1.

    La partie données de cette alerte peut être l’une des chaînes suivantes :

    • Utilisateur : l’utilisateur qui a inscrit l’appareil est activement connecté. Le serveur GPM peut envoyer une configuration spécifique à l’utilisateur pour les csp/stratégies qui prennent en charge la configuration par utilisateur
    • Autres : un autre utilisateur se connecte, mais cet utilisateur n’a pas de compte GPM. Le serveur peut uniquement appliquer une configuration à l’échelle de l’appareil, par exemple, la configuration s’applique à tous les utilisateurs de l’appareil.
    • Aucun : aucun utilisateur actif ne se connecte. Le serveur peut uniquement appliquer la configuration à l’échelle de l’appareil et la configuration disponible est limitée à l’environnement de l’appareil (aucun utilisateur actif ne se connecte).

    Voici un exemple d’alerte :

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

    Le serveur avertit l’appareil s’il s’agit d’une configuration ciblée par l’utilisateur ou l’appareil par un préfixe de LocURL du nœud de gestion, avec ./user pour une configuration ciblée sur l’utilisateur ou ./device pour une configuration ciblée sur l’appareil. Par défaut, s’il n’y a pas de préfixe avec ./device ou ./user, il s’agit d’une configuration ciblée sur l’appareil.

    Le LocURL suivant affiche une configuration de nœud CSP par utilisateur : ./user/vendor/MSFT/EnterpriseModernAppManagement/AppInstallation/<PackageFamilyName>/StoreInstall

    Le LocURL suivant montre une configuration de nœud CSP par appareil : ./device/vendor/MSFT/RemoteWipe/DoWipe

    Codes de status de réponse SyncML

    Lors de l’utilisation de SyncML dans OMA DM, des codes status de réponse standard sont retournés. Le tableau suivant répertorie les codes de réponse SyncML courants status que vous êtes susceptible de voir. Pour plus d’informations sur les codes de status de réponse SyncML, consultez la section 10 de la spécification du protocole de représentation SyncML.

    Code d’état Description
    200 La commande SyncML s’est terminée avec succès.
    202 Accepté pour traitement. Ce code désigne une opération asynchrone, telle qu’une demande d’exécution à distance d’une application.
    212 Authentification acceptée. Normalement, vous voyez uniquement ce code en réponse à l’élément SyncHdr (utilisé pour l’authentification dans la norme OMA-DM). Vous pouvez voir ce code si vous examinez les journaux DM OMA, mais les fournisseurs de services cloud ne génèrent généralement pas ce code.
    214 Opération annulée. La commande SyncML s’est terminée correctement, mais aucune autre commande n’est traitée dans la session.
    215 Non exécuté. Une commande n’a pas été exécutée suite à l’interaction de l’utilisateur pour annuler la commande.
    216 Atomic restaurer OK. Une commande se trouvait à l’intérieur d’un Atomic élément et Atomic a échoué. Cette commande a été restaurée avec succès.
    400 Requête incorrecte. Impossible d’exécuter la commande demandée en raison d’une syntaxe incorrecte. Les fournisseurs de services cloud ne génèrent généralement pas cette erreur, mais vous pouvez la voir si votre SyncML est mal formé.
    401 Informations d’identification non valides. Échec de la commande demandée, car le demandeur doit fournir une authentification appropriée. Les fournisseurs de services cloud ne génèrent généralement pas cette erreur.
    403 Interdit. La commande demandée a échoué, mais le destinataire a compris la commande demandée.
    404 Introuvable. La cible demandée est introuvable. Ce code est généré si vous interrogez un nœud qui n’existe pas.
    405 Commande non autorisée. Ce code de réponse est généré si vous essayez d’écrire dans un nœud en lecture seule.
    406 Fonctionnalité facultative non prise en charge. Ce code de réponse est généré si vous essayez d’accéder à une propriété que le fournisseur csp ne prend pas en charge.
    415 Type ou format non pris en charge. Ce code de réponse peut résulter d’erreurs d’analyse ou de mise en forme XML.
    418 Existe déjà. Ce code de réponse se produit si vous tentez d’ajouter un nœud qui existe déjà.
    425 Autorisation refusée. La commande demandée a échoué, car l’expéditeur ne dispose pas des autorisations de contrôle d’accès (ACL) adéquates sur le destinataire. Les erreurs « Accès refusé » sont généralement traduites en ce code de réponse.
    500 Échec de la commande. Échec générique. Le destinataire a rencontré une condition inattendue, ce qui l’a empêché de répondre à la demande. Ce code de réponse se produit lorsque le DPU SyncML ne peut pas mapper le code d’erreur d’origine.
    507 Atomic Échoué. L’une des opérations d’un Atomic bloc a échoué.
    516 Atomic Échec de la restauration. Une Atomic opération a échoué et la commande n’a pas été restaurée avec succès.

    Informations de référence sur les fournisseurs de services de configuration