Supporto del protocollo OMA DM

Il client OMA DM comunica con il server tramite HTTPS e usa Dm Sync (OMA DM v1.2) come payload del messaggio. Questo articolo descrive la funzionalità dm OMA supportata in generale dal client dm. La descrizione completa del protocollo OMA DM v1.2 è disponibile nel sito Web OMA.

Standard OMA DM

La tabella seguente illustra gli standard OMA DM usati da Windows.

Area generale Standard OMA DM supportato
Trasporto dati e sessione
  • Sessione remota DI GESTIONE INDIRIZZI HTTPS avviata dal client su TLS/SSL.
  • Sessione remota del servizio Migrazione del database HTTPS tramite TLS/SSL.
  • Notifica di avvio del server Dm remoto tramite WAP Push over Short Message Service (SMS). Non usato dalla gestione aziendale.
  • Bootstrap remoto tramite WAP Push over SMS. Non usato dalla gestione aziendale.
    		•
    Bootstrap XML Xml di provisioning client OMA.
    Comandi del protocollo DM L'elenco seguente mostra i comandi usati dal dispositivo. Per altre informazioni sugli elementi del comando OMA DM, vedere "sito Web OMA" disponibile nel sito Web OMA.
  • Aggiungi (aggiunta implicita supportata)
  • Avviso (avviso DM): l'avviso generico (1226) viene usato dal client di gestione aziendale quando l'utente attiva un'azione di annullamento della registrazione MDM dal dispositivo o quando un CSP termina alcune azioni asincrone. L'avviso del dispositivo (1224) viene usato per notificare al server un evento attivato dal dispositivo.
  • Atomic: l'esecuzione di un comando Add seguito da Replace nello stesso nodo all'interno di un elemento atomico non è supportata. I comandi Atomic e Get annidati non sono consentiti e generano il codice di errore 500.
  • Elimina: rimuove un nodo dall'albero dm e l'intero sottoalbero sotto tale nodo, se esistente
  • Exec: richiama un eseguibile nel dispositivo client
  • Get: recupera i dati dal dispositivo client; Per i nodi interni, i nomi dei nodi figlio nell'elemento Data vengono restituiti in formato con codifica URI
  • Sostituisci: sovrascrive i dati nel dispositivo client
  • Risultato: restituisce i risultati dei dati di un comando Get al server Dm
  • Sequenza: specifica l'ordine in cui deve essere elaborato un gruppo di comandi
  • Stato: indica lo stato di completamento (esito positivo o negativo) di un'operazione

    Se un elemento XML che non è un comando OMA DM valido si trova in uno degli elementi seguenti, viene restituito il codice di stato 400 per tale elemento:
  • SyncBody
  • Atomica
  • Sequenza

    Se nel comando DM non viene specificato alcun CmdID, il client restituisce vuoto nell'elemento status e nel codice di stato 400.

    Se gli elementi Atomic sono annidati, vengono restituiti i codici di stato seguenti:
  • Il comando Atomic annidato restituisce 500.
  • Il comando atomico padre restituisce 507.

    Per altre informazioni sul comando Atomic, vedere Elementi comuni del protocollo OMA DM.
    L'esecuzione di un comando Add seguito da Replace nello stesso nodo all'interno di un elemento Atomic non è supportata.

    LocURI non può iniziare con /.

    Il tag Meta XML in SyncHdr viene ignorato dal dispositivo.
    		•
    Oggetti standard OMA DM DevInfo
  • DevDetail
  • Oggetti account DMS OMA DM (OMA DM versione 1.2)
    		•
    Sicurezza
  • Autenticare il messaggio SMS di notifica di avvio del server DM (non usato dalla gestione aziendale)
  • Autenticazione client BASIC e MD5 a livello di applicazione
  • Autenticare il server con le credenziali MD5 a livello di applicazione
  • Integrità e autenticazione dei dati con HMAC a livello di applicazione
  • Controllo dell'integrità dei dati, della crittografia e dell'autenticazione client basata su certificato a livello TLS/SSL
    		•
    Nodi Nell'albero OMA DM si applicano le regole seguenti per il nome del nodo:
  • "." può far parte del nome del nodo.
  • Il nome del nodo non può essere vuoto.
  • Il nome del nodo non può essere solo il carattere asterisco (*).
    		•
    File di provisioning Il formato XML di provisioning deve essere corretto e seguire la definizione in SyncML Representation Protocol.

    Se un elemento XML che non è un comando OMA DM valido si trova in SyncBody, viene restituito il codice di stato 400 per tale elemento.
    Nota
    Per rappresentare una stringa Unicode come URI, codificare prima la stringa come UTF-8. Codificare quindi ognuno dei byte UTF-8 usando la codifica URI.
    Supporto WBXML Windows supporta l'invio e la ricezione di SyncML sia in formato XML che in formato WBXML codificato. Questo supporto a doppio formato è configurabile usando il nodo DEFAULTENCODING con la caratteristica w7 APPLICATION durante la registrazione. Per altre informazioni sulla codifica WBXML, vedere la sezione 8 della specifica SyncML Representation Protocol .
    Gestione di oggetti di grandi dimensioni In Windows 10 è stato aggiunto il supporto client per il caricamento di oggetti di grandi dimensioni nel server.

    Elementi comuni del protocollo OMA DM

    Gli elementi comuni vengono usati da altri tipi di elemento OMA DM. Nella tabella seguente sono elencati gli elementi comuni di OMA DM usati per configurare i dispositivi. Per altre informazioni sugli elementi comuni di OMA DM, vedere "SyncML Representation Protocol Gestione dispositivi Usage" (OMA-SyncML-DMRepPro-V1_1_2-20030613-A) disponibile nel sito Web OMA.

    Elemento Descrizione
    Chal Specifica una richiesta di autenticazione. Il server o il client può inviare una richiesta all'altro se nel messaggio di richiesta originale non sono state fornite credenziali o credenziali insufficienti.
    Cmd Specifica il nome di un comando OMA DM a cui viene fatto riferimento in un elemento Status.
    CmdID Specifica l'identificatore univoco per un comando OMA DM.
    CmdRef Specifica l'ID del comando per cui vengono restituite informazioni sullo stato o sui risultati. Questo elemento accetta il valore dell'elemento CmdID del messaggio di richiesta corrispondente.
    Cred Specifica le credenziali di autenticazione per l'originatore del messaggio.
    Finale Indica che il messaggio corrente è l'ultimo messaggio nel pacchetto.
    LocName Specifica il nome visualizzato negli elementi Destinazione e Origine, usato per inviare un ID utente per l'autenticazione MD5.
    LocURI Specifica l'indirizzo della destinazione o del percorso di origine. Se l'indirizzo contiene un carattere non alfanumerico, deve essere sottoposto a escape correttamente in base allo standard di codifica URL.
    Msgid Specifica un identificatore univoco per un messaggio di sessione OMA DM.
    MsgRef Specifica l'ID del messaggio di richiesta corrispondente. Questo elemento accetta il valore dell'elemento MsgID del messaggio di richiesta.
    RespURI Specifica l'URI che il destinatario deve usare quando invia una risposta a questo messaggio.
    Sessionid Specifica l'identificatore della sessione dm OMA associata al messaggio contenitore. Se il server non notifica al dispositivo che supporta una nuova versione (tramite il nodo SyncApplicationVersion nel CSP DMClient), il client restituisce l'ID sessione in formato integer in formato decimale. Se il server supporta la sincronizzazione sessione DM versione 2.0, usata in Windows, il client del dispositivo restituisce 2 byte.
    Source Specifica l'indirizzo di origine del messaggio.
    SourceRef Specifica l'origine del messaggio di richiesta corrispondente. Questo elemento accetta il valore dell'elemento Source del messaggio di richiesta e viene restituito nell'elemento Status o Results.
    Target Specifica l'indirizzo del nodo nell'albero del database che è la destinazione del comando OMA DM.
    TargetRef Specifica l'indirizzo di destinazione nel messaggio di richiesta corrispondente. Questo elemento accetta il valore dell'elemento Target del messaggio di richiesta e viene restituito nell'elemento Status o Results.
    VerDTD Specifica l'identificatore della versione principale e secondaria della specifica del protocollo di rappresentazione OMA DM usata per rappresentare il messaggio.
    VerProto Specifica l'identificatore di versione principale e secondaria della specifica del protocollo OMA DM usata con il messaggio.

    Sessione di gestione dei dispositivi

    Una sessione di Gestione dispositivi (DM) è costituita da una serie di comandi scambiati tra un server Dm e un dispositivo client. Il server invia comandi che indicano le operazioni che devono essere eseguite nell'albero di gestione del dispositivo client. Il client risponde inviando comandi contenenti i risultati e le informazioni sullo stato richieste.

    Una breve sessione dm può essere riepilogata come segue:

    Un server invia un comando Get a un dispositivo client per recuperare il contenuto di uno dei nodi dell'albero di gestione. Il dispositivo esegue l'operazione e risponde con un comando Result che contiene il contenuto richiesto.

    Una sessione dm può essere suddivisa in due fasi:

    1. Fase di installazione: in risposta a un evento trigger, un dispositivo client invia un messaggio di avvio a un server dm. Lo scambio di dispositivi e server richiedeva l'autenticazione e le informazioni sul dispositivo. Questa fase è rappresentata dai passaggi 1, 2 e 3.
    2. Fase di gestione: il server dm è in controllo. Invia comandi di gestione al dispositivo e il dispositivo risponde. La fase 2 termina quando il server dm interrompe l'invio dei comandi e termina la sessione. Questa fase è rappresentata dai passaggi 3, 4 e 5.

    Le informazioni seguenti mostrano la sequenza di eventi durante una tipica sessione dm.

    1. Il client dm viene richiamato per richiamare il server di gestione

      Scenario aziendale: la pianificazione delle attività del dispositivo richiama il client dm.

      Il server MO invia un messaggio di trigger del server per richiamare il client dm.

      Il messaggio del trigger include l'ID server e indica al dispositivo client di avviare una sessione con il server. Il dispositivo client autentica il messaggio del trigger e verifica che il server sia autorizzato a comunicare con esso.

      Scenario aziendale: all'ora pianificata, il client dm viene richiamato periodicamente per richiamare il server di gestione aziendale tramite HTTPS.

    2. Il dispositivo invia un messaggio, tramite una connessione IP, per avviare la sessione.

      Questo messaggio include le informazioni e le credenziali del dispositivo. Il client e il server esenziano l'autenticazione reciproca tramite un canale TLS/SSL o a livello di applicazione dm.

    3. Il server dm risponde tramite una connessione IP (HTTPS). Il server invia i comandi di gestione dei dispositivi iniziali, se presenti.

    4. Il dispositivo risponde ai comandi di gestione del server. Questo messaggio include i risultati dell'esecuzione delle operazioni di gestione dei dispositivi specificate.

    5. Il server Dm termina la sessione o invia un altro comando. La sessione dm termina o il passaggio 4 viene ripetuto.

    I numeri di passaggio non rappresentano i numeri di identificazione dei messaggi (MsgID). Tutti i messaggi dal server devono avere un MsgID univoco all'interno della sessione, a partire da 1 per il primo messaggio e aumentando di un incremento di 1 per ogni messaggio aggiuntivo. Per altre informazioni sul protocollo MsgID e OMA SyncML, vedere OMA Gestione dispositivi Representation Protocol (DM_RepPro-V1_2-20070209-A).

    Durante l'autenticazione reciproca a livello di applicazione OMA DM, se il codice di risposta del dispositivo all'elemento Cred nella richiesta del server è 212, non è necessaria alcuna ulteriore autenticazione per la parte restante della sessione dm. Se si verifica l'autenticazione MD5, è possibile restituire l'elemento Chal . Il successivo nonce in Chal deve quindi essere usato per il digest MD5 all'avvio della sessione dm successiva.

    Se una richiesta include credenziali e il codice di risposta alla richiesta è 200, le stesse credenziali devono essere inviate all'interno della richiesta successiva. Se l'elemento Chal è incluso e l'autenticazione MD5 è necessaria, viene creato un nuovo digest usando il nonce successivo tramite l'elemento per la Chal richiesta successiva.

    Per altre informazioni sull'autenticazione client Basic o MD5, Autenticazione server MD5, hash MD5 e nonce MD5, vedere la specifica OMA Gestione dispositivi Security (OMA-TS-DM_Security-V1_2_1-20080617-A), la gestione del codice di risposta per l'autenticazione e gli esempi passo passo nella specifica del protocollo OMA Gestione dispositivi (OMA-TS-DM_Protocol-V1_2_1-20080617-A), disponibile da sito Web OMA.

    Configurazione destinata all'utente e configurazione di destinazione del dispositivo

    Per i CSP e i criteri che supportano la configurazione per utente, il server MDM può inviare valori di impostazione di destinazione utente al dispositivo a cui un utente registrato tramite MDM è attivamente connesso. Il dispositivo notifica al server lo stato di accesso tramite un avviso del dispositivo (1224) con tipo di avviso = in DM pkg#1.

    La parte dei dati di questo avviso potrebbe essere una delle stringhe seguenti:

    • Utente: l'utente che ha registrato il dispositivo è attivamente connesso. Il server MDM può inviare la configurazione specifica dell'utente per i CSP/criteri che supportano la configurazione per utente
    • Altri: un altro utente esegue l'accesso, ma tale utente non ha un account MDM. Il server può applicare solo la configurazione a livello di dispositivo, ad esempio la configurazione si applica a tutti gli utenti del dispositivo.
    • Nessuno: nessun accesso utente attivo. Il server può applicare solo la configurazione a livello di dispositivo e la configurazione disponibile è limitata all'ambiente del dispositivo (nessun accesso utente attivo).

    Ecco un esempio di avviso:

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

    Il server notifica al dispositivo se si tratta di una configurazione di destinazione utente o di destinazione del dispositivo con un prefisso per locURL del nodo di gestione, con ./user per la configurazione di destinazione dell'utente o ./device per la configurazione di destinazione del dispositivo. Per impostazione predefinita, se non è disponibile alcun prefisso con ./device o ./user, si tratta di una configurazione di destinazione del dispositivo.

    Il locURL seguente mostra una configurazione del nodo CSP per utente: ./user/vendor/MSFT/EnterpriseModernAppManagement/AppInstallation/<PackageFamilyName>/StoreInstall

    Il locURL seguente mostra una configurazione del nodo CSP per dispositivo: ./device/vendor/MSFT/RemoteWipe/DoWipe

    Codici di stato della risposta SyncML

    Quando si usa SyncML in OMA DM, vengono restituiti i codici di stato della risposta standard. Nella tabella seguente sono elencati i codici di stato comuni della risposta SyncML che probabilmente verranno visualizzati. Per altre informazioni sui codici di stato della risposta SyncML, vedere la sezione 10 della specifica SyncML Representation Protocol .

    Codice di stato Descrizione
    200 Il comando SyncML è stato completato correttamente.
    202 Accettato per l'elaborazione. Questo codice indica un'operazione asincrona, ad esempio una richiesta di esecuzione remota di un'applicazione.
    212 Autenticazione accettata. In genere questo codice viene visualizzato solo in risposta all'elemento SyncHdr (usato per l'autenticazione nello standard OMA-DM). È possibile che questo codice venga visualizzato se si esaminano i log di OMA DM, ma i CSP in genere non generano questo codice.
    214 Operazione annullata. Il comando SyncML è stato completato correttamente, ma non vengono elaborati altri comandi all'interno della sessione.
    215 Non eseguito. Un comando non è stato eseguito a causa dell'interazione dell'utente per annullare il comando.
    216 Atomic rollback OK. Un comando si trovava all'interno di un Atomic elemento e Atomic non è riuscito. Il rollback di questo comando è stato eseguito correttamente.
    400 Richiesta non valida. Impossibile eseguire il comando richiesto a causa di una sintassi non valida. I CSP in genere non generano questo errore, ma è possibile che venga visualizzato se syncML non è valido.
    401 Credenziali non valide. Il comando richiesto non è riuscito perché il richiedente deve fornire l'autenticazione corretta. I CSP in genere non generano questo errore.
    403 Proibito. Il comando richiesto non è riuscito, ma il destinatario ha compreso il comando richiesto.
    404 Non trovato. La destinazione richiesta non è stata trovata. Questo codice viene generato se si esegue una query su un nodo che non esiste.
    405 Comando non consentito. Questo codice di risposta viene generato se si tenta di scrivere in un nodo di sola lettura.
    406 Funzionalità facoltativa non supportata. Questo codice di risposta viene generato se si tenta di accedere a una proprietà non supportata dal CSP.
    415 Tipo o formato non supportato. Questo codice di risposta può risultare da errori di analisi o formattazione XML.
    418 Esiste già. Questo codice di risposta si verifica se si tenta di aggiungere un nodo già esistente.
    425 Autorizzazione negata. Il comando richiesto non è riuscito perché il mittente non dispone di autorizzazioni di controllo di accesso (ACL) adeguate per il destinatario. Gli errori di accesso negato vengono in genere convertiti in questo codice di risposta.
    500 Comando non riuscito. Errore generico. Il destinatario ha rilevato una condizione imprevista, che ha impedito di soddisfare la richiesta. Questo codice di risposta si verifica quando la DPU SyncML non è in grado di eseguire il mapping del codice di errore di origine.
    507 Atomic Fallito. Una delle operazioni in un Atomic blocco non è riuscita.
    516 Atomic rollback non riuscito. Un'operazione Atomic non è riuscita e non è stato eseguito il rollback del comando.

    Riferimento del provider di servizi di configurazione