Suporte ao protocolo OMA DM

O OMA DMClient se comunica com o servidor por HTTPS e usa o DM Sync (OMA DM v1.2) como o conteúdo da mensagem. Este artigo descreve a funcionalidade do OMA DM compatível com o DMClient em geral. A descrição completa do protocolo OMA DM v1.2 pode ser encontrada no site do OMA.

Padrões do OMA DM

A tabela a seguir mostra os padrões do OMA DM usados pelo Windows.

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 do OMA DM usados para configurar os dispositivos. Para obter mais informações sobre elementos comuns do OMA DM, consulte "SyncML Representation Protocol Gerenciamento de Dispositivos Usage" (OMA-SyncML-DMRepPro-V1_1_2-20030613-A) disponível no site do OMA.

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 indicando as 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.

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

Um servidor envia um comando Get a um dispositivo cliente para recuperar o conteúdo de um dos nós da árvore de gerenciamento. O dispositivo realiza 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 configuração: Em resposta a um evento de acionamento, um dispositivo cliente envia uma mensagem inicial para um servidor DM. O dispositivo e o servidor trocam as informações necessárias de autenticação e 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 para de enviar 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 típica de DM.

1. DMClient é invocado para retornar ao servidor de gerenciamento
   
   Cenário corporativo - A programação de tarefas do dispositivo invoca o DMClient.

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

   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 corporativo – no horário agendado, o DMClient é invocado periodicamente para retornar ao servidor de gerenciamento corporativo por HTTPS.

2. O dispositivo envia uma mensagem, por uma conexão IP, para iniciar a sessão.

   Essa mensagem inclui informações e credenciais do dispositivo. O cliente e o servidor fazem autenticação mútua por meio de 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 dispositivo, 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 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 das etapas não representam números de identificação da 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 MsgID e o protocolo SyncML do OMA, consulte Protocolo de representação do OMA Gerenciamento de Dispositivos (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 para o elemento Cred na solicitação do servidor for 212, nenhuma autenticação adicional será necessária para o restante da sessão DM. Se a autenticação MD5 ocorrer, o Chal elemento poderá ser retornado. Em seguida, o próximo nonce de entrada Chal deve ser usado para o resumo 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 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 para a Chal próxima solicitação.

Para obter mais informações sobre autenticação de cliente Básica ou MD5, autenticação de servidor MD5, hash MD5 e nonce MD5, consulte a Especificação de Segurança do OMA Gerenciamento de Dispositivos (OMA-TS-DM_Security-V1_2_1-20080617-A), manipulação 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 do OMA.

Configuração direcionada ao usuário vs. configuração direcionada ao dispositivo

Para CSPs e políticas que dão suporte à configuração por usuário, o servidor MDM pode enviar valores de configuração direcionada ao usuário para o dispositivo em que um usuário registrado no MDM está conectado ativamente. O dispositivo notifica o servidor sobre o 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 pode enviar configurações específicas do usuário para CSPs/políticas que dão suporte à configuração por 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 no dispositivo.
• Nenhum: nenhuma entrada de usuário ativo. O servidor só pode aplicar a configuração em todo o dispositivo, e a configuração disponível é restrita ao ambiente do dispositivo (nenhuma entrada de usuário ativo).

Veja 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 é 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 não houver prefixo com ./device ou ./user, é uma configuração direcionada ao dispositivo.

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

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

Códigos de status de resposta do SyncML

Ao usar o SyncML no OMA DM, há códigos de status de resposta padrã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 códigos de status de resposta do SyncML, consulte a seção 10 da especificação do Protocolo de Representação do SyncML.

Artigos relacionados

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