OMA DM-protocol ondersteuning

  • Artikel
  • 12/16/2021
  • 12 minuten te lezen
    • D
    • M
    • een
    • v
    • d
    • +11
Is deze pagina nuttig?

Dank u.

de OMA DM client communiceert met de server via HTTPS en gebruikt DM Sync (OMA DM v1. 2) als het bericht payload. Dit onderwerp beschrijft de OMA DM functionaliteit die de DM client in het algemeen ondersteunt. De volledige beschrijving van het OMA DM protocol v1.2 is te vinden op de OMA website.

OMA DM standards

de volgende tabel toont de OMA DM standards die Windows gebruikt.

Algemeen gebied OMA DM-standaard die wordt ondersteund
Data transport en sessie
  • Client-geïnitieerde externe https DM sessie via SSL.
  • externe https DM-sessie via SSL.
  • remote DM server initiation notification using WAP Push over Short Message Service (SMS). Niet gebruikt door enterprise management.
  • bootstrap op afstand met behulp van WAP Push over SMS. Niet gebruikt door enterprise management.
  • Bootstrap XML OMA Client Provisioning XML.
    DM protocol commando ‘s de volgende lijst toont de commando’ s die door het apparaat worden gebruikt. Voor meer informatie over de OMA DM Commando elementen, zie “OMA website” beschikbaar op de OMA website.

  • Add (impliciet toevoegen ondersteund)
  • Alert (DM alert): Generic alert (1226) wordt gebruikt door enterprise management client wanneer de gebruiker een MDM uninrollment actie vanaf het apparaat activeert of wanneer een CSP een aantal asynchrone acties voltooit. Apparaatwaarschuwing (1224) wordt gebruikt om de server op de hoogte te stellen van een door een apparaat veroorzaakte gebeurtenis.
  • atomisch: het uitvoeren van een Add-opdracht gevolgd door Replace op hetzelfde knooppunt binnen een atomair element wordt niet ondersteund. Geneste atomaire en Get commando ‘ s zijn niet toegestaan en zal fout code 500 genereren.
  • verwijderen: Verwijdert een knooppunt van de DM-boom, en de hele deelboom onder dat knooppunt indien aanwezig
  • Exec: Roept een uitvoerbaar bestand op de client-apparaat
  • Get: Haalt gegevens van de client-apparaat; voor het interieur knooppunten, het kind node namen in het Data-element worden geretourneerd in de URI-encoded-format
  • Plaats: Overschrijft de gegevens op de client-apparaat
  • Resultaat: Geeft als resultaat de gegevens de resultaten van een Get-opdracht naar de DM server
  • Reeks: Bepaalt de volgorde waarin een groep van commando ‘ s moet worden uitgevoerd.
  • Status: Geeft de voltooiingsstatus (succes of mislukking) aan van een operatie
    als een XML-element dat geen geldige OMA DM-opdracht is onder een van de volgende elementen staat, wordt de statuscode 400 voor dat element geretourneerd:
  • SyncBody
  • Atomic
  • sequentie
    als er geen CmdID is opgegeven in het DM commando, geeft de client blanco terug in het statuselement en de statuscode 400.
    als atomaire elementen genest zijn, worden de volgende statuscodes geretourneerd:
  • het geneste atomaire commando geeft 500 terug.
  • het bovenliggende atomaire commando geeft 507 terug.
    voor meer informatie over het atomaire Commando, zie OMA DM protocol common elements.
    het uitvoeren van een commando toevoegen gevolgd door vervangen op hetzelfde knooppunt binnen een atomair element wordt niet ondersteund.
    LocURI kan niet beginnen met /.
    meta XML tag in SyncHdr wordt genegeerd door het apparaat.
  • OMA DM standard objects DevInfo

  • DevDetail
  • OMA DM DMS account objects (OMA DM versie 1.2)
  • Beveiliging
  • Verifiëren DM server initiatie SMS bericht (niet gebruikt door enterprise management)
  • Application layer Basis-en MD5-client authenticatie
  • Authenticatie server met MD5 identificatie op applicatie niveau
  • Data-integriteit en de verificatie met HMAC op applicatie niveau
  • SSL-certificaat niveau-gebaseerde client/server-verificatie, codering en data-integriteit controleren
  • Knooppunten In de OMA DM boom, de volgende regels van toepassing voor de naam van het knooppunt:

  • “.”kan deel uitmaken van de node naam.
  • de node naam mag niet leeg zijn.
  • de naam van het knooppunt kan niet alleen het sterretje ( * ) zijn.
  • Provisioning Files Provisioning XML moet goed gevormd zijn en de definitie volgen in SyncML Representation Protocol] (https://go.microsoft.com/fwlink/p/?LinkId=526905).
    als een XML-element dat geen geldig OMA DM-commando is onder SyncBody staat, wordt de statuscode 400 geretourneerd voor dat element.

    Note
    om een Unicode-string als een URI weer te geven, codeer je de string eerst als UTF-8. Vervolgens codeert u elk van de UTF-8 bytes met behulp van URI-codering.
    WBXML-ondersteuning Windows ondersteunt het verzenden en ontvangen van SyncML in zowel XML-als gecodeerde WBXML-indeling. Dit kan worden geconfigureerd met behulp van het DEFAULTENCODING-knooppunt onder de W7-TOEPASSINGSKARAKTERISTIEK tijdens de inschrijving. Zie paragraaf 8 van de specificatie van het SyncML-Representatieprotocol voor meer informatie over WBXML-codering.
    afhandeling van grote objecten in Windows 10, versie 1511, werd clientondersteuning toegevoegd voor het uploaden van grote objecten naar de server.

    OMA DM protocol common elements

    Common elements worden gebruikt door andere OMA DM element types. De volgende tabel toont de OMA DM common elementen die gebruikt worden om de apparaten te configureren. Voor meer informatie over OMA DM common elements, zie “SyncML Representation Protocol Device Management Usage” (OMA-SyncML-DMRepPro-V1_1_2-20030613-A) beschikbaar op de OMA website.

    Element beschrijving
    Chal specificeert een authenticatie-uitdaging. De server of client kan een uitdaging naar de andere sturen als er geen referenties of inadequate referenties zijn gegeven in het oorspronkelijke verzoekbericht.
    Cmd specificeert de naam van een OMA DM-opdracht waarnaar in een Statuselement wordt verwezen.
    CmdID specificeert de unieke identifier voor een OMA DM Commando.
    CmdRef specificeert de ID van het commando waarvoor status-of resultaatinformatie wordt geretourneerd. Dit element neemt de waarde van het CmdID-element van het overeenkomstige verzoekbericht.
    Cred geeft de aanmeldingsreferentie aan voor de afzender van het bericht.
    Final geeft aan dat het huidige bericht Het Laatste bericht in het pakket is.
    LocName specificeert de weergavenaam in de doel-en bronelementen, gebruikt voor het verzenden van een gebruikers-ID voor MD5-verificatie.
    LocURI specificeert het adres van de doel-of bronlocatie. Als het adres een niet-alfanumeriek teken bevat, moet het correct worden escaped volgens de URL-coderingsstandaard.
    MsgID specificeert een unieke identifier voor een OMA DM sessiebericht.
    MsgRef specificeert de ID van het overeenkomstige verzoekbericht. Dit element neemt de waarde van het msgid-element van het verzoekbericht.
    RespURI geeft de URI aan die de ontvanger moet gebruiken bij het verzenden van een antwoord op dit bericht.
    SessionID specificeert de identifier van de OMA DM-sessie die geassocieerd is met het bericht dat het bevat.

    opmerking
    als de server het apparaat niet meldt dat het een nieuwe versie ondersteunt (via SyncApplicationVersion node in de DMCLIENT CSP), retourneert de client de SessionID in integer in decimaal formaat. Als de server DM session sync versie 2.0 ondersteunt, die wordt gebruikt in Windows 10, retourneert de apparaatclient 2 bytes.
    bron geeft het bronadres van het bericht aan.
    SourceRef geeft de bron van het overeenkomstige verzoekbericht aan. Dit element neemt de waarde van het bronelement van het verzoekbericht en wordt geretourneerd in het element Status of resultaten.
    Target specificeert het adres van het knooppunt, in de DM-Boom, dat het doel is van het OMA DM-Commando.
    TargetRef specificeert het doeladres in het overeenkomstige verzoekbericht. Dit element neemt de waarde van het doelelement van het verzoekbericht en wordt geretourneerd in het element Status of resultaten.
    VerDTD specificeert de major en minor version identifier van de OMA DM representation protocol specification gebruikt om het bericht weer te geven.
    VerProto specificeert de major en minor version identifier van de OMA DM protocol specificatie gebruikt met het bericht.

    Apparaatbeheersessie

    een Apparaatbeheers-sessie (DM) bestaat uit een reeks opdrachten die worden uitgewisseld tussen een DM-server en een client-apparaat. De server verzendt opdrachten die bewerkingen aangeven die moeten worden uitgevoerd op de beheerstructuur van het clientapparaat. De client reageert door commando ‘ s te sturen die de resultaten en alle gevraagde statusinformatie bevatten.

    een korte DM-sessie kan als volgt worden samengevat:

    een server stuurt een Get-opdracht naar een client-apparaat om de inhoud van een van de knooppunten van de beheerstructuur op te halen. Het apparaat voert de bewerking uit en reageert met een Resultaatopdracht die de gevraagde inhoud bevat.

    een DM-sessie kan in twee fasen worden verdeeld:

    1. Instellingsfase: als reactie op een triggergebeurtenis stuurt een client-apparaat een initiërend bericht naar een DM-server. De device and server exchange had authenticatie en apparaatinformatie nodig. Deze fase wordt weergegeven door de stappen 1, 2 en 3 in de volgende tabel.
    2. Beheersfase: de DM-server heeft de controle. Het stuurt Beheer commando ‘ s naar het apparaat en het apparaat reageert. Fase twee eindigt wanneer de DM server stopt met het verzenden van commando ‘ s en de sessie beëindigt. Deze fase wordt weergegeven door de stappen 3, 4 en 5 in de volgende tabel.

    de volgende informatie toont de volgorde van gebeurtenissen tijdens een typische DM-sessie.

    1. DM client wordt aangeroepen om terug te bellen naar de beheerserver
      Enterprise scenario – het apparaat taakschema roept de DM client.

      de MO-server verzendt een trigger-bericht voor de server om de DM-client aan te roepen.

      het triggerbericht bevat de server-ID en vertelt het clientapparaat om een sessie met de server te starten. Het clientapparaat verifieert het triggerbericht en controleert of de server gemachtigd is om ermee te communiceren.
      Ondernemingsscenario: op het geplande tijdstip wordt de DM-client periodiek aangeroepen om via HTTPS terug te bellen naar de enterprise managementserver.

    2. het apparaat verzendt via een IP-verbinding een bericht om de sessie te starten.

      dit bericht bevat apparaatinformatie en referenties. De client en server doen wederzijdse authenticatie via een SSL-kanaal of op DM-applicatieniveau.

    3. de DM server reageert, via een IP-verbinding (HTTPS). De server verzendt eventuele Eerste apparaatbeheercommando ‘ s.

    4. het apparaat reageert op serverbeheercommando ‘ s. Dit bericht bevat de resultaten van het uitvoeren van de gespecificeerde apparaatbeheerbewerkingen.

    5. de DM server beëindigt de sessie of stuurt een ander commando. De DM sessie eindigt, of Stap 4 wordt herhaald.

    de stapnummers staan niet voor message identification numbers (msgid). Alle berichten van de server moeten een msgid hebben dat uniek is binnen de sessie, beginnend bij 1 Voor het eerste bericht, en oplopend met een toename van 1 voor elk extra bericht. Zie OMA Device Management Representation Protocol (DM_REPPRO-V1_2-20070209-A) voor meer informatie over het msgid-en OMA SyncML-protocol.

    tijdens OMA DM application level wederzijdse authenticatie is, als de apparaatresponscode voor het Cred-element in het serververzoek 212 is, geen verdere authenticatie nodig voor de rest van de DM-sessie. In het geval van de MD5 authenticatie kan het Chal element worden geretourneerd. Dan moet de volgende nonce in Chal worden gebruikt voor de MD5 digest wanneer de volgende DM sessie wordt gestart.

    als een verzoek referenties bevat en de antwoordcode op het verzoek 200 is, moet dezelfde informatie binnen het volgende verzoek worden verzonden. Als het Chal-element is opgenomen en de MD5-authenticatie is vereist, wordt een nieuwe digest aangemaakt door het volgende nonce via het Chal-element te gebruiken voor het volgende verzoek.

    voor meer informatie over Basis-of MD5-clientverificatie, MD5-serververificatie, MD5-hash en MD5 nonce, zie de OMA-Apparaatbeheerbeveiligingsspecificatie (OMA-TS-DM_Security-V1_2_1-20080617-a), verwerking van authenticatieresponscodes en stapsgewijze voorbeelden in OMA-Apparaatbeheerprotocolspecificatie (OMA-TS-DM_Protocol-V1_2_1-20080617-A), beschikbaar op de OMA-website.

    gebruiker gericht vs. Apparaatgeoriënteerde configuratie

    voor CSP ‘ s en beleid dat configuratie per gebruiker ondersteunt, kan de MDM-server gebruikersgeoriënteerde instellingswaarden sturen naar het apparaat waarop een MDM-ingeschreven gebruiker actief is aangemeld. Het apparaat waarschuwt de server over de login status via een device alert (1224) met Alert type = in DM pkg#1.

    het gegevensgedeelte van deze waarschuwing kan een van de volgende tekenreeksen zijn:

    • gebruiker: de gebruiker die het apparaat heeft ingeschreven, is actief aangemeld. De MDM-server kan gebruikersspecifieke configuratie verzenden voor CSP ‘ s/beleid dat per gebruiker configuratie
    • anderen ondersteunt – een andere gebruiker login maar die gebruiker heeft geen MDM-account. De server kan alleen apparaatbrede configuratie toepassen, de configuratie is bijvoorbeeld van toepassing op alle gebruikers in het apparaat.
    • geen-geen actieve gebruiker login. De server kan alleen apparaatbrede configuratie toepassen en de beschikbare configuratie is beperkt tot de apparaatomgeving (geen actieve Gebruikerslogin).

    Hieronder is een waarschuwingsvoorbeeld:

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

    de server waarschuwt het apparaat of het een gebruiker gerichte of apparaat gerichte configuratie door een prefix naar het beheer node LocURL, met./ user Voor gebruiker gerichte configuratie, of ./ device voor apparaatgerichte configuratie. Standaard, als er geen prefix met ./ apparaat of ./ gebruiker, het is Apparaat gerichte configuratie.

    de volgende LocURL toont een CSP-knooppuntconfiguratie per gebruiker: ./user/vendor/MSFT/EnterpriseModernAppManagement/AppInstallation/<PackageFamilyName>/StoreInstall

    de volgende LocURL toont een CSP-knooppuntconfiguratie per apparaat: ./ device/vendor/MSFT/RemoteWipe / DoWipe

    SyncML-responsstatuscodes

    bij gebruik van SyncML in OMA DM zijn er standaard responsstatuscodes die worden geretourneerd. In de volgende tabel staan de Algemene SyncML-responsstatuscodes die u waarschijnlijk zult zien. Zie paragraaf 10 van de specificatie van het SyncML-Representatieprotocol voor meer informatie over SyncML-responsstatuscodes.

    statuscode beschrijving
    200 de opdracht SyncML is succesvol voltooid.
    202 aanvaard voor verwerking. Dit is meestal een asynchrone operatie, zoals een verzoek om een externe uitvoering van een toepassing uit te voeren.
    212 authenticatie geaccepteerd. Normaal gesproken zie je dit alleen als reactie op het SyncHdr element (gebruikt voor authenticatie in de OMA-DM standaard). U kunt dit zien als je kijkt naar OMA DM logs, maar CSP ‘ s meestal niet genereren dit.
    214 operatie geannuleerd. De SyncML-opdracht is succesvol voltooid, maar er worden geen opdrachten meer verwerkt binnen de sessie.
    215 niet geëxecuteerd. Een commando is niet uitgevoerd als gevolg van gebruikersinteractie om het commando te annuleren.
    216 Atomic terugrollen, oké. Een opdracht was in een Atomic element en Atomic is mislukt. Dit commando is met succes teruggedraaid.
    400 slecht verzoek. De gevraagde opdracht kon niet worden uitgevoerd vanwege onjuiste syntaxis. CSP ‘ s meestal niet genereren deze fout, maar je zou het kunnen zien als uw SyncML is misvormd.
    401 ongeldige referenties. Het gevraagde commando is mislukt omdat de aanvrager de juiste authenticatie moet geven. CSP ‘ s genereren deze fout meestal niet.
    403 verboden. De gevraagde opdracht is mislukt, maar de ontvanger heeft de gevraagde opdracht begrepen.
    404 niet gevonden. Het gevraagde doel is niet gevonden. Deze code wordt gegenereerd als u een node opvraagt die niet bestaat.
    405 opdracht niet toegestaan. Deze antwoordcode wordt gegenereerd als u probeert te schrijven naar een alleen-lezen node.
    406 optionele functie niet ondersteund. Deze reactiecode wordt gegenereerd als u toegang probeert te krijgen tot een eigenschap die de CSP niet ondersteunt.
    415 niet ondersteund type of formaat. Deze reactiecode kan het gevolg zijn van XML-parseer-of opmaakfouten.
    418 bestaat al. Deze antwoordcode treedt op als u probeert een knooppunt toe te voegen dat al bestaat.
    425 Toestemming Geweigerd. De gevraagde opdracht is mislukt omdat de afzender geen adequate ACL (access control permissions) voor de ontvanger heeft. “Toegang geweigerd” fouten worden meestal vertaald naar deze reactie code.
    500 opdracht mislukt. Algemene mislukking. De ontvanger is op een onverwachte voorwaarde gestuit waardoor hij niet aan het verzoek kon voldoen. Deze antwoordcode treedt op wanneer de SyncML-DPU de foutcode van oorsprong niet kan toewijzen.
    507 Atomic mislukt. Een van de bewerkingen in een Atomic – blok is mislukt.
    516 Atomic terugdraaien mislukt. Een Atomic operatie is mislukt en de opdracht is niet met succes teruggedraaid.

    Geef een antwoord

    Het e-mailadres wordt niet gepubliceerd.