Share via

Suporte ao protocolo OMA DM

O cliente DM OMA se comunica com o servidor por https e usa a DM sync (DM do OMA v1.2) como o conteúdo da mensagem. Este artigo descreve a funcionalidade de DM OMA que o cliente DM dá suporte em geral. A descrição completa do protocolo OMA DM v1.2 pode ser encontrada no site do OMA.

Padrões de DM OMA

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

Área geral Padrão de DM OMA com suporte
Transporte e sessão de dados
  • Sessão de DM HTTPS remota iniciada pelo cliente no TLS/SSL.
  • Sessão remota de DM HTTPS no TLS/SSL.
  • Notificação de iniciação do servidor DM remoto usando o SMS (Serviço de Mensagem Curta) do WAP Push over. Não usado pelo gerenciamento empresarial.
  • Inicialização remota usando o WAP Push over SMS. Não usado pelo gerenciamento empresarial.
    		•
    Bootstrap XML XML de provisionamento de cliente OMA.
    Comandos de 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 da OMA.
  • Adicionar (Suporte para Adicionar Implícito)
  • Alerta (alerta de DM): o alerta genérico (1226) é usado pelo cliente de gerenciamento empresarial quando o usuário dispara uma ação de desenrollamento 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 disparado pelo dispositivo.
  • Atomic: não há suporte para executar um comando Add seguido de Substituir no mesmo nó dentro de um elemento atômico. Os comandos Atomic e Get aninhados não são permitidos e geram o código de erro 500.
  • Excluir: remove um nó da árvore DM e toda a subconserção abaixo desse nó se existir
  • Exec: invoca um executável no dispositivo cliente
  • Obter: recupera dados do dispositivo cliente; para nós interiores, os nomes de nó filho no elemento Data são retornados no formato codificado por URI
  • Substituir: substitui os dados no dispositivo cliente
  • Resultado: retorna os resultados de dados de um comando Get para o servidor DM
  • Sequência: especifica a ordem na qual um grupo de comandos deve ser processado
  • Status: indica o status de conclusão (êxito ou falha) de uma operação

    Se um elemento XML que não é um comando OMA DM válido estiver sob um dos seguintes elementos, o código status 400 será retornado para esse elemento:
  • Syncbody
  • Atômica
  • Seqüência

    Se nenhum CmdID for fornecido no comando DM, o cliente retornará em branco no elemento status e no código status 400.

    Se os elementos atômicos estiverem aninhados, os seguintes códigos status serão retornados:
  • O comando atômico aninhado retorna 500.
  • O comando Atomic pai retorna 507.

    Para obter mais informações sobre o comando Atomic, consulte Elementos comuns do protocolo OMA DM.
    Não há suporte para executar um comando Add seguido de Substituir no mesmo nó dentro de um elemento Atomic.

    O LocURI não pode começar com /.

    A marca Meta XML no SyncHdr é ignorada pelo dispositivo.
    		•
    Objetos padrão OMA DM DevInfo
  • DevDetail
  • Objetos de conta DMS de DM do OMA (versão 1.2 do DM do OMA)
    		•
    Segurança
  • Autenticar mensagem SMS de notificação de iniciação do servidor DM (não usada pelo gerenciamento empresarial)
  • Autenticação de cliente da camada de aplicativo Basic e MD5
  • Autenticar servidor com credencial MD5 no nível do aplicativo
  • Integridade e autenticação de dados com o HMAC no nível do aplicativo
  • Autenticação, criptografia e integridade de dados no nível de TLS/SSL marcar
    		•
    Nós Na árvore DM OMA, as seguintes regras se aplicam ao 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 (*).
    		•
    Provisionamento de arquivos O provisionamento do XML deve estar bem formado e seguir a definição no Protocolo de Representação SyncML.

    Se um elemento XML que não é um comando OMA DM válido estiver em SyncBody, o código status 400 será retornado para esse elemento.
    Observação
    Para representar uma cadeia de caracteres Unicode como um URI, primeiro codifica a cadeia de caracteres como UTF-8. Em seguida, codifica cada um dos bytes UTF-8 usando a codificação de URI.
    Suporte ao WBXML O Windows dá suporte ao envio e ao recebimento de SyncML no formato XML e no formato WBXML codificado. Esse suporte de formato duplo é configurável usando o nó DEFAULTENCODING sob a característica w7 APPLICATION durante o registro. Para obter mais informações sobre a codificação WBXML, consulte a seção 8 da especificação Protocolo de Representação SyncML .
    Manipulação de objetos grandes No Windows 10, o suporte ao cliente para carregar objetos grandes no servidor foi adicionado.

    Elementos comuns do protocolo OMA DM

    Elementos comuns são usados por outros tipos de elemento OMA DM. A tabela a seguir lista os elementos comuns de DM OMA usados para configurar os dispositivos. Para obter mais informações sobre elementos comuns do DM OMA, consulte "Protocolo de Representação SyncML Gerenciamento de Dispositivos Use" (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 credenciais ou credenciais inadequadas tiverem sido dadas na mensagem de solicitação original.
    Cmd Especifica o nome de um comando OMA DM referenciado em um elemento Status.
    CmdID Especifica o identificador exclusivo para um comando DM OMA.
    CmdRef Especifica a ID do comando para o qual status ou informações de resultados estão sendo retornadas. Esse elemento usa o valor do elemento CmdID da mensagem de solicitação correspondente.
    Cred Especifica a credencial de autenticação para o criador da mensagem.
    Final Indica que a mensagem atual é a última mensagem no pacote.
    LocName Especifica o nome de exibição nos elementos Target e Source, usados para enviar uma ID de usuário para autenticação MD5.
    LocURI Especifica o endereço do local de destino ou de origem. Se o endereço contiver um caractere não alfanumérico, ele deverá 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 de DM OMA.
    MsgRef Especifica a ID da mensagem de solicitação correspondente. Esse elemento usa o valor do elemento MsgID da mensagem de solicitação.
    RespURI Especifica o URI que o destinatário deve usar ao enviar uma resposta para essa mensagem.
    Sessionid Especifica o identificador da sessão de DM OMA associada à mensagem que contém. Se o servidor não notificar o dispositivo que ele dá suporte a uma nova versão (por meio do nó SyncApplicationVersion no CSP DMClient), o cliente retornará o SessionID em inteiro no formato decimal. Se o servidor for compatível com a sincronização de sessão DM versão 2.0, que é usada no Windows, o cliente do dispositivo retornará 2 bytes.
    Origem Especifica o endereço de origem da mensagem.
    SourceRef Especifica a origem da mensagem de solicitação correspondente. Esse elemento pega o valor do elemento Fonte da mensagem de solicitação e é retornado no elemento Status ou Resultados.
    Target Especifica o endereço do nó na Árvore de DM que é o destino do comando OMA DM.
    TargetRef Especifica o endereço de destino na mensagem de solicitação correspondente. Esse elemento usa o valor da mensagem de solicitação Elemento Destino e é retornado no elemento Status ou Resultados.
    VerDTD Especifica o identificador de versão principal e menor da especificação de protocolo de representação de DM OMA usada para representar a mensagem.
    VerProto Especifica o identificador de versão principal e menor da especificação de protocolo OMA DM usada com a mensagem.

    Sessão de gerenciamento de dispositivo

    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 que indicam operações que devem ser executadas na árvore de gerenciamento do dispositivo cliente. O cliente responde enviando comandos que contêm os resultados e quaisquer informações de status solicitadas.

    Uma sessão de DM curta pode ser resumida como:

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

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

    1. Fase de instalação: em resposta a um evento de gatilho, um dispositivo cliente envia uma mensagem de iniciação para um servidor DM. A troca de dispositivos e servidores precisava de autenticação e informações de dispositivo. Essa fase é representada pelas etapas 1, 2 e 3.
    2. Fase de gerenciamento: o servidor DM está no controle. Ele envia comandos de gerenciamento para o dispositivo e o dispositivo responde. A fase 2 termina quando o servidor DM interrompe o envio de comandos e encerra a sessão. Essa fase é representada pelas etapas 3, 4 e 5.

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

    1. O cliente DM é invocado para chamar de volta para o servidor de gerenciamento

      Cenário empresarial – O agendamento de tarefas do dispositivo invoca o cliente DM.

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

      A mensagem de gatilho inclui a ID do servidor e informa ao dispositivo cliente para iniciar uma sessão com o servidor. O dispositivo cliente autentica a mensagem de gatilho e verifica se o servidor está autorizado a se comunicar com ele.

      Cenário empresarial – Na hora agendada, o cliente DM é invocado periodicamente para chamar de volta para o servidor de gerenciamento empresarial por HTTPS.

    2. O dispositivo envia uma mensagem, por meio 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 TLS/SSL ou no nível do aplicativo DM.

    3. O servidor DM responde por meio 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 de servidor. Esta mensagem inclui os resultados da execução das operações de gerenciamento de dispositivo 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 da 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 por um incremento de 1 para cada mensagem extra. Para obter mais informações sobre o protocolo MsgID e OMA SyncML, consulte Protocolo de Representação de Gerenciamento de Dispositivos OMA (DM_RepPro-V1_2-20070209-A).

    Durante a autenticação mútua no nível do 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 será necessária para o restante da sessão de DM. Se ocorrer a autenticação MD5, o Chal elemento poderá ser retornado. Em seguida, o próximo nó em Chal deve ser usado para o digestão MD5 quando a próxima sessão de DM for iniciada.

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

    Para obter mais informações sobre a autenticação do cliente Basic ou MD5, a autenticação do servidor MD5, o hash MD5 e o nó MD5, consulte a especificação OMA Gerenciamento de Dispositivos Security (OMA-TS-DM_Security-V1_2_1-20080617-A), tratamento de código de resposta de autenticação e exemplos passo a passo no OMA Gerenciamento de Dispositivos Especificação de protocolo (OMA-TS-DM_Protocol-V1_2_1-20080617-A), disponível no site da OMA.

    Configuração de destino do usuário versus dispositivo

    Para CSPs e políticas compatíveis por configuração de usuário, o servidor MDM pode enviar valores de configuração direcionados ao usuário para o dispositivo no qual um usuário registrado em MDM está conectado ativamente. O dispositivo notifica o servidor do status de entrada por meio de um alerta de dispositivo (1224) com tipo de alerta = em DM pkg#1.

    A parte de dados desse alerta pode ser uma das seguintes cadeias de caracteres:

    • Usuário: o usuário que registrou o dispositivo está conectado ativamente. O servidor MDM poderia enviar configuração específica do usuário para CSPs/políticas que dão suporte por configuração de usuário
    • Outros: outro usuário entra, 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 usuário ativo entra. O servidor só pode aplicar a configuração em todo o dispositivo e a configuração disponível é restrita ao ambiente do dispositivo (nenhum usuário ativo entra).

    Aqui 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 ele é uma configuração direcionada ao usuário ou direcionada ao dispositivo por um prefixo para o LocURL do nó de gerenciamento, com ./user para configuração direcionada ao usuário ou ./device para configuração direcionada ao dispositivo. Por padrão, se nenhum prefixo com ./device ou ./user, é uma 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 configuração de nó CSP por dispositivo: ./device/vendor/MSFT/RemoteWipe/DoWipe

    Códigos de status de resposta SyncML

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

    Código de status Descrição
    200 O comando SyncML foi concluído com êxito.
    202 Aceito para processamento. Esse código denota 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ó vê esse código em resposta ao elemento SyncHdr (usado para autenticação no padrão OMA-DM). Você poderá ver esse código se olhar para os logs de DM do OMA, mas os CSPs normalmente não geram esse código.
    214 Operação cancelada. O comando SyncML foi concluído com êxito, mas não há mais comandos processados na 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 Atomic elemento e Atomic falhou. Esse comando foi revertido com êxito.
    400 Solicitação incorreta. O comando solicitado não pôde ser executado devido à sintaxe malformada. Os CSPs geralmente não geram esse erro, no entanto, você pode vê-lo se seu SyncML estiver malformado.
    401 Credenciais inválidas. O comando solicitado falhou porque o solicitante deve fornecer a 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 destino solicitado não foi encontrado. Esse 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 com suporte. Esse código de resposta será gerado se você tentar acessar uma propriedade que o CSP não dá suporte.
    415 Tipo ou formato sem suporte. Esse código de resposta pode resultar de erros de análise ou formatação de XML.
    418 Já existe. Esse código de resposta ocorrerá se você tentar adicionar um nó que já existe.
    425 Permissão negada. O comando solicitado falhou porque o remetente não tem acl (permissões de controle de acesso) adequadas no destinatário. Os erros de "acesso negado" geralmente são traduzidos para esse código de resposta.
    500 Falha no comando. Falha genérica. O destinatário encontrou uma condição inesperada, o que o impediu de atender à solicitação. Esse código de resposta ocorre quando a DPU SyncML não pode mapear o código de erro de origem.
    507 Atomic Falhou. Uma das operações em um Atomic bloco falhou.
    516 Atomic falha ao reverter. Uma Atomic operação falhou e o comando não foi revertido com êxito.

    Referência de provedor de serviços de configuração