stöd för oma DM-protokoll

Skriven av den i Articles
  • artikel
  • 12/16/2021
  • 12 minuter att läsa
    • D
    • M
    • a
    • v
    • d
    • +11
är den här sidan till hjälp?

tack.

oma DM-klienten kommunicerar med servern via HTTPS och använder DM Sync (OMA DM v1.2) som meddelande nyttolast. Det här avsnittet beskriver oma DM-funktionalitet som DM-klienten stöder i allmänhet. Den fullständiga beskrivningen av oma DM-protokollet v1.2 finns på OMA: s webbplats.

oma DM-standarder

följande tabell visar de oma DM-standarder som Windows använder.

allmänt område oma DM-standard som stöds
datatransport och session
  • Klientinitierad fjärrstyrd HTTPS DM-session över SSL.
  • fjärr HTTPS DM-session över SSL.
  • fjärr DM-server initiering anmälan med WAP Push over Short Message Service (SMS). Används inte av företagsledning.
  • Remote bootstrap genom att använda WAP Push over SMS. Används inte av företagsledning.
    		•
    Bootstrap XML oma klient Provisioning XML.
    DM-protokollkommandon följande lista visar de kommandon som används av enheten. För mer information om kommandoelementen för oma DM, se ”oma-webbplats” tillgänglig från oma-webbplatsen.

  • Lägg till (Implicit Add stöds)
  • Alert (DM alert): Generic alert (1226) används av enterprise management client när användaren utlöser en MDM unenrollment åtgärd från enheten eller när en CSP avslutar vissa asynkrona åtgärder. Device alert (1224) används för att meddela servern någon enhet utlöst händelse.
  • Atom: att utföra ett Add-kommando följt av ersätt på samma nod i ett atomelement stöds inte. Kapslade Atom-och Get-kommandon är inte tillåtna och kommer att generera felkod 500.
  • radera: Tar bort en nod från DM-trädet och hela underträdet under den noden om det finns en
  • Exec: anropar en körbar på klientenheten
  • Get: hämtar data från klientenheten; för inre noder returneras underordnade nodnamn i dataelementet i URI-kodat format
  • ersätt: skriver över data på klientenheten
  • resultat: returnerar dataresultaten för en hämta kommando till DM-servern
  • sekvens: anger i vilken ordning en grupp kommandon måste behandlas
  • status: Anger slutförandestatus (framgång eller misslyckande) för en åtgärd
    om ett XML-element som inte är ett giltigt OMA DM-kommando finns under något av följande element returneras statuskoden 400 för det elementet:
  • SyncBody
  • Atomic
  • sekvens
    om ingen CmdID tillhandahålls i kommandot DM, returnerar klienten tomt i statuselementet och statuskoden 400.
    om Atomelement är kapslade returneras följande statuskoder:
  • det kapslade Atomkommandot returnerar 500.
  • det överordnade Atomkommandot returnerar 507.
    för mer information om Atomkommandot, se oma DM protocol common elements.
    att utföra ett Add-kommando följt av ersätt på samma nod i ett Atomelement stöds inte.
    LocURI kan inte börja med /.
    Meta XML-tagg i SyncHdr ignoreras av enheten.
    		•
    oma DM standardobjekt DevInfo

  • DevDetail
  • oma DM DMS kontoobjekt (oma DM version 1.2)
    		•
    säkerhet
  • autentisera DM server initiation notification SMS-meddelande (används inte av företagsledning)
  • Application layer Basic och MD5 client authentication
  • autentisera servern med MD5 credential på applikationsnivå
  • dataintegritet och autentisering med HMAC på applikationsnivå
  • SSL-nivå certifikatbaserad klient/server autentisering, kryptering och data integritetskontroll
    		•
    noder i Oma DM-trädet gäller följande regler för nodnamnet:

  • ”.”kan vara en del av nodnamnet.
  • nodnamnet kan inte vara tomt.
  • nodnamnet kan inte bara vara tecknet asterisk ( * ).
    		•
    Provisioning filer Provisioning XML måste vara välformade och följa definitionen i SyncML Representation Protocol](https://go.microsoft.com/fwlink/p/?LinkId=526905).
    om ett XML-element som inte är ett giltigt OMA DM-kommando är under SyncBody returneras statuskoden 400 för det elementet.

    Obs
    för att representera en Unicode-sträng som en URI, koda först strängen som UTF-8. Koda sedan var och en av UTF-8 byte med URI-kodning.
    WBXML-stöd Windows stöder sändning och mottagning av SyncML i både XML-format och kodat WBXML-format. Detta kan konfigureras genom att använda noden DEFAULTENCODING under W7-APPLIKATIONSKARAKTERISTIKEN under registrering. För mer information om WBXML-kodning, se avsnitt 8 i SyncML-Representationsprotokollspecifikationen.
    hantering av stora objekt i Windows 10, version 1511, tillsattes kundsupport för att ladda upp stora objekt till servern.

    oma DM-protokoll vanliga element

    vanliga element används av andra oma DM-elementtyper. I följande tabell visas de vanliga elementen i OMA dm som används för att konfigurera enheterna. För mer information om oma DM vanliga element, se ”SyncML Representation Protocol Device Management Usage” (OMA-SyncML-DMRepPro-V1_1_2-20030613-a) tillgänglig från oma: s webbplats.

    Element beskrivning
    Chal anger en autentiseringsutmaning. Servern eller klienten kan skicka en utmaning till den andra om inga referenser eller otillräckliga referenser gavs i det ursprungliga begäran meddelandet.
    cmd anger namnet på ett oma DM-kommando som refereras i ett Statuselement.
    CmdID anger den unika identifieraren för ett OMA DM-kommando.
    Cmdref anger ID för kommandot för vilket status-eller resultatinformation returneras. Detta element tar värdet av cmdid-elementet i motsvarande förfrågningsmeddelande.
    Cred anger autentiseringsuppgifterna för meddelandets upphovsman.
    Final anger att det aktuella meddelandet är det sista meddelandet i paketet.
    LocName anger visningsnamnet i mål-och Källelementen, som används för att skicka ett användar-ID för MD5-autentisering.
    LocURI anger adressen för målet eller källplatsen. Om adressen innehåller ett icke-alfanumeriskt tecken måste den vara korrekt undantagen enligt URL-kodningsstandarden.
    msgstr anger en unik identifierare för ett OMA DM-sessionsmeddelande.
    MsgRef anger ID för motsvarande förfrågningsmeddelande. Detta element tar värdet av msgstr-elementet för begäran.
    RespURI anger den URI som mottagaren måste använda när han skickar ett svar på det här meddelandet.
    SessionID anger identifieraren för oma DM-sessionen som är associerad med det innehållande meddelandet.

    Obs
    om servern inte meddelar enheten att den stöder en ny version (via SyncApplicationVersion-noden i DMClient CSP) returnerar klienten SessionID i heltal i decimalformat. Om servern stöder DM session sync version 2.0, som används i Windows 10, returnerar enhetsklienten 2 byte.
    källa anger meddelandekällans adress.
    SourceRef anger källan till motsvarande förfrågningsmeddelande. Detta element tar värdet av källelementet för begäran om meddelande och returneras i Status-eller Resultatelementet.
    mål anger adressen till noden, i DM-trädet, som är målet för kommandot OMA DM.
    TargetRef anger måladressen i motsvarande förfrågningsmeddelande. Det här elementet tar värdet av målelementet för begäran om meddelande och returneras i Status-eller Resultatelementet.
    VerDTD anger huvud-och mindre versionsidentifieraren för oma DM-representationsprotokollspecifikationen som används för att representera meddelandet.
    VerProto anger huvud-och mindre versionsidentifieraren för oma DM-protokollspecifikationen som används med meddelandet.

    enhetshanteringssession

    en Enhetshanteringssession (DM) består av en serie kommandon som utbyts mellan en DM-server och en klientenhet. Servern skickar kommandon som anger operationer som måste utföras på klientenhetens hanteringsträd. Klienten svarar genom att skicka kommandon som innehåller resultaten och all begärd statusinformation.

    en kort DM-session kan sammanfattas som följande:

    en server skickar ett Get-kommando till en klientenhet för att hämta innehållet i en av noderna i hanteringsträdet. Enheten utför operationen och svarar med ett Resultatkommando som innehåller det begärda innehållet.

    en DM-session kan delas in i två faser:

    1. Inställningsfas: som svar på en utlösningshändelse skickar en klientenhet ett initieringsmeddelande till en DM-server. Enheten och serverutbytet behövde autentisering och enhetsinformation. Denna fas representeras av steg 1, 2 och 3 i följande tabell.
    2. Hanteringsfas: DM-servern har kontroll. Den skickar hanteringskommandon till enheten och enheten svarar. Fas två slutar när DM-servern slutar skicka kommandon och avslutar sessionen. Denna fas representeras av steg 3, 4 och 5 i följande tabell.

    följande information visar händelseförloppet under en typisk DM-session.

    1. DM-klienten anropas för att ringa tillbaka till hanteringsservern
      Enterprise scenario – enhetens aktivitetsschema anropar DM-klienten.

      MO-servern skickar ett serverutlösningsmeddelande för att anropa DM-klienten.

      utlösningsmeddelandet innehåller server-ID och berättar för klientenheten att initiera en session med servern. Klientenheten autentiserar utlösningsmeddelandet och verifierar att servern är behörig att kommunicera med den.
      Enterprise scenario – vid den schemalagda tiden anropas DM-klienten regelbundet för att ringa tillbaka till enterprise management server via HTTPS.

    2. enheten skickar ett meddelande via en IP-anslutning för att initiera sessionen.

      detta meddelande innehåller enhetsinformation och autentiseringsuppgifter. Klienten och servern gör ömsesidig autentisering via en SSL-kanal eller på DM-applikationsnivå.

    3. DM-servern svarar via en IP-anslutning (HTTPS). Servern skickar initiala enhetshanteringskommandon, om några.

    4. enheten svarar på serverhanteringskommandon. Det här meddelandet innehåller resultaten av att utföra de angivna enhetshanteringsoperationerna.

    5. DM-servern avslutar sessionen eller skickar ett annat kommando. DM-sessionen avslutas, eller steg 4 upprepas.

    stegnumren representerar inte message identification numbers (msgstr). Alla meddelanden från servern måste ha ETT msgstr som är unikt i sessionen, börjar vid 1 för det första meddelandet och ökar med ett steg om 1 för varje extra meddelande. För mer information om msgstr och oma SyncML-protokollet, se oma Device Management Representation Protocol (DM_RepPro-V1_2-20070209-a).

    under oma DM-applikationsnivå ömsesidig autentisering, om enhetens svarskod till Cred-elementet i serverbegäran är 212, behövs ingen ytterligare autentisering för resten av DM-sessionen. När det gäller MD5-autentisering kan Chal-elementet returneras. Då måste nästa nonce i Chal användas för MD5-smältningen när nästa DM-session startas.

    om en begäran innehåller referenser och svarskoden till begäran är 200, måste samma referens skickas inom nästa begäran. Om Chal-elementet ingår och MD5-autentisering krävs, skapas en ny sammanfattning genom att använda nästa nonce via Chal-elementet för nästa begäran.

    för mer information om grundläggande eller MD5 klient autentisering, MD5 Server autentisering, MD5 hash och MD5 nonce, se oma Device Management Security specification (OMA-TS-DM_Security-V1_2_1-20080617-A), autentisering svarskod hantering och steg-för-steg prover i Oma Device Management Protocol specification (OMA-TS-DM_Protocol-V1_2_1-20080617-a), tillgänglig från oma: s webbplats.

    användaren riktade vs. Enhetsinriktad konfiguration

    för CSP: er och policyer som stöder konfiguration per användare kan MDM-servern skicka användarinriktade inställningsvärden till den enhet som en MDM-registrerad användare är aktivt inloggad på. Enheten meddelar servern om inloggningsstatus via en enhetsvarning (1224) med varningstyp = i DM pkg#1.

    Datadelen av denna varning kan vara en av följande strängar:

    • användare-användaren som registrerade enheten är aktivt inloggad. MDM-servern kan skicka användarspecifik konfiguration för CSP/policyer som stöder per Användarkonfiguration
    • andra – en annan användarinloggning men den användaren har inget MDM-konto. Servern kan bara tillämpa enhetsomfattande konfiguration, till exempel gäller konfigurationen för alla användare i enheten.
    • None-ingen aktiv användarinloggning. Servern kan bara tillämpa enhetsomfattande konfiguration och tillgänglig konfiguration är begränsad till enhetsmiljön (ingen aktiv användarinloggning).

    nedan är ett varningsexempel:

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

    servern meddelar enheten om det är en användare riktade eller enhet riktad konfiguration av ett prefix till hanteringsnoden LocURL, med ./ användare för användarinriktad konfiguration, eller ./ enhet för enhet riktad konfiguration. Som standard, om inget prefix med ./ enhet eller ./ användare, det är enhetsinriktad konfiguration.

    följande LocURL visar en CSP-nodkonfiguration per användare:./user/vendor/MSFT/EnterpriseModernAppManagement/AppInstallation/<PackageFamilyName>/StoreInstall

    följande LocURL visar en CSP-nodkonfiguration per enhet: ./ device / vendor/Msft / RemoteWipe / DoWipe

    SyncML-svarstatuskoder

    när du använder SyncML i OMA DM finns det standardstatuskoder för svar som returneras. I följande tabell visas de vanliga SyncML-svarstatuskoderna som du sannolikt kommer att se. För mer information om SyncML-svarsstatuskoder, se avsnitt 10 i SyncML-Representationsprotokollspecifikationen.

    statuskod beskrivning
    200 kommandot SyncML slutfördes framgångsrikt.
    202 godkänd för bearbetning. Detta är vanligtvis en asynkron operation, till exempel en begäran om att köra en fjärrkörning av en applikation.
    212 autentisering accepteras. Normalt ser du bara detta som svar på SyncHdr-elementet (används för autentisering i Oma-DM-standarden). Du kan se detta om du tittar på OMA DM-loggar, men CSP: er genererar vanligtvis inte detta.
    214 operationen avbröts. Kommandot SyncML slutfördes framgångsrikt, men inga fler kommandon kommer att behandlas inom sessionen.
    215 inte avrättad. Ett kommando utfördes inte som ett resultat av användarinteraktion för att avbryta kommandot.
    216 Atomic rulla tillbaka OK. Ett kommando var inuti ett Atomic – element och Atomic misslyckades. Detta kommando rullades tillbaka framgångsrikt.
    400 Dålig begäran. Det gick inte att utföra det begärda kommandot på grund av felaktig syntax. CSP: er genererar vanligtvis inte detta fel, men du kan se det om din SyncML är felaktig.
    401 ogiltiga referenser. Det begärda kommandot misslyckades eftersom begäraren måste tillhandahålla korrekt autentisering. CSP: er genererar vanligtvis inte detta fel.
    403 förbjudet. Det begärda kommandot misslyckades, men mottagaren förstod det begärda kommandot.
    404 hittades inte. Det begärda målet hittades inte. Den här koden genereras om du frågar en nod som inte finns.
    405 kommando inte tillåtet. Denna svarskod genereras om du försöker skriva till en skrivskyddad nod.
    406 valfri funktion stöds inte. Den här svarskoden genereras om du försöker komma åt en egenskap som CSP inte stöder.
    415 typ eller format som inte stöds. Denna svarskod kan bero på XML-parsning eller formateringsfel.
    418 finns redan. Den här svarskoden uppstår om du försöker lägga till en nod som redan finns.
    425 Tillstånd Nekas. Det begärda kommandot misslyckades eftersom avsändaren inte har tillräckliga åtkomstkontrollbehörigheter (ACL) på mottagaren. ”Access denied” – fel översätts vanligtvis till denna svarskod.
    500 kommandot misslyckades. Generiskt misslyckande. Mottagaren stötte på ett oväntat villkor som hindrade den från att uppfylla begäran. Denna svarskod kommer att inträffa när SyncML DPU inte kan mappa den ursprungliga felkoden.
    507 Atomic misslyckades. En av operationerna i ett Atomic – block misslyckades.
    516 Atomic rulla tillbaka misslyckades. En Atomic – operation misslyckades och kommandot rullades inte tillbaka framgångsrikt.

    Lämna ett svar

    Din e-postadress kommer inte publiceras.