suport pentru protocolul OMA DM

Written by on in Articles
  • articol
  • 12/16/2021
  • 12 minute de citit
    • D
    • M
    • a
    • v
    • d
    • +11
este utilă această pagină?

mulțumesc.

clientul OMA DM comunică cu serverul prin HTTPS și utilizează DM Sync (OMA DM v1.2) ca sarcină utilă a mesajului. Acest subiect descrie funcționalitatea OMA DM pe care clientul DM o acceptă în general. Descrierea completă a protocolului OMA DM v1.2 poate fi găsită pe site-ul OMA.

standarde OMA DM

următorul tabel prezintă standardele OMA DM pe care Windows le utilizează.

zona generală standardul OMA DM care este acceptat
transport de date și sesiune
  • sesiune HTTPS DM inițiată de Client prin SSL.
  • sesiune HTTPS DM la distanță prin SSL.
  • notificare de inițiere a serverului DM la distanță utilizând serviciul de mesaje scurte (SMS) WAP Push over. Nu este utilizat de managementul întreprinderii.
  • bootstrap la distanță prin utilizarea WAP Push over SMS. Nu este utilizat de managementul întreprinderii.
    		•
    Bootstrap XML oma client de aprovizionare XML.
    comenzile protocolului DM următoarea listă afișează comenzile utilizate de dispozitiv. Pentru mai multe informații despre elementele de comandă OMA DM, consultați „site-ul OMA” disponibil de pe site-ul OMA.

  • Add (implicit Add supported)
  • Alert (DM alert): Alert Generic (1226) este utilizat de enterprise management client atunci când utilizatorul declanșează o acțiune MDM unenrollment de pe dispozitiv sau atunci când un CSP termină unele acțiuni asincrone. Device alert (1224) este utilizat pentru a notifica serverul un eveniment declanșat de dispozitiv.
  • Atomic: efectuarea unei comenzi de adăugare urmată de înlocuire pe același nod dintr-un element atomic nu este acceptată. Comenzile Atomice și Get imbricate nu sunt permise și vor genera codul de eroare 500.
  • se șterge: Elimină un nod din arborele DM și întregul subarbor sub acel nod dacă există
  • Exec: invocă un executabil pe dispozitivul client
  • Get: preia datele de pe dispozitivul client; pentru nodurile interioare, numele nodului copil din elementul de date sunt returnate în format codificat URI
  • Replace: suprascrie datele de pe dispozitivul client
  • Result: returnează rezultatele de date ale unui obțineți comanda către serverul DM
  • secvență: specifică ordinea în care trebuie procesat un grup de comenzi
  • stare: Indică starea de finalizare (succes sau eșec) a unei operații
    dacă un element XML care nu este o comandă oma DM validă se află sub unul dintre următoarele elemente, codul de stare 400 este returnat pentru acel element:
  • SyncBody
  • Atomic
  • secvență
    dacă nu este furnizat CmdID în comanda DM, clientul returnează necompletat în elementul de stare și Codul de stare 400.
    dacă elementele atomice sunt imbricate, următoarele coduri de stare sunt returnate:
  • comanda atomică imbricată returnează 500.
  • comanda atomică părinte returnează 507.
    pentru mai multe informații despre comanda atomică, consultați elemente comune ale protocolului OMA DM.
    efectuarea unei comenzi de adăugare urmată de înlocuire pe același nod dintr-un element Atomic nu este acceptată.
    locurile nu pot începe cu /.
    eticheta meta XML în SyncHdr este ignorată de dispozitiv.
    		•
    OMA DM obiecte standard DevInfo

  • DevDetail
  • oma DM DMS obiecte de cont (oma DM versiunea 1.2)
    		•
    securitate
  • autentifica DM Server inițiere notificare mesaj SMS (nu este utilizat de enterprise management)
  • aplicarea layer Basic și MD5 autentificare client
  • autentifica server cu MD5 acreditare la nivel de aplicație
  • integritatea datelor și autentificare cu HMAC la nivel de aplicație
  • SSL nivel certificat client/server de autentificare, criptare, și verificarea integrității
    		•
    noduri în arborele OMA DM, următoarele reguli se aplică pentru numele nodului:

  • „.”poate face parte din numele nodului.
  • numele nodului nu poate fi gol.
  • numele nodului nu poate fi doar caracterul asterisc ( * ).
    		•
    furnizarea fișierelor furnizarea XML trebuie să fie bine formată și să urmeze definiția din Protocolul de reprezentare SyncML] (https://go.microsoft.com/fwlink/p/?LinkId=526905).
    dacă un element XML care nu este o comandă oma DM validă se află sub SyncBody, codul de stare 400 este returnat pentru acel element.

    notă
    pentru a reprezenta un șir Unicode ca URI, codificați mai întâi șirul ca UTF-8. Apoi codificați fiecare dintre octeții UTF-8 folosind codificarea URI.
    suport WBXML Windows acceptă trimiterea și primirea SyncML atât în format XML, cât și în format WBXML codat. Acest lucru este configurabil utilizând nodul DEFAULTENCODING sub caracteristica aplicației w7 în timpul înscrierii. Pentru mai multe informații despre codificarea WBXML, consultați secțiunea 8 a specificației Protocolului de reprezentare SyncML.
    manipularea obiectelor mari în Windows 10, versiunea 1511, a fost adăugat suport client pentru încărcarea obiectelor mari pe server.

    elementele comune ale protocolului OMA DM

    elementele comune sunt utilizate de alte tipuri de elemente OMA dm. Următorul tabel listează elementele comune OMA DM utilizate pentru configurarea dispozitivelor. Pentru mai multe informații despre oma DM elemente comune, consultați „SyncML Representation Protocol Device Management Usage” (Oma-SyncML-DMRepPro-V1_1_2-20030613-a) Disponibil de pe site-ul OMA.

    Element descriere
    Chal specifică o provocare de autentificare. Serverul sau Clientul poate trimite o provocare celuilalt dacă nu au fost date acreditări sau acreditări inadecvate în mesajul inițial de solicitare.
    Cmd specifică numele unei comenzi OMA DM la care se face referire într-un element de stare.
    CmdID specifică identificatorul unic pentru o comandă OMA DM.
    CmdRef specifică ID-ul comenzii pentru care informațiile de stare sau rezultate sunt returnate. Acest element ia valoarea elementului CmdID al mesajului de solicitare corespunzător.
    Cred specifică acreditarea de autentificare pentru inițiatorul mesajului.
    Final indică faptul că mesajul curent este ultimul mesaj din pachet.
    LocName specifică numele afișat în elementele țintă și sursă, utilizat pentru trimiterea unui ID de utilizator pentru autentificarea MD5.
    LocURI specifică adresa Locației țintă sau sursă. Dacă adresa conține un caracter non-alfanumeric, acesta trebuie scăpat în mod corespunzător în conformitate cu standardul de codificare URL.
    msgstr specifică un identificator unic pentru un mesaj de sesiune OMA DM.
    MsgRef specifică ID-ul mesajului de solicitare corespunzător. Acest element ia valoarea elementului mesaj de solicitare msgstr.
    RespURI specifică URI-ul pe care destinatarul trebuie să îl utilizeze atunci când trimite un răspuns la acest mesaj.
    SessionID specifică identificatorul sesiunii OMA DM asociat mesajului care conține.

    notă
    dacă serverul nu notifică dispozitivul că acceptă o nouă versiune (prin nodul SyncApplicationVersion în CSP DMClient), clientul returnează SessionID în întreg în format zecimal. Dacă serverul acceptă versiunea 2.0 DM session sync, care este utilizată în Windows 10, clientul dispozitivului returnează 2 octeți.
    Sursa specifică adresa sursei mesajului.
    SourceRef specifică sursa mesajului de solicitare corespunzător. Acest element ia valoarea elementului sursă al mesajului de solicitare și este returnat în elementul Stare sau rezultate.
    Target specifică adresa nodului, în arborele DM, care este ținta comenzii OMA DM.
    TargetRef specifică adresa țintă în mesajul de solicitare corespunzător. Acest element ia valoarea elementului țintă al mesajului de solicitare și este returnat în elementul Stare sau rezultate.
    VerDTD specifică identificatorul versiunii majore și minore a specificației Protocolului de reprezentare OMA DM utilizat pentru a reprezenta mesajul.
    VerProto specifică identificatorul versiunii majore și minore a specificației protocolului OMA DM utilizat împreună cu mesajul.

    sesiunea de gestionare a dispozitivelor

    o sesiune de gestionare a dispozitivelor (DM) constă dintr-o serie de comenzi schimbate între un server DM și un dispozitiv client. Serverul trimite comenzi care indică operațiuni care trebuie efectuate pe arborele de gestionare al dispozitivului client. Clientul răspunde prin trimiterea de comenzi care conțin rezultatele și orice informații de stare solicitate.

    o scurtă sesiune DM poate fi rezumată după cum urmează:

    un server trimite o comandă Get către un dispozitiv client pentru a prelua conținutul unuia dintre nodurile arborelui de gestionare. Dispozitivul efectuează operația și răspunde cu o comandă de rezultat care conține conținutul solicitat.

    o sesiune DM poate fi împărțită în două faze:

    1. faza de configurare: ca răspuns la un eveniment declanșator, un dispozitiv client trimite un mesaj de inițiere către un server DM. Schimbul de dispozitive și servere avea nevoie de autentificare și informații despre dispozitiv. Această fază este reprezentată de pașii 1, 2 și 3 din tabelul următor.
    2. faza de gestionare: serverul DM este în control. Trimite comenzi de gestionare către dispozitiv și dispozitivul răspunde. Faza a doua se termină atunci când serverul DM nu mai trimite comenzi și termină sesiunea. Această fază este reprezentată de pașii 3, 4 și 5 din tabelul următor.

    următoarele informații arată succesiunea evenimentelor din timpul unei sesiuni DM tipice.

    1. client DM este invocat pentru a apela înapoi la serverul de management
      scenariu Enterprise – programul de activitate dispozitiv invocă clientul DM.

      serverul MO trimite un mesaj de declanșare a serverului pentru a invoca clientul DM.

      mesajul de declanșare include ID-ul serverului și spune dispozitivului client să inițieze o sesiune cu serverul. Dispozitivul client autentifică mesajul declanșator și verifică dacă serverul este autorizat să comunice cu acesta.
      Enterprise scenario – la ora programată, clientul DM este invocat periodic pentru a apela înapoi la serverul de management al întreprinderii prin HTTPS.

    2. dispozitivul trimite un mesaj, printr-o conexiune IP, pentru a iniția sesiunea.

      acest mesaj include informații despre dispozitiv și acreditări. Clientul și serverul efectuează autentificarea reciprocă pe un canal SSL sau la nivelul aplicației DM.

    3. serverul DM răspunde, printr-o conexiune IP (HTTPS). Serverul trimite comenzi inițiale de gestionare a dispozitivului, dacă există.

    4. dispozitivul răspunde la comenzile de gestionare a serverului. Acest mesaj include rezultatele efectuării operațiunilor de gestionare a dispozitivului specificate.

    5. serverul DM termină sesiunea sau trimite o altă comandă. Sesiunea DM se încheie sau se repetă pasul 4.

    numerele de pas nu reprezintă numerele de identificare a mesajelor (msgstr). Toate mesajele de pe server trebuie să aibă un msgstr unic în cadrul sesiunii, începând de la 1 pentru primul mesaj și crescând cu o creștere de 1 pentru fiecare mesaj suplimentar. Pentru mai multe informații despre protocolul msgid și OMA SyncML, consultați Protocolul de reprezentare a gestionării dispozitivelor OMA (DM_RepPro-V1_2-20070209-a).

    în timpul autentificării reciproce la nivel de aplicație OMA DM, dacă codul de răspuns al dispozitivului la elementul Cred din cererea serverului este 212, nu este necesară nicio autentificare suplimentară pentru restul sesiunii DM. În cazul autentificării MD5, elementul Chal poate fi returnat. Apoi, următorul nonce în Chal trebuie utilizat pentru MD5 digest atunci când următoarea sesiune DM este pornit.

    dacă o solicitare include acreditări și Codul De răspuns la solicitare este 200, aceeași acreditare trebuie trimisă în următoarea solicitare. Dacă elementul Chal este inclus și autentificarea MD5 este necesară, un nou rezumat este creat utilizând următorul nonce prin elementul Chal pentru următoarea solicitare.

    pentru mai multe informații despre autentificarea clientului de bază sau MD5, autentificarea serverului MD5, hash MD5 și MD5 nonce, consultați Specificația de securitate a gestionării dispozitivelor OMA (oma-TS-DM_Security-V1_2_1-20080617-a), manipularea codului de răspuns la autentificare și eșantioane pas cu pas în specificația Protocolului de gestionare a dispozitivelor OMA (oma-TS-DM_Protocol-V1_2_1-20080617-A), disponibilă de la site-ul oma.

    utilizator vizat vs. Configurare direcționată dispozitiv

    pentru CSP-uri și politici care acceptă fiecare configurație de utilizator, serverul MDM poate trimite valori de setare direcționate de utilizator la dispozitivul la care este conectat activ un utilizator înscris în MDM. Dispozitivul notifică serverul despre starea de conectare printr-o alertă de dispozitiv (1224) cu tip de alertă = în DM pkg#1.

    partea de date a acestei alerte ar putea fi una dintre următoarele șiruri:

    • utilizator-utilizatorul care a înscris dispozitivul este conectat activ. Serverul MDM ar putea trimite configurație specifică utilizatorului pentru CSPs / politici care acceptă configurația per utilizator
    • altele – un alt utilizator de conectare, dar acel utilizator nu are un cont MDM. Serverul poate aplica numai configurația la nivel de dispozitiv, de exemplu, configurația se aplică tuturor utilizatorilor din dispozitiv.
    • nici unul – nu autentificare utilizator activ. Serverul poate aplica numai configurația la nivel de dispozitiv, iar configurația disponibilă este limitată la mediul dispozitivului (fără autentificare activă a utilizatorului).

    mai jos este un exemplu de alertă:

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

    serverul notifică dispozitivul dacă este o configurație vizată de utilizator sau de dispozitiv vizată printr-un prefix La LocURL-ul nodului de gestionare, cu ./ utilizator pentru utilizator de configurare vizate, sau ./ dispozitiv pentru Dispozitiv de configurare vizate. În mod implicit, dacă nu există prefix cu ./ dispozitiv sau ./ utilizator, este dispozitiv de configurare vizate.

    următorul LocURL arată o configurație de nod CSP per utilizator: ./user/vendor/MSFT/EnterpriseModernAppManagement/AppInstallation/<PackageFamilyName>/StoreInstall

    următorul LocURL arată o configurație de nod CSP pe dispozitiv: ./ device/vendor/MSFT/RemoteWipe / DoWipe

    SyncML response status codes

    când utilizați SyncML în OMA DM, există coduri de stare standard de răspuns care sunt returnate. Următorul tabel listează codurile de stare de răspuns SyncML comune pe care este posibil să le vedeți. Pentru mai multe informații despre codurile de stare a răspunsului SyncML, consultați secțiunea 10 din specificația Protocolului de reprezentare SyncML.

    Codul De stare descriere
    200 comanda SyncML a fost finalizată cu succes.
    202 acceptat pentru procesare. Aceasta este de obicei o operație asincronă, cum ar fi o solicitare de a rula o execuție la distanță a unei aplicații.
    212 autentificarea acceptată. În mod normal, veți vedea acest lucru doar ca răspuns la elementul SyncHdr (utilizat pentru autentificare în standardul OMA-DM). Este posibil să vedeți acest lucru dacă vă uitați la jurnalele OMA DM, dar CSP-urile nu generează de obicei acest lucru.
    214 operațiunea a fost anulată. Comanda SyncML finalizat cu succes, dar nu mai multe comenzi vor fi procesate în cadrul sesiunii.
    215 nu a fost executat. O comandă nu a fost executată ca urmare a interacțiunii utilizatorului pentru a anula comanda.
    216 Atomic întoarce-te bine. O comandă se afla în interiorul unui element Atomic și Atomic a eșuat. Această comandă a fost retrasă cu succes.
    400 cerere proastă. Comanda solicitată nu a putut fi efectuată din cauza sintaxei malformate. CSP-urile nu generează de obicei această eroare, totuși s-ar putea să o vedeți dacă SyncML-ul dvs. este malformat.
    401 acreditări nevalide. Comanda solicitată a eșuat deoarece solicitantul trebuie să furnizeze autentificarea corespunzătoare. CSP-urile nu generează de obicei această eroare.
    403 interzis. Comanda solicitată a eșuat, dar destinatarul a înțeles comanda solicitată.
    404 nu a fost găsit. Ținta solicitată nu a fost găsită. Acest cod va fi generat dacă interogați un nod care nu există.
    405 comanda nu este permisă. Acest cod de răspuns va fi generat dacă încercați să scrieți într-un nod numai în citire.
    406 caracteristică opțională nu este acceptată. Acest cod de răspuns va fi generat dacă încercați să accesați o proprietate pe care CSP nu o acceptă.
    415 tip sau format neacceptat. Acest cod de răspuns poate rezulta din erori de parsare sau formatare XML.
    418 există deja. Acest cod de răspuns apare dacă încercați să adăugați un nod care există deja.
    425 Permisiune Refuzată. Comanda solicitată a eșuat deoarece expeditorul nu are permisiuni adecvate de control al accesului (ACL) asupra destinatarului. Erorile” Access denied ” sunt de obicei traduse în acest cod de răspuns.
    500 comanda a eșuat. Eșec Generic. Destinatarul a întâmpinat o condiție neașteptată care l-a împiedicat să îndeplinească cererea. Acest cod de răspuns va apărea atunci când SyncML DPU nu poate mapa codul de eroare originar.
    507 Atomic a eșuat. Una dintre operațiile dintr-un bloc Atomic a eșuat.
    516 Atomic roll înapoi nu a reușit. O operațiune Atomic a eșuat și comanda nu a fost retrasă cu succes.

    Lasă un răspuns

    Adresa ta de email nu va fi publicată.