Oma DM protocol support

Written by on in Articles
  • artikel
  • 12/16/2021
  • 12 minutter at læse
    • D
    • M
    • a
    • v
    • d
    • +11
er denne side nyttig?

Tak.

oma DM-klienten kommunikerer med serveren via HTTPS og bruger DM Sync (oma DM v1.2) som meddelelsens nyttelast. Dette emne beskriver den oma DM-funktionalitet, som DM-klienten generelt understøtter. Den fulde beskrivelse af OMA DM protokol v1.2 kan findes på oma hjemmeside.

oma DM standarder

følgende tabel viser oma DM standarder, som vinduer bruger.

generelt område oma DM standard, der understøttes
datatransport og session
  • Klientinitieret ekstern HTTPS DM-session over SSL.
  • Fjern HTTPS DM session over SSL.
  • remote DM server initiering meddelelse ved hjælp af VAP Push over Short Message Service (SMS). Ikke brugt af virksomhedsledelse.
  • Fjern bootstrap ved hjælp af VAP Push over SMS. Ikke brugt af virksomhedsledelse.
    		•
    Bootstrap Oma Client Provisioning.
    DM-protokolkommandoer følgende liste viser de kommandoer, der bruges af enheden. For mere information om oma DM kommando elementer, se “oma hjemmeside” tilgængelig fra oma hjemmeside.

  • Tilføj(Implicit Tilføj understøttet)
  • Alert (DM alert): generisk alert (1226) bruges af enterprise management client, når brugeren udløser en MDM-unenrollment-handling fra enheden, eller når en CSP afslutter nogle asynkrone handlinger. Device alert (1224) bruges til at underrette serveren nogle enhed udløst begivenhed.
  • Atomic: udførelse af en Tilføjelseskommando efterfulgt af Erstat på den samme knude i et atomelement understøttes ikke. Indlejrede Atomic og få kommandoer er ikke tilladt, og vil generere fejlkode 500.
  • Slet: Fjerner en node fra DM-træet og hele undertræet under den node, hvis en findes
  • eksekver: påberåber sig en eksekverbar på klientenheden
  • Hent: henter data fra klientenheden; for indvendige noder returneres underordnede node-navne i dataelementet i Uri-kodet format
  • Erstat: overskriver data på klientenheden
  • resultat: returnerer dataresultaterne for den enhed, der er nødvendig for en get-kommando til DM-serveren
  • sekvens: angiver rækkefølgen, i hvilken en gruppe kommandoer skal behandles
  • status: Angiver fuldførelsesstatus (succes eller fiasko) for en operation
    hvis et element, der ikke er en gyldig oma DM-kommando, er under et af følgende elementer, returneres statuskoden 400 for det pågældende element:
  • SyncBody
  • Atomic
  • sekvens
    hvis der ikke findes nogen CmdID i DM-kommandoen, returnerer klienten Tom i statuselementet og statuskoden 400.
    hvis Atomelementer er indlejret, returneres følgende statuskoder:
  • den indlejrede Atomkommando returnerer 500.
  • den overordnede Atomkommando returnerer 507.
    For mere information om Atomkommandoen, se oma DM protocol common elements.
    udførelse af en Tilføjelseskommando efterfulgt af Erstat på den samme node i et Atomelement understøttes ikke.
    LocURI kan ikke starte med /.
    Meta – tag i SyncHdr ignoreres af enheden.
    		•
    oma DM standardobjekter DevInfo

  • DevDetail
  • oma DM DMS kontoobjekter (oma DM version 1.2)
    		•
    sikkerhed
  • Godkend DM-serverinitieringsmeddelelse SMS-besked (ikke brugt af enterprise management)
  • Application layer Basic og MD5-klientgodkendelse
  • Godkend server med MD5-legitimation på applikationsniveau
  • dataintegritet og godkendelse med HMAC på applikationsniveau
  • SSL-niveau certifikatbaseret klient/servergodkendelse, kryptering og data integritetskontrol
    		•
    noder i Oma DM-træet gælder følgende regler for nodenavnet:

  • “.”kan være en del af nodenavnet.
  • nodenavnet kan ikke være tomt.
  • nodenavnet kan ikke kun være asterisk ( * ) – tegnet.
    		•
    klargøringsfiler klargøringsfiler skal være velformede og følge definitionen i SyncML-Repræsentationsprotokol](https://go.microsoft.com/fwlink/p/?LinkId=526905).
    hvis et element, der ikke er en gyldig oma DM-kommando, er under SyncBody, returneres statuskoden 400 for det pågældende element.

    Bemærk
    for at repræsentere en Unicode-streng som en URI skal du først kode strengen som UTF-8. Derefter kode hver af UTF – 8 bytes ved hjælp af URI-kodning.
    understøtter afsendelse og modtagelse af SyncML i både format og kodet format. Dette kan konfigureres ved hjælp af standardkodeknudepunktet under applikationskarakteristikken v7 under tilmelding. Se Afsnit 8 i SyncML-Repræsentationsprotokol-specifikationen for flere oplysninger om kodning af MVML.
    håndtering af store objekter i Vinduer 10, version 1511 blev kundesupport til upload af store objekter til serveren tilføjet.

    oma DM-protokol fælles elementer

    fælles elementer bruges af andre oma DM-elementtyper. Følgende tabel viser oma DM almindelige elementer, der bruges til at konfigurere enhederne. For mere information om oma DM fælles elementer, se “SyncML repræsentation Protocol Device Management Usage” (oma-SyncML-DMRepPro-V1_1_2-20030613-a) tilgængelig fra oma hjemmeside.

    Element beskrivelse
    Chal angiver en godkendelsesudfordring. Serveren eller klienten kan sende en udfordring til den anden, hvis der ikke blev givet nogen legitimationsoplysninger eller utilstrækkelige legitimationsoplysninger i den oprindelige anmodningsmeddelelse.
    Cmd angiver navnet på en oma DM-kommando, der refereres til i et statuselement.
    CmdID angiver den entydige identifikator for en oma DM-kommando.
    CmdRef angiver id ‘ et for den kommando, for hvilken status-eller resultatoplysninger returneres. Dette element tager værdien af CmdID-elementet i den tilsvarende anmodningsmeddelelse.
    Cred angiver autentificeringsoplysningerne for meddelelsens ophavsmand.
    Final angiver, at den aktuelle meddelelse er den sidste meddelelse i pakken.
    LocName angiver visningsnavnet i mål-og Kildeelementerne, der bruges til at sende et bruger-ID til MD5-godkendelse.
    LocURI angiver adressen på målet eller kildeplaceringen. Hvis adressen indeholder et ikke-alfanumerisk tegn, skal det undgås korrekt i henhold til URL-kodningsstandarden.
    msgstr angiver en entydig identifikator for en oma DM-sessionsmeddelelse.
    MsgRef angiver ID ‘ et for den tilsvarende anmodningsmeddelelse. Dette element tager værdien af forespørgselsmeddelelsen msgstr-element.
    RespURI angiver den URI, som modtageren skal bruge, når der sendes et svar på denne meddelelse.
    SessionID angiver identifikatoren for oma DM-sessionen, der er knyttet til den indeholdende meddelelse.

    Bemærk
    hvis serveren ikke meddeler enheden, at den understøtter en ny version (gennem SyncApplicationVersion node i DMClient CSP), returnerer klienten SessionID i heltal i decimalformat. Hvis serveren understøtter DM session sync version 2.0, som bruges i Vinduer 10, returnerer enhedsklienten 2 byte.
    kilde angiver meddelelsens kildeadresse.
    SourceRef angiver kilden til den tilsvarende anmodningsmeddelelse. Dette element tager værdien af elementet forespørgselsmeddelelseskilde og returneres i elementet Status eller resultater.
    mål angiver adressen på noden i DM-træet, der er målet for oma DM-kommandoen.
    TargetRef angiver måladressen i den tilsvarende anmodningsmeddelelse. Dette element tager værdien af målelementet for anmodningsmeddelelsen og returneres i Status-eller Resultatelementet.
    VerDTD angiver den overordnede og underordnede versionsidentifikator for oma DM-repræsentationsprotokol-specifikationen, der bruges til at repræsentere meddelelsen.
    VerProto angiver den overordnede og underordnede versionsidentifikator for oma DM-protokolspecifikationen, der bruges sammen med meddelelsen.

    Enhedsstyringssession

    en enhedsstyringssession (DM) består af en række kommandoer, der udveksles mellem en DM-server og en klientenhed. Serveren sender kommandoer, der angiver handlinger, der skal udføres på klientenhedens styringstræ. Klienten reagerer ved at sende kommandoer, der indeholder resultaterne og eventuelle ønskede statusoplysninger.

    en kort DM-session kan opsummeres som følgende:

    en server sender en Get-kommando til en klientenhed for at hente indholdet af en af knudepunkterne i styringstræet. Enheden udfører operationen og reagerer med en Resultatkommando, der indeholder det ønskede indhold.

    en DM-session kan opdeles i to faser:

    1. installationsfase: som svar på en triggerhændelse sender en klientenhed en initierende meddelelse til en DM-server. Udvekslingen af enheder og servere havde brug for oplysninger om godkendelse og enheder. Denne fase er repræsenteret ved trin 1, 2 og 3 i den følgende tabel.
    2. Ledelsesfase: DM-serveren er i kontrol. Det sender styringskommandoer til enheden, og enheden reagerer. Fase to slutter, når DM-serveren holder op med at sende kommandoer og afslutter sessionen. Denne fase er repræsenteret ved trin 3, 4 og 5 i den følgende tabel.

    følgende oplysninger viser begivenhedssekvensen under en typisk DM-session.

    1. DM-klient påberåbes for at ringe tilbage til administrationsserveren
      Enterprise scenario – enhedsopgaveplanen påberåber DM-klienten.

      MO-serveren sender en serverudløsermeddelelse for at påberåbe sig DM-klienten.

      udløsermeddelelsen indeholder server-ID ‘ et og beder klientenheden om at starte en session med serveren. Klientenheden godkender udløsermeddelelsen og verificerer, at serveren er autoriseret til at kommunikere med den.
      Enterprise scenario-på det planlagte tidspunkt påberåbes DM-klienten med jævne mellemrum for at ringe tilbage til enterprise management-serveren via HTTPS.

    2. enheden sender en besked via en IP-forbindelse for at starte sessionen.

      denne meddelelse indeholder enhedsoplysninger og legitimationsoplysninger. Klienten og serveren foretager gensidig godkendelse via en SSL-kanal eller på DM-applikationsniveau.

    3. DM-serveren reagerer via en IP-forbindelse (HTTPS). Serveren sender indledende enhedsstyringskommandoer, hvis nogen.

    4. enheden reagerer på serverstyringskommandoer. Denne meddelelse indeholder resultaterne af udførelsen af de angivne enhedsstyringsoperationer.

    5. DM-serveren afslutter sessionen eller sender en anden kommando. DM-sessionen slutter, eller trin 4 gentages.

    trinnumrene repræsenterer ikke meddelelsesidentifikationsnumre (msgstr). Alle meddelelser fra serveren skal have en msgstr, der er unik i sessionen, startende ved 1 for den første meddelelse og øges med et trin på 1 for hver ekstra meddelelse. For mere information om msgstr og OMA SyncML-protokollen, se Oma Device Management Representation Protocol (DM_RepPro-V1_2-20070209-a).

    under oma DM-applikationsniveau gensidig godkendelse, hvis enhedens svarkode til Cred-element i serveranmodningen er 212, er der ikke behov for yderligere godkendelse i resten af DM-sessionen. I tilfælde af MD5-godkendelse kan Chal-elementet returneres. Derefter skal den næste nonce i Chal bruges til MD5-fordøjelsen, når den næste DM-session startes.

    hvis en anmodning indeholder legitimationsoplysninger, og svarkoden på anmodningen er 200, skal den samme legitimationsoplysninger sendes inden for den næste anmodning. Hvis Chal-elementet er inkluderet, og MD5-godkendelsen er påkrævet, oprettes en ny fordøjelse ved hjælp af den næste nonce via Chal-elementet til næste anmodning.

    For mere information om grundlæggende eller MD5-klientgodkendelse, MD5-servergodkendelse, MD5 hash og MD5 nonce, se oma Device Management Security specification (Oma-TS-DM_Security-V1_2_1-20080617-a), håndtering af godkendelsesresponskode og trinvise prøver i Oma Device Management Protocol specification (oma-TS-DM_Protocol-V1_2_1-20080617-a), tilgængelig fra oma ‘ s hjemmeside.

    bruger målrettet vs. Enhedsmålrettet konfiguration

    for CSP ‘ er og politikker, der understøtter konfiguration pr.bruger, kan MDM-serveren sende brugermålrettede indstillingsværdier til den enhed, som en MDM-tilmeldt bruger aktivt er logget ind på. Enheden giver serveren besked om login-status via en enhedsalarm (1224) med alarmtype = i DM pkg#1.

    datadelen af denne alarm kan være en af følgende strenge:

    • bruger-den bruger, der tilmeldte enheden, er aktivt logget ind. MDM-serveren kunne sende brugerspecifik konfiguration for CSP ‘ er/politikker, der understøtter per Brugerkonfiguration
    • andre – en anden bruger login, men den bruger har ikke en MDM-konto. Serveren kan kun anvende enhedsomfattende konfiguration, for eksempel gælder konfiguration for alle brugere i enheden.
    • ingen-ingen aktiv bruger login. Serveren kan kun anvende enhedsomfattende konfiguration, og den tilgængelige konfiguration er begrænset til enhedsmiljøet (ingen aktiv bruger login).

    nedenfor er et advarselseksempel:

    <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 meddeler enheden, om det er en bruger målrettet eller enhed målrettet konfiguration af et præfiks til ledelsen node LocURL, med ./ bruger til bruger målrettet konfiguration, eller ./ enhed til enhed målrettet konfiguration. Som standard, hvis ingen præfiks med ./ enhed eller ./ bruger, det er enhed målrettet konfiguration.

    følgende LocURL viser en per bruger CSP node konfiguration:./user/vendor/MSFT/EnterpriseModernAppManagement/AppInstallation/<PackageFamilyName>/StoreInstall

    følgende LocURL viser en CSP-knudekonfiguration pr. enhed: ./enhed/leverandør/MSFT/Fjerntørre / Dybrør

    SyncML response status codes

    når du bruger SyncML i OMA DM, er der standard responsstatus koder, der returneres. Følgende tabel viser de almindelige SyncML-svarstatuskoder, du sandsynligvis vil se. For mere information om SyncML-svarstatuskoder, se Afsnit 10 i SyncML-Repræsentationsprotokollspecifikationen.

    Status kode beskrivelse
    200 SyncML-kommandoen blev gennemført med succes.
    202 accepteret til behandling. Dette er normalt en asynkron handling, såsom en anmodning om at køre en fjernudførelse af et program.
    212 godkendelse accepteret. Normalt vil du kun se dette som svar på SyncHdr-elementet (bruges til godkendelse i Oma-DM-standarden). Du kan se dette, hvis du ser på oma DM-logfiler, men CSP ‘ er genererer typisk ikke dette.
    214 operation annulleret. SyncML-kommandoen er fuldført, men der vil ikke blive behandlet flere kommandoer i sessionen.
    215 ikke henrettet. En kommando blev ikke udført som et resultat af brugerinteraktion for at annullere kommandoen.
    216 Atomic rul tilbage OK. En kommando var inde i et Atomic element og Atomic mislykkedes. Denne kommando blev rullet tilbage med succes.
    400 dårlig anmodning. Den ønskede kommando kunne ikke udføres på grund af misdannet syntaks. CSP ‘ er genererer normalt ikke denne fejl, men du kan muligvis se den, hvis din SyncML er misdannet.
    401 ugyldige legitimationsoplysninger. Den anmodede kommando mislykkedes, fordi anmoderen skal give korrekt godkendelse. CSP ‘ er genererer normalt ikke denne fejl.
    403 forbudt. Den ønskede kommando mislykkedes, men modtageren forstod den ønskede kommando.
    404 ikke fundet. Det ønskede mål blev ikke fundet. Denne kode genereres, hvis du forespørger på en node, der ikke findes.
    405 kommando ikke tilladt. Denne svarkode genereres, hvis du prøver at skrive til en skrivebeskyttet node.
    406 valgfri funktion understøttes ikke. Denne svarkode genereres, hvis du forsøger at få adgang til en ejendom, som CSP ikke understøtter.
    415 ikke-understøttet type eller format. Denne svarkode kan skyldes fejl i parsing eller formatering.
    418 findes allerede. Denne svarkode opstår, hvis du forsøger at tilføje en node, der allerede findes.
    425 Tilladelse Nægtet. Den ønskede kommando mislykkedes, fordi afsenderen ikke har tilstrækkelige adgangskontroltilladelser (ACL) på modtageren. “Adgang nægtet” fejl bliver normalt oversat til denne svarkode.
    500 kommandoen mislykkedes. Generisk fiasko. Modtageren stødte på en uventet tilstand, der forhindrede den i at opfylde anmodningen. Denne svarkode opstår, når SyncML DPU ikke kan kortlægge den oprindelige fejlkode.
    507 Atomic mislykkedes. En af operationerne i en Atomic blok mislykkedes.
    516 Atomic rul tilbage mislykkedes. En Atomic operation mislykkedes, og kommandoen blev ikke rullet tilbage med succes.

    Skriv et svar

    Din e-mailadresse vil ikke blive publiceret.