podpora protokolu oma DM

Written by on in Articles
  • článek
  • 12/16/2021
  • 12 zápis ke čtení
    • D
    • M
    • a
    • v
    • d
    • +11
je tato stránka užitečná?

Děkuji.

klient oma DM komunikuje se serverem přes HTTPS a jako užitečné zatížení zprávy používá DM Sync (oma DM v1.2). Toto téma popisuje funkci OMA DM, kterou klient DM obecně podporuje. Úplný popis protokolu oma DM v1. 2 naleznete na webových stránkách OMA.

standardy OMA DM

následující tabulka ukazuje standardy OMA DM, které systém Windows používá.

obecná oblast OMA DM standard, který je podporován
přenos dat a relace
  • klient-inicioval vzdálené HTTPS DM relace přes SSL.
  • vzdálená relace HTTPS DM přes SSL.
  • vzdálené oznámení o zahájení DM serveru pomocí služby WAP Push over Short Message Service (SMS). Nepoužívá vedení podniku.
  • vzdálený bootstrap pomocí WAP Push over SMS. Nepoužívá vedení podniku.
    		•
    Bootstrap XML Oma Client Provisioning XML.
    příkazy protokolu dm následující seznam zobrazuje příkazy, které zařízení používá. Další informace o prvcích příkazu OMA DM naleznete na stránce „webová stránka OMA“, která je k dispozici na webových stránkách OMA.

  • Add (implicitní Add podporováno)
  • Alert (DM alert): Generic alert (1226)je používán enterprise management client, když uživatel spustí MDM unenrollment akci ze zařízení nebo když CSP dokončí některé asynchronní akce. Upozornění na zařízení (1224) se používá k upozornění serveru na nějakou událost spuštěnou zařízením.
  • Atomic: provedení příkazu Add následovaného nahrazením na stejném uzlu v atomovém prvku není podporováno. Vnořené příkazy Atomic a Get nejsou povoleny a vygenerují kód chyby 500.
  • Smazat: Odstraní uzel ze stromu DM a celý podstrom pod tímto uzlem, pokud existuje
  • Exec: vyvolá spustitelný soubor na klientském zařízení
  • Get: načte data z klientského zařízení; pro vnitřní uzly jsou názvy podřízených uzlů v datovém prvku vráceny ve formátu kódovaném URI
  • Replace: přepíše data na klientském zařízení
  • výsledek: vrátí výsledky dat příkazu Get na server DM
  • sekvence: určuje pořadí, ve kterém musí být skupina příkazů zpracována
  • stav: Označuje stav dokončení (úspěch nebo selhání) operace
    pokud je prvek XML, který není platným příkazem OMA DM, pod jedním z následujících prvků, vrátí se pro tento prvek stavový kód 400:
  • SyncBody
  • Atomic
  • sekvence
    pokud není v příkazu DM zadán CmdID, klient vrátí prázdný prvek stavu a stavový kód 400.
    pokud jsou atomové prvky vnořeny, jsou vráceny následující stavové kódy:
  • vnořený atomový příkaz vrací 500.
  • Nadřazený atomový příkaz vrátí 507.
    další informace o atomovém příkazu naleznete v části společné prvky protokolu oma DM.
    provedení příkazu Add následovaného nahrazením na stejném uzlu V atomovém prvku není podporováno.
    LocURI nemůže začínat /.
    Meta XML tag v SyncHdr je ignorován zařízením.
    		•
    oma DM standardní objekty DevInfo

  • DevDetail
  • objekty účtu OMA DM DMS (OMA DM verze 1.2)
    		•
    zabezpečení
  • ověření DM serveru oznámení o zahájení SMS zprávy (nepoužívá enterprise management)
  • Aplikační vrstva základní a MD5 ověření klienta
  • ověření serveru pomocí MD5 pověření na aplikační úrovni
  • integrita dat a autentizace pomocí HMAC na aplikační úrovni
  • ověření klienta/serveru na základě certifikátu SSL, šifrování a kontrola integrity dat
    		•
    uzly ve stromu OMA DM platí pro název uzlu následující pravidla:

  • „.“může být součástí názvu uzlu.
  • název uzlu nemůže být prázdný.
  • název uzlu nemůže být pouze znakem hvězdičky ( * ).
    		•
    zřizovací soubory zřizovací XML musí být dobře vytvořeny a musí se řídit definicí v SyncML Representation Protocol] (https://go.microsoft.com/fwlink/p/?LinkId=526905).
    pokud je prvek XML, který není platným příkazem OMA DM, pod SyncBody, vrátí se pro tento prvek stavový kód 400.

    Poznámka
    Chcete-li reprezentovat řetězec Unicode jako URI, nejprve kódujte řetězec jako UTF-8. Poté zakódujte každý z bajtů UTF-8 pomocí kódování URI.
    podpora WBXML Windows podporuje odesílání a přijímání SyncML ve formátu XML i kódovaném formátu WBXML. To je konfigurovatelné pomocí uzlu DEFAULTENCODING pod charakteristikou aplikace w7 během zápisu. Další informace o kódování WBXML naleznete v části 8 specifikace protokolu reprezentace SyncML.
    manipulace s velkými objekty v systému Windows 10, Verze 1511, byla přidána podpora klienta pro nahrávání velkých objektů na server.

    oma DM protokol běžné prvky

    běžné prvky jsou používány jinými typy prvků OMA DM. V následující tabulce jsou uvedeny běžné prvky OMA DM použité ke konfiguraci zařízení. Další informace o společných prvcích OMA DM naleznete v části „SyncML Representation Protocol Device Management Usage“ (OMA-SyncML-DMRepPro-V1_1_2-20030613-A) dostupné na webových stránkách OMA.

    prvek popis
    Chal určuje výzvu k ověření. Server nebo klient může poslat výzvu druhému, pokud v původní zprávě žádosti nebyly uvedeny žádné pověření nebo nedostatečné pověření.
    Cmd určuje název příkazu OMA DM odkazovaného ve stavovém prvku.
    CmdID určuje jedinečný identifikátor příkazu OMA DM.
    CmdRef určuje ID příkazu, pro který jsou vráceny informace o stavu nebo výsledcích. Tento prvek má hodnotu prvku CmdID odpovídající zprávy požadavku.
    Cred určuje autentizační pověření pro původce zprávy.
    Poslední označuje, že aktuální zpráva je poslední zprávou v balíčku.
    LocName určuje zobrazované jméno v cílových a zdrojových prvcích, které se používá pro odeslání ID uživatele pro autentizaci MD5.
    LocURI určuje adresu cílového nebo zdrojového umístění. Pokud Adresa obsahuje nealfanumerický znak, musí být správně escapována podle standardu kódování URL.
    msgstr určuje jedinečný identifikátor zprávy relace oma DM.
    MsgRef určuje ID odpovídající zprávy požadavku. Tento prvek má hodnotu prvku zprávy požadavku msgstr.
    RespURI určuje URI, které musí příjemce použít při odesílání odpovědi na tuto zprávu.
    SessionID určuje identifikátor relace OMA DM přidružené k obsahující zprávě.

    Poznámka
    pokud server neoznámí zařízení, že podporuje novou verzi (prostřednictvím uzlu SyncApplicationVersion v DMClient CSP), klient vrátí SessionID v celočíselném formátu v desítkovém formátu. Pokud server podporuje DM session sync verze 2.0, která se používá v systému Windows 10, klient zařízení vrátí 2 bajty.
    zdroj určuje adresu zdroje zprávy.
    SourceRef určuje zdroj odpovídající zprávy požadavku. Tento prvek má hodnotu zdrojového prvku zprávy požadavku a je vrácen v prvku stav nebo výsledky.
    cíl určuje adresu uzlu ve stromu DM, který je cílem příkazu OMA DM.
    TargetRef určuje cílovou adresu v odpovídající zprávě požadavku. Tento prvek má hodnotu cílového prvku zprávy požadavku a je vrácen v prvku stav nebo výsledky.
    VerDTD určuje hlavní a vedlejší identifikátor verze specifikace protokolu oma DM representation protocol použité k reprezentaci zprávy.
    VerProto určuje hlavní a vedlejší identifikátor verze specifikace protokolu OMA DM použitého se zprávou.

    relace správy zařízení

    relace správy zařízení (DM) se skládá z řady příkazů vyměňovaných mezi serverem DM a klientským zařízením. Server odešle příkazy označující operace, které musí být provedeny na stromu správy klientského zařízení. Klient reaguje zasláním příkazů, které obsahují výsledky a veškeré požadované informace o stavu.

    krátkou relaci DM lze shrnout takto:

    server odešle příkaz Get do klientského zařízení, aby načetl obsah jednoho z uzlů stromu správy. Zařízení provede operaci a odpoví příkazem výsledek, který obsahuje požadovaný obsah.

    relaci DM lze rozdělit do dvou fází:

    1. fáze nastavení: v reakci na spouštěcí událost odešle klientské zařízení iniciační zprávu serveru DM. Výměna zařízení a serveru potřebovala ověření a informace o zařízení. Tato fáze je reprezentována kroky 1, 2 a 3 v následující tabulce.
    2. fáze řízení: DM server je pod kontrolou. Odešle příkazy pro správu do zařízení a zařízení reaguje. Druhá fáze končí, když server DM přestane odesílat příkazy a ukončí relaci. Tato fáze je reprezentována kroky 3, 4 a 5 v následující tabulce.

    následující informace ukazují sled událostí během typické relace DM.

    1. DM klient je vyvolán pro volání zpět na server pro správu
      podnikový scénář-plán úloh zařízení vyvolá klienta DM.

      MO server odešle spouštěcí zprávu serveru pro vyvolání klienta DM.

      spouštěcí zpráva obsahuje ID serveru a řekne klientskému zařízení, aby zahájilo relaci se serverem. Klientské zařízení ověřuje spouštěcí zprávu a ověřuje, že server je oprávněn s ní komunikovat.
      podnikový scénář-v naplánovaném čase je klient DM pravidelně vyvolán, aby mohl volat zpět na Server enterprise management přes HTTPS.

    2. zařízení odešle zprávu, přes připojení IP, zahájit relaci.

      tato zpráva obsahuje informace o zařízení a pověření. Klient a server provádějí vzájemnou autentizaci přes SSL kanál nebo na aplikační úrovni DM.

    3. server DM reaguje přes připojení IP (HTTPS). Server odešle počáteční příkazy pro správu zařízení, pokud existují.

    4. zařízení reaguje na příkazy správy serveru. Tato zpráva obsahuje výsledky provádění zadaných operací správy zařízení.

    5. server DM Ukončí relaci nebo odešle jiný příkaz. Relace DM končí nebo se opakuje Krok 4.

    čísla kroků nepředstavují identifikační čísla zpráv (msgstr). Všechny zprávy ze serveru musí mít msgstr, který je v rámci relace jedinečný, počínaje 1 pro první zprávu a zvyšující se o přírůstek 1 pro každou další zprávu. Další informace o protokolu MsgID a oma SyncML naleznete v části Oma Device Management Representation Protocol (DM_RepPro-V1_2-20070209-A).

    během vzájemné autentizace na úrovni aplikace OMA DM, je – li kód odezvy zařízení na prvek Cred v požadavku serveru 212, není pro zbytek relace DM zapotřebí žádné další ověření. V případě autentizace MD5 může být prvek Chal vrácen. Pak další nonce v Chal musí být použit pro MD5 digest při spuštění další relace DM.

    pokud požadavek obsahuje pověření a kód odpovědi na požadavek je 200, musí být stejné pověření odesláno v rámci dalšího požadavku. Pokud je prvek Chal zahrnut a je vyžadováno ověření MD5, vytvoří se nový přehled pomocí dalšího prvku nonce přes prvek Chal pro další požadavek.

    další informace o základním nebo MD5 ověřování klienta, MD5 ověřování serveru, MD5 hash, a MD5 nonce, viz oma Device Management Security specification (OMA-TS-DM_Security-V1_2_1-20080617-A), zpracování kódu autentizační odpovědi a ukázky krok za krokem v Oma Device Management Protocol specification (OMA-TS-DM_Protocol-V1_2_1-20080617-A), k dispozici na webových stránkách OMA.

    cílené uživatele vs. Cílená konfigurace zařízení

    u CSP a zásad, které podporují konfiguraci uživatele, může Server MDM odeslat hodnoty cíleného nastavení uživatele zařízení, do kterého je uživatel zapsaný MDM aktivně přihlášen. Zařízení upozorní server na stav přihlášení prostřednictvím zařízení alert (1224) s Alert type = V DM pkg#1.

    datová část tohoto upozornění může být jedním z následujících řetězců:

    • uživatel-uživatel, který zařízení zaregistroval, je aktivně přihlášen. MDM server by mohl poslat konfiguraci specifickou pro uživatele pro CSP / politiky, které podporují konfiguraci uživatele
    • Ostatní-další přihlášení uživatele, ale tento uživatel nemá účet MDM. Server může použít pouze konfiguraci pro celé zařízení, například konfigurace se vztahuje na všechny uživatele v zařízení.
    • žádné-žádné aktivní přihlášení uživatele. Server může použít pouze konfiguraci pro celé zařízení a dostupná konfigurace je omezena na prostředí zařízení (bez aktivního přihlášení uživatele).

    níže je uveden příklad výstrahy:

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

    server upozorní zařízení, zda se jedná o cílenou konfiguraci uživatele nebo zařízení cílenou prefixem LocURL uzlu správy, s./ uživatel pro uživatele cílené konfigurace, nebo ./ zařízení pro cílenou konfiguraci zařízení. Ve výchozím nastavení, pokud není předpona s./ zařízení nebo ./ uživatel, to je zařízení cílené konfigurace.

    následující LocURL ukazuje konfiguraci uzlu CSP na uživatele: ./user/vendor/MSFT/EnterpriseModernAppManagement/AppInstallation/<PackageFamilyName>/StoreInstall

    následující LocURL ukazuje konfiguraci uzlu CSP na zařízení: ./ device / vendor / MSFT/RemoteWipe / DoWipe

    kódy stavu odezvy SyncML

    při použití SyncML v OMA DM jsou vráceny standardní kódy stavu odezvy. V následující tabulce jsou uvedeny běžné kódy stavu odezvy SyncML, které pravděpodobně uvidíte. Další informace o stavových kódech odezvy SyncML naleznete v části 10 specifikace protokolu reprezentace SyncML.

    stavový kód popis
    200 příkaz SyncML byl úspěšně dokončen.
    202 přijato ke zpracování. Toto je obvykle asynchronní operace, například požadavek na vzdálené spuštění aplikace.
    212 ověření přijato. Normálně to uvidíte pouze v reakci na prvek SyncHdr (používaný pro autentizaci ve standardu OMA-DM). Můžete to vidět, pokud se podíváte na protokoly OMA DM, ale CSP to obvykle negenerují.
    214 operace zrušena. Příkaz SyncML byl úspěšně dokončen, ale v rámci relace nebudou zpracovány žádné další příkazy.
    215 nebyl popraven. Příkaz nebyl proveden v důsledku interakce uživatele, aby se příkaz zrušil.
    216 Atomic vrátit zpět OK. Příkaz byl uvnitř prvku Atomic a Atomic selhal. Tento příkaz byl úspěšně vrácen zpět.
    400 špatná žádost. Požadovaný příkaz nemohl být proveden z důvodu nesprávné syntaxe. CSP obvykle tuto chybu negenerují, můžete ji však vidět, pokud je váš SyncML poškozen.
    401 neplatná pověření. Požadovaný příkaz selhal, protože žadatel musí poskytnout správné ověření. CSP obvykle tuto chybu negenerují.
    403 zakázáno. Požadovaný příkaz selhal, ale příjemce požadovanému příkazu rozuměl.
    404 nebyl nalezen. Požadovaný cíl nebyl nalezen. Tento kód bude vygenerován, pokud dotazujete uzel, který neexistuje.
    405 příkaz není povolen. Tento kód odpovědi bude vygenerován, pokud se pokusíte zapsat do uzlu pouze pro čtení.
    406 volitelná funkce není podporována. Tento kód odpovědi bude vygenerován, pokud se pokusíte získat přístup k vlastnosti, kterou CSP nepodporuje.
    415 Nepodporovaný typ nebo formát. Tento kód odpovědi může být výsledkem analýzy XML nebo chyb formátování.
    418 už existuje. Tento kód odpovědi nastane, pokud se pokusíte přidat uzel, který již existuje.
    425 Povolení Zamítnuto. Požadovaný příkaz selhal, protože odesílatel nemá u příjemce odpovídající oprávnění k řízení přístupu (ACL). Chyby“ Přístup odepřen “ se obvykle překládají do tohoto kódu odpovědi.
    500 příkaz selhal. Obecné selhání. Příjemce narazil na neočekávanou podmínku, která mu zabránila splnit žádost. Tento kód odpovědi nastane, když SyncML DPU nemůže mapovat původní kód chyby.
    507 Atomic neuspěl. Jedna z operací v bloku Atomic selhala.
    516 Atomic vrátit se nepodařilo. Operace Atomic selhala a příkaz nebyl úspěšně vrácen zpět.

    Napsat komentář

    Vaše e-mailová adresa nebude zveřejněna.