Suporte ao protocolo OMA DM

• Aplica-se a:

  ✅ Windows 11, ✅ Windows 10

O cliente OMA DM comunica com o servidor através de HTTPS e utiliza a Sincronização de DM (OMA DM v1.2) como payload de mensagens. Este artigo descreve a funcionalidade do DM OMA que o cliente DM suporta em geral. A descrição completa do protocolo OMA DM v1.2 pode ser encontrada no site do OMA.

Normas do OMA DM

A tabela seguinte mostra as normas OMA DM que o Windows utiliza.

Área geral	Norma OMA DM suportada
Transporte e sessão de dados	Sessão DM DE HTTPS remota iniciada pelo cliente através de TLS/SSL. Sessão DM HTTPS remota através de TLS/SSL. Notificação de iniciação remota do servidor DM através do Push de WAP através do Serviço de Mensagens Curtas (SMS). Não utilizado pela gestão empresarial. Bootstrap remoto com WAP Push através de SMS. Não utilizado pela gestão empresarial.
Bootstrap XML	XML de Aprovisionamento de Cliente OMA.
Comandos do protocolo DM	A lista seguinte mostra os comandos utilizados pelo dispositivo. Para obter mais informações sobre os elementos de comando OMA DM, veja "Site OMA" disponível no site do OMA. Adicionar (Adicionar Implícito suportado) Alerta (alerta de DM): o alerta genérico (1226) é utilizado pelo cliente de gestão empresarial quando o utilizador aciona uma ação de anulação da inscrição de MDM do dispositivo ou quando um CSP termina algumas ações assíncronas. O alerta de dispositivo (1224) é utilizado para notificar o servidor de algum evento acionado pelo dispositivo. Atomic: Executar um comando Adicionar seguido de Substituir no mesmo nó dentro de um elemento atómico não é suportado. Os comandos Atómico aninhado e Get não são permitidos e geram o código de erro 500. Eliminar: remove um nó da árvore DM e toda a subárvore abaixo desse nó, se existir um Exec: Invoca um executável no dispositivo cliente Obter: obtém dados do dispositivo cliente; para nós interiores, os nomes dos nós subordinados no elemento Dados são devolvidos no formato codificado com URI Substituir: substitui os dados no dispositivo cliente Resultado: Devolve os resultados de dados de um comando Get para o servidor DM Sequência: especifica a ordem pela qual um grupo de comandos tem de ser processado Estado: Indica o status de conclusão (êxito ou falha) de uma operação Se um elemento XML que não seja um comando OMA DM válido estiver sob um dos seguintes elementos, o código de status 400 é devolvido para esse elemento: SyncBody Atómico Sequência Se não for fornecido nenhum CmdID no comando DM, o cliente devolve blank no elemento status e no código de status 400. Se os elementos atómicos estiverem aninhados, são devolvidos os seguintes códigos de status: O comando Atómico aninhado devolve 500. O comando atómico principal devolve 507. Para obter mais informações sobre o comando Atomic, veja Elementos comuns do protocolo OMA DM. A execução de um comando Adicionar seguida de Substituir no mesmo nó dentro de um elemento Atómico não é suportada. O LocURI não pode começar com /. A etiqueta Meta XML no SyncHdr é ignorada pelo dispositivo.
Objetos padrão da DM OMA	DevInfo DevDetail Objetos de conta DMS do OMA DM (versão 1.2 do OMA DM)
Segurança	Autenticar mensagem SMS de notificação de iniciação do servidor DM (não utilizada pela gestão empresarial) Aplicação layer Basic and MD5 client authentication (Autenticação de cliente MD5 e Básica da camada de aplicação) Autenticar servidor com credencial MD5 ao nível da aplicação Integridade e autenticação de dados com o HMAC ao nível da aplicação Autenticação, encriptação e integridade de dados do cliente/servidor baseado em certificados do nível TLS/SSL marcar
Nós	Na árvore DM OMA, aplicam-se as seguintes regras 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 caráter asterisco (*).
Aprovisionar Ficheiros	O Aprovisionamento de XML tem de estar bem formado e seguir a definição no Protocolo de Representação SyncML. Se um elemento XML que não seja um comando OMA DM válido estiver em SyncBody, o código de status 400 é devolvido para esse elemento. Observação Para representar uma cadeia Unicode como um URI, codificar primeiro a cadeia como UTF-8. Em seguida, codifigue cada um dos bytes UTF-8 com a codificação URI.
Suporte WBXML	O Windows suporta o envio e a receção do SyncML no formato XML e no formato WBXML codificado. Este suporte de formato duplo é configurável com o nó DEFAULTENCODING sob a característica w7 APPLICATION durante a inscrição. Para obter mais informações sobre a codificação WBXML, veja a secção 8 da especificação do Protocolo de Representação SyncML .
Processamento de objetos grandes	No Windows 10, foi adicionado suporte ao cliente para carregar objetos grandes para o servidor.

Elementos comuns do protocolo OMA DM

Os elementos comuns são utilizados por outros tipos de elementos OMA DM. A tabela seguinte lista os elementos comuns do OMA DM utilizados para configurar os dispositivos. Para obter mais informações sobre os elementos comuns da DM OMA, veja "SyncML Representation Protocol Gerenciamento de Dispositivos Usage" (OMA-SyncML-DMRepPro-V1_1_2-20030613-A) disponível no site do OMA.

Elemento	Descrição
Chal	Especifica um desafio de autenticação. O servidor ou cliente pode enviar um desafio para o outro caso não tenham sido dadas credenciais ou credenciais inadequadas na mensagem de pedido original.
Cmd	Especifica o nome de um comando OMA DM referenciado num elemento Estado.
CmdID	Especifica o identificador exclusivo para um comando OMA DM.
CmdRef	Especifica o ID do comando para o qual status ou informações de resultados estão a ser devolvidas. Este elemento utiliza o valor do elemento CmdID da mensagem de pedido correspondente.
Cred	Especifica a credencial de autenticação do criador da mensagem.
Final	Indica que a mensagem atual é a última mensagem no pacote.
LocName	Especifica o nome a apresentar nos elementos Destino e Origem, utilizados para enviar um ID de utilizador para autenticação MD5.
LocURI	Especifica o endereço da localização de destino ou de origem. Se o endereço contiver um caráter não alfanumérico, tem de ser corretamente escapado de acordo com a norma 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 pedido correspondente. Este elemento utiliza o valor do elemento MsgID da mensagem de pedido.
RespURI	Especifica o URI que o destinatário tem de utilizar ao enviar uma resposta a esta mensagem.
SessionID	Especifica o identificador da sessão DM OMA associada à mensagem que contém. Se o servidor não notificar o dispositivo de que suporta uma nova versão (através do nó SyncApplicationVersion no CSP DMClient), o cliente devolve o SessionID em número inteiro em formato decimal. Se o servidor suportar a versão 2.0 da sincronização de sessão de DM, que é utilizada no Windows, o cliente do dispositivo devolve 2 bytes.
Origem	Especifica o endereço de origem da mensagem.
SourceRef	Especifica a origem da mensagem de pedido correspondente. Este elemento utiliza o valor do elemento Origem da mensagem de pedido e é devolvido no elemento Estado 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 pedido correspondente. Este elemento utiliza o valor do elemento Target da mensagem de pedido e é devolvido no elemento Estado ou Resultados.
VerDTD	Especifica o identificador da versão principal e secundária da especificação do protocolo de representação do DM OMA utilizada para representar a mensagem.
VerProto	Especifica o identificador da versão principal e secundária da especificação do protocolo OMA DM utilizada com a mensagem.

Sessão de gestão de dispositivos

Uma sessão de Gerenciamento de Dispositivos (DM) consiste numa série de comandos trocados entre um servidor DM e um dispositivo cliente. O servidor envia comandos que indicam operações que têm de ser executadas na árvore de gestão do dispositivo cliente. O cliente responde enviando comandos que contêm os resultados e quaisquer informações de status pedidas.

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

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

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

1. Fase de configuração: em resposta a um evento de acionador, um dispositivo cliente envia uma mensagem de início para um servidor DM. A troca de dispositivos e servidores precisava de autenticação e informações do dispositivo. Esta fase é representada pelos passos 1, 2 e 3.
2. Fase de gestão: o servidor DM está no controlo. Envia comandos de gestão para o dispositivo e o dispositivo responde. A Fase 2 termina quando o servidor DM deixa de enviar comandos e termina a sessão. Esta fase é representada pelos passos 3, 4 e 5.

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

1. O cliente DM é invocado para chamar de volta para o servidor de gestão
   
   Cenário empresarial – o agendamento de tarefas do dispositivo invoca o cliente DM.

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

   A mensagem de acionador inclui o ID do servidor e indica ao dispositivo cliente para iniciar uma sessão com o servidor. O dispositivo cliente autentica a mensagem do acionador e verifica se o servidor está autorizado a comunicar com o mesmo.
   
   Cenário empresarial – na hora agendada, o cliente DM é invocado periodicamente para voltar a ligar para o servidor de gestão empresarial através de HTTPS.

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

   Esta mensagem inclui informações e credenciais do dispositivo. O cliente e o servidor fazem a autenticação mútua através de um canal TLS/SSL ou ao nível da aplicação DM.

3. O servidor DM responde através de uma ligação IP (HTTPS). O servidor envia comandos de gestão de dispositivos iniciais, se existirem.

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

5. O servidor DM termina a sessão ou envia outro comando. A sessão de DM termina ou o Passo 4 é repetido.

Os números de passo não representam números de identificação de mensagens (MsgID). Todas as mensagens do servidor têm de ter um MsgID exclusivo na sessão, começando em 1 para a primeira mensagem e aumentando um incremento de 1 para cada mensagem extra. Para obter mais informações sobre o protocolo MsgID e OMA SyncML, consulte OMA Gerenciamento de Dispositivos Representation Protocol (DM_RepPro-V1_2-20070209-A).

Durante a autenticação mútua ao nível da aplicação OMA DM, se o código de resposta do dispositivo para o elemento Cred no pedido do servidor for 212, não é necessária mais autenticação para o resto da sessão de DM. Se ocorrer a autenticação MD5, o Chal elemento pode ser devolvido. Em seguida, o próximo nonce em Chal tem de ser utilizado para o resumo MD5 quando a próxima sessão de DM for iniciada.

Se um pedido incluir credenciais e o código de resposta para o pedido for 200, a mesma credencial tem de ser enviada no próximo pedido. Se o Chal elemento estiver incluído e a autenticação MD5 for necessária, será criado um novo resumo com o próximo nonce através do elemento para o Chal próximo pedido.

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

Utilizador direcionado vs. Configuração direcionada para o dispositivo

Para CSPs e políticas que suportam a configuração por utilizador, o servidor MDM pode enviar valores de definição direcionados pelo utilizador para o dispositivo no qual um utilizador inscrito na MDM tem sessão iniciada ativamente. O dispositivo notifica o servidor do status de início de sessão através de um alerta de dispositivo (1224) com o Tipo de alerta = em PKG DM#1.

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

• Utilizador: o utilizador que inscreveu o dispositivo tem sessão iniciada ativamente. O servidor MDM pode enviar uma configuração específica do utilizador para CSPs/políticas que suportam a configuração por utilizador
• Outros: outro utilizador inicia sessão, mas esse utilizador não tem uma conta MDM. O servidor só pode aplicar a configuração ao nível do dispositivo, por exemplo, a configuração aplica-se a todos os utilizadores no dispositivo.
• Nenhum: nenhum utilizador ativo inicia sessão. O servidor só pode aplicar a configuração em todo o dispositivo e a configuração disponível está restrita ao ambiente do dispositivo (sem início de sessão de utilizador ativo).

Eis 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 quer se trate de uma configuração direcionada para o utilizador ou direcionada para o dispositivo através de um prefixo para o LocURL do nó de gestão, com ./user para a configuração direcionada para o utilizador ou ./device para a configuração direcionada para o dispositivo. Por predefinição, se não existir um prefixo com ./device ou ./user, é uma configuração direcionada para o dispositivo.

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

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

Códigos de status de resposta SyncML

Ao utilizar o SyncML no OMA DM, existem códigos de resposta padrão status que são devolvidos. A tabela seguinte lista a resposta syncML comum status códigos que provavelmente verá. Para obter mais informações sobre códigos status de resposta SyncML, veja a secção 10 da especificação do Protocolo de Representação SyncML.

Código de status	Descrição
200	O comando SyncML foi concluído com êxito.
202	Aceite para processamento. Este código indica uma operação assíncrona, como um pedido para executar uma execução remota de uma aplicação.
212	Autenticação aceite. Normalmente, só vê este código em resposta ao elemento SyncHdr (utilizado para autenticação na norma OMA-DM). Poderá ver este código se observar os registos do DM OMA, mas os CSPs normalmente não geram este código.
214	Operação cancelada. O comando SyncML foi concluído com êxito, mas não são processados mais comandos na sessão.
215	Não executado. Um comando não foi executado como resultado da interação do utilizador para cancelar o comando.
216	Atomic reverter OK. Um comando estava dentro de um Atomic elemento e Atomic falhou. Este comando foi revertido com êxito.
400	Pedido incorreto. Não foi possível executar o comando pedido devido a sintaxe com formato incorreto. Normalmente, os CSPs não geram este erro. No entanto, poderá vê-lo se o SyncML tiver um formato incorreto.
401	Credenciais inválidas. O comando pedido falhou porque o requerente tem de fornecer a autenticação adequada. Normalmente, os CSPs não geram este erro.
403	Proibido. O comando pedido falhou, mas o destinatário compreendeu o comando pedido.
404	Não encontrado. O destino pedido não foi encontrado. Este código é gerado se consultar um nó que não existe.
405	Comando não permitido. Este código de resposta é gerado se tentar escrever num nó só de leitura.
406	Funcionalidade opcional não suportada. Este código de resposta é gerado se tentar aceder a 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. Este código de resposta ocorre se tentar adicionar um nó que já existe.
425	Permissão Negada. O comando pedido falhou porque o remetente não tem permissões de controlo de acesso (ACL) adequadas no destinatário. Normalmente, os erros de "Acesso negado" são traduzidos para este código de resposta.
500	O comando falhou. Falha genérica. O destinatário encontrou uma condição inesperada, o que impediu que cumprisse o pedido. Este código de resposta ocorre quando a DPU de SyncML não consegue mapear o código de erro de origem.
507	Atomic falhou. Uma das operações num Atomic bloco falhou.
516	Atomic falha na reversão. Uma Atomic operação falhou e o comando não foi revertido com êxito.

Artigos relacionados

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