OMA DM suporte de protocolo

Written by on in Articles
  • Artigo
  • 12/16/2021
  • 12 minutos de leitura
    • D
    • M
    • um
    • v
    • d
    • +11
É esta página útil?Obrigado .

o cliente OMA DM se comunica com o servidor por HTTPS e usa Dm Sync (OMA DM V1.2) como carga útil da mensagem. Este tópico descreve a funcionalidade OMA DM que o cliente DM suporta em geral. A descrição completa do protocolo OMA DM v1.2 pode ser encontrada no site da OMA.

padrões OMA DM

a tabela a seguir mostra os padrões OMA DM que o Windows usa.

área Geral OMA DM padrão que é suportado
o transporte de Dados e de sessão
  • iniciada pelo Cliente remoto HTTPS DM sessão através de SSL.
  • sessão DM HTTPS Remota por SSL.
  • notificação de iniciação remota do servidor DM usando WAP Push over Short Message Service (SMS). Não usado pelo enterprise management.
  • bootstrap remoto usando WAP Push over SMS. Não usado pelo enterprise management.
    		•
    Bootstrap XML oma Client Provisioning XML.
    comandos do protocolo DM a lista a seguir mostra os comandos usados pelo dispositivo. Para obter mais informações sobre os elementos de comando OMA DM, consulte “site oma” disponível no site oma.

  • Add (implícito add supported)
  • Alert (DM alert): Alerta Genérico (1226) é usado pelo enterprise management client quando o usuário aciona uma ação de unenrollment MDM do dispositivo ou quando um CSP conclui algumas ações assíncronas. O alerta de dispositivo (1224) é usado para notificar o servidor de algum evento acionado por dispositivo.
  • Atomic: executar um comando Add seguido de Replace no mesmo nó dentro de um elemento atômico não é suportado. Os comandos Atomic e Get aninhados não são permitidos e gerarão o código de erro 500.
  • apagar: Remove um nó do DM árvore, e toda a subárvore abaixo do nó, se existir um
  • Exec: Invoca um executável no dispositivo do cliente
  • Get: Recupera dados a partir do dispositivo de cliente; para o interior de nós, o filho de nomes de nó do elemento de Dados são retornados na URI-formato codificado
  • Substituir: Substitui os dados no dispositivo do cliente
  • Resultado: Retorna os dados de resultados de um comando Get para o DM do servidor
  • Sequência: Especifica a ordem na qual um grupo de comandos deve ser processado
  • Status: Indica o status de conclusão (sucesso ou fracasso) de uma operação
    Se um elemento XML não é válido OMA DM comando está sob uma das seguintes elementos, o código de status 400 é retornado para o elemento:
  • SyncBody
  • Atômica
  • Sequência
    Se não CmdID é fornecido no DM comando, o cliente retorna em branco no elemento de status e o código de status 400.
    se os elementos atômicos estiverem aninhados, os seguintes códigos de status serão retornados:
  • o comando atômico aninhado retorna 500.
  • o comando atômico pai retorna 507.
    para obter mais informações sobre o comando atômico, consulte o protocolo OMA DM common elements.
    executar um comando Add seguido de Replace no mesmo nó dentro de um elemento atômico não é suportado.
    LocURI não pode começar com /.
    a Tag Meta XML no SyncHdr é ignorada pelo dispositivo.
    		•
    OMA DM objetos padrão DevInfo

  • DevDetail
  • OMA DM DMS da conta de objetos (OMA DM versão 1.2)
    		•
    Segurança
  • Autenticar DM servidor de início de notificação de mensagem SMS (não usada pelo enterprise management)
  • camada de Aplicativo Básico e MD5 autenticação de cliente
  • Autenticar o servidor com o MD5 credencial em nível de aplicação
  • autenticação e integridade de Dados com HMAC com o nível de aplicação
  • SSL certificado de nível baseado em cliente/servidor de autenticação, criptografia de dados e verificação de integridade
    		•
    Nós Na OMA DM árvore, as seguintes regras se aplicam para o nome do nó:

  • “.”pode fazer parte do nome do nó.
  • o nome do nó não pode estar vazio.
  • o nome do nó não pode ser apenas o caractere asterisco ( * ).
    		•
    Arquivos de provisionamento o provisionamento XML deve estar bem formado e seguir A definição no SyncML Representation Protocol](https://go.microsoft.com/fwlink/p/?LinkId=526905).
    se um elemento XML que não é um comando OMA DM válido estiver em SyncBody, o código de status 400 será retornado para esse elemento.

    Nota
    para representar uma string Unicode como URI, primeiro codifique a string como UTF-8. Em seguida, codifique cada um dos bytes UTF-8 usando a codificação URI.
    suporte WBXML O Windows suporta o envio e recebimento de SyncML no formato XML e no formato WBXML codificado. Isso é configurável usando o nó DEFAULTENCODING sob a característica do aplicativo w7 durante o registro. Para obter mais informações sobre a codificação WBXML, consulte a seção 8 da especificação SyncML Representation Protocol.
    manipulação de objetos grandes no Windows 10, Versão 1511, suporte ao cliente para upload de objetos grandes para o servidor foi adicionado.

    elementos comuns do protocolo OMA DM

    elementos comuns são usados por outros tipos de elementos OMA DM. A tabela a seguir lista os elementos comuns do OMA DM usados para configurar os dispositivos. Para obter mais informações sobre OMA DM common elements, consulte “SyncML Representation Protocol Device Management Usage” (oma-SyncML-DMRepPro-V1_1_2-20030613-a) disponível no site da OMA.

    Elemento Descrição
    Chal Especifica um desafio de autenticação. O servidor ou cliente pode enviar um desafio para o outro se nenhuma credencial ou credenciais inadequadas foram dadas na mensagem de solicitação original.
    Cmd especifica o nome de um comando OMA DM referenciado em um elemento de Status.
    CmdID especifica o identificador exclusivo para um comando OMA DM.
    CmdRef especifica o ID do comando para o qual as informações de status ou resultados estão sendo retornadas. Este elemento leva o valor do elemento CmdID da mensagem de solicitação correspondente.
    Cred Especifica a credencial de autenticação para o originador da mensagem.
    Final Indica que a mensagem atual é a última mensagem no pacote.
    LocName especifica o nome de exibição nos elementos de destino e de origem, usados para enviar um ID de usuário para Autenticação MD5.
    LocURI especifica o endereço do destino ou local de origem. Se o endereço contiver um caractere não alfanumérico, ele deve ser escapado corretamente de acordo com o padrão de codificação de URL.
    MsgID especifica um identificador exclusivo para uma mensagem de sessão OMA DM.
    MsgRef especifica o ID da mensagem de solicitação correspondente. Este elemento leva o valor do elemento msgid da mensagem de solicitação.
    RespURI Especifica o URI que o destinatário deve utilizar quando enviar uma resposta a esta mensagem.
    SessionID especifica o identificador da sessão OMA DM associada à mensagem que contém.

    Nota
    se o servidor não notificar o dispositivo que ele suporta uma nova versão (por meio do nó SyncApplicationVersion no CSP DMClient), o cliente retornará a SessionID em integer no formato decimal. Se o servidor suportar DM session sync versão 2.0, que é usado no Windows 10, O Cliente do dispositivo retornará 2 bytes.
    fonte especifica o endereço de origem da mensagem.
    SourceRef especifica a origem da mensagem de solicitação correspondente. Esse elemento recebe o valor do elemento de origem da mensagem de solicitação e é retornado no elemento Status ou resultados.
    Target especifica o endereço do nó, na árvore DM, Que é o destino do comando OMA DM.
    TargetRef especifica o endereço de destino na mensagem de solicitação correspondente. Esse elemento recebe o valor do elemento de destino da mensagem de solicitação e é retornado no elemento Status ou resultados.
    VerDTD especifica o identificador de versão maior e menor da especificação do protocolo de representação OMA DM usada para representar a mensagem.
    VerProto especifica o identificador de versão maior e menor da especificação do protocolo OMA DM usada com a mensagem.

    sessão de gerenciamento de dispositivos

    uma sessão de gerenciamento de dispositivos (DM) consiste em uma série de comandos trocados entre um servidor DM e um dispositivo cliente. O servidor envia comandos indicando operações que devem ser executadas na árvore de gerenciamento do dispositivo cliente. O cliente responde enviando comandos que contêm os resultados e qualquer informação de status solicitada.

    Um curto DM sessão pode ser resumido como a seguir:

    Um servidor envia um comando Get para um dispositivo cliente para obter o conteúdo de um dos nós da árvore de gerenciamento. O dispositivo executa a operação e responde com um comando de resultado que contém o conteúdo solicitado.

    uma sessão de DM pode ser dividida em duas fases:

    1. fase de configuração: em resposta a um evento de disparo, um dispositivo cliente envia uma mensagem inicial para um servidor DM. A troca de dispositivo e servidor precisava de autenticação e informações do dispositivo. Esta fase é representada pelas etapas 1, 2 e 3 na tabela a seguir.
    2. fase de Gerenciamento: o servidor DM está no controle. Ele envia comandos de gerenciamento para o dispositivo e o dispositivo responde. A fase dois termina quando o servidor DM para de enviar comandos e encerra a sessão. Esta fase é representada pelas etapas 3, 4 e 5 na tabela a seguir.

    as seguintes informações mostram a sequência de eventos durante uma sessão típica de DM.

    1. o cliente DM é chamado para chamar de volta ao cenário corporativo do servidor de gerenciamento
      – o cronograma de tarefas do dispositivo invoca o cliente DM.

      o servidor MO envia uma mensagem de disparo do servidor para invocar o cliente DM.

      a mensagem trigger inclui o ID do servidor e diz ao dispositivo cliente para iniciar uma sessão com o servidor. O dispositivo cliente autentica a mensagem trigger e verifica se o servidor está autorizado a se comunicar com ele.
      cenário corporativo – no horário agendado, o cliente DM é chamado periodicamente para chamar de volta ao servidor de gerenciamento corporativo por HTTPS.

    2. O dispositivo envia uma mensagem, através de uma conexão IP para iniciar a sessão.

      esta mensagem inclui informações e credenciais do dispositivo. O cliente e o servidor fazem autenticação mútua em um canal SSL ou no nível do aplicativo DM.

    3. o servidor DM responde, através de uma conexão IP (HTTPS). O servidor envia comandos iniciais de gerenciamento de dispositivos, se houver.

    4. o dispositivo responde aos comandos de gerenciamento do servidor. Esta mensagem inclui os resultados da execução das operações de gerenciamento de dispositivos especificadas.

    5. o servidor DM encerra a sessão ou envia outro comando. A sessão DM termina ou a Etapa 4 é repetida.

    os números de etapa não representam números de identificação de mensagem (MsgID). Todas as mensagens do servidor devem ter um MsgID exclusivo dentro da sessão, começando em 1 para a primeira mensagem e aumentando em um incremento de 1 para cada mensagem extra. Para obter mais informações sobre o protocolo msgid e OMA SyncML, consulte o protocolo de representação de gerenciamento de dispositivos oma (DM_RepPro-V1_2-20070209-a).

    durante a autenticação mútua de nível de aplicativo OMA DM, se o código de resposta do dispositivo ao elemento Cred na solicitação do servidor for 212, nenhuma autenticação adicional é necessária para o restante da sessão DM. No caso da autenticação MD5, o elemento Chal pode ser retornado. Em seguida, o próximo nonce no Chal deve ser usado para o resumo MD5 quando a próxima sessão DM for iniciada.

    se uma solicitação incluir credenciais e o código de resposta à solicitação for 200, a mesma credencial deve ser enviada dentro da próxima solicitação. Se o elemento Chal for incluído e a autenticação MD5 for necessária, um novo resumo será criado usando o próximo nonce por meio do elemento Chal para a próxima solicitação.

    Para obter mais informações sobre o Basic ou o MD5 de autenticação de cliente, MD5 servidor de autenticação MD5 hash MD5 e o nonce, consulte a OMA Dispositivo de Segurança para Gerenciamento de especificação (OMA-TS-DM_Security-V1_2_1-20080617-A), resposta de autenticação de código de manipulação e passo-a-passo de amostras de OMA Dispositivo de Protocolo de Gestão de especificação (OMA-TS-DM_Protocol-V1_2_1-20080617-A), disponível a partir do OMA site.

    alvo do Usuário vs. Configuração direcionada do dispositivo

    para CSPs e políticas que suportam por configuração do usuário, o servidor MDM pode enviar valores de configuração direcionados ao Usuário para o dispositivo no qual um usuário inscrito no MDM está conectado ativamente. O dispositivo notifica o servidor do status de login por meio de um alerta de dispositivo (1224) com tipo de alerta = Em DM PKG#1.

    a parte de dados deste alerta pode ser uma das seguintes strings:

    • usuário – o usuário que inscreveu o dispositivo está conectado ativamente. O servidor MDM pode enviar configuração específica do Usuário para CSPs / políticas que suportam por configuração do Usuário
    • outros – outro login do usuário, mas esse usuário não tem uma conta MDM. O servidor só pode aplicar a configuração em todo o dispositivo, por exemplo, a configuração se aplica a todos os usuários do dispositivo.
    • nenhum-nenhum login ativo do Usuário. O servidor só pode aplicar a configuração em todo o dispositivo e a configuração disponível é restrita ao ambiente do dispositivo (sem login ativo do Usuário).

    abaixo está um exemplo de alerta:

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

    o servidor notifica o dispositivo se é um usuário direcionado ou dispositivo direcionado configuração por um prefixo para LocURL do nó de gerenciamento, com ./ Usuário para configuração direcionada ao usuário, ou ./ dispositivo para configuração direcionada ao dispositivo. Por padrão, se nenhum prefixo com ./ dispositivo ou ./ Usuário, é configuração direcionada ao dispositivo.

    o seguinte LocURL mostra uma configuração de nó CSP por usuário:./user/vendor/MSFT/EnterpriseModernAppManagement/AppInstallation/<PackageFamilyName>/StoreInstall

    O seguinte LocURL mostra uma por dispositivo CSP configuração de nó de: ./device/vendor/MSFT/RemoteWipe / DoWipe

    códigos de status de resposta SyncML

    ao usar SyncML no OMA DM, existem códigos de status de resposta padrão que são retornados. A tabela a seguir lista os códigos de status de resposta SyncML comuns que você provavelmente verá. Para obter mais informações sobre os códigos de status de resposta SyncML, consulte a Seção 10 da especificação SyncML Representation Protocol.

    código de Status Descrição
    200 O SyncML comando foi concluído com êxito.
    202 Aceito para processamento. Esta é geralmente uma operação assíncrona, como uma solicitação para executar uma Execução Remota de um aplicativo.
    212 autenticação aceita. Normalmente, você só verá isso em resposta ao elemento SyncHdr (usado para Autenticação no padrão OMA-DM). Você pode ver isso se observar os logs do OMA DM, mas os CSPs normalmente não geram isso.
    214 Operação cancelada. O comando SyncML foi concluído com êxito, mas não mais comandos serão processados dentro da sessão.
    215 Não executado. Um comando não foi executado como resultado da interação do Usuário para cancelar o comando.
    216 Atomic reverter OK. Um comando estava dentro de um elemento Atomic e Atomic falhou. Este comando foi revertido com sucesso.
    400 mau pedido. O comando solicitado não pôde ser executado por causa da sintaxe malformada. Os CSPs geralmente não geram esse erro, no entanto, você pode ver se o seu SyncML está malformado.
    401 credenciais Inválidas. O comando solicitado falhou porque o solicitante deve fornecer autenticação adequada. Os CSPs geralmente não geram esse erro.
    403 proibido. O comando solicitado falhou, mas o destinatário entendeu o comando solicitado.
    404 Não encontrado. O alvo solicitado não foi encontrado. Este código será gerado se você consultar um nó que não existe.
    405 Comando não permitido. Esse código de resposta será gerado se você tentar gravar em um nó somente leitura.
    406 recurso opcional não suportado. Este código de resposta será gerado se você tentar acessar uma propriedade que o CSP não suporta.
    415 tipo ou formato não suportado. Este código de resposta pode resultar de erros de análise ou formatação XML.
    418 Já existe. Esse código de resposta ocorre se você tentar adicionar um nó que já existe.
    425 Permissão Negada. O comando solicitado falhou porque o remetente não tem permissões adequadas de controle de acesso (ACL) no destinatário. Os erros de “acesso negado” geralmente são traduzidos para este código de resposta.
    500 o comando falhou. Falha genérica. O destinatário encontrou uma condição inesperada que o impediu de cumprir a solicitação. Este código de resposta ocorrerá quando o SyncML DPU não puder mapear o código de erro de origem.
    507 Atomic falhou. Uma das operações em um bloco Atomic falhou.
    516 Atomic reverter falhou. Uma operação Atomic falhou e o comando não foi revertido com sucesso.

    Deixe uma resposta

    O seu endereço de email não será publicado.