OMA DM protokoll támogatás

Written by on in Articles
  • jogcímcsoport
  • 12/16/2021
  • 12 perc olvasni
    • D
    • M
    • a
    • v
    • d
    • +11
hasznos ez az oldal?

köszönöm.

az OMA DM kliens HTTPS-en keresztül kommunikál a szerverrel, és a DM Sync-et (OMA DM v1.2) Használja az üzenet Hasznos adataként. Ez a témakör az OMA DM funkciókat ismerteti, amelyeket a DM kliens általában támogat. Az OMA DM V1. 2 protokoll teljes leírása megtalálható az OMA honlapján.

OMA DM szabványok

az alábbi táblázat a Windows által használt OMA DM szabványokat mutatja be.

általános terület OMA DM szabvány, amely támogatott
adatátvitel és munkamenet
  • Ügyfél által kezdeményezett távoli HTTPS DM munkamenet SSL-en keresztül.
  • távoli HTTPS DM munkamenet SSL-en keresztül.
  • távoli DM-kiszolgáló kezdeményezési értesítése WAP Push over Short Message Service (SMS) használatával. A vállalati menedzsment nem használja.
  • távoli bootstrap segítségével WAP Push over SMS. A vállalati menedzsment nem használja.
    		•
    Bootstrap XML OMA kliens kiépítési XML.
    DM protokoll parancsok az alábbi lista az eszköz által használt parancsokat mutatja. Az OMA DM parancselemekkel kapcsolatos további információkért lásd: “OMA webhely”, amely elérhető az OMA webhelyen.

  • Add (Implicit Add supported)
  • Alert (DM alert): az Általános riasztást (1226) a vállalati felügyeleti ügyfél használja, amikor a felhasználó MDM unenrollment műveletet indít az eszközről, vagy amikor egy CSP végez néhány aszinkron műveletet. Device alert (1224) arra szolgál, hogy értesítse a kiszolgálót valamilyen eszköz által kiváltott eseményről.
  • Atomic: az Add parancs, majd a Replace végrehajtása ugyanazon a csomóponton egy atomelemen belül nem támogatott. A beágyazott Atomic és Get parancsok nem engedélyezettek, és 500-as hibakódot generálnak.
  • el kell hagyni: Eltávolít egy csomópontot a DM-fáról, és az adott csomópont alatti teljes részfa, ha létezik
  • Exec: végrehajtható fájlt hív meg az ügyféleszközön
  • Get: adatokat kér le az ügyféleszközről; belső csomópontok esetében az Adatelemben szereplő gyermekcsomópontok nevei URI-kódolt formátumban kerülnek visszaadásra
  • Replace: felülírja az ügyféleszköz adatait
  • eredmény: visszaadja egy ügyféleszköz adateredményeit parancs letöltése a DM-kiszolgálóra
  • sorrend: meghatározza a parancsok csoportjának feldolgozásának sorrendjét
  • állapot: A
    művelet befejezési állapotát (siker vagy kudarc) jelzi, ha egy érvényes OMA DM paranccsal nem rendelkező XML elem az alábbi elemek valamelyike alatt található, akkor az elemhez a 400 állapotkód kerül visszaadásra:
  • SyncBody
  • Atomic
  • Sequence
    ha a DM parancsban nincs CmdID megadva, a kliens üresen tér vissza a status elemben és a status code 400-ban.
    atomi elemek beágyazása esetén a következő állapotkódok kerülnek visszaadásra:
  • a beágyazott atomi parancs 500-at ad vissza.
  • a szülő Atomparancs értéke 507.
    az Atomic paranccsal kapcsolatos további információkért lásd: OMA DM protocol common elements.
    az Add parancs, majd a Replace parancs végrehajtása ugyanazon a csomóponton egy atomi elemen belül nem támogatott.
    a LocURI nem kezdődhet / – vel.
    Meta XML tag SyncHdr figyelmen kívül hagyja a készülék.
    		•
    OMA DM standard objektumok DevInfo

  • DevDetail
  • OMA DM DMS fiók objektumok (OMA DM Verzió 1.2)
    		•
    biztonság
  • hitelesítse a DM-kiszolgáló kezdeményezési értesítését SMS üzenet (a vállalatvezetés nem használja)
  • alkalmazásréteg alap-és MD5-ügyfélhitelesítés
  • hitelesítse a kiszolgálót MD5-hitelesítő adatokkal alkalmazásszinten
  • adatintegritás és hitelesítés HMAC-val alkalmazásszinten
  • SSL-szintű tanúsítványalapú ügyfél – /szerverhitelesítés, titkosítás, Az adatok integritásának ellenőrzése
    		•
    csomópontok az OMA DM fában a csomópont nevére a következő szabályok vonatkoznak:

  • “.”része lehet a csomópont nevének.
  • a csomópont neve nem lehet üres.
  • a csomópont neve nem lehet csak csillag (*) karakter.
    		•
    kiépítési fájlok a kiépítési XML-nek jól formáltnak kell lennie, és követnie kell a SyncML Representation Protocol](https://go.microsoft.com/fwlink/p/?LinkId=526905) definícióját.
    ha egy XML elem, amely nem érvényes OMA DM parancs alatt SyncBody, az állapotkód 400 vissza az adott elem.

    Megjegyzés
    ha egy Unicode karakterláncot URI-ként szeretne ábrázolni, először kódolja a karakterláncot UTF-8-ként. Ezután kódolja az UTF-8 bájtokat URI kódolással.
    WBXML támogatás A Windows támogatja a SyncML küldését és fogadását mind XML formátumban, mind kódolt WBXML formátumban. Ez konfigurálható a DEFAULTENCODING csomópont használatával a W7 alkalmazás jellemző alatt a beiratkozás során. A WBXML kódolással kapcsolatos további információkért lásd a SyncML Reprezentációs protokoll specifikáció 8. szakaszát.
    nagy objektumok kezelése A Windows 10 1511-es verziójában hozzáadták az ügyfelek támogatását a nagy objektumok kiszolgálóra történő feltöltéséhez.

    OMA DM protokoll közös elemek

    a közös elemeket más OMA DM elemtípusok használják. Az alábbi táblázat felsorolja az eszközök konfigurálásához használt OMA DM közös elemeket. További információ az OMA DM közös elemeiről: “SyncML Reprezentációs protokoll Eszközkezelés használata” (OMA-SyncML-DMRepPro-V1_1_2-20030613-a) elérhető az OMA webhelyén.

    elem leírás
    Chal hitelesítési kihívást ad meg. A kiszolgáló vagy az ügyfél kihívást küldhet a másiknak, ha az eredeti kérési üzenetben nem adtak meg hitelesítő adatokat vagy nem megfelelő hitelesítő adatokat.
    Cmd megadja egy OMA DM parancs nevét, amelyre egy Állapotelem hivatkozik.
    CmdID meghatározza az OMA DM parancs egyedi azonosítóját.
    CmdRef megadja annak a parancsnak az azonosítóját, amelyhez az állapot-vagy eredményinformációkat visszaadja. Ez az elem a megfelelő kérési üzenet CmdID elemének értékét veszi fel.
    Cred megadja az üzenet kezdeményezőjének hitelesítési hitelesítő adatait.
    Final azt jelzi, hogy az aktuális üzenet az utolsó üzenet a csomagban.
    LocName megadja a cél-és Forráselemek megjelenítési nevét, amelyet az MD5-hitelesítés felhasználói azonosítójának küldéséhez használnak.
    LocURI megadja a cél-vagy forráshely címét. Ha a cím nem alfanumerikus karaktert tartalmaz, akkor azt az URL kódolási szabvány szerint megfelelően el kell kerülni.
    msgstr megadja az OMA DM munkamenet-üzenet egyedi azonosítóját.
    MsgRef megadja a megfelelő kérési üzenet azonosítóját. Ez az elem a kérés üzenet msgstr elem értékét veszi fel.
    RespURI megadja azt az URI-t, amelyet a címzettnek használnia kell, amikor választ küld erre az üzenetre.
    SessionID meghatározza a tartalmazó üzenethez társított OMA DM munkamenet azonosítóját.

    Megjegyzés
    ha a kiszolgáló nem értesíti az eszközt arról, hogy támogatja az új verziót (a SyncApplicationVersion csomóponton keresztül a DMClient CSP-ben), az ügyfél a SessionID-t egész számként adja vissza decimális formátumban. Ha a kiszolgáló támogatja a DM session sync 2.0 verziót, amelyet a Windows 10 használ, az eszköz kliens 2 bájtot ad vissza.
    forrás az üzenetforrás címét adja meg.
    SourceRef megadja a megfelelő kérési üzenet forrását. Ez az elem a request message Source elem értékét veszi fel, és az állapot vagy az eredmények elemben kerül visszaadásra.
    Target megadja a csomópont címét a DM fában, amely az OMA DM parancs célja.
    TargetRef megadja a célcímet a megfelelő kérési üzenetben. Ez az elem a request message Célelem értékét veszi fel, és az állapot vagy az eredmények elemben kerül visszaadásra.
    VerDTD meghatározza az OMA DM reprezentációs protokoll specifikációjának fő és kisebb verzióazonosítóját, amelyet az üzenet ábrázolására használnak.
    a VerProto az üzenetben használt OMA DM protokoll specifikáció major és minor verzióazonosítóját adja meg.

    eszközkezelési munkamenet

    az eszközkezelési (DM) munkamenet a DM-kiszolgáló és az ügyféleszköz között kicserélt parancsok sorozatából áll. A kiszolgáló parancsokat küld, amelyek jelzik azokat a műveleteket, amelyeket az ügyféleszköz kezelési fáján kell végrehajtani. Az ügyfél az eredményeket és a kért állapotinformációkat tartalmazó parancsok küldésével válaszol.

    egy rövid DM munkamenet a következőképpen foglalható össze:

    a kiszolgáló Get parancsot küld egy ügyféleszköznek, hogy lekérje a kezelési FA egyik csomópontjának tartalmát. A készülék végrehajtja a műveletet, és egy Eredményparanccsal válaszol, amely tartalmazza a kért tartalmat.

    a DM munkamenet két szakaszra osztható:

    1. beállítási szakasz: egy kiváltó eseményre adott válaszként az ügyféleszköz kezdeményező üzenetet küld egy DM-kiszolgálónak. Az eszköz és a szerver cseréje hitelesítési és eszközinformációkat igényelt. Ezt a fázist a következő táblázat 1., 2. és 3. lépése mutatja be.
    2. kezelési szakasz: a DM szerver irányítja. Kezelési parancsokat küld az eszköznek, és az eszköz válaszol. A második fázis akkor ér véget, amikor a DM-kiszolgáló leállítja a parancsok küldését, és befejezi a munkamenetet. Ezt a fázist a következő táblázat 3., 4. és 5. lépése mutatja be.

    az alábbi információk az események sorrendjét mutatják egy tipikus DM munkamenet során.

    1. a DM-ügyfél meghívásra kerül, hogy visszahívja a felügyeleti kiszolgálót
      vállalati forgatókönyv – az eszköz feladatütemezése meghívja a DM-ügyfelet.

      a MO szerver egy szerverindító üzenetet küld a DM kliens meghívására.

      az indító üzenet tartalmazza a kiszolgáló azonosítóját, és arra utasítja az ügyféleszközt, hogy indítson munkamenetet a kiszolgálóval. Az ügyféleszköz hitelesíti a kiváltó üzenetet, és ellenőrzi, hogy a kiszolgáló jogosult-e kommunikálni vele.
      vállalati forgatókönyv – az ütemezett időpontban a DM-ügyfelet rendszeresen meghívják, hogy HTTPS-en keresztül hívjon vissza a vállalati felügyeleti kiszolgálóra.

    2. a készülék IP-kapcsolaton keresztül üzenetet küld a munkamenet elindításához.

      ez az üzenet eszközinformációkat és hitelesítő adatokat tartalmaz. Az ügyfél és a kiszolgáló kölcsönös hitelesítést végez SSL csatornán vagy DM alkalmazás szinten.

    3. a DM-kiszolgáló IP-kapcsolaton (HTTPS) keresztül válaszol. A kiszolgáló kezdeti Eszközkezelő parancsokat küld, ha vannak ilyenek.

    4. a készülék reagál a Kiszolgálókezelő parancsokra. Ez az üzenet tartalmazza a megadott eszközkezelési műveletek végrehajtásának eredményeit.

    5. a DM szerver leállítja a munkamenetet, vagy újabb parancsot küld. A DM munkamenet befejeződik, vagy a 4.lépés megismétlődik.

    a lépésszámok nem az üzenetazonosító számokat (msgstr) jelölik. A kiszolgálóról érkező összes üzenetnek rendelkeznie kell a munkameneten belül egyedi msgstr-azonosítóval, amely az első üzenetnél 1-től kezdődik, minden további üzenetnél pedig 1-gyel növekszik. Az msgstr és az OMA SyncML protokollal kapcsolatos további információkért lásd: OMA Device Management Representation Protocol (DM_RepPro-V1_2-20070209-a).

    az OMA DM alkalmazásszintű kölcsönös hitelesítés során, ha az eszköz válaszkódja a kiszolgáló kérésének Cred elemére 212, A DM munkamenet hátralévő részében nincs szükség további hitelesítésre. Az MD5 hitelesítés esetén a Chal elem visszaküldhető. Ezután a következő nonce in Chal-t kell használni az MD5 emésztéshez, amikor a következő DM munkamenet elindul.

    ha egy kérés hitelesítő adatokat tartalmaz, és a kérelemre adott válaszkód 200, ugyanazt a hitelesítő adatot kell elküldeni a következő kérelemben. Ha a Chal elem szerepel, és az MD5 hitelesítésre van szükség, egy új kivonatot hoz létre a következő nonce használatával a Chal elemen keresztül a következő kéréshez.

    az alapvető vagy MD5 ügyfélhitelesítésről, az MD5 szerverhitelesítésről, az MD5 hash-ról és az MD5 nonce-ről további információt az OMA Device Management Security specification (OMA-TS-DM_Security-V1_2_1-20080617-a), A hitelesítési válaszkód kezeléséről és a lépésenkénti mintákról az OMA Device Management Protocol specification (OMA-TS-DM_Protocol-V1_2_1-20080617-a) webhelyen talál, amely a következő címen érhető el: az oma honlapja.

    felhasználó célzott vs. Device targeted configuration

    a felhasználói konfigurációnként támogatott CSP-k és házirendek esetén az MDM-kiszolgáló felhasználói célzott beállítási értékeket küldhet arra az eszközre, amelybe egy MDM-regisztrációval rendelkező felhasználó aktívan be van jelentkezve. A készülék értesíti a kiszolgálót a bejelentkezési állapotról egy eszközriasztáson (1224) keresztül, amelynek Alert type = in DM pkg#1.

    a riasztás adatrésze a következő karakterláncok egyike lehet:

    • felhasználó-az eszközt regisztráló Felhasználó aktívan be van jelentkezve. Az MDM-kiszolgáló felhasználóspecifikus konfigurációt küldhet a
    • felhasználói konfigurációt támogató CSP-k/házirendek számára Egyéb – egy másik felhasználói bejelentkezés, de ennek a felhasználónak nincs MDM-fiókja. A kiszolgáló csak eszközszintű konfigurációt alkalmazhat, például a konfiguráció az eszköz összes felhasználójára vonatkozik.
    • None – nincs aktív felhasználói bejelentkezés. A kiszolgáló csak az egész eszközre kiterjedő konfigurációt alkalmazhat, az elérhető konfiguráció pedig az eszközkörnyezetre korlátozódik (nincs aktív felhasználói bejelentkezés).

    az alábbiakban egy figyelmeztető példa található:

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

    a kiszolgáló értesíti az eszközt, hogy ez egy felhasználó által célzott vagy eszköz által célzott konfiguráció előtaggal a felügyeleti csomópont LocURL, a ./ felhasználó a felhasználó által célzott konfigurációhoz, vagy ./ eszköz az eszköz célzott konfigurálásához. Alapértelmezés szerint, ha nincs előtag ./ eszköz vagy ./ felhasználó, Ez eszköz célzott konfiguráció.

    a következő LocURL egy felhasználónkénti CSP csomópont konfigurációt mutat: ./user/vendor/MSFT/EnterpriseModernAppManagement/AppInstallation/<PackageFamilyName>/StoreInstall

    a következő LocURL eszközenkénti CSP-csomópont-konfigurációt mutat: ./ device/vendor/MSFT/RemoteWipe / DoWipe

    SyncML válasz állapotkódok

    amikor SyncML-t használ az OMA DM-ben, vannak szabványos válasz állapotkódok, amelyeket visszaad. Az alábbi táblázat felsorolja azokat a gyakori SyncML válaszállapot-kódokat, amelyeket valószínűleg látni fog. A SyncML válaszállapot-kódokkal kapcsolatos további információkért lásd a SyncML Reprezentációs protokoll specifikációjának 10. szakaszát.

    állapotkód leírás
    200 a SyncML parancs sikeresen befejeződött.
    202 feldolgozásra elfogadva. Ez általában aszinkron művelet, például egy alkalmazás távoli végrehajtásának futtatására irányuló kérés.
    212 hitelesítés elfogadva. Általában ezt csak a SyncHdr elemre válaszul látja (amelyet az OMA-DM szabvány hitelesítéséhez használnak). Ezt láthatja, ha megnézi az OMA DM naplókat, de a CSP-k általában nem generálják ezt.
    214 művelet lefújva. A SyncML parancs sikeresen befejeződött, de több parancs nem kerül feldolgozásra a munkameneten belül.
    215 nincs kivégezve. A parancs nem került végrehajtásra a parancs törlésére irányuló felhasználói beavatkozás eredményeként.
    216 Atomic roll vissza OK. Egy parancs Atomic elemen belül volt, és Atomic nem sikerült. Ezt a parancsot sikeresen visszavonták.
    400 rossz kérés. A kért parancs nem hajtható végre hibás szintaxis miatt. A CSP-k általában nem generálják ezt a hibát, azonban előfordulhat, hogy a SyncML hibás.
    401 érvénytelen hitelesítő adatok. A kért parancs nem sikerült, mert a kérelmezőnek megfelelő hitelesítést kell biztosítania. A CSP-k általában nem generálják ezt a hibát.
    403 tilos. A kért parancs nem sikerült, de a címzett megértette a kért parancsot.
    404 Nem található. A kért cél nem található. Ez a kód akkor jön létre, ha nem létező csomópontot kérdez.
    405 parancs nem megengedett. Ez a válaszkód akkor jön létre, ha megpróbál írni egy csak olvasható csomópontra.
    406 opcionális funkció nem támogatott. Ez a válaszkód akkor jön létre, ha olyan tulajdonsághoz próbál hozzáférni, amelyet a CSP nem támogat.
    415 nem támogatott típus vagy formátum. Ez a válaszkód XML elemzési vagy formázási hibákból származhat.
    418 már létezik. Ez a válaszkód akkor fordul elő, ha már létező csomópontot próbál hozzáadni.
    425 Engedély Megtagadva. A kért parancs nem sikerült, mert a feladó nem rendelkezik megfelelő hozzáférés-vezérlési engedélyekkel (ACL) a címzettnél. A” hozzáférés megtagadva ” hibákat általában erre a válaszkódra fordítják.
    500 a parancs sikertelen. Általános hiba. A címzett váratlan feltételbe ütközött, amely megakadályozta a kérés teljesítését. Ez a válaszkód akkor fordul elő, ha a SyncML DPU nem tudja leképezni az eredeti hibakódot.
    507 Atomic nem sikerült. A Atomic blokk egyik művelete sikertelen volt.
    516 Atomic a visszagörgetés nem sikerült. A Atomic művelet sikertelen volt, és a parancs nem lett sikeresen visszaállítva.

    Vélemény, hozzászólás?

    Az e-mail-címet nem tesszük közzé.