OMA DM プロトコルのサポート
OMA DM クライアントは HTTPS 経由でサーバーと通信し、メッセージ ペイロードとして DM Sync (OMA DM v1.2) を使用します。 この記事では、DM クライアントが一般的にサポートする OMA DM 機能について説明します。 OMA DM プロトコル v1.2 の詳細については、 OMA Web サイトを参照してください。
OMA DM 標準
次の表は、Windows で使用される OMA DM 標準を示しています。
| 一般領域 | サポートされている OMA DM 標準 |
|---|---|
| データ トランスポートとセッション | |
| ブートストラップ XML | OMA クライアント プロビジョニング XML。 |
| DM プロトコル コマンド | 次の一覧は、デバイスで使用されるコマンドを示しています。 OMA DM コマンド要素の詳細については、OMA Web サイトから入手できる 「OMA Web サイト」を参照してください。 有効な OMA DM コマンドではない XML 要素が次のいずれかの要素の下にある場合、その要素の状態コード 400 が返されます。 DM コマンドで CmdID が指定されていない場合、クライアントは status 要素と状態コード 400 で空白を返します。 Atomic 要素が入れ子になっている場合は、次の状態コードが返されます。 Atomic コマンドの詳細については、「OMA DM プロトコルの共通要素」を参照してください。 Atomic 要素内の同じノードで Add コマンドの後に Replace を実行することはサポートされていません。 LocURI は で /始めることはできません。SyncHdr のメタ XML タグは、デバイスによって無視されます。 |
| OMA DM 標準オブジェクト | DevInfo |
| セキュリティ | |
| ノード | OMA DM ツリーでは、ノード名に次の規則が適用されます。*) 文字だけにすることはできません。 |
| プロビジョニング ファイル | プロビジョニング XML は整形式で、 SyncML 表現プロトコルの定義に従う必要があります。 有効な OMA DM コマンドではない XML 要素が SyncBody の下にある場合、その要素の状態コード 400 が返されます。 注 Unicode 文字列を URI として表すには、最初に文字列を UTF-8 としてエンコードします。 次に、URI エンコードを使用して、UTF-8 バイトのそれぞれをエンコードします。 |
| WBXML のサポート | Windows では、XML 形式とエンコードされた WBXML 形式の両方で SyncML の送受信がサポートされています。 このデュアル形式のサポートは、登録時に w7 APPLICATION 特性の下の DEFAULTENCODING ノードを使用して構成できます。 WBXML エンコードの詳細については、 SyncML 表現プロトコル 仕様のセクション 8 を参照してください。 |
| ラージ オブジェクトの処理 | Windows 10では、大きなオブジェクトをサーバーにアップロードするためのクライアント サポートが追加されました。 |
OMA DM プロトコルの一般的な要素
一般的な要素は、他の OMA DM 要素型で使用されます。 次の表に、デバイスの構成に使用される OMA DM の一般的な要素を示します。 OMA DM の一般的な要素の詳細については、OMA Web サイトから入手できる 「SyncML 表現プロトコル デバイス管理使用法」(OMA-SyncML-DMRepPro-V1_1_2-20030613-A) を参照してください。
| 要素 | 説明 |
|---|---|
| Chal | 認証チャレンジを指定します。 サーバーまたはクライアントは、元の要求メッセージに資格情報または不適切な資格情報が指定されていない場合に、もう一方にチャレンジを送信できます。 |
| Cmd | Status 要素で参照される OMA DM コマンドの名前を指定します。 |
| CmdID | OMA DM コマンドの一意識別子を指定します。 |
| CmdRef | 状態または結果の情報が返されるコマンドの ID を指定します。 この要素は、対応する要求メッセージの CmdID 要素の値を受け取ります。 |
| クレド | メッセージの発信元の認証資格情報を指定します。 |
| 最終的な | 現在のメッセージがパッケージの最後のメッセージであることを示します。 |
| LocName | MD5 認証のユーザー ID を送信するために使用される Target 要素と Source 要素の表示名を指定します。 |
| LocURI | ターゲットまたはソースの場所のアドレスを指定します。 アドレスに英数字以外の文字が含まれている場合は、URL エンコード標準に従って適切にエスケープする必要があります。 |
| MsgID | OMA DM セッション メッセージの一意識別子を指定します。 |
| MsgRef | 対応する要求メッセージの ID を指定します。 この要素は、要求メッセージ MsgID 要素の値を受け取ります。 |
| RespURI | このメッセージに応答を送信するときに受信者が使用する必要がある URI を指定します。 |
| Sessionid | 含まれているメッセージに関連付けられている OMA DM セッションの識別子を指定します。 サーバーが新しいバージョンをサポートしていることをデバイスに通知しない場合 (DMClient CSP の SyncApplicationVersion ノードを使用)、クライアントは 10 進形式で SessionID を整数で返します。 サーバーが WINDOWS で使用される DM セッション同期バージョン 2.0 をサポートしている場合、デバイス クライアントは 2 バイトを返します。 |
| Source | メッセージ ソース アドレスを指定します。 |
| SourceRef | 対応する要求メッセージのソースを指定します。 この要素は、要求メッセージ Source 要素の値を受け取り、Status 要素または Results 要素で返されます。 |
| ターゲット | OMA DM コマンドのターゲットである DM ツリー内のノードのアドレスを指定します。 |
| TargetRef | 対応する要求メッセージのターゲット アドレスを指定します。 この要素は、要求メッセージ Target 要素の値を受け取り、Status 要素または Results 要素で返されます。 |
| VerDTD | メッセージを表すために使用される OMA DM 表現プロトコル仕様のメジャー バージョン識別子とマイナー バージョン識別子を指定します。 |
| VerProto | メッセージと共に使用される OMA DM プロトコル仕様のメジャー バージョン識別子とマイナー バージョン識別子を指定します。 |
デバイス管理セッション
デバイス管理 (DM) セッションは、DM サーバーとクライアント デバイスの間で交換される一連のコマンドで構成されます。 サーバーは、クライアント デバイスの管理ツリーで実行する必要がある操作を示すコマンドを送信します。 クライアントは、結果と要求された状態情報を含むコマンドを送信することで応答します。
短い DM セッションは、次のように要約できます。
サーバーは Get コマンドをクライアント デバイスに送信して、管理ツリーのいずれかのノードの内容を取得します。 デバイスは操作を実行し、要求された内容を含む Result コマンドで応答します。
DM セッションは、次の 2 つのフェーズに分けることができます。
- セットアップ フェーズ: トリガー イベントに応答して、クライアント デバイスは開始メッセージを DM サーバーに送信します。 デバイスとサーバーの交換には、認証とデバイス情報が必要でした。 このフェーズは、手順 1、2、および 3 で表されます。
- 管理フェーズ: DM サーバーが制御されています。 管理コマンドがデバイスに送信され、デバイスが応答します。 フェーズ 2 は、DM サーバーがコマンドの送信を停止し、セッションを終了すると終了します。 このフェーズは、手順 3、4、および 5 で表されます。
次の情報は、一般的な DM セッション中のイベントのシーケンスを示しています。
DM クライアントを呼び出して管理サーバーにコールバックする
エンタープライズ シナリオ - デバイス タスク スケジュールによって DM クライアントが呼び出されます。MO サーバーは、DM クライアントを呼び出すサーバー トリガー メッセージを送信します。
トリガー メッセージにはサーバー ID が含まれており、クライアント デバイスにサーバーとのセッションを開始するように指示します。 クライアント デバイスは、トリガー メッセージを認証し、サーバーと通信する権限があることを確認します。
エンタープライズ シナリオ - スケジュールされた時刻に、DM クライアントが定期的に呼び出され、HTTPS 経由でエンタープライズ管理サーバーにコールバックされます。デバイスは、IP 接続経由でメッセージを送信してセッションを開始します。
このメッセージには、デバイス情報と資格情報が含まれます。 クライアントとサーバーは、TLS/SSL チャネルまたは DM アプリケーション レベルで相互認証を行います。
DM サーバーは、IP 接続 (HTTPS) 経由で応答します。 サーバーは、初期デバイス管理コマンド (存在する場合) を送信します。
デバイスはサーバー管理コマンドに応答します。 このメッセージには、指定したデバイス管理操作を実行した結果が含まれます。
DM サーバーはセッションを終了するか、別のコマンドを送信します。 DM セッションが終了するか、手順 4 が繰り返されます。
ステップ番号はメッセージ識別番号 (MsgID) を表しません。 サーバーからのすべてのメッセージには、セッション内で一意の MsgID が必要です。最初のメッセージの場合は 1 から始まり、余分なメッセージごとに 1 ずつ増加します。 MsgID および OMA SyncML プロトコルの詳細については、「OMA デバイス管理 表現プロトコル (DM_RepPro-V1_2-20070209-A)」を参照してください。
OMA DM アプリケーション レベルの相互認証中に、サーバー要求の Cred 要素に対するデバイス応答コードが 212 の場合、DM セッションの残りの部分に対してそれ以上の認証は必要ありません。 MD5 認証が発生した場合は、 要素を Chal 返すことができます。 次に、次の DM セッションが開始されるときに、次の nonce Chal を MD5 ダイジェストに使用する必要があります。
要求に資格情報が含まれており、要求への応答コードが 200 の場合は、次の要求内で同じ資格情報を送信する必要があります。 要素が Chal 含まれており、MD5 認証が必要な場合は、次の要求に要素を介して次の nonce を使用して新しいダイジェストが Chal 作成されます。
Basic または MD5 クライアント認証、MD5 サーバー認証の詳細については、 MD5 ハッシュと MD5 nonce は、OMA Web サイトから入手できる OMA デバイス管理 セキュリティ仕様 (OMA-TS-DM_Security-V1_2_1-20080617-A)、認証応答コード処理、および OMA デバイス管理 プロトコル仕様 (OMA-TS-DM_Protocol-V1_2_1-20080617-A) を参照してください。
ユーザーターゲット構成とデバイスターゲット構成
ユーザーごとの構成をサポートする CSP とポリシーの場合、MDM サーバーは、MDM に登録されたユーザーがアクティブにログインしているデバイスに、ユーザー対象の設定値を送信できます。 デバイスは、DM pkg#1 のアラートの種類 = を使用して、デバイス アラート (1224) を介してサインイン状態をサーバーに通知します。
このアラートのデータ部分は、次のいずれかの文字列である可能性があります。
- ユーザー: デバイスを登録したユーザーがアクティブにログインしています。 MDM サーバーは、ユーザーごとの構成をサポートする CSP/ポリシーのユーザー固有の構成を送信できます
- その他: 別のユーザーがサインインしますが、そのユーザーに MDM アカウントがありません。 サーバーはデバイス全体の構成のみを適用できます。たとえば、構成はデバイス内のすべてのユーザーに適用されます。
- なし: アクティブなユーザー サインインなし。 サーバーはデバイス全体の構成のみを適用でき、使用可能な構成はデバイス環境に制限されます (アクティブなユーザー サインインはありません)。
アラートの例を次に示します。
<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>
サーバーは、管理ノードの LocURL ./user./device のプレフィックスによって、ユーザーターゲット構成かデバイスターゲット構成かをデバイスに通知します。 既定では、 または ./userのプレフィックス./deviceがない場合は、デバイスターゲットの構成です。
次の LocURL は、ユーザーごとの CSP ノード構成を示しています。 ./user/vendor/MSFT/EnterpriseModernAppManagement/AppInstallation/<PackageFamilyName>/StoreInstall
次の LocURL は、デバイスごとの CSP ノード構成を示しています。 ./device/vendor/MSFT/RemoteWipe/DoWipe
SyncML 応答の状態コード
OMA DM で SyncML を使用する場合、返される標準応答状態コードがあります。 次の表に、表示される可能性がある一般的な SyncML 応答状態コードの一覧を示します。 SyncML 応答状態コードの詳細については、 SyncML 表現プロトコル の仕様のセクション 10 を参照してください。
| 状態コード | 説明 |
|---|---|
| 200 | SyncML コマンドが正常に完了しました。 |
| 202 | 処理に使用できます。 このコードは、アプリケーションのリモート実行を実行する要求など、非同期操作を表します。 |
| 212 | 認証が受け入れられます。 通常、このコードは SyncHdr 要素 (OMA-DM 標準での認証に使用) に応答する場合にのみ表示されます。 OMA DM ログを確認すると、このコードが表示されることがありますが、CSP では通常、このコードは生成されません。 |
| 214 | 操作が取り消されました。 SyncML コマンドは正常に完了しましたが、セッション内ではそれ以上のコマンドは処理されません。 |
| 215 | 実行されません。 コマンドを取り消すユーザー操作の結果、コマンドが実行されませんでした。 |
| 216 | Atomic ロールバック OK。 コマンドが要素内にあり Atomic 、 Atomic 失敗しました。 このコマンドは正常にロールバックされました。 |
| 400 | 要求が正しくありません。 構文の形式が正しくないため、要求されたコマンドを実行できませんでした。 CSP では通常、このエラーは生成されませんが、SyncML の形式が正しくない場合に表示される場合があります。 |
| 401 | 資格情報が無効です。 要求者が適切な認証を提供する必要があるため、要求されたコマンドが失敗しました。 CSP は通常、このエラーを生成しません。 |
| 403 | 禁止。 要求されたコマンドは失敗しましたが、受信者は要求されたコマンドを理解しました。 |
| 404 | 見つかりません。 要求されたターゲットが見つかりませんでした。 このコードは、存在しないノードに対してクエリを実行すると生成されます。 |
| 405 | コマンドは許可されていません。 この応答コードは、読み取り専用ノードに書き込もうとすると生成されます。 |
| 406 | オプション機能はサポートされていません。 この応答コードは、CSP がサポートしていないプロパティにアクセスしようとすると生成されます。 |
| 415 | サポートされていない型または形式。 この応答コードは、XML 解析または書式設定エラーの結果として発生する可能性があります。 |
| 418 | 既に存在します。 この応答コードは、既に存在するノードを追加しようとすると発生します。 |
| 425 | アクセス許可が拒否されました。 送信者が受信者に対して適切なアクセス制御アクセス許可 (ACL) を持っていないため、要求されたコマンドが失敗しました。 "アクセスが拒否されました" エラーは、通常、この応答コードに変換されます。 |
| 500 | コマンドが失敗しました。 一般的なエラー。 受信者が予期しない条件を検出したため、要求を満たさなくなります。 この応答コードは、SyncML DPU が発生元のエラー コードをマップできない場合に発生します。 |
| 507 | Atomic 失敗 しました。 ブロック内のいずれかの操作が Atomic 失敗しました。 |
| 516 | Atomic ロールバックに失敗しました。 Atomic操作が失敗し、コマンドが正常にロールバックされませんでした。 |
関連記事
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示