obsługa protokołu OMA DM

Written by on in Articles
  • artykuł
  • 12/16/2021
  • 12 protokół do czytania
    • D
    • M
    • a
    • v
    • d
    • +11
czy ta strona jest pomocna?

Dziękuję.

klient OMA DM komunikuje się z serwerem przez HTTPS i używa DM Sync (OMA DM v1.2) jako ładunku wiadomości. Ten temat opisuje funkcjonalność OMA DM, którą klient DM obsługuje w ogóle. Pełny opis protokołu OMA DM v1. 2 można znaleźć na stronie internetowej OMA.

standardy OMA DM

poniższa tabela przedstawia standardy oma DM używane przez System Windows.

obszar ogólny obsługiwany standard oma DM
transport danych i sesja
  • inicjowana przez Klienta zdalna sesja HTTPS DM przez SSL.
  • Zdalna sesja HTTPS DM przez SSL.
  • zdalne powiadomienie o inicjacji serwera DM za pomocą usługi WAP Push over Short Message Service (SMS). Nie jest używany przez enterprise management.
  • zdalny bootstrap za pomocą WAP Push over SMS. Nie jest używany przez enterprise management.
    		•
    Bootstrap XML oma Client Provisioning XML.
    polecenia protokołu DM poniższa lista pokazuje polecenia używane przez urządzenie. Więcej informacji na temat elementów poleceń oma DM można znaleźć w „witrynie OMA” dostępnej na stronie OMA.

  • Add (Implicit add supported)
  • Alert (DM alert): ogólny alert (1226) jest używany przez enterprise management client, gdy użytkownik uruchamia akcję odblokowania MDM z urządzenia lub gdy CSP zakończy niektóre akcje asynchroniczne. Device alert (1224) służy do powiadamiania serwera o zdarzeniu wywołanym przez urządzenie.
  • Atomic: wykonywanie polecenia Add, a następnie Replace na tym samym węźle w elemencie atomic nie jest obsługiwane. Zagnieżdżone komendy Atomic I Get nie są dozwolone i wygenerują kod błędu 500.
  • Usuń:
  • Exec: wywołuje plik wykonywalny na urządzeniu klienckim
  • Get: pobiera dane z urządzenia klienckiego; dla wewnętrznych węzłów, podrzędne nazwy węzłów w elemencie danych są zwracane w formacie zakodowanym URI
  • Replace: nadpisuje dane na urządzeniu klienckim
  • Result: zwraca wyniki danych na urządzeniu klienckim
  • polecenie Get do serwera DM
  • Sekwencja: określa kolejność przetwarzania grupy poleceń
  • status: Wskazuje status zakończenia (powodzenia lub niepowodzenia) operacji
    jeśli element XML, który nie jest poprawnym poleceniem oma DM, Znajduje się pod jednym z następujących elementów, dla tego elementu zwracany jest kod statusu 400:
  • SyncBody
  • Atomic
  • Sequence
    jeśli w poleceniu DM Nie podano CmdID, klient zwraca puste pole w elemencie status i kod statusu 400.
    jeśli pierwiastki atomowe są zagnieżdżone, zwracane są następujące kody stanu:
  • zagnieżdżone polecenie atomowe zwraca 500.
  • nadrzędne polecenie atomowe zwraca 507.
    aby uzyskać więcej informacji o komendzie atomowej, zobacz wspólne elementy protokołu oma DM.
    wykonywanie polecenia Add, a następnie Replace na tym samym węźle w elemencie atomowym nie jest obsługiwane.
    LocURI nie może zaczynać się od /.
    meta XML tag w SyncHdr jest ignorowany przez urządzenie.
    		•
    obiekty standardowe OMA DM DevInfo

  • DevDetail
  • obiekty konta oma DM DMS (OMA DM Wersja 1.2)
    		•
    bezpieczeństwo
  • Uwierzytelnij powiadomienie SMS o inicjacji serwera DM (nie używane przez enterprise management)
  • warstwa aplikacji uwierzytelnianie podstawowe i klient MD5
  • Uwierzytelnianie serwera z poświadczeniem MD5 na poziomie aplikacji
  • integralność danych i uwierzytelnianie za pomocą HMAC na poziomie aplikacji
  • oparte na certyfikatach uwierzytelnianie klienta/serwera, szyfrowanie i integralność danych Sprawdź
    		•
    węzły w drzewie oma DM obowiązują następujące reguły dla nazwy węzła:

  • „.”może być częścią nazwy węzła.
  • nazwa węzła nie może być pusta.
  • nazwa węzła nie może być tylko znakiem gwiazdki ( * ).
    		•
    pliki Aprowizacji Aprowizacja XML musi być dobrze uformowana i postępować zgodnie z definicją w protokole reprezentacji SyncML](https://go.microsoft.com/fwlink/p/?LinkId=526905).
    jeśli element XML, który nie jest poprawnym poleceniem oma DM, jest pod SyncBody, dla tego elementu zwracany jest kod stanu 400.

    Uwaga
    aby reprezentować ciąg znaków Unicode jako URI, najpierw Zakoduj łańcuch jako UTF-8. Następnie Zakoduj każdy z UTF-8 bajtów za pomocą kodowania URI.
    obsługa WBXML Windows obsługuje wysyłanie i odbieranie SyncML zarówno w formacie XML, jak i zakodowanym formacie WBXML. Jest to konfigurowalne przy użyciu węzła DEFAULTENCODING w charakterystyce aplikacji w7 podczas rejestracji. Więcej informacji na temat kodowania WBXML znajduje się w sekcji 8 specyfikacji protokołu reprezentacji SyncML.
    obsługa dużych obiektów w systemie Windows 10 w wersji 1511 dodano obsługę klienta w celu przesyłania dużych obiektów na serwer.

    wspólne elementy protokołu oma DM

    wspólne elementy są używane przez inne typy elementów OMA DM. Poniższa tabela zawiera wspólne elementy OMA DM używane do konfiguracji urządzeń. Więcej informacji na temat wspólnych elementów OMA DM można znaleźć w sekcji „SyncML Representation Protocol Device Management Usage” (OMA-SyncML-DMRepPro-V1_1_2-20030613-a) dostępnej na stronie internetowej OMA.

    Element opis
    Chal określa wyzwanie uwierzytelniania. Serwer lub klient może wysłać wyzwanie do drugiej osoby, jeśli w oryginalnej wiadomości żądania nie podano danych uwierzytelniających lub niewystarczających danych uwierzytelniających.
    Cmd Określa nazwę polecenia OMA DM, do którego odwołuje się element Status.
    CmdID określa unikalny identyfikator dla polecenia OMA DM.
    CmdRef określa ID polecenia, dla którego zwracana jest informacja o stanie lub wynikach. Ten element przyjmuje wartość elementu CmdID odpowiadającego mu komunikatu żądania.
    Cred określa poświadczenie uwierzytelniania twórcy wiadomości.
    Ostatnia wskazuje, że bieżąca wiadomość jest ostatnią wiadomością w pakiecie.
    LocName określa wyświetlaną nazwę w elementach docelowym i źródłowym, używaną do wysyłania identyfikatora użytkownika do uwierzytelniania MD5.
    LocURI Określa adres docelowej lub źródłowej lokalizacji. Jeśli adres zawiera znak nie alfanumeryczny, musi być poprawnie poprzedzony znakami ucieczki zgodnie ze standardem kodowania URL.
    msgstr określa unikalny identyfikator dla wiadomości sesji OMA DM.
    MsgRef określa ID odpowiedniej wiadomości żądania. Ten element przyjmuje wartość elementu msgstr wiadomości żądania.
    RespURI określa URI, którego odbiorca musi użyć podczas wysyłania odpowiedzi na tę wiadomość.
    SessionID Określa identyfikator sesji oma DM skojarzonej z zawartą wiadomością.

    Uwaga
    jeśli serwer nie powiadomi urządzenia, że obsługuje nową wersję (poprzez węzeł SyncApplicationVersion W CSP DMClient), klient zwróci identyfikator SessionID w liczbie całkowitej w formacie dziesiętnym. Jeśli serwer obsługuje DM session sync w wersji 2.0, która jest używana w systemie Windows 10, Klient urządzenia zwraca 2 bajty.
    źródło Określa adres źródłowy wiadomości.
    SourceRef określa źródło odpowiedniego komunikatu żądania. Ten element przyjmuje wartość elementu źródłowego komunikatu żądania i jest zwracany w elemencie Status lub Results.
    Target Określa adres węzła w drzewie DM, który jest celem polecenia OMA DM.
    TargetRef Określa adres docelowy w odpowiednim komunikacie żądania. Ten element przyjmuje wartość elementu docelowego komunikatu żądania i jest zwracany w elemencie Status lub Results.
    VerDTD Określa identyfikator wersji głównej i podrzędnej specyfikacji protokołu reprezentacji oma DM używanego do reprezentowania wiadomości.
    VerProto Określa identyfikator wersji głównej i podrzędnej specyfikacji protokołu oma DM używanego w wiadomości.

    sesja zarządzania urządzeniami

    sesja zarządzania urządzeniami (DM) składa się z serii poleceń wymienianych między serwerem DM a urządzeniem klienckim. Serwer wysyła polecenia wskazujące operacje, które muszą zostać wykonane na drzewie zarządzania urządzenia klienta. Klient odpowiada wysyłając polecenia, które zawierają wyniki i wszelkie wymagane informacje o statusie.

    krótka sesja DM może być podsumowana następująco:

    serwer wysyła polecenie Get do urządzenia klienta, aby pobrać zawartość jednego z węzłów drzewa zarządzania. Urządzenie wykonuje operację i odpowiada poleceniem Result, które zawiera żądaną zawartość.

    sesję DM można podzielić na dwie fazy:

    1. Faza konfiguracji: w odpowiedzi na zdarzenie wyzwalające urządzenie klienckie wysyła wiadomość inicjującą do serwera DM. Wymiana urządzenia i serwera wymagała uwierzytelnienia i informacji o urządzeniu. Ta faza jest reprezentowana przez kroki 1, 2 i 3 w poniższej tabeli.
    2. Faza zarządzania: serwer DM jest pod kontrolą. Wysyła polecenia zarządzania do urządzenia, a urządzenie reaguje. Faza druga kończy się, gdy serwer DM przestaje wysyłać polecenia i kończy sesję. Ta faza jest reprezentowana przez kroki 3, 4 i 5 w poniższej tabeli.

    poniższe informacje pokazują kolejność zdarzeń podczas typowej sesji DM.

    1. klient DM jest wywoływany w celu wywołania z powrotem na serwer zarządzania
      Scenariusz Enterprise-Harmonogram zadań urządzenia wywołuje klienta DM.

      serwer MO wysyła komunikat wyzwalający serwer, aby wywołać klienta DM.

      komunikat wyzwalający zawiera identyfikator serwera i informuje urządzenie klienckie o rozpoczęciu sesji z serwerem. Urządzenie klienckie uwierzytelnia komunikat wyzwalający i weryfikuje, czy serwer jest upoważniony do komunikacji z nim.
      Scenariusz Enterprise-w zaplanowanym czasie klient DM jest okresowo wywoływany, aby oddzwonić do serwera enterprise management server przez HTTPS.

    2. urządzenie wysyła wiadomość za pośrednictwem połączenia IP, aby zainicjować sesję.

      ten komunikat zawiera informacje o urządzeniu i poświadczenia. Klient i serwer dokonują wzajemnego uwierzytelniania za pośrednictwem kanału SSL lub na poziomie aplikacji DM.

    3. serwer DM odpowiada poprzez połączenie IP (HTTPS). Serwer wysyła wstępne polecenia zarządzania urządzeniami, jeśli takie istnieją.

    4. urządzenie reaguje na polecenia zarządzania serwerem. Ten Komunikat Zawiera wyniki wykonywania określonych operacji zarządzania urządzeniami.

    5. serwer DM kończy sesję lub wysyła kolejne polecenie. Sesja DM kończy się, lub Krok 4 jest powtarzany.

    numery kroków nie reprezentują numerów IDENTYFIKACYJNYCH wiadomości (msgstr). Wszystkie wiadomości z serwera muszą mieć unikalny MsgID w ramach sesji, zaczynając od 1 dla pierwszej wiadomości i zwiększając o 1 dla każdej dodatkowej wiadomości. Aby uzyskać więcej informacji na temat MsgID i protokołu oma SyncML, zobacz oma Device Management Representation Protocol (DM_RepPro-V1_2-20070209-a).

    podczas wzajemnego uwierzytelniania na poziomie aplikacji OMA DM, jeśli kod odpowiedzi urządzenia na element Cred w żądaniu serwera wynosi 212, dalsze uwierzytelnianie nie jest potrzebne do końca sesji DM. W przypadku uwierzytelniania MD5 można zwrócić element Chal. Następnie następny nonce w Chal musi być użyty do przetworzenia MD5, gdy następna sesja DM jest uruchamiana.

    jeśli żądanie zawiera poświadczenia, a kod odpowiedzi na żądanie wynosi 200, ten sam poświadczenie musi zostać przesłane w następnym żądaniu. Jeśli element Chal jest dołączony i wymagane jest uwierzytelnienie MD5, nowy skrót jest tworzony przez użycie następnego nonce przez element Chal do następnego żądania.

    aby uzyskać więcej informacji na temat uwierzytelniania klienta podstawowego lub MD5, uwierzytelniania serwera MD5, skrótu MD5 i nonce MD5, zobacz specyfikację zabezpieczeń zarządzania urządzeniami OMA (OMA-TS-DM_Security-V1_2_1-20080617-a), obsługę kodu odpowiedzi uwierzytelniania i próbki krok po kroku w specyfikacji protokołu zarządzania urządzeniami oma (OMA-TS-DM_Protocol-V1_2_1-20080617-a), dostępne na stronie oma.

    user targeted vs. Konfiguracja ukierunkowana na urządzenie

    w przypadku dostawców usług CSP i zasad obsługujących konfigurację użytkownika serwer MDM może wysyłać wartości ustawień ukierunkowanych na użytkownika do urządzenia, do którego Użytkownik Zarejestrowany w MDM jest aktywnie zalogowany. Urządzenie powiadamia serwer o statusie logowania poprzez device alert ( 1224)z Alert type = w DM pkg # 1.

    część danych tego alertu może być jednym z następujących ciągów:

    • Użytkownik – Użytkownik, który zarejestrował urządzenie jest aktywnie zalogowany. Serwer MDM może wysyłać konfigurację specyficzną dla użytkownika dla CSP/polityk, które obsługują konfigurację dla każdego użytkownika
    • inni-inny login użytkownika, ale ten użytkownik nie ma konta MDM. Serwer może zastosować tylko konfigurację dla całego urządzenia, na przykład konfiguracja dotyczy wszystkich użytkowników w urządzeniu.
    • brak-brak aktywnego logowania użytkownika. Serwer może zastosować tylko konfigurację dla całego urządzenia, a dostępna konfiguracja jest ograniczona do środowiska urządzenia (brak aktywnego logowania użytkownika).

    poniżej przykład alertu:

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

    serwer powiadamia urządzenie, czy jest to konfiguracja ukierunkowana na użytkownika, czy na urządzenie, za pomocą prefiksu do LocURL węzła zarządzania ./ user dla konfiguracji ukierunkowanej na użytkownika, lub ./ device for device targeted configuration. Domyślnie, jeśli nie ma prefiksu z ./ urządzenie lub ./ user, jest to konfiguracja ukierunkowana na urządzenie.

    następujący LocURL pokazuje konfigurację węzła CSP na użytkownika:./user/vendor/MSFT/EnterpriseModernAppManagement/AppInstallation/<PackageFamilyName>/StoreInstall

    poniższy LocURL pokazuje konfigurację węzła CSP na urządzenie: ./device/vendor/MSFT/RemoteWipe / DoWipe

    KODY STANU odpowiedzi SyncML

    podczas korzystania z SyncML w OMA DM zwracane są standardowe kody stanu odpowiedzi. Poniższa tabela zawiera listę popularnych kodów statusu odpowiedzi SyncML, które prawdopodobnie zobaczysz. Więcej informacji na temat kodów stanu odpowiedzi SyncML można znaleźć w sekcji 10 specyfikacji protokołu reprezentacji SyncML.

    kod statusu opis
    200 polecenie SyncML zakończyło się pomyślnie.
    202 akceptowane do przetwarzania. Zwykle jest to operacja asynchroniczna, taka jak żądanie uruchomienia zdalnego wykonania aplikacji.
    212 uwierzytelnienie przyjęte. Zwykle jest to widoczne tylko w odpowiedzi na element SyncHdr (używany do uwierzytelniania w standardzie OMA-DM). Możesz to zobaczyć, jeśli spojrzysz na dzienniki OMA DM, ale CSP zazwyczaj tego nie generują.
    214 operacja odwołana. Polecenie SyncML zakończyło się pomyślnie, ale nie będzie przetwarzane więcej poleceń w ramach sesji.
    215 nie stracony. Polecenie nie zostało wykonane w wyniku interakcji użytkownika w celu anulowania polecenia.
    216 Atomic cofnąć się OK. Polecenie znajdowało się wewnątrz elementu Atomic i Atomic nie powiodło się. Komenda ta została wycofana z powodzeniem.
    400 zła Prośba. Żądane polecenie nie mogło zostać wykonane z powodu nieprawidłowej składni. CSP zazwyczaj nie generują tego błędu, jednak możesz go zobaczyć, jeśli SyncML jest nieprawidłowo sformatowany.
    401 nieprawidłowe dane uwierzytelniające. Żądane polecenie nie powiodło się, ponieważ żądający musi zapewnić odpowiednie uwierzytelnienie. Dostawcy usług CSP zazwyczaj nie generują tego błędu.
    403 zabronione. Żądane polecenie nie powiodło się, ale odbiorca zrozumiał żądane polecenie.
    404 nie znaleziono. Żądany cel nie został znaleziony. Ten kod zostanie wygenerowany, jeśli zapytasz węzeł, który nie istnieje.
    405 rozkaz nie jest dozwolony. Ten kod odpowiedzi zostanie wygenerowany, jeśli spróbujesz napisać do węzła tylko do odczytu.
    406 Opcjonalna funkcja nie jest obsługiwana. Ten kod odpowiedzi zostanie wygenerowany, jeśli spróbujesz uzyskać dostęp do właściwości, której CSP nie obsługuje.
    415 nieobsługiwany typ lub format. Ten kod odpowiedzi może wynikać z błędów przetwarzania lub formatowania XML.
    418 już istnieje. Ten kod odpowiedzi występuje, gdy próbujesz dodać węzeł, który już istnieje.
    425 Odmawiam Zgody. Żądane polecenie nie powiodło się, ponieważ nadawca nie ma odpowiednich uprawnień kontroli dostępu (ACL) dla odbiorcy. Błędy „Odmowa dostępu” zwykle są tłumaczone na ten kod odpowiedzi.
    500 polecenie nie powiodło się. Ogólna porażka. Odbiorca napotkał nieoczekiwany warunek, który uniemożliwił mu spełnienie żądania. Ten kod odpowiedzi pojawi się, gdy DPU SyncML nie będzie w stanie zmapować kodu błędu.
    507 Atomic nie udało się. Jedna z operacji w bloku Atomic nie powiodła się.
    516 Atomic powrót nieudany. Operacja Atomic nie powiodła się i polecenie nie zostało pomyślnie wycofane.

    Dodaj komentarz

    Twój adres e-mail nie zostanie opublikowany.