Unterstützung des OMA DM-Protokolls

Erstellt von am in Articles
  • Artikel
  • 12/16/2021
  • 12 minuten zum Lesen
    • D
    • M
    • eine
    • v
    • d
    • +11
Ist diese Seite hilfreich?

Vielen Dank.

Der OMA DM-Client kommuniziert mit dem Server über HTTPS und verwendet DM Sync (OMA DM v1.2) als Nachrichtennutzlast. In diesem Thema wird die OMA DM-Funktionalität beschrieben, die der DM-Client im Allgemeinen unterstützt. Die vollständige Beschreibung des OMA DM-Protokolls v1.2 finden Sie auf der OMA-Website.

OMA-DM-Standards

Die folgende Tabelle zeigt die von Windows verwendeten OMA-DM-Standards.

Allgemeiner Bereich OMA DM Standard, der unterstützt wird
Datentransport und Sitzung
  • Clientinitiierte Remote-HTTPS-DM-Sitzung über SSL.
  • Remote-HTTPS-DM-Sitzung über SSL.
  • Remote DM server initiierung Benachrichtigung mit WAP Push über Short Message Service (SMS). Nicht von Enterprise Management verwendet.
  • Remote-Bootstrap mit WAP-Push über SMS. Nicht von Enterprise Management verwendet.
    		•
    Bootstrap XML OMA-Client-Bereitstellung von XML.
    DM-Protokollbefehle Die folgende Liste zeigt die Befehle, die vom Gerät verwendet werden. Weitere Informationen zu den OMA DM-Befehlselementen finden Sie unter „OMA-Website“ auf der OMA-Website.

  • Hinzufügen (Implizites Hinzufügen wird unterstützt)
  • Warnung (DM-Warnung): Die generische Warnung (1226) wird vom Enterprise Management Client verwendet, wenn der Benutzer eine MDM-Deaktivierungsaktion vom Gerät aus auslöst oder wenn ein CSP einige asynchrone Aktionen beendet. Device alert (1224) wird verwendet, um den Server über ein vom Gerät ausgelöstes Ereignis zu informieren.
  • Atomic: Das Ausführen eines Add-Befehls gefolgt von Replace auf demselben Knoten innerhalb eines atomaren Elements wird nicht unterstützt. Verschachtelte Atomic- und Get-Befehle sind nicht zulässig und generieren den Fehlercode 500.
  • Löschen: Entfernt einen Knoten aus dem DM-Baum und den gesamten Unterbaum unter diesem Knoten, falls einer vorhanden ist
  • Exec: Ruft eine ausführbare Datei auf dem Clientgerät auf
  • Get: Ruft Daten vom Clientgerät ab; Für interne Knoten werden die untergeordneten Knotennamen im Datenelement im URI-codierten Format zurückgegeben
  • Replace: Überschreibt Daten auf dem Clientgerät
  • Result: Gibt die Datenergebnisse eines Get-Befehls zurück
  • Sequenz: Gibt die Reihenfolge an, in der eine Gruppe von Befehlen verarbeitet werden muss
  • Status: Gibt den Abschlussstatus (Erfolg oder Misserfolg) einer Operation an
    Wenn sich ein XML-Element, das kein gültiger OMA-DM-Befehl ist, unter einem der folgenden Elemente befindet, wird der Statuscode 400 für dieses Element zurückgegeben:
  • SyncBody
  • Atomic
  • Sequence
    Wenn im DM-Befehl keine CmdID angegeben ist, gibt der Client blank im status-Element und den Statuscode 400 zurück.
    Wenn atomare Elemente verschachtelt sind, werden die folgenden Statuscodes zurückgegeben:
  • Der Befehl nested Atomic gibt 500 zurück.
  • Der übergeordnete Atombefehl gibt 507 zurück.
    Weitere Informationen zum atomaren Befehl finden Sie unter Allgemeine Elemente des OMA DM-Protokolls.
    Das Ausführen eines Add-Befehls gefolgt von Replace auf demselben Knoten innerhalb eines atomaren Elements wird nicht unterstützt.
    LocURI kann nicht mit / beginnen.
    Meta XML Tag in SyncHdr wird vom Gerät ignoriert.
    		•
    OMA DM Standardobjekte DevInfo

  • DevDetail
  • OMA DM DMS Kontoobjekte (OMA DM Version 1.2)
    		•
    Sicherheit
  • DM-Server-Initiierungsbenachrichtigung per SMS authentifizieren (wird von der Unternehmensverwaltung nicht verwendet)
  • Basic- und MD5-Clientauthentifizierung auf Anwendungsebene
  • Server mit MD5-Anmeldeinformationen auf Anwendungsebene authentifizieren
  • Datenintegrität und Authentifizierung mit HMAC auf Anwendungsebene
  • Zertifikatbasierte Client/Server-Authentifizierung, Verschlüsselung und Datenintegrität auf SSL-Ebene prüfen
    		•
    Knoten Im OMA-DM-Baum gelten die folgenden Regeln für den Knotennamen:

  • „.“ kann Teil des Knotennamens sein.
  • Der Knotenname darf nicht leer sein.
  • Der Knotenname darf nicht nur das Sternchen (*) sein.
    		•
    Provisioning-Dateien Provisioning-XML muss wohlgeformt sein und der Definition in SyncML [Protocol](https://go.microsoft.com/fwlink/p/?LinkId=526905) folgen.
    Wenn sich unter SyncBody ein XML-Element befindet, das kein gültiger OMA-DM-Befehl ist, wird der Statuscode 400 für dieses Element zurückgegeben.

    Hinweis
    Um eine Unicode-Zeichenfolge als URI darzustellen, codieren Sie die Zeichenfolge zuerst als UTF-8. Codieren Sie dann jedes der UTF-8-Bytes mithilfe der URI-Codierung.
    WBXML-Unterstützung Windows unterstützt das Senden und Empfangen von SyncML sowohl im XML-Format als auch im codierten WBXML-Format. Dies kann mithilfe des DEFAULTENCODING-Knotens unter dem w7-Anwendungsmerkmal während der Registrierung konfiguriert werden. Weitere Informationen zur WBXML-Codierung finden Sie in Abschnitt 8 der SyncML Representation Protocol specification.
    Umgang mit großen Objekten In Windows 10, Version 1511, wurde die Clientunterstützung für das Hochladen großer Objekte auf den Server hinzugefügt.

    OMA DM Protokoll gemeinsame Elemente

    Gemeinsame Elemente werden von anderen OMA DM Elementtypen verwendet. In der folgenden Tabelle sind die allgemeinen OMA DM-Elemente aufgeführt, die zum Konfigurieren der Geräte verwendet werden. Weitere Informationen zu OMA DM Common Elements finden Sie unter „Verwendung des SyncML-Darstellungsprotokolls für die Geräteverwaltung“ (OMA-SyncML-DMRepPro-V1_1_2-20030613-A), das auf der OMA-Website verfügbar ist.

    Element Beschreibung
    Chal Gibt eine Authentifizierungsherausforderung an. Der Server oder Client kann eine Herausforderung an den anderen senden, wenn in der ursprünglichen Anforderungsnachricht keine oder unzureichende Anmeldeinformationen angegeben wurden.
    Cmd Gibt den Namen eines OMA DM-Befehls an, auf den in einem Status-Element verwiesen wird.
    CmdID Gibt den eindeutigen Bezeichner für einen OMA-DM-Befehl an.
    CmdRef Gibt die ID des Befehls an, für den Status- oder Ergebnisinformationen zurückgegeben werden. Dieses Element übernimmt den Wert des CmdID-Elements der entsprechenden Anforderungsnachricht.
    Cred Gibt den Authentifizierungsnachweis für den Absender der Nachricht an.
    Final Gibt an, dass die aktuelle Nachricht die letzte Nachricht im Paket ist.
    LocName Gibt den Anzeigenamen in den Ziel- und Quellelementen an, der zum Senden einer Benutzer-ID für die MD5-Authentifizierung verwendet wird.
    LocURI Gibt die Adresse des Ziel- oder Quellspeicherorts an. Wenn die Adresse ein nicht alphanumerisches Zeichen enthält, muss sie gemäß dem URL-Codierungsstandard ordnungsgemäß maskiert werden.
    MSGSTR Gibt einen eindeutigen Bezeichner für eine OMA DM-Sitzungsnachricht an.
    MsgRef Gibt die ID der entsprechenden Anforderungsnachricht an. Dieses Element nimmt den Wert des MsgID-Elements der Anforderungsnachricht an.
    RespURI Gibt den URI an, den der Empfänger beim Senden einer Antwort auf diese Nachricht verwenden muss.
    SessionID Gibt die Kennung der OMA DM-Sitzung an, die der enthaltenden Nachricht zugeordnet ist.

    Hinweis
    Wenn der Server das Gerät nicht darüber informiert, dass es eine neue Version unterstützt (über den Knoten SyncApplicationVersion im DMClient-CSP), gibt der Client die Sitzungs-ID als Ganzzahl im Dezimalformat zurück. Wenn der Server DM Session Sync Version 2.0 unterstützt, die in Windows 10 verwendet wird, gibt der Geräte-Client 2 Bytes zurück.
    Quelle Gibt die Adresse der Nachrichtenquelle an.
    SourceRef Gibt die Quelle der entsprechenden Anforderungsnachricht an. Dieses Element übernimmt den Wert des Anforderungsnachrichtenquellenelements und wird im Status- oder Ergebniselement zurückgegeben.
    Target Gibt die Adresse des Knotens im DM-Baum an, der das Ziel des Befehls OMA DM ist.
    TargetRef Gibt die Zieladresse in der entsprechenden Anforderungsnachricht an. Dieses Element übernimmt den Wert des Anforderungsnachrichtenzielelements und wird im Status- oder Ergebniselement zurückgegeben.
    VerDTD Gibt die Haupt- und Nebenversionskennung der OMA DM-Darstellungsprotokollspezifikation an, die zur Darstellung der Nachricht verwendet wird.
    VerProto Gibt die Haupt- und Nebenversionskennung der OMA DM-Protokollspezifikation an, die mit der Nachricht verwendet wird.

    Geräteverwaltungssitzung

    Eine Geräteverwaltungssitzung (DM) besteht aus einer Reihe von Befehlen, die zwischen einem DM-Server und einem Clientgerät ausgetauscht werden. Der Server sendet Befehle, die Vorgänge angeben, die in der Verwaltungsstruktur des Clientgeräts ausgeführt werden müssen. Der Client antwortet, indem er Befehle sendet, die die Ergebnisse und alle angeforderten Statusinformationen enthalten.

    Eine kurze DM-Sitzung kann wie folgt zusammengefasst werden:

    Ein Server sendet einen Get-Befehl an ein Clientgerät, um den Inhalt eines der Knoten der Verwaltungsstruktur abzurufen. Das Gerät führt den Vorgang aus und antwortet mit einem Ergebnisbefehl, der den angeforderten Inhalt enthält.

    Eine DM-Sitzung kann in zwei Phasen unterteilt werden:

    1. Setup-Phase: Als Reaktion auf ein Triggerereignis sendet ein Client-Gerät eine Initiierungsnachricht an einen DM-Server. Das Gerät und der Server tauschen erforderliche Authentifizierungs- und Geräteinformationen aus. Diese Phase wird durch die Schritte 1, 2 und 3 in der folgenden Tabelle dargestellt.
    2. Verwaltungsphase: Der DM-Server hat die Kontrolle. Es sendet Verwaltungsbefehle an das Gerät und das Gerät antwortet. Phase zwei endet, wenn der DM-Server keine Befehle mehr sendet und die Sitzung beendet. Diese Phase wird durch die Schritte 3, 4 und 5 in der folgenden Tabelle dargestellt.

    Die folgenden Informationen zeigen die Abfolge der Ereignisse während einer typischen DM-Sitzung.

    1. DM-Client wird aufgerufen, um den Management Server
      Enterprise-Szenario zurückzurufen – Der Geräteaufgabenzeitplan ruft den DM-Client auf.

      Der MO-Server sendet eine Server-Triggernachricht, um den DM-Client aufzurufen.

      Die Triggernachricht enthält die Server-ID und weist das Clientgerät an, eine Sitzung mit dem Server zu initiieren. Das Clientgerät authentifiziert die Triggernachricht und überprüft, ob der Server berechtigt ist, mit ihr zu kommunizieren.
      Unternehmensszenario – Zum geplanten Zeitpunkt wird der DM-Client regelmäßig aufgerufen, um den Enterprise Management Server über HTTPS aufzurufen.

    2. Das Gerät sendet eine Nachricht über eine IP-Verbindung, um die Sitzung zu initiieren.

      Diese Nachricht enthält Geräteinformationen und Anmeldeinformationen. Client und Server authentifizieren sich gegenseitig über einen SSL-Kanal oder auf DM-Anwendungsebene.

    3. Der DM-Server antwortet über eine IP-Verbindung (HTTPS). Der Server sendet ggf. erste Geräteverwaltungsbefehle.

    4. Das Gerät reagiert auf Serververwaltungsbefehle. Diese Nachricht enthält die Ergebnisse der Ausführung der angegebenen Geräteverwaltungsvorgänge.

    5. Der DM-Server beendet die Sitzung oder sendet einen anderen Befehl. Die DM-Sitzung endet oder Schritt 4 wird wiederholt.

    Die Schrittnummern stellen keine Nachrichtenidentifikationsnummern (MSGSTR) dar. Alle Nachrichten vom Server müssen eine MsgID haben, die innerhalb der Sitzung eindeutig ist, beginnend bei 1 für die erste Nachricht und erhöht sich um ein Inkrement von 1 für jede zusätzliche Nachricht. Weitere Informationen zu MsgID und dem OMA SyncML-Protokoll finden Sie unter OMA Device Management Representation Protocol (DM_RepPro-V1_2-20070209-A).

    Wenn während der gegenseitigen Authentifizierung auf OMA DM-Anwendungsebene der Geräte-Antwortcode für das Cred-Element in der Serveranforderung 212 ist, ist für den Rest der DM-Sitzung keine weitere Authentifizierung erforderlich. Bei der MD5-Authentifizierung kann das Chal-Element zurückgegeben werden. Dann muss die nächste Nonce in Chal für den MD5-Digest verwendet werden, wenn die nächste DM-Sitzung gestartet wird.

    Wenn eine Anforderung Anmeldeinformationen enthält und der Antwortcode für die Anforderung 200 lautet, muss dieselbe Berechtigung in der nächsten Anforderung gesendet werden. Wenn das Chal-Element enthalten ist und die MD5-Authentifizierung erforderlich ist, wird ein neuer Digest erstellt, indem die nächste Nonce über das Chal-Element für die nächste Anforderung verwendet wird.

    Weitere Informationen zur Basis- oder MD5-Clientauthentifizierung, MD5-Serverauthentifizierung, MD5-Hash und MD5-Nonce finden Sie in der OMA-Geräteverwaltungssicherheitsspezifikation (OMA-TS-DM_Security-V1_2_1-20080617-A), der Authentifizierungsantwortcodebehandlung und schrittweisen Beispielen in der OMA-Geräteverwaltungsprotokollspezifikation (OMA-TS-DM_Protocol-V1_2_1-20080617-A), verfügbar unter von der OMA-Website.

    Benutzer gezielt vs. Gerätebezogene Konfiguration

    Für CSPs und Richtlinien, die die Konfiguration pro Benutzer unterstützen, kann der MDM-Server benutzerbezogene Einstellungswerte an das Gerät senden, bei dem ein MDM-registrierter Benutzer aktiv angemeldet ist. Das Gerät benachrichtigt den Server über den Login-Status über einen Geräte-Alert (1224) mit Alert type = in DM pkg#1.

    Der Datenteil dieser Warnung könnte eine der folgenden Zeichenfolgen sein:

    • Benutzer – Der Benutzer, der das Gerät registriert hat, ist aktiv angemeldet. Der MDM-Server kann benutzerspezifische Konfigurationen für CSPs / Richtlinien senden, die pro Benutzerkonfiguration
    • Andere unterstützen – eine andere Benutzeranmeldung, aber dieser Benutzer verfügt nicht über ein MDM-Konto. Der Server kann nur eine geräteweite Konfiguration anwenden, z. B. gilt die Konfiguration für alle Benutzer im Gerät.
    • Keine – keine aktive Benutzeranmeldung. Der Server kann nur eine geräteweite Konfiguration anwenden und die verfügbare Konfiguration ist auf die Geräteumgebung beschränkt (keine aktive Benutzeranmeldung).

    Unten ist ein Warnungs-Beispiel:

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

    Der Server benachrichtigt das Gerät, ob es sich um eine Benutzer- oder Gerätekonfiguration handelt, indem er der LocURL des Verwaltungsknotens ein Präfix mit hinzufügt ./user für benutzerspezifische Konfiguration, bzw./device für geräteorientierte Konfiguration. Standardmäßig, wenn kein Präfix mit ./gerät oder ./benutzer, es ist gerät gezielte konfiguration.

    Die folgende LocURL zeigt eine CSP-Knotenkonfiguration pro Benutzer an: ./user/vendor/MSFT/EnterpriseModernAppManagement/AppInstallation/<PackageFamilyName>/StoreInstall

    Die folgende LocURL zeigt eine CSP-Knotenkonfiguration pro Gerät: ./device/vendor/MSFT/RemoteWipe/DoWipe

    SyncML-Antwortstatuscodes

    Bei Verwendung von SyncML in OMA DM werden standardmäßige Antwortstatuscodes zurückgegeben. In der folgenden Tabelle sind die allgemeinen SyncML-Antwortstatuscodes aufgeführt, die wahrscheinlich angezeigt werden. Weitere Informationen zu SyncML-Antwortstatuscodes finden Sie in Abschnitt 10 der SyncML Representation Protocol Specification.

    Statuscode Beschreibung
    200 Der Befehl SyncML wurde erfolgreich abgeschlossen.
    202 Zur Bearbeitung angenommen. Dies ist normalerweise ein asynchroner Vorgang, z. B. eine Anforderung zum Ausführen einer Remoteausführung einer Anwendung.
    212 Authentifizierung akzeptiert. Normalerweise sehen Sie dies nur als Antwort auf das SyncHdr-Element (das für die Authentifizierung im OMA-DM-Standard verwendet wird). Sie können dies sehen, wenn Sie sich OMA-DM-Protokolle ansehen, aber CSPs generieren dies normalerweise nicht.
    214 Operation abgebrochen. Der SyncML-Befehl wurde erfolgreich abgeschlossen, es werden jedoch keine weiteren Befehle innerhalb der Sitzung verarbeitet.
    215 Nicht ausgeführt. Ein Befehl wurde nicht als Ergebnis der Benutzerinteraktion ausgeführt, um den Befehl abzubrechen.
    216 Atomic rollback OK. Ein Befehl befand sich in einem Atomic -Element und Atomic ist fehlgeschlagen. Dieser Befehl wurde erfolgreich zurückgesetzt.
    400 Schlechte Anfrage. Der angeforderte Befehl konnte aufgrund einer fehlerhaften Syntax nicht ausgeführt werden. CSPs generieren diesen Fehler normalerweise nicht, Sie können ihn jedoch sehen, wenn Ihre SyncML fehlerhaft ist.
    401 Ungültige Anmeldeinformationen. Der angeforderte Befehl ist fehlgeschlagen, da der Anforderer eine ordnungsgemäße Authentifizierung bereitstellen muss. CSPs generieren diesen Fehler normalerweise nicht.
    403 Verboten. Der angeforderte Befehl ist fehlgeschlagen, aber der Empfänger hat den angeforderten Befehl verstanden.
    404 Nicht gefunden. Die angeforderte Seite konnte nicht gefunden werden. Dieser Code wird generiert, wenn Sie einen Knoten abfragen, der nicht existiert.
    405 Befehl nicht erlaubt. Dieser Antwortcode wird generiert, wenn Sie versuchen, in einen schreibgeschützten Knoten zu schreiben.
    406 Optionale Funktion nicht unterstützt. Dieser Antwortcode wird generiert, wenn Sie versuchen, auf eine Eigenschaft zuzugreifen, die der CSP nicht unterstützt.
    415 Nicht unterstützter Typ oder Format. Dieser Antwortcode kann aus XML-Analyse- oder Formatierungsfehlern resultieren.
    418 Existiert bereits. Dieser Antwortcode tritt auf, wenn Sie versuchen, einen bereits vorhandenen Knoten hinzuzufügen.
    425 Erlaubnis verweigert. Der angeforderte Befehl ist fehlgeschlagen, da der Absender nicht über ausreichende Zugriffssteuerungsberechtigungen (ACL) für den Empfänger verfügt. „Zugriff verweigert“ -Fehler werden normalerweise in diesen Antwortcode übersetzt.
    500 Befehl fehlgeschlagen. Generisches Versagen. Der Empfänger ist auf eine unerwartete Bedingung gestoßen, die ihn daran hinderte, die Anforderung zu erfüllen. Dieser Antwortcode tritt auf, wenn die SyncML-DPU den ursprünglichen Fehlercode nicht zuordnen kann.
    507 Atomic gescheitert. Eine der Operationen in einem Atomic -Block ist fehlgeschlagen.
    516 Atomic rollback fehlgeschlagen. Ein Atomic -Vorgang ist fehlgeschlagen, und der Befehl wurde nicht erfolgreich zurückgesetzt.

    Schreibe einen Kommentar

    Deine E-Mail-Adresse wird nicht veröffentlicht.