OMA DM-protokollstøtte

Written by on in Articles
  • Artikkel
  • 12/16/2021
  • 12 minutter å lese
    • D
    • M
    • a
    • v
    • d
    • +11
Er denne siden nyttig?

Takk.

OMA dm-klienten kommuniserer med serveren VIA HTTPS og bruker DM Sync (OMA DM v1.2) som meldings nyttelast. Dette emnet beskriver OMA DM-funksjonaliteten SOM dm-klienten støtter generelt. Den fullstendige beskrivelsen av oma DM protocol v1. 2 finner DU PÅ oma-nettstedet.

OMA dm-standarder

tabellen nedenfor viser OMA DM-standardene Som Windows bruker.

Generelt område OMA DM-standard som støttes
datatransport og økt
  • Klientinitiert ekstern HTTPS DM-økt over SSL.
  • Ekstern HTTPS DM-økt over SSL.
  • Varsel Om initiering Av Ekstern dm-server ved HJELP AV WAP-Push Over Short Message Service (SMS). Ikke brukt av enterprise management.
  • Ekstern bootstrap ved HJELP AV WAP Push OVER SMS. Ikke brukt av enterprise management.
    		•
    Bootstrap XML OMA Klient Klargjøring XML.
    dm-protokollkommandoer følgende liste viser kommandoene som brukes av enheten. Hvis du vil ha mer informasjon om oma dm-kommandoelementene, kan du se» oma-nettsted » som er tilgjengelig fra oma-nettstedet.

  • Legg Til (Implisitt Legg til støttes)
  • Alert (DM alert): Generisk varsel (1226) brukes av enterprise management client når brukeren utløser EN MDM-unenrollment-handling fra enheten eller når EN CSP fullfører noen asynkrone handlinger. Device alert (1224) brukes til å varsle serveren noen enhet utløst hendelse.
  • Atomic: Utfører En Add-kommando etterfulgt av Erstatt på samme node i et atomelement støttes ikke. Nestede Atomic og Get kommandoer er ikke tillatt og vil generere feilkode 500.
  • Slett: Fjerner en node fra dm-treet, og hele undertreet under denne noden hvis det finnes
  • Exec: Aktiverer en kjørbar på klientenheten
  • Get: Henter data fra klientenheten; for innvendige noder returneres de underordnede nodenavnene i Dataelementet I uri-kodet format
  • Erstatt: Overskriver data på klientenheten
  • Resultat: Returnerer dataresultatene til en få kommandoen til dm-SERVEREN
  • sekvens: angir rekkefølgen en gruppe kommandoer Må Behandles i
  • status: Angir fullføringsstatusen (suksess eller fiasko) for en operasjon
    hvis ET XML-element som ikke er en gyldig OMA DM-kommando, er under ett av følgende elementer, returneres statuskoden 400 for dette elementet:
  • Synckbody
  • Atomic
  • Sekvens
    hvis Ingen CmdID er gitt I dm-kommandoen, returnerer klienten tomt i statuselementet og statuskoden 400.
    hvis Atomelementer er nestet, returneres følgende statuskoder:
  • Den nestede Atomkommandoen returnerer 500.
  • den overordnede Atomkommandoen returnerer 507.
    for mer informasjon Om Atomic command, se oma dm protocol common elements.
    Utføre En Add-kommando etterfulgt av Erstatt på samme node i Et Atomelement støttes ikke.
    LocURI kan ikke starte med /.
    Meta XML-kode I SyncHdr ignoreres av enheten.
    		•
    Oma dm standard objekter DevInfo

  • DevDetail
  • OMA dm dms konto objekter (oma dm versjon 1.2)
    		•
    Sikkerhet
  • Godkjenne dm server initiering varsling SMS-melding (ikke brukt av enterprise management)
  • Applikasjonslag Grunnleggende og MD5 klientautentisering
  • Godkjenne server MED MD5 legitimasjon på programnivå
  • dataintegritet og godkjenning MED HMAC på programnivå
  • SSL-nivå sertifikatbasert klient/server godkjenning, kryptering og data Integritetskontroll
    		•
    Noder i oma dm-treet gjelder følgende regler for nodenavnet:

  • «.»kan være en del av nodenavnet.
  • nodenavnet kan ikke være tomt.
  • nodenavnet kan ikke bare være tegnet stjerne ( * ).
    		•
    Klargjøringsfiler KLARGJØRINGS XML må være godt utformet og følge definisjonen I SyncML Representation Protocol] (https://go.microsoft.com/fwlink/p/?LinkId=526905).
    hvis ET XML-element som ikke er en gyldig OMA dm-kommando, er Under Synckbody, returneres statuskoden 400 for dette elementet.

    Merk
    hvis Du vil representere En Unicode-streng som EN URI, må du først kode strengen som UTF-8. Deretter koder du hver AV UTF-8 byte ved HJELP AV URI-koding.
    wbxml-støtte Windows støtter sending Og mottak Av SyncML i BÅDE XML-format og kodet wbxml-format. DETTE kan konfigureres VED Å bruke defaultencoding-noden under W7-APPLIKASJONSKARAKTERISTIKKEN under registrering. Hvis DU vil ha mer informasjon OM wbxml-koding, kan du se avsnitt 8 I Spesifikasjonen SyncML Representation Protocol.
    Håndtering av store objekter I Windows 10, versjon 1511, ble klientstøtte for opplasting av store objekter til serveren lagt til.

    oma dm protocol vanlige elementer

    Vanlige elementer brukes av andre oma dm elementtyper. Tabellen nedenfor viser DE VANLIGE OMA dm-elementene som brukes til å konfigurere enhetene. Hvis du vil ha mer informasjon om oma dm vanlige elementer, kan du se «Bruk Av SyncML Representation Protocol Device Management» (Oma-SyncML-DMRepPro-V1_1_2-20030613-a) tilgjengelig fra oma-nettstedet.

    Element Beskrivelse
    Chal Angir en godkjenningsutfordring. Serveren eller klienten kan sende en utfordring til den andre hvis ingen legitimasjon eller utilstrekkelig legitimasjon ble gitt i den opprinnelige forespørselsmeldingen.
    Cmd Angir navnet på en OMA DM-kommando som det refereres til i Et Statuselement.
    CmdID Angir den unike identifikatoren for en OMA DM-kommando.
    CmdRef Angir IDEN for kommandoen som status-eller resultatinformasjon returneres for. Dette elementet tar Verdien Av CmdID-elementet i den tilsvarende forespørselsmeldingen.
    Cred Angir godkjenningslegitimasjonen for opphavsmannen til meldingen.
    Endelig Indikerer at gjeldende melding er den siste meldingen i pakken.
    LocName Angir visningsnavnet i Mål-og Kildeelementene, som brukes til å sende en bruker-ID FOR MD5-godkjenning.
    LocURI Angir adressen til målet eller kildeplasseringen. Hvis adressen inneholder et ikke-alfanumerisk tegn, må det være riktig rømt i henhold TIL URL-kodingsstandarden.
    Msgstr Angir en unik identifikator for en OMA dm-øktmelding.
    MsgRef Angir IDEN for den tilsvarende forespørselsmeldingen. Dette elementet tar verdien av forespørselsmeldingen Msgstr-elementet.
    RespURI Angir URI som mottakeren må bruke når du sender et svar på denne meldingen.
    SessionID Angir identifikatoren for OMA DM-økten som er knyttet til meldingen som inneholder.

    Merk
    hvis serveren ikke varsler enheten om at den støtter en ny versjon (Via syncapplicationversion-noden I DMClient CSP), returnerer klienten SessionID i heltall i desimalformat. Hvis serveren støtter dm session sync versjon 2.0, som brukes I Windows 10, returnerer enhetsklienten 2 byte.
    Kilde Angir adressen til meldingskilden.
    SourceRef Angir kilden til den tilsvarende forespørselsmeldingen. Dette elementet tar verdien av kildeelementet Forespørsel melding og returneres I Status-eller Resultat-elementet.
    Mål Angir adressen til noden, I Dm-Treet, som er målet for KOMMANDOEN OMA DM.
    TargetRef Angir måladressen i den tilsvarende forespørselsmeldingen. Dette elementet tar verdien av målelementet forespørsel melding og returneres I Status-eller Resultat-elementet.
    VerDTD Angir hoved-og underordnede versjonsidentifikatoren for OMA DM representation protocol-spesifikasjonen som brukes til å representere meldingen.
    VerProto Angir hoved – og underordnede versjonsidentifikatoren for OMA DM-protokollspesifikasjonen som brukes med meldingen.

    Enhetsadministrasjonsøkt

    en Enhetsadministrasjonsøkt (Dm) består av en rekke kommandoer som utveksles mellom EN DM-server og en klientenhet. Serveren sender kommandoer som angir operasjoner som må utføres på klientenhetens administrasjonstreet. Klienten svarer ved å sende kommandoer som inneholder resultatene og eventuell forespurt statusinformasjon.

    en kort dm-økt kan oppsummeres som følgende:

    en server sender En Get-kommando til en klientenhet for å hente innholdet i en av nodene i administrasjonstreet. Enheten utfører operasjonen og svarer Med En Resultatkommando som inneholder det forespurte innholdet.

    EN dm-økt kan deles inn i to faser:

    1. Oppsettsfase: Som svar på en utløserhendelse sender en klientenhet en initierende melding til EN DM-server. Enheten og serverutvekslingen trengte autentisering og enhetsinformasjon. Denne fasen er representert ved trinn 1, 2 og 3 i følgende tabell.
    2. Administrasjonsfase: DM-serveren har kontroll. Den sender administrasjonskommandoer til enheten og enheten reagerer. Fase to slutter når DM-serveren slutter å sende kommandoer og avslutter økten. Denne fasen er representert ved trinn 3, 4 og 5 i følgende tabell.

    følgende informasjon viser hendelsesforløpet under en TYPISK DM-økt.

    1. DM-klient startes for å ringe tilbake til administrasjonsserveren
      Enterprise scenario-enhet aktivitetsplanen aktiverer dm-klienten.

      MO-serveren sender en serverutløsermelding for å starte dm-klienten.

      utløsermeldingen inkluderer server-IDEN og ber klientenheten om å starte en økt med serveren. Klientenheten godkjenner utløsermeldingen og bekrefter at serveren er autorisert til å kommunisere med den.
      Enterprise scenario-PÅ det planlagte tidspunktet startes dm-klienten regelmessig for å ringe tilbake til enterprise management-serveren VIA HTTPS.

    2. enheten sender en melding, over EN IP-tilkobling, for å starte økten.

      denne meldingen inneholder enhetsinformasjon og legitimasjon. Klienten og serveren gjør gjensidig godkjenning over EN SSL-kanal eller PÅ dm-programnivå.

    3. DM-serveren svarer via EN IP-tilkobling (HTTPS). Serveren sender innledende enhetsadministrasjonskommandoer, hvis noen.

    4. enheten reagerer på serveradministrasjonskommandoer. Denne meldingen inneholder resultatene av å utføre de angitte enhetsadministrasjonsoperasjonene.

    5. DM-serveren avslutter økten eller sender en annen kommando. DM-økten avsluttes, Eller Trinn 4 gjentas.

    trinnnumrene representerer Ikke meldingsidentifikasjonsnumre (Msgstr). Alle meldinger fra serveren må ha en Msgstr som er unik i økten, starter på 1 for den første meldingen, og øker med en økning på 1 for hver ekstra melding. Hvis Du vil ha mer informasjon Om Msgstr Og Oma SyncML-protokollen, kan DU se OMA Device Management Representation Protocol (DM_RepPro-V1_2-20070209-A).

    under gjensidig godkjenning PÅ OMA dm-programnivå, hvis enhetssvarskoden Til Cred-elementet i serverforespørselen er 212, er det ikke nødvendig med ytterligere godkjenning for resten av dm-økten. I TILFELLE MD5-autentiseringen kan Chal-elementet returneres. Deretter må neste nonce I Chal brukes TIL MD5-fordøyelsen når neste DM-økt startes.

    hvis en forespørsel inneholder legitimasjon og svarkoden til forespørselen er 200, må samme legitimasjon sendes innen neste forespørsel. Hvis Chal-elementet er inkludert og MD5-godkjenningen kreves, opprettes en ny fordøyelse ved å bruke neste nonce via Chal-elementet for neste forespørsel.

    hvis du vil ha mer informasjon Om Grunnleggende eller MD5-klientautentisering, MD5-serverautentisering, MD5 hash og MD5 nonce, kan DU se sikkerhetsspesifikasjonen Oma-TS-DM_Security-V1_2_1-20080617-A), håndtering av autentiseringsresponskode og trinnvise prøver i oma-Ts-DM_Protocol-V1_2_1-20080617-a), tilgjengelig fra omas hjemmeside.

    bruker målrettet vs. Enhetsmålrettet konfigurasjon

    FOR Csp-Er og policyer som støtter per brukerkonfigurasjon, KAN MDM-serveren sende brukermålrettede innstillingsverdier til enheten SOM EN MDM-registrert bruker er aktivt logget på. Enheten varsler serveren om påloggingsstatusen via et enhetsvarsel (1224) med Varseltype = I DM pkg#1.

    datadelen av dette varselet kan være en av følgende strenger:

    • Bruker-brukeren som registrerte enheten, er aktivt logget inn. MDM-serveren kan sende brukerspesifikk konfigurasjon for Csp-er/policyer som støtter per brukerkonfigurasjon
    • Andre-en annen brukerinnlogging, men brukeren har ikke EN MDM-konto. Serveren kan bare bruke enhetsdekkende konfigurasjon, for eksempel gjelder konfigurasjon for alle brukere i enheten.
    • Ingen-ingen aktiv brukerinnlogging. Serveren kan bare bruke enhetsdekkende konfigurasjon, og tilgjengelig konfigurasjon er begrenset til enhetsmiljøet (ingen aktiv brukerinnlogging).

    Nedenfor er et varseleksempel:

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

    serveren varsler enheten om det er en brukermålrettet eller enhetsmålrettet konfigurasjon med et prefiks til administrasjonsnodens LocURL, med ./ bruker for brukermålrettet konfigurasjon, eller ./ enhet for enhetens målrettede konfigurasjon. Som standard, hvis ingen prefiks med ./ enhet eller ./ bruker, det er enhetsmålrettet konfigurasjon.

    Følgende LocURL viser EN CSP-nodekonfigurasjon per bruker: ./user/vendor/MSFT/EnterpriseModernAppManagement/AppInstallation/<PackageFamilyName>/StoreInstall

    Følgende LocURL viser EN CSP-nodekonfigurasjon per enhet: ./ device / vendor/Msft / RemoteWipe / DoWipe

    SyncML responsstatuskoder

    når Du bruker SyncML I OMA DM, er det standard responsstatuskoder som returneres. Tabellen nedenfor viser de vanlige SyncML responsstatuskodene du sannsynligvis vil se. Hvis Du vil ha mer informasjon Om SyncML responsstatuskoder, kan du se avsnitt 10 I Spesifikasjonen For SyncML Representation Protocol.

    Statuskode Beskrivelse
    200 SyncML-kommandoen ble fullført.
    202 Akseptert for behandling. Dette er vanligvis en asynkron operasjon, for eksempel en forespørsel om å kjøre en ekstern kjøring av et program.
    212 Godkjenning akseptert. Normalt ser du bare dette som svar På SyncHdr-elementet (brukt til godkjenning i oma-DM-standarden). Du kan se dette hvis du ser PÅ OMA DM logger, men CSPs genererer vanligvis ikke dette.
    214 Operasjonen er avlyst. SyncML-kommandoen ble fullført, men ingen flere kommandoer vil bli behandlet i økten.
    215 ikke henrettet. En kommando ble ikke utført som et resultat av brukermedvirkning for å avbryte kommandoen.
    216 Atomic rull TILBAKE OK. En kommando var inne i et Atomic – element og Atomic mislyktes. Denne kommandoen ble rullet tilbake vellykket.
    400 Dårlig forespørsel. Den forespurte kommandoen kunne ikke utføres på grunn av feilformet syntaks. CSPs genererer vanligvis ikke denne feilen, men du kan se den hvis SyncML er misformet.
    401 Ugyldig legitimasjon. Den forespurte kommandoen mislyktes fordi forespørgeren må gi riktig godkjenning. CSPs genererer vanligvis ikke denne feilen.
    403 Forbudt. Den forespurte kommandoen mislyktes, men mottakeren forsto den forespurte kommandoen.
    404 Ikke funnet. Det forespurte målet ble ikke funnet. Denne koden genereres hvis du spør en node som ikke finnes.
    405 Kommando ikke tillatt. Denne svarkoden genereres hvis du prøver å skrive til en skrivebeskyttet node.
    406 Valgfri funksjon støttes ikke. Denne svarkoden genereres hvis du prøver å få tilgang til en egenskap SOM CSP ikke støtter.
    415 Ikke Støttet type eller format. Denne svarkoden kan skyldes XML-parsing eller formateringsfeil.
    418 Eksisterer Allerede. Denne svarkoden oppstår hvis du prøver å legge til en node som allerede finnes.
    425 Tillatelse Nektet. Den forespurte kommandoen mislyktes fordi avsenderen ikke har tilstrekkelige TILGANGSKONTROLLTILLATELSER (ACL) på mottakeren. «Access denied» – feil blir vanligvis oversatt til denne svarkoden.
    500 Kommandoen mislyktes. Generisk feil. Mottakeren opplevde en uventet tilstand som forhindret den i å oppfylle forespørselen. Denne svarkoden vil oppstå når SyncML DPU ikke kan tilordne den opprinnelige feilkoden.
    507 Atomic mislyktes. En av operasjonene i en Atomic – blokk mislyktes.
    516 Atomic rulle tilbake mislyktes. En Atomic – operasjon mislyktes, og kommandoen ble ikke rullet tilbake.

    Legg igjen en kommentar

    Din e-postadresse vil ikke bli publisert.