OMA DM-protokollatuki

Written by on in Articles
  • momentti
  • 12/16/2021
  • 12 luettavat minuutit
    • D
    • M
    • a
    • v
    • d
    • +11
onko tästä sivusta apua?

Kiitos.

OMA DM-asiakas kommunikoi palvelimen kanssa HTTPS: n kautta ja käyttää DM Sync: tä (OMA DM v1.2) viestin hyötykuormana. Tässä aihepiirissä kuvataan OMA DM-toimintoja, joita DM-asiakas tukee yleensä. OMA DM-protokollan V1.2 täydellinen kuvaus löytyy Oman verkkosivuilta.

OMA DM-standardit

seuraavassa taulukossa on esitetty Windowsin käyttämät OMA DM-standardit.

yleinen alue oma DM-standardi, jota tuetaan
tiedonsiirto ja istunto
  • asiakkaan käynnistämä ETÄHALLINTAISTUNTO SSL: n kautta.
  • remote HTTPS DM-istunto SSL: n kautta.
  • Remote DM server initiation notification using wap Push over Short Message Service (SMS). Ei yrityksen johdon käytössä.
  • kauko bootstrap käyttämällä WAP Push over-tekstiviestiä. Ei yrityksen johdon käytössä.
    		•
    Bootstrap XML oma Client Provisioning XML.
    DM-protokollan komennot seuraava luettelo näyttää komennot, joita laite käyttää. Lisätietoja OMA DM-komentoelementeistä on kohdassa ”OMA website”, joka on saatavilla OMA website-sivustolta.

  • Add (implisiittinen Add supported)
  • Alert (DM alert): Yleishälytystä (1226) käytetään enterprise management-asiakasohjelmassa, kun käyttäjä käynnistää MDM: n purkutoiminnon laitteesta tai kun CSP lopettaa joitakin asynkronisia toimia. Laitehälytystä (1224) käytetään ilmoittamaan palvelimelle jokin laitteen laukaisema tapahtuma.
  • Atomic: Add-komennon ja Replacen suorittamista samassa solmussa atomielementin sisällä ei tueta. Sisäkkäisiä Atomic-ja Get-komentoja ei sallita ja ne tuottavat virhekoodia 500.
  • Poista: Poistaa solmun DM-puusta, ja koko kyseisen solmun alapuolella oleva alaryhmä, jos sellainen on
  • Exec: kutsuu suoritustiedoston asiakaslaitteelle
  • Get: hakee tiedot asiakaslaitteesta; sisäsolmujen osalta Tietoelementin lapsisolmujen nimet palautetaan URI-koodatussa muodossa
  • Replace: korvaa tiedot asiakaslaitteessa
  • Result: palauttaa datatulokset get-komento DM-palvelimelle
  • sekvenssi: määrittää järjestyksen, jossa komentoryhmä on käsiteltävä
  • tila: Ilmoittaa operaation valmiustilan (onnistuminen tai epäonnistuminen)
    jos XML-elementti, joka ei ole kelvollinen OMA DM-komento, kuuluu johonkin seuraavista elementeistä, kyseisen elementin tilakoodi 400 palautetaan:
  • SyncBody
  • Atomic
  • sekvenssi
    jos DM-komennossa ei ole CmdID: tä, asiakas palauttaa tyhjän tilaelementtiin ja tilakoodiin 400.
    jos Atomielementtejä on sisäkkäin, palautetaan seuraavat tilakoodit:
  • sisäkkäinen Atomikomento palauttaa 500.
  • emoatomin komento palauttaa 507.
    lisätietoja Atomikomennosta on ohjeaiheessa OMA DM protocol common elements.
    Add-komennon ja Replacen suorittamista samassa solmussa Atomielementin sisällä ei tueta.
    Lokuri ei voi alkaa /.
    Synchdr: n Meta XML-tagia laite ei huomioi.
    		•
    OMA DM standardiobjektit DevInfo

  • DevDetail
  • OMA DM DMS-tiliobjektit (OMA DM versio 1.2)
    		•
    turvallisuus
  • Todenna DM-palvelimen aloitusilmoitus tekstiviestillä (ei yritysjohdon käytössä)
  • sovelluskerroksen perus-ja MD5-asiakkaan todennus
  • Todenna palvelin MD5-salauksella sovellustasolla
  • tietojen eheys ja todennus HMAC: lla sovellustasolla
  • SSL-tason varmenteeseen perustuva asiakkaan/palvelimen todennus, salaus ja tiedot eheyden tarkistus
    		•
    solmut OMA DM-puussa solmun nimeä koskevat seuraavat säännöt:

  • ”.”voi olla osa solmun nimeä.
  • Solmun nimi ei voi olla tyhjä.
  • Solmun nimi ei voi olla vain asteriski ( * ) – merkki.
    		•
    Provisioning Files Provisioning XML must be well formed and follow the definition in SyncML Representation Protocol] (https://go.microsoft.com/fwlink/p/?LinkId=526905).
    jos XML-elementti, joka ei ole kelvollinen OMA DM-komento, on SyncBody-komennolla, kyseisen elementin tilakoodi 400 palautetaan.

    Huomautus
    edustaakseen Unicode-merkkijonoa urina, koodaa merkkijono ensin UTF-8: ksi. Koodaa sitten kukin UTF-8 tavua URI-koodauksella.
    WBXML-tuki Windows tukee SyncML: n lähettämistä ja vastaanottamista sekä XML-muodossa että koodattuna WBXML-muodossa. Tämä on konfiguroitavissa käyttämällä W7-sovelluksen ominaisuuden alla olevaa OLETUSKOODAUSSOLMUA rekisteröinnin aikana. Lisätietoja WBXML koodaus, katso osa 8 SyncML Edustusprotokollan erittely.
    suurten objektien käsittely Windows 10: n versiossa 1511 lisättiin asiakastuki suurten objektien lataamiseksi palvelimelle.

    OMA DM-protokolla yhteisiä elementtejä

    käytetään muissa OMA DM-elementtityypeissä. Seuraavassa taulukossa on lueteltu laitteiden konfigurointiin käytetyt omat DM-yleiset elementit. Lisätietoja OMA DM: n yhteisistä elementeistä on kohdassa ”SyncML Representation Protocol Device Management Usage” (oma-SyncML-DMRepPro-V1_1_2-20030613-a).

    alkuaine kuvaus
    Chal määrittää todennushaasteen. Palvelin tai asiakas voi lähettää haasteen toiselle, jos alkuperäisessä pyyntöviestissä ei ollut tunnistetietoja tai puutteellisia tunnistetietoja.
    Cmd määrittää Tilaelementissä viitatun OMA DM-komennon nimen.
    CmdID määrittää OMA DM-komennon yksilöllisen tunnisteen.
    CmdRef määrittää sen komennon ID: n, jonka tila-tai tulostietoja palautetaan. Tämä elementti vastaa vastaavan pyyntösanoman CmdID-elementin arvoa.
    Cred määrittää viestin lähettäjän todennushyvityksen.
    lopullinen osoittaa, että nykyinen viesti on paketin viimeinen viesti.
    LocName määrittää kohde-ja Lähdeelementtien näyttönimen, jota käytetään MD5-todennuksen käyttäjätunnuksen lähettämiseen.
    Lokuuri määrittää kohteen tai lähteen sijainnin osoitteen. Jos osoite Sisältää ei-aakkosnumeerisen merkin, se on poistettava asianmukaisesti URL-koodausstandardin mukaisesti.
    MsgID määrittää oman DM-istuntosanoman yksilöllisen tunnisteen.
    MsgRef määrittää vastaavan pyyntösanoman ID: n. Tämä elementti ottaa pyynnön viestin MsgID-elementin arvon.
    RespURI määrittää URI: n, jota vastaanottajan on käytettävä lähettäessään vastausta tähän viestiin.
    SessionID määrittää viestin sisältävään viestiin liittyvän OMA DM-istunnon tunnisteen.

    Huomautus
    jos palvelin ei ilmoita laitteelle, että se tukee uutta versiota (Dmclient CSP: n SyncApplicationVersion solmun kautta), asiakas palauttaa Sessionidin kokonaislukuna desimaalimuodossa. Jos palvelin tukee DM session sync-versiota 2.0, jota käytetään Windows 10: ssä, laiteasiakas palauttaa 2 tavua.
    lähde määrittää viestin lähdeosoitteen.
    SourceRef määrittää vastaavan pyyntösanoman lähteen. Tämä elementti ottaa pyynnön Sanoman Lähdeelementin arvon ja palautetaan tila-tai Tuloselementtiin.
    kohde määrittää DM-puussa olevan solmun osoitteen, joka on OMA DM-komennon kohde.
    TargetRef määrittää kohdeosoitteen vastaavassa pyyntösanomassa. Tämä elementti ottaa pyynnön viestin Kohdeelementin arvon ja palautetaan tila-tai Tuloselementtiin.
    VerDTD määrittää viestin esittämiseen käytetyn OMA DM-edustusprotokollan määrittelyn iso-ja molliversion tunnisteen.
    VerProto määrittää viestissä käytetyn OMA DM-protokollamäärityksen iso-ja molliversion tunnisteen.

    Laitehallinta-istunto

    Laitehallinta-istunto (DM) koostuu komentosarjasta, jota vaihdetaan DM-palvelimen ja asiakaslaitteen välillä. Palvelin lähettää komentoja, jotka osoittavat toiminnot, jotka on suoritettava asiakaslaitteen hallintapuussa. Asiakas vastaa lähettämällä komentoja, jotka sisältävät tulokset ja pyydetyt tilatiedot.

    lyhyt DM-istunto voidaan tiivistää seuraavasti:

    palvelin lähettää Get-komennon asiakaslaitteelle hakemaan hallintapuun yhden solmun sisällön. Laite suorittaa toiminnon ja vastaa Result-komennolla, joka sisältää pyydetyn sisällön.

    DM-istunto voidaan jakaa kahteen vaiheeseen:

    1. Setup phase: vastauksena käynnistystapahtumaan asiakaslaite lähettää käynnistävän viestin DM-palvelimelle. Laite – ja palvelinvaihdossa tarvittiin todennus-ja laitetietoja. Tätä vaihetta edustavat vaiheet 1, 2 ja 3 Seuraavassa taulukossa.
    2. Hallintavaihe: DM-palvelin on hallinnassa. Se lähettää hallintakomentoja laitteeseen ja laite vastaa. Vaihe kaksi päättyy, kun DM-palvelin lopettaa komentojen lähettämisen ja päättää istunnon. Tämä vaihe esitetään seuraavan taulukon vaiheissa 3, 4 ja 5.

    seuraavat tiedot osoittavat tyypillisen DM-istunnon tapahtumasarjan.

    1. DM client kutsutaan takaisin hallintapalvelimeen
      Enterprise scenario-laitteen tehtäväaikataulu vetoaa DM-asiakasohjelmaan.

      MO-palvelin lähettää palvelimen käynnistyssanoman vedotakseen DM-asiakasohjelmaan.

      käynnistyssanoma sisältää palvelintunnuksen ja kertoo asiakaslaitteen aloittavan istunnon palvelimella. Asiakaslaite todentaa laukaisuviestin ja varmistaa, että palvelimella on valtuudet kommunikoida sen kanssa.
      Enterprise scenario-sovittuna aikana DM-asiakasta kutsutaan määräajoin soittamaan takaisin enterprise management Serverille HTTPS: n kautta.

    2. laite lähettää IP-yhteyden kautta viestin istunnon aloittamiseksi.

      tämä viesti sisältää laitetiedot ja tunnukset. Asiakas ja palvelin tekevät keskinäisen todennuksen SSL-kanavalla tai DM-sovellustasolla.

    3. DM-palvelin vastaa IP-yhteyden (HTTPS) kautta. Palvelin lähettää mahdolliset alustavat laitehallinnan komennot.

    4. laite vastaa palvelimen hallinnan komentoihin. Tämä viesti sisältää määritettyjen laitehallintatoimintojen tulokset.

    5. DM-palvelin päättää istunnon tai lähettää toisen komennon. DM-istunto päättyy tai Vaihe 4 toistetaan.

    askelnumerot eivät edusta viestin tunnistenumeroita (MsgID). Kaikki viestit palvelimelta on MsgID, joka on ainutlaatuinen istunnossa, alkaen 1 Ensimmäinen viesti, ja kasvaa lisäämällä 1 jokaista ylimääräistä viestiä. Lisätietoja MsgID: stä ja OMA SyncML-protokollasta on ohjeaiheessa oma Laitehallinnan Edustusprotokolla (DM_RepPro-V1_2-20070209-A).

    OMA DM-sovellustason keskinäisen todennuksen aikana, jos laitteen vastauskoodi Palvelinpyynnössä olevaan cred-elementtiin on 212, muuta todennusta ei tarvita DM-istunnon loppuaikana. MD5-todennuksen tapauksessa Chal-elementti voidaan palauttaa. Sitten Seuraava nonce Chal on käytettävä MD5 digest kun seuraava DM istunto aloitetaan.

    jos pyyntö sisältää tunnistetiedot ja vastauskoodi pyyntöön on 200, sama tunnistetiedot on lähetettävä seuraavan pyynnön yhteydessä. Jos Chal-elementti on mukana ja vaaditaan MD5-todennus, luodaan uusi digest käyttämällä seuraavaa noncea Chal-elementin kautta seuraavaa pyyntöä varten.

    lisätietoja asiakkaan perus-tai MD5-todennuksesta, MD5-palvelimen todennuksesta, MD5-hajautuksesta ja MD5-noncesta on OMA Laitehallinnan Suojausselosteessa (OMA-TS-DM_SECURITY-V1_2_1-20080617-A), authentication response Code handling and step-by-step samples in OMA Device Management Protocol specification (OMA-TS-DM_Protocol-V1_2_1-20080617-a), saatavilla Oman kotisivuilta.

    Kohdekäyttäjä vs. Device targeted configuration

    for CSPs and policies that support per user configuration, the MDM server can send user targeted setting values to the device that a MDM-rekisteröitynyt käyttäjä on aktiivisesti Kirjautunut sisään. Laite ilmoittaa palvelimelle kirjautumistilan laitehälytyksellä (1224), jonka Alert type = in DM pkg#1.

    tämän kuulutuksen dataosa voi olla jokin seuraavista merkkijonoista:

    • käyttäjä-käyttäjä, joka rekisteröi laitteen, on aktiivisesti Kirjautunut sisään. MDM-palvelin voi lähettää käyttäjäkohtaisen määrityksen CSPs/ – käytännöille, jotka tukevat käyttäjäkohtaista määritystä
    • muut-toinen käyttäjätunnus, mutta kyseisellä Käyttäjällä ei ole MDM-tiliä. Palvelin voi soveltaa vain laitteen laajuista määritystä, esimerkiksi määritys koskee kaikkia laitteen käyttäjiä.
    • None-no active user login. Palvelin voi käyttää vain laitteen kokoista määritystä, ja käytettävissä oleva määritys on rajoitettu laiteympäristöön (ei aktiivista käyttäjätunnusta).

    alla varoitusesimerkki:

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

    palvelin ilmoittaa laitteelle, onko kyseessä käyttäjän kohdennettu vai laitteen kohdennettu kokoonpano johtosolmun LocURL-etuliitteellä, jossa./ user käyttäjän kohdennettu kokoonpano, tai ./ device for device targeted configuration. Oletuksena, jos ei etuliite kanssa ./ laite tai ./ käyttäjä, se on laitteen kohdennettu kokoonpano.

    Seuraava Lokurl näyttää käyttäjäkohtaisen CSP-solmun määrityksen: ./user/vendor/MSFT/EnterpriseModernAppManagement/AppInstallation/<PackageFamilyName>/StoreInstall

    Seuraava LocURL näyttää laitekohtaisen CSP-solmun määrityksen: ./device/vendor/MSFT/RemoteWipe / DoWipe

    SyncML response status codes

    käytettäessä SyncML in OMA DM, on olemassa vakiomuotoisia vasteen status-koodeja, jotka palautetaan. Seuraavassa taulukossa luetellaan yleiset SyncML-vasteen tilakoodit, jotka todennäköisesti näet. Lisätietoja SyncML-vasteen tilakoodeista on SyncML – Edustusprotokollan spesifikaation kohdassa 10.

    Statuskoodi kuvaus
    200 SyncML-komento valmistui onnistuneesti.
    202 hyväksytty käsiteltäväksi. Tämä on yleensä asynkroninen operaatio, kuten pyyntö suorittaa sovelluksen etätoteutus.
    212 tunnistautuminen hyväksytty. Normaalisti näet tämän vain vastauksena SyncHdr-elementtiin (käytetään todennukseen OMA-DM-standardissa). Saatat nähdä tämän, jos katsot OMA DM lokit, mutta CSPs eivät yleensä luo tätä.
    214 operaatio peruttu. SyncML-komento valmistui onnistuneesti, mutta istunnossa ei käsitellä enää komentoja.
    215 ei teloitettu. Komentoa ei suoritettu käyttäjän vuorovaikutuksen seurauksena komennon peruuttamiseksi.
    216 Atomic Kelaa taaksepäin. Atomic elementin sisällä oli komento, joka epäonnistui Atomic. Tämä käsky palautettiin onnistuneesti.
    400 huono pyyntö. Pyydettyä komentoa ei voitu suorittaa virheellisen syntaksin vuoksi. CSPs eivät yleensä luo tätä virhettä, mutta saatat nähdä sen, jos SyncML on epämuodostunut.
    401 Virheelliset tunnukset. Pyydetty komento epäonnistui, koska pyytäjän on annettava asianmukainen todennus. CSP: t eivät yleensä luo tätä virhettä.
    403 kielletty. Pyydetty komento epäonnistui, mutta vastaanottaja ymmärsi pyydetyn komennon.
    404 ei löytynyt. Pyydettyä kohdetta ei löytynyt. Tämä koodi luodaan, jos kyselet solmua, jota ei ole olemassa.
    405 komentoa ei sallita. Tämä vastauskoodi luodaan, jos yrität kirjoittaa vain luku-solmuun.
    406 valinnainen ominaisuus ei tueta. Tämä vastauskoodi luodaan, jos yrität käyttää ominaisuutta, jota CSP ei tue.
    415 tyyppiä tai muotoa ei tueta. Tämä vastauskoodi voi johtua XML jäsennys-tai muotoiluvirheistä.
    418 se on jo olemassa. Tämä vastauskoodi tapahtuu, jos yrität lisätä jo olemassa olevan solmun.
    425 Lupa Evätty. Pyydetty komento epäonnistui, koska lähettäjällä ei ole vastaanottajalle riittäviä käyttöoikeuksia (ACL). ”Access denied” – virheet käännetään yleensä tähän vastauskoodiin.
    500 komento epäonnistui. Yleinen vika. Vastaanottaja kohtasi odottamattoman tilan, joka esti sitä täyttämästä pyyntöä. Tämä vastauskoodi syntyy, kun SyncML-DPU ei pysty kartoittamaan alkuperäistä virhekoodia.
    507 Atomic epäonnistuin. Yksi Atomic lohkon operaatioista epäonnistui.
    516 Atomic kelaus epäonnistui. Atomic operaatio epäonnistui, eikä komentoa rullattu takaisin onnistuneesti.

    Vastaa

    Sähköpostiosoitettasi ei julkaista.