OMA DM supporto per il protocollo

Written by on in Articles
  • Articolo
  • 12/16/2021
  • 12 minuti a leggere
    • D
    • M
    • un
    • v
    • d
    • +11
questa pagina è stata utile?

Grazie.

Il client OMA DM comunica con il server tramite HTTPS e utilizza DM Sync (OMA DM v1.2) come carico utile del messaggio. Questo argomento descrive la funzionalità OMA DM che il client DM supporta in generale. La descrizione completa del protocollo OMA DM v1.2 può essere trovata sul sito web OMA.

Standard OMA DM

La tabella seguente mostra gli standard OMA DM utilizzati da Windows.

Area generale OMA DM standard che è supportato
Trasporto dati e sessione
  • Sessione remota HTTPS DM avviata dal client su SSL.
  • Sessione remota HTTPS DM su SSL.
  • Notifica di avvio del server DM remoto tramite WAP Push over Short Message Service (SMS). Non utilizzato dalla gestione aziendale.
  • bootstrap remoto utilizzando WAP Push over SMS. Non utilizzato dalla gestione aziendale.
    		•
    Bootstrap XML OMA Client di provisioning XML.
    Comandi del protocollo DM L’elenco seguente mostra i comandi utilizzati dal dispositivo. Per ulteriori informazioni sugli elementi di comando OMA DM, vedere “Sito web OMA” disponibile dal sito Web OMA.

  • Add (Implicit Add supported)
  • Alert (DM alert): Alert generico (1226) viene utilizzato da Enterprise Management client quando l’utente attiva un’azione di annullamento MDM dal dispositivo o quando un CSP termina alcune azioni asincrone. Device alert (1224) viene utilizzato per notificare al server alcuni eventi attivati dal dispositivo.
  • Atomic: l’esecuzione di un comando Add seguito da Replace sullo stesso nodo all’interno di un elemento atomico non è supportata. I comandi atomici e Get nidificati non sono consentiti e genereranno il codice di errore 500.
  • Elimina: Rimuove un nodo dal DM albero, e l’intera sottostruttura sotto quel nodo se esiste
  • Exec: Richiama un file eseguibile sul dispositivo client
  • Ottenere: Recupera i dati dal dispositivo client; per i nodi interni, il nodo del bambino nomi dell’elemento di Dati vengono restituiti in URI-formato codificato
  • Sostituire: Sovrascrive i dati sul dispositivo client
  • Risultato: Restituisce i risultati dei dati di un comando Get al server DM
  • Sequenza: Specifica l’ordine in cui un gruppo di comandi che devono essere trattati
  • Stato: Indica lo stato di completamento (successo o il fallimento) di un’operazione
    Se un elemento XML che non è un valido OMA DM comando in uno dei seguenti elementi, il codice di stato 400 è tornato per l’elemento:
  • SyncBody
  • Atomic
  • Sequenza
    Se non CmdID è previsto nel DM comando, il cliente restituisce vuoto nell’elemento di stato e il codice di stato 400.
    Se gli elementi atomici sono annidati, vengono restituiti i seguenti codici di stato:
  • Il comando atomico nidificato restituisce 500.
  • Il comando atomico genitore restituisce 507.
    Per ulteriori informazioni sul comando atomico, vedere OMA DM protocol common elements.
    L’esecuzione di un comando Add seguito da Replace sullo stesso nodo all’interno di un elemento atomico non è supportata.
    LocURI non può iniziare con /.
    Il tag Meta XML in SyncHdr viene ignorato dal dispositivo.
    		•
    OMA DM standard objects DevInfo

  • DevDetail
  • OMA DM DMS account objects (OMA DM versione 1.2)
    		•
    Sicurezza
  • Autenticare DM server iniziazione SMS di notifica di messaggio (non utilizzato da enterprise management)
  • Applicazione di strato di Base MD5 e l’autenticazione del client
  • l’Autenticazione server con MD5 credenziali a livello di applicazione
  • l’integrità dei Dati e l’autenticazione con HMAC a livello di applicazione
  • SSL certificato di livello basato su client/server di autenticazione, la crittografia e il controllo di integrità dei dati
    		•
    i Nodi In OMA DM albero, si applicano le seguenti regole per il nodo nome:

  • “.”può essere parte del nome del nodo.
  • Il nome del nodo non può essere vuoto.
  • Il nome del nodo non può essere solo l’asterisco ( * ).
    		•
    I file di provisioning Il provisioning XML deve essere ben formato e seguire la definizione nel protocollo di rappresentazione SyncML](https://go.microsoft.com/fwlink/p/?LinkId=526905).
    Se un elemento XML che non è un comando OMA DM valido è sotto SyncBody, viene restituito il codice di stato 400 per quell’elemento.

    Nota
    Per rappresentare una stringa Unicode come URI, prima codificare la stringa come UTF-8. Quindi codificare ciascuno dei byte UTF-8 utilizzando la codifica URI.
    Supporto WBXML Windows supporta l’invio e la ricezione di SyncML sia in formato XML che in formato WBXML codificato. Questo è configurabile utilizzando il nodo DEFAULTENCODING sotto la caratteristica dell’APPLICAZIONE w7 durante la registrazione. Per ulteriori informazioni sulla codifica WBXML, vedere la sezione 8 della specifica del protocollo di rappresentazione SyncML.
    Gestione di oggetti di grandi dimensioni In Windows 10, versione 1511, è stato aggiunto il supporto client per il caricamento di oggetti di grandi dimensioni sul server.

    Protocollo OMA DM elementi comuni

    Gli elementi comuni sono utilizzati da altri tipi di elementi OMA DM. La seguente tabella elenca gli elementi comuni OMA DM utilizzati per configurare i dispositivi. Per ulteriori informazioni sugli elementi comuni OMA DM, vedere” SyncML Representation Protocol Device Management Usage ” (OMA-SyncML-DMRepPro-V1_1_2-20030613-A) disponibile dal sito Web OMA.

    Elemento Descrizione
    Chal Specifica una sfida di autenticazione. Il server o il client possono inviare una sfida all’altro se non sono state fornite credenziali o credenziali inadeguate nel messaggio di richiesta originale.
    Cmd Specifica il nome di un comando OMA DM a cui fa riferimento un elemento di stato.
    CmdID Specifica l’identificatore univoco per un comando OMA DM.
    CmdRef Specifica l’ID del comando per il quale vengono restituite le informazioni sullo stato o sui risultati. Questo elemento prende il valore dell’elemento CmdID del messaggio di richiesta corrispondente.
    Cred Specifica le credenziali di autenticazione per l’originatore del messaggio.
    Final Indica che il messaggio corrente è l’ultimo messaggio nel pacchetto.
    LocName Specifica il nome visualizzato negli elementi di destinazione e di origine, utilizzati per l’invio di un ID utente per l’autenticazione MD5.
    LocURI Specifica l’indirizzo del percorso di destinazione o di origine. Se l’indirizzo contiene un carattere non alfanumerico, deve essere correttamente escape secondo lo 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 prende il valore dell’elemento request message MsgID.
    RespURI Specifica l’URI che il destinatario deve utilizzare quando invia una risposta a questo messaggio.
    SessionID Specifica l’identificatore della sessione OMA DM associata al messaggio contenente.

    Nota
    Se il server non notifica al dispositivo che supporta una nuova versione (tramite il nodo SyncApplicationVersion nel CSP DMClient), il client restituisce SessionID in integer in formato decimale. Se il server supporta DM session sync versione 2.0, che viene utilizzato in Windows 10, 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 prende il valore dell’elemento di origine del messaggio di richiesta e viene restituito nell’elemento Stato o Risultati.
    Target Specifica l’indirizzo del nodo, nell’albero DM, che è la destinazione del comando OMA DM.
    TargetRef Specifica l’indirizzo di destinazione nel messaggio di richiesta corrispondente. Questo elemento prende il valore dell’elemento di destinazione del messaggio di richiesta e viene restituito nell’elemento Stato o Risultati.
    VerDTD Specifica l’identificatore di versione maggiore e minore della specifica del protocollo di rappresentazione OMA DM utilizzata per rappresentare il messaggio.
    VerProto Specifica l’identificatore di versione maggiore e minore della specifica del protocollo OMA DM utilizzata con il messaggio.

    Sessione di gestione dei dispositivi

    Una sessione di gestione dei dispositivi (DM) consiste in 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 che contengono i risultati e tutte le informazioni di stato richieste.

    Una breve sessione DM può essere riassunta 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 configurazione: 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 nella tabella seguente.
    2. Fase di gestione: Il server DM è in controllo. Invia comandi di gestione al dispositivo e il dispositivo risponde. La fase due termina quando il server DM interrompe l’invio dei comandi e termina la sessione. Questa fase è rappresentata dai passaggi 3, 4 e 5 nella tabella seguente.

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

    1. Il client DM viene richiamato per richiamare lo scenario Enterprise del server di gestione
      : la pianificazione delle attività del dispositivo richiama il client DM.

      Il server MO invia un messaggio di attivazione del server per richiamare il client DM.

      Il messaggio di attivazione include l’ID del server e indica al dispositivo client di avviare una sessione con il server. Il dispositivo client autentica il messaggio di attivazione 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 eseguono l’autenticazione reciproca su un canale SSL o a livello di applicazione DM.

    3. Il server DM risponde, tramite una connessione IP (HTTPS). Il server invia i comandi iniziali di gestione del dispositivo, se presenti.

    4. Il dispositivo risponde ai comandi di gestione del server. Questo messaggio include i risultati dell’esecuzione delle operazioni di gestione del dispositivo 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 passo 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 ulteriori informazioni sul protocollo MSGID e OMA SyncML, vedere OMA Device Management 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 il resto della sessione DM. Nel caso dell’autenticazione MD5, l’elemento Chal può essere restituito. Quindi il prossimo nonce in Chal deve essere usato per il digest MD5 quando viene avviata la prossima sessione DM.

    Se una richiesta include credenziali e il codice di risposta alla richiesta è 200, la stessa credenziale deve essere inviata nella richiesta successiva. Se l’elemento Chal è incluso ed è richiesta l’autenticazione MD5, viene creato un nuovo digest utilizzando il nonce successivo tramite l’elemento Chal per la richiesta successiva.

    Per ulteriori informazioni sull’autenticazione client di base o MD5, sull’autenticazione server MD5, sull’hash MD5 e sul nonce MD5, vedere le specifiche di sicurezza OMA Device Management (OMA-TS-DM_Security-V1_2_1-20080617-A), la gestione del codice di risposta all’autenticazione e gli esempi passo-passo nelle specifiche OMA Device Management Protocol (OMA-TS-DM_Protocol-V1_2_1-20080617-A), disponibile dal sito OMA.

    Utente mirato vs. 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 dell’utente al dispositivo in cui un utente registrato con MDM è attivamente connesso. Il dispositivo notifica al server lo stato di accesso tramite un avviso dispositivo (1224) con tipo di avviso = in DM pkg#1.

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

    • Utente: l’utente che ha registrato il dispositivo è attivamente connesso. Il server MDM potrebbe inviare la configurazione specifica dell’utente per CSP / criteri che supportano la configurazione per utente
    • Altri-un altro utente di accesso, ma che l’utente non dispone di un account MDM. Il server può applicare solo la configurazione a livello di dispositivo, ad esempio, la configurazione si applica a tutti gli utenti nel 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).

    Di seguito è riportato 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 mirata all’utente o al dispositivo mediante un prefisso al LocURL del nodo di gestione, con ./ utente per la configurazione mirata dell’utente, o ./ dispositivo per la configurazione mirata del dispositivo. Per impostazione predefinita, se nessun prefisso con ./ dispositivo o ./ utente, è dispositivo di configurazione mirata.

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

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

    SyncML risposta codici di stato

    Quando si utilizza SyncML in OMA DM, ci sono codici di stato di risposta standard che vengono restituiti. La seguente tabella elenca i codici di stato di risposta SyncML comuni che è probabile che vengano visualizzati. Per ulteriori informazioni sui codici di stato della risposta SyncML, vedere la sezione 10 della specifica del protocollo di rappresentazione SyncML.

    Codice di stato Descrizione
    200 Il comando SyncML è stato completato correttamente.
    202 Accettato per l’elaborazione. Di solito si tratta di un’operazione asincrona, ad esempio una richiesta di eseguire un’esecuzione remota di un’applicazione.
    212 Autenticazione accettata. Normalmente lo vedrai solo in risposta all’elemento SyncHdr (utilizzato per l’autenticazione nello standard OMA-DM). Potresti vederlo se guardi i registri OMA DM, ma i CSP in genere non lo generano.
    214 Operazione annullata. Il comando SyncML è stato completato correttamente, ma non verranno elaborati altri comandi all’interno della sessione.
    215 Non eseguito. Un comando non è stato eseguito come risultato dell’interazione dell’utente per annullare il comando.
    216 Atomic indietro OK. Un comando era all’interno di un elemento Atomic e Atomic non è riuscito. Questo comando è stato eseguito correttamente.
    400 Pessima richiesta. Impossibile eseguire il comando richiesto a causa della sintassi malformata. I CSP di solito non generano questo errore, tuttavia potresti vederlo se il tuo SyncML è malformato.
    401 Credenziali non valide. Il comando richiesto non è riuscito perché il richiedente deve fornire l’autenticazione corretta. I CSP di solito 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 verrà generato se si interroga un nodo che non esiste.
    405 Comando non consentito. Questo codice di risposta verrà generato se si tenta di scrivere su un nodo di sola lettura.
    406 Funzione opzionale non supportata. Questo codice di risposta verrà generato se si tenta di accedere a una proprietà che il CSP non supporta.
    415 Tipo o formato non supportato. Questo codice di risposta può derivare 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 Permesso negato. Il comando richiesto non è riuscito perché il mittente non dispone di autorizzazioni di controllo di accesso adeguate (ACL) sul destinatario. Gli errori” Accesso negato ” di solito vengono tradotti in questo codice di risposta.
    500 Comando non riuscito. Errore generico. Il destinatario ha riscontrato una condizione imprevista che gli ha impedito di soddisfare la richiesta. Questo codice di risposta si verifica quando la DPU SyncML non è in grado di mappare il codice di errore di origine.
    507 Atomic fallito. Una delle operazioni in un blocco Atomic non è riuscita.
    516 Atomic rollback fallito. Operazione Atomic non riuscita e il comando non è stato eseguito correttamente.

    Lascia un commento

    Il tuo indirizzo email non sarà pubblicato.