次の方法で共有


移行フェーズ 5 - 移行後のタスク

AD RMS から Azure Information Protection への移行のフェーズ 5 では、次の情報を使用します。 これらの手順では、 AD RMS から Azure Information Protection への移行の手順 10 ~ 12 について説明します。

手順 10: AD RMS のプロビジョニング解除

Active Directory からサービス接続ポイント (SCP) を削除して、コンピューターがオンプレミスの Rights Management インフラストラクチャを検出できないようにします。 これは、レジストリで構成したリダイレクトのために移行した既存のクライアントでは省略可能です (たとえば、移行スクリプトを実行します)。 ただし、SCP を削除すると、移行が完了したときに新しいクライアントや RMS 関連のサービスやツールが SCP を見つけることができなくなります。 この時点で、すべてのコンピューター接続が Azure Rights Management サービスに接続されます。

SCP を削除するには、ドメインエンタープライズ管理者としてログインしていることを確認し、次の手順を使用します。

  1. Active Directory Rights Management Services コンソールで、AD RMS クラスターを右クリックし、[ プロパティ] をクリックします。

  2. [ SCP ] タブをクリックします。

  3. [ SCP の変更 ] チェック ボックスをオンにします。

  4. [ 現在の SCP の削除] を選択し、[OK] をクリック します

次に、AD RMS サーバーのアクティビティを監視します。 たとえば、 システム正常性レポートServiceRequest テーブル 、または 保護されたコンテンツへのユーザー アクセスを監査する要求を確認します

RMS クライアントがこれらのサーバーと通信しなくなったことを確認し、クライアントが Azure Information Protection を正常に使用していることを確認したら、これらのサーバーから AD RMS サーバーの役割を削除できます。 専用サーバーを使用している場合は、最初にサーバーを一定期間シャットダウンする際の注意が必要になる場合があります。 これにより、クライアントが Azure Information Protection を使用していない理由を調査しながら、サービス継続性のためにこれらのサーバーを再起動する必要がある可能性がある問題が報告されていないことを確認できます。

AD RMS サーバーのプロビジョニングを解除したら、テンプレートとラベルを確認する機会を得ることができます。 たとえば、テンプレートをラベルに変換し、ユーザーが選択する数を減らしたり、再構成したりできるように統合します。 これは、既定のテンプレートを発行する場合にも適しています。

秘密度ラベルと統合ラベル付けクライアントの場合は、Microsoft Purview コンプライアンス ポータルを使用します。 詳細については、Microsoft 365 のドキュメントを参照してください。

Important

この移行の最後に、AD RMS クラスターを Azure Information Protection と Hold Your Own Key (HYOK) オプションと共に使用することはできません。

Office 2010 を実行するコンピューターの追加の構成

Important

Office 2010 延長サポートは、2020 年 10 月 13 日に終了しました。

移行されたクライアントが Office 2010 を実行している場合、AD RMS サーバーのプロビジョニング解除後に、保護されたコンテンツを開くのに遅延が発生する可能性があります。 または、保護されたコンテンツを開く資格情報を持っていないというメッセージがユーザーに表示される場合があります。 これらの問題を解決するには、これらのコンピューターのネットワーク リダイレクトを作成します。これにより、AD RMS URL FQDN がコンピューターのローカル IP アドレス (127.0.0.1) にリダイレクトされます。 これを行うには、各コンピューターでローカル ホスト ファイルを構成するか、DNS を使用します。

  • ローカル ホスト ファイルを使用したリダイレクト: ローカル ホスト ファイルに次の行を追加します。 <AD RMS URL FQDN> は、プレフィックスや Web ページを使用せずに、AD RMS クラスターの値に置き換えます。

    127.0.0.1 <AD RMS URL FQDN>
    
  • DNS 経由のリダイレクト: IP アドレスが 127.0.0.1 の AD RMS URL FQDN の新しいホスト (A) レコードを作成します。

手順 11: クライアント移行タスクを完了する

モバイル デバイス クライアントと Mac コンピューターの場合: AD RMS モバイル デバイス拡張機能を展開したときに作成した DNS SRV レコードを削除します。

これらの DNS 変更が反映されると、これらのクライアントは自動的に検出され、Azure Rights Management サービスの使用が開始されます。 ただし、Office Mac を実行する Mac コンピューターでは、AD RMS から情報がキャッシュされます。 これらのコンピューターの場合、このプロセスには最大 30 日かかることがあります。

Mac コンピューターで検出プロセスをすぐに実行するには、キーチェーンで "adal" を検索し、すべての ADAL エントリを削除します。 次に、これらのコンピューターで次のコマンドを実行します。


rm -r ~/Library/Cache/MSRightsManagement

rm -r ~/Library/Caches/com.microsoft.RMS-XPCService

rm -r ~/Library/Caches/Microsoft\ Rights\ Management\ Services

rm -r ~/Library/Containers/com.microsoft.RMS-XPCService

rm -r ~/Library/Containers/com.microsoft.RMSTestApp

rm ~/Library/Group\ Containers/UBF8T346G9.Office/DRM.plist

killall cfprefsd

既存のすべての Windows コンピューターが Azure Information Protection に移行された場合、オンボード コントロールを引き続き使用し、移行プロセス用に作成した AIPMigrated グループを維持する理由はありません。

最初にオンボード コントロールを削除してから、移行スクリプトをデプロイするために作成した AIPMigrated グループと任意のソフトウェア展開方法を削除できます。

オンボード コントロールを削除するには:

  1. PowerShell セッションで、Azure Rights Management サービスに接続し、メッセージが表示されたら、グローバル管理者の資格情報を指定します。

    Connect-AipService
    
    
  2. 次のコマンドを実行し、「 Y 」と入力して確認します。

    Set-AipServiceOnboardingControlPolicy -UseRmsUserLicense $False
    

    このコマンドは、すべてのコンピューターがドキュメントと電子メールを保護できるように、Azure Rights Management 保護サービスのライセンス適用を削除します。

  3. オンボード コントロールが設定されなくなったことを確認します。

    Get-AipServiceOnboardingControlPolicy
    

    出力では、ライセンスFalse が表示され、SecurityGroupOjbectId の GUID は表示されません

最後に、Office 2010 を使用していて、Windows タスク スケジューラ ライブラリで AD RMS Rights Policy テンプレート管理 (自動) タスクを有効にしている場合は、Azure Information Protection クライアントで使用されていないため、このタスクを無効にします。

通常、このタスクはグループ ポリシーを使用して有効になり、AD RMS の展開をサポートします。 このタスクは、 Microsoft>Windows>Active Directory Rights Management Services クライアントにあります。

Important

Office 2010 延長サポートは、2020 年 10 月 13 日に終了しました。

手順 12: Azure Information Protection テナント キーのキーを更新する

このモードでは 1024 ビット キーと SHA-1 が使用されるため、AD RMS のデプロイで RMS 暗号化モード 1 が使用されていた場合は、移行が完了するときにこの手順が必要です。 この構成は、十分なレベルの保護を提供すると見なされます。 Microsoft は、1024 ビット RSA キーなどの下位のキー長の使用と、SHA-1 などの不適切なレベルの保護を提供するプロトコルの関連する使用を保証していません。

キーを更新すると、RMS 暗号化モード 2 を使用する保護が行われ、2048 ビット キーと SHA-256 が使用されます。

AD RMS の展開で暗号化モード 2 が使用されていた場合でも、新しいキーを使用すると、AD RMS キーへの潜在的なセキュリティ侵害からテナントを保護できるため、この手順を実行することをお勧めします。

Azure Information Protection テナント キー ("キーのローリング" とも呼ばれます) のキーを更新すると、現在アクティブなキーがアーカイブされ、Azure Information Protection は指定した別のキーの使用を開始します。 この異なるキーは、Azure Key Vault で作成する新しいキー、またはテナント用に自動的に作成された既定のキーです。

あるキーから別のキーへの移動はすぐには行われませんが、数週間以上かかります。 これは即時ではないため、元のキーへの侵害が疑われるまで待つ必要はありませんが、移行が完了したらすぐにこの手順を実行してください。

Azure Information Protection テナント キーのキーを更新するには:

  • テナント キーが Microsoft によって管理されている場合: PowerShell コマンドレット Set-AipServiceKeyProperties を実行し、テナント用に自動的に作成されたキーのキー識別子を指定します。 Get-AipServiceKeys コマンドレットを実行して、指定する値を識別できます。 テナントに対して自動的に作成されたキーの作成日は最も古いので、次のコマンドを使用して識別できます。

    (Get-AipServiceKeys) | Sort-Object CreationTime | Select-Object -First 1
    
  • テナント キーが自分で管理されている場合 (BYOK):Azure Key Vault で、Azure Information Protection テナントのキー作成プロセスを繰り返し、 Use-AipServiceKeyVaultKey コマンドレットをもう一度実行して、この新しいキーの URI を指定します。

Azure Information Protection テナント キーの管理の詳細については、「[テナント キーの操作](/purview/rights-management-tenant-key#operations-for-your-tenant-key」を参照してください。

次のステップ

移行が完了したら、 分類、ラベル付け、保護に関する AIP デプロイ ロードマップを 確認して、必要なその他の展開タスクを特定します。