次の方法で共有

フェーズ 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 サービス コンソールで、AD RMS クラスターを右クリックしてから、[プロパティ] をクリックします。

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

  3. SCP の変更 チェックボックスを選択します。

  4. [Remove Current SCP] を選択してから[OK] をクリックします。

次に、AD RMS サーバーのアクティビティを監視します。 たとえば、System Health レポートの要求、ServiceRequest テーブル、または保護されたコンテンツへのユーザー アクセスの監査をチェックします。

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

また、AD RMS サーバーのプロビジョニングを解除した後に、テンプレートとラベルを見直す機会が必要な場合があります。 たとえば、ユーザーが選択または再構成する対象が少なくなるように、テンプレートをラベルに変換して統合する場合です。 これは、既定のテンプレートを発行する絶好のタイミングでもあります。

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

重要

この移行が終わると、Azure Information Protection および Hold Your Own Key (HYOK) オプションで AD RMS クラスターを使うことができなくなります。

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

重要

Office 2010 の延長サポートは、2020 年 10 月 13 日に終了しました。 詳細については、「AIP とレガシ Windows および Officeバージョン」を参照してください。

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

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

    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 サービス クライアント。

重要

Office 2010 の延長サポートは、2020 年 10 月 13 日に終了しました。 詳細については、「AIP とレガシ Windows および Officeバージョン」を参照してください。

ステップ 12: Azure Information Protection テナント キーを更新します。

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

キー更新すると、RMS 暗号化モード 2 を使用した保護が行われ、結果として 2048 ビットのキーと SHA-256 を使用することになります。

AD RMS の展開に Cryptographic モード 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 テナント キーの管理の詳細については、「Azure Information Protection テナント キーの操作」を参照してください。

次のステップ

これで移行は完了です。「分類、ラベル付け、保護のための AIP デプロイ ロードマップ」を参照して、必要に応じて実行するその他のデプロイ タスクがあるか確認してください。