宣言型管理の宣言とステータスチャネルは、MDMのコマンドやプロファイルと共存できます。これは、すべてのMDMワークフローを一度に更新することなく、新しい機能を段階的に採用できることを意味します。例えば、サーバはステータスサブスクリプションを実装するだけで、すべての宣言型管理を採用する必要なく、MDMプロトコルにステータスチャネルを効果的に追加できます。
重要なことは、この統合によって既存のMDMの動作が妨げられないことです。宣言型管理の機能を使用するには、新しいMDMコマンドを使用して、宣言型管理を明示的に有効にする必要があります。有効にしない場合、MDMプロトコルは以前とまったく同じように機能します。
サーバが通常のMDMコマンド処理フローに従って、Declarativeをデバイスに送信することにより、宣言型管理が有効になります。このコマンドには、次の2つの目的があります。
宣言型管理機能を有効にします。
サーバが宣言を更新しており、デバイスが宣言をサーバと同期する必要があることをデバイスに通知します。この場合、コマンドに同期トークンを含むペイロードを含めて、効率的な同期フローを実現できます。
MDMで宣言型管理を有効にすると、無効にすることはできません。ただし、サーバがデバイスからすべての宣言を削除することにより、宣言型管理の動作を事実上無効にすることができます。
デバイスの登録を解除した場合、デバイスは、宣言を通じて適用されたすべてのポリシーを含む、すべての宣言型管理状態を削除します。
macOSと共有iPadでは、デバイスチャネルとユーザーチャネルで別々に管理コマンドを送信して、各チャネルで宣言型管理を有効にする必要があります。同様に、各チャネルは宣言型管理ステータスを個別に報告します。
以下の手順に従って、宣言を同期します。
サーバからMDMプッシュ通知をデバイスに送信します。
デバイスは通常の方法で、サーバに次のMDMコマンドを要求することにより、MDMプッシュに応答します。
サーバは、Declarativeを使用して応答します。このコマンドには、Synchronization JSONデータが含まれている必要があります。
デバイスは、サーバのコマンドで送信されたSync内のDeclarationsをチェックします。
デバイスがサーバから宣言マニフェストを取得します。
デバイスが変更を同期します。
以下のセクションでは、同期の手順4〜6について詳しく説明します。
サーバは、宣言の現在の状態を表すトークンを保持して、特定のデバイスと同期します。デバイスやユーザーによって宣言が異なる場合があるため、サーバはデバイスごとおよびユーザーごとにこのトークンを保持する必要があります。宣言のセットが変更される（新しい宣言が追加されるか、既存の宣言が変更または削除される）たびに、サーバはトークンの値を変更する必要があります。トークン値は、クライアントが比較の時に使用する不透明型の文字列であるため、サーバは任意の形式を自由に使用できますが、サイズを256オクテット以下に制限する必要があります。
サーバは、コマンドのDataキーに含まれるDeclarations項目としてトークンをデバイスに送信できます。また、サーバは、適用する宣言セットのデータとともに、サーバの宣言マニフェストレスポンスでトークンをデバイスに送信します。
クライアントは、サーバの宣言マニフェストを処理する際、サーバから送信された宣言トークンを保持します。デバイスはこの値に基づいて、宣言マニフェストを更新する必要があるかどうかを判断します。デバイスは、Declarativeコマンドを受け取ると、同期動作をトリガします。同期動作では、次のルールを使用して、実行する手順が決定されます。
DeclarativeにDataキーが含まれていない場合、デバイスはDeclarative Management Checkinのtokens Endpointリクエストを使用して、サーバから現在の同期トークンセットを取得します。そのあと、サーバの応答から抽出されたDeclarationsキーを使用します。
DeclarativeにDataキーが含まれている場合、デバイスはDeclarationsの値を抽出します。
デバイスは、新しい宣言トークンを、サーバから前回受信した宣言トークンと比較します。
新しいトークンと既存のトークンが一致する場合、デバイスは、前回の同期以降にサーバ上の宣言が変更されていないと見なし、現在の同期動作は終了します。
新しいトークンと既存のトークンが一致しない場合、デバイスは同期動作を続行し、Declarative Management Checkinのdeclaration-items Endpointリクエストを使用して、宣言マニフェストをサーバから取得します。宣言マニフェストは、各宣言のタイプのキーを含むJSONオブジェクトです。キーの値は、宣言項目記述子の配列です。これらの記述子には、デバイスが同期する各宣言に対するIdentifierおよびServerTokenの値が含まれています。
デバイスは、宣言マニフェストに含まれている宣言項目に基づいて、次のロジックで状態をサーバと同期させます。
宣言マニフェストに含まれている宣言項目のIdentifierが、デバイス上に存在するどの宣言のIdentifierとも一致しない場合、デバイスはその宣言を新しい宣言と見なし、Declarative Management Checkinのdeclaration Endpointリクエストを使用して、その宣言を取得します。
宣言マニフェストに含まれている宣言項目のIdentifierが、デバイス上に存在するある宣言のIdentifierと一致し、Server項目が一致しない場合、デバイスはその宣言を更新された宣言と見なし、Declarative Management Checkinのdeclaration Endpointリクエストを使用して、その宣言を取得します。
宣言マニフェスト全体を処理したあと、デバイス上に存在する宣言の中にIdentifierが宣言マニフェストに含まれていないものがある場合、デバイスはそれらの宣言を削除対象としてマークします。
宣言マニフェストを処理し、新しい宣言または変更された宣言を取得したあと、デバイスは、削除対象としてマークしたすべての宣言を削除します。さらに、状態を更新するために、新しい宣言と変更された宣言を適用し、削除した宣言の適用を解除します。
一部のアセット宣言には、Referenceが含まれています。これにはDataが含まれており、対応するアセットデータが存在するURLが指定されます。デバイスは、このURLをMDMサーバでホストされているものとして扱い、通常のMDMプロトコル規則をリクエストに適用します。Referenceキーには追加のキーがあり、システムはそれらのキーを使用して、ダウンロードされたアセットデータの整合性を検証します。データを取得して検証するデバイス手順は、次の通りです。
デバイスが、MDMデバイスID証明書に設定されたクライアント証明書を使用して、TLS接続を確立します。
デバイスが、MDM登録プロファイルペイロードで指定されたCheckを使用して信頼性を評価することにより、TLS接続サーバ証明書を検証します。この場合、デバイスは、MDM登録プロファイルペイロードで指定されたPinningに従います。
デバイスが、HTTPレスポンスのContent-Typeヘッダに、アセットのReferenceにあるContentの値と一致するメディアタイプが指定されていることを確認します。メディアタイプの値が一致しない場合、アセットデータのダウンロードは失敗します。
デバイスが、ダウンロードしたデータのバイト単位でのサイズがアセットのReferenceにあるSizeの値と一致しているかどうかを確認します。サイズが一致しない場合、アセットデータのダウンロードは失敗します。
デバイスが、ダウンロードしたデータのSHA-256ハッシュがアセットのReferenceにあるHash-SHA-256キーの値と一致しているかどうかを確認します。ハッシュ値が一致しない場合、アセットデータのダウンロードは失敗します。
comおよびcomの両方の構成に、対応するプロファイルデータが存在する場所のURLを指定するProfileキーが含まれています。デバイスは、このURLをMDMサーバでホストされているものと見なし、通常のMDMプロトコル規則をリクエストに適用します。特に次の点に注意してください。
デバイスが、MDMデバイスID証明書に設定されたクライアント証明書を使用して、TLS接続を確立します。
デバイスが、MDM登録プロファイルペイロードで指定されたCheckを使用して信頼性を評価することにより、TLS接続サーバ証明書を検証します。この場合、デバイスは、MDM登録プロファイルペイロードで指定されたPinningに従います。