Prise en charge du protocole OMA DM

Written by on in Articles
  • Article
  • 12/16/2021
  • 12 minutes à lire
    • D
    • M
    • a
    • v
    • d
    • +11
Cette page est-elle utile ?

Merci.

Le client OMA DM communique avec le serveur via HTTPS et utilise la synchronisation DM (OMA DM v1.2) comme charge utile du message. Cette rubrique décrit la fonctionnalité OMA DM prise en charge par le client DM en général. La description complète du protocole OMA DM v1.2 peut être consultée sur le site Web OMA.

Normes OMA DM

Le tableau suivant présente les normes OMA DM utilisées par Windows.

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 SSL.
  • Session DM HTTPS distante sur SSL.
  • Notification d’initiation du serveur DM distant à l’aide du service de messages courts Push over WAP (SMS). Non utilisé par la direction de l’entreprise.
  • Bootstrap à distance en utilisant WAP Push over SMS. Non utilisé par la direction de l’entreprise.
    		•
    XML d’amorçage XML de provisionnement du client OMA.
    Commandes de protocole DM La liste suivante affiche les commandes utilisées par le périphérique. Pour plus d’informations sur les éléments de commande OMA DM, voir « Site Web OMA » disponible sur le site Web OMA.

  • Add (Ajout implicite pris en charge)
  • Alert (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 du périphérique ou lorsqu’un CSP termine certaines actions asynchrones. L’alerte de périphérique (1224) est utilisée pour notifier au serveur un événement déclenché par un périphérique.
  • Atomique : L’exécution d’une commande Add suivie de Replace sur le même nœud dans 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éreront le code d’erreur 500.
  • Supprimer: Supprime un nœud de l’arborescence DM, et le sous-arbre entier sous ce nœud s’il en existe un
  • Exec : Appelle un exécutable sur le périphérique client
  • Get : Récupère les données du périphérique client ; pour les nœuds intérieurs, les noms de nœuds enfants de l’élément de données sont renvoyés au format encodé en URI
  • Replace : Écrase les données du périphérique client
  • Result : Renvoie les résultats des 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 l’état d’achèvement (succès ou échec) d’une opération
    Si un élément XML qui n’est pas une commande OMA DM valide se trouve sous l’un des éléments suivants, le code d’état 400 est renvoyé pour cet élément:
  • SyncBody
  • Atomic
  • Sequence
    Si aucun CmdID n’est fourni dans la commande DM, le client renvoie vide dans l’élément status et le code d’état 400.
    Si des éléments atomiques sont imbriqués, les codes d’état suivants sont renvoyés:
  • La commande atomique imbriquée renvoie 500.
  • La commande atomique parente renvoie 507.
    Pour plus d’informations sur la commande atomique, voir OMA DM protocol common elements.
    L’exécution d’une commande Add suivie de Replace sur le même nœud dans un élément atomique n’est pas prise en charge.
    LocURI ne peut pas commencer par /.
    La balise Meta XML dans SyncHdr est ignorée par le périphérique.
    		•
    Objets standard OMA DM DevInfo

  • DevDetail
  • Objets de compte OMA DM DMS (version OMA DM 1.2)
    		•
    Sécurité
  • Authentifier le message SMS de notification d’initiation du serveur DM (non utilisé par la direction de l’entreprise)
  • Authentification de base de la couche d’application et du client MD5
  • Authentifier le serveur avec les informations d’identification MD5 au niveau de l’application
  • Intégrité des données et authentification avec HMAC au niveau de l’application
  • Authentification client/serveur basée sur certificat de niveau SSL, cryptage et données vérification de l’intégrité
    		•
    Nœuds Dans l’arborescence OMA DM, 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 le caractère astérisque (*).
    		•
    Fichiers de provisionnement Le provisionnement XML doit être bien formé et suivre la définition dans SyncML Representation Protocol] (https://go.microsoft.com/fwlink/p/?LinkId=526905).
    Si un élément XML qui n’est pas une commande OMA DM valide est sous SyncBody, le code d’état 400 est renvoyé pour cet élément.

    Note
    Pour représenter une chaîne Unicode sous forme d’URI, encodez d’abord la chaîne en UTF-8. Encodez ensuite chacun des octets UTF-8 en utilisant le codage 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é. Ceci est configurable en utilisant le nœud DEFAULTENCODING sous la caractéristique de l’APPLICATION w7 lors de l’inscription. Pour plus d’informations sur l’encodage WBXML, reportez-vous à la section 8 de la spécification du protocole de représentation SyncML.
    Gestion des objets volumineux Dans Windows 10, version 1511, le support client pour le téléchargement d’objets volumineux sur le serveur a été ajouté.

    Éléments communs du protocole OMA DM

    Les éléments communs sont utilisés par d’autres types d’éléments OMA DM. Le tableau suivant répertorie les éléments communs OMA DM utilisés pour configurer les périphériques. Pour plus d’informations sur les éléments communs OMA DM, voir « Utilisation de la gestion des périphériques du protocole de représentation SyncML » (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 des informations d’identification inadéquates n’ont été données dans le message de demande d’origine.
    Cmd Spécifie le nom d’une commande OMA DM référencée dans un élément Status.
    CmdID Spécifie l’identifiant unique d’une commande OMA DM.
    CmdRef Spécifie l’ID de la commande pour laquelle les informations d’état ou de résultats sont renvoyées. Cet élément prend la valeur de l’élément CmdID du message de requête correspondant.
    Cred Spécifie les informations d’identification d’authentification pour l’auteur du message.
    Final Indique que le message actuel est le dernier message du paquet.
    LocName Spécifie le nom d’affichage dans les éléments Cible et Source, utilisé pour l’envoi d’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 échappée selon la norme de codage d’URL.
    MSGSTR Spécifie un identifiant unique pour un message de session OMA DM.
    MsgRef Spécifie l’ID du message de requête correspondant. Cet élément prend la valeur de l’élément message de requête Msgstr.
    RespURI Spécifie l’URI que le destinataire doit utiliser lors de l’envoi d’une réponse à ce message.
    SessionID Spécifie l’identifiant de la session OMA DM associée au message contenant.

    Note
    Si le serveur n’informe pas le périphérique qu’il prend en charge une nouvelle version (via le nœud SyncApplicationVersion dans le CSP DMClient), le client renvoie l’ID de session en entier au format décimal. Si le serveur prend en charge la version 2.0 de synchronisation de session DM, utilisée dans Windows 10, le client de périphérique renvoie 2 octets.
    Source Spécifie l’adresse source du message.
    SourceRef Spécifie la source du message de requête correspondant. Cet élément prend la valeur de l’élément Source du message de demande et est renvoyé 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 OMA DM.
    TargetRef Spécifie l’adresse cible dans le message de requête correspondant. Cet élément prend la valeur de l’élément Cible du message de demande et est renvoyé dans l’élément Status ou Results.
    VerDTD Spécifie l’identifiant de version majeure et mineure de la spécification de protocole de représentation OMA DM utilisée pour représenter le message.
    VerProto Spécifie l’identifiant de version majeure et mineure de la spécification de protocole OMA DM utilisée avec le message.

    Session de gestion des périphériques

    Une session de gestion des périphériques (DM) consiste en une série de commandes échangées entre un serveur DM et un périphérique 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 contenant les résultats et toute information d’état demandée.

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

    Un serveur envoie une commande Get à un périphérique 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 par une commande de résultat contenant le contenu demandé.

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

    1. Phase de configuration : En réponse à un événement de déclenchement, un périphérique client envoie un message d’initiation à un serveur DM. L’échange de l’appareil et du serveur nécessitait une authentification et des informations sur l’appareil. Cette phase est représentée par les étapes 1, 2 et 3 dans le tableau suivant.
    2. Phase de gestion : Le serveur DM est en contrôle. Il envoie des commandes de gestion à l’appareil et celui-ci répond. La deuxième phase se termine lorsque le serveur DM arrête d’envoyer des commandes et met fin à la session. Cette phase est représentée par les étapes 3, 4 et 5 dans le tableau suivant.

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

    1. Le client DM est appelé pour rappeler le scénario d’entreprise du serveur de gestion
      – La planification des tâches du périphérique appelle le client DM.

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

      Le message de déclenchement inclut l’ID du serveur et indique au périphérique client d’initier une session avec le serveur. Le périphérique client authentifie le message de déclenchement et vérifie que le serveur est autorisé à communiquer avec lui.Scénario d’entreprise
      – À l’heure planifiée, le client DM est appelé périodiquement pour rappeler le serveur de gestion d’entreprise via HTTPS.

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

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

    3. Le serveur DM répond, via une connexion IP (HTTPS). Le serveur envoie les commandes initiales de gestion des périphériques, 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 périphériques spécifiées.

    5. Le serveur DM termine 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 de message (MSGSTR). Tous les messages du serveur doivent avoir un MSGSTR unique au sein de 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 Msgstr et le protocole OMA SyncML, consultez OMA Device Management Representation Protocol (DM_RepPro-V1_2-20070209-A).

    Pendant l’authentification mutuelle au niveau de l’application OMA DM, si le code de réponse du périphérique à l’élément Cred dans la requête du serveur est 212, aucune autre authentification n’est nécessaire pour le reste de la session DM. Dans le cas de l’authentification MD5, l’élément Chal peut être retourné. Ensuite, le nonce suivant dans Chal doit être utilisé pour le condensé MD5 lorsque la prochaine session DM est démarrée.

    Si une demande contient 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 lors de la demande suivante. Si l’élément Chal est inclus et que l’authentification MD5 est requise, un nouveau résumé est créé en utilisant le nonce suivant via l’élément Chal pour la requête suivante.

    Pour plus d’informations sur l’authentification client de base ou MD5, l’authentification du serveur MD5, le hachage MD5 et le nonce MD5, consultez la spécification de sécurité de gestion des périphériques OMA (OMA-TS-DM_Security-V1_2_1-20080617-A), la gestion du code de réponse d’authentification et des échantillons pas à pas dans la spécification de protocole de gestion des périphériques OMA (OMA-TS-DM_Protocol-V1_2_1-20080617-A), disponible sur le site de l’OMA.

    Utilisateur ciblé vs. Configuration ciblée par périphérique

    Pour les CSP et les stratégies prenant en charge la configuration par utilisateur, le serveur MDM peut envoyer des valeurs de réglage ciblées par utilisateur au périphérique auquel un utilisateur inscrit à MDM est activement connecté. Le dispositif informe le serveur de l’état de connexion via une alerte de dispositif (1224) avec le type d’alerte = en pkg #1 de DM.

    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 MDM peut envoyer une configuration spécifique à l’utilisateur pour les CSP/stratégies prenant en charge la configuration par utilisateur
    • Autres – une autre connexion utilisateur, mais cet utilisateur n’a pas de compte MDM. Le serveur ne peut appliquer que la configuration à l’ensemble du périphérique, par exemple, la configuration s’applique à tous les utilisateurs du périphérique.
    • Aucun – aucune connexion utilisateur active. Le serveur ne peut appliquer que la configuration à l’ensemble de l’appareil et la configuration disponible est limitée à l’environnement de l’appareil (pas de connexion utilisateur active).

    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 notifie au périphérique s’il s’agit d’une configuration ciblée par un utilisateur ou un périphérique par un préfixe au LocURL du nœud de gestion, avec./ utilisateur pour la configuration ciblée par l’utilisateur, ou ./ périphérique pour la configuration ciblée du périphérique. Par défaut, si aucun préfixe avec ./ appareil ou./ utilisateur, il s’agit d’une configuration ciblée sur le périphérique.

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

    Le LocURL suivant affiche une configuration de nœud CSP par périphérique: ./device/vendor/MSFT/RemoteWipe/DoWipe

    Codes d’état de réponse SyncML

    Lorsque vous utilisez SyncML dans OMA DM, des codes d’état de réponse standard sont renvoyés. Le tableau suivant répertorie les codes d’état de réponse SyncML courants que vous êtes susceptible de voir. Pour plus d’informations sur les codes d’état de réponse SyncML, reportez-vous à 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 le traitement. Il s’agit généralement d’une opération asynchrone, telle qu’une demande d’exécution à distance d’une application.
    212 Authentification acceptée. Normalement, vous ne le verrez qu’en réponse à l’élément SyncHdr (utilisé pour l’authentification dans la norme OMA-DM). Vous pouvez le voir si vous regardez les journaux OMA DM, mais les CSP ne le génèrent généralement pas.
    214 Opération annulée. La commande SyncML s’est terminée avec succès, mais aucune autre commande ne sera traitée au cours de la session.
    215 Non exécuté. Une commande n’a pas été exécutée à la suite d’une interaction de l’utilisateur pour annuler la commande.
    216 Atomic reculez OK. Une commande se trouvait dans un élément Atomic et Atomic a échoué. Cette commande a été annulée avec succès.
    400 Mauvaise demande. La commande demandée n’a pas pu être exécutée en raison d’une syntaxe mal formée. Les CSP 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. La commande demandée a échoué car le demandeur doit fournir une authentification appropriée. Les EFPC 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 n’a pas été trouvée. Ce code sera généré si vous interrogez un nœud qui n’existe pas.
    405 Commande non autorisée. Ce code de réponse sera généré si vous essayez d’écrire sur un nœud en lecture seule.
    406 Fonctionnalité facultative non prise en charge. Ce code de réponse sera généré si vous essayez d’accéder à une propriété que le 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 XML ou de formatage.
    418 Existe déjà. Ce code de réponse se produit si vous essayez d’ajouter un nœud qui existe déjà.
    425 Permission Refusée. La commande demandée a échoué car l’expéditeur ne dispose pas d’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 La commande a échoué. Échec générique. Le destinataire a rencontré une condition inattendue qui l’a empêché de répondre à la demande. Ce code de réponse se produira lorsque le DPU SyncML ne peut pas mapper le code d’erreur d’origine.
    507 Atomic échec. L’une des opérations dans un bloc Atomic a échoué.
    516 Atomic la restauration a échoué. Une opération Atomic a échoué et la commande n’a pas été annulée avec succès.

    Laisser un commentaire

    Votre adresse e-mail ne sera pas publiée.