移行フェーズ 2 - AD RMS のサーバー側の構成Migration phase 2 - server-side configuration for AD RMS

適用対象: Active Directory Rights Management サービス、Azure Information ProtectionOffice 365Applies to: Active Directory Rights Management Services, Azure Information Protection, Office 365

AD RMS から Azure Information Protection への移行フェーズ 2 では、次の情報を使用してください。Use the following information for Phase 2 of migrating from AD RMS to Azure Information Protection. これらの手順では、「AD RMS から Azure Information Protection への移行」の手順 4 から手順 6 を説明します。These procedures cover steps 4 though 6 from Migrating from AD RMS to Azure Information Protection.

手順 4.Step 4. AD RMS から構成データをエクスポートし、それを Azure Information Protection にインポートするExport configuration data from AD RMS and import it to Azure Information Protection

この手順は、2 段階の処理です。This step is a two-part process:

  1. 信頼された発行ドメイン (TPD) を .xml ファイルにエクスポートすることによって、AD RMS から構成データをエクスポートします。Export the configuration data from AD RMS by exporting the trusted publishing domains (TPDs) to an .xml file. このプロセスは、すべての移行について同じです。This process is the same for all migrations.

  2. 構成データを Azure Information Protection にインポートします。Import the configuration data to Azure Information Protection. 現在の AD RMS のデプロイ構成と、Azure RMS テナント キーに対する優先トポロジに応じて、この手順のプロセスは異なります。There are different processes for this step, depending on your current AD RMS deployment configuration and your preferred topology for your Azure RMS tenant key.

構成データを AD RMS からエクスポートするExport the configuration data from AD RMS

すべての AD RMS クラスター上の、組織のコンテンツを保護していたすべての信頼された発行ドメインに対して、次の手順を実行します。Do the following procedure on all AD RMS clusters, for all trusted publishing domains that have protected content for your organization. ライセンス専用クラスターでこの手順を実行する必要はありません。You do not need to run this procedure on licensing-only clusters.

構成データ (信頼された発行ドメインの情報) をエクスポートするにはTo export the configuration data (trusted publishing domain information)

  1. AD RMS の管理権限を持つユーザーとして AD RMS クラスターにログオンします。Log on the AD RMS cluster as a user with AD RMS administration permissions.

  2. AD RMS 管理コンソール (Active Directory Rights Management サービス) から、AD RMS クラスター名を展開し、 [信頼ポリシー] を展開し、 [信頼された発行ドメイン] をクリックします。From the AD RMS management console (Active Directory Rights Management Services), expand the AD RMS cluster name, expand Trust Policies, and then click Trusted Publishing Domains.

  3. 結果ウィンドウで信頼された発行ドメインを選択し、操作ウィンドウから [信頼された発行ドメインのエクスポート] をクリックします。In the results pane, select the trusted publishing domain, and then, from the Actions pane, click Export Trusted Publishing Domain.

  4. [信頼された発行ドメインのエクスポート] ダイアログ ボックスで:In the Export Trusted Publishing Domain dialog box:

    • [名前を付けて保存] をクリックし、パスとファイル名を指定して保存します。Click Save As and save to path and a file name of your choice. ファイル名の拡張子としては必ず .xml を指定します (自動的には付加されません)。Make sure to specify .xml as the file name extension (this is not appended automatically).

    • 強いパスワードを指定して確認します。Specify and confirm a strong password. このパスワードを覚えておいてください。後で、構成データを Azure Information Protection にインポートするときに必要になります。Remember this password, because you will need it later, when you import the configuration data to Azure Information Protection.

    • 信頼されたドメイン ファイルを RMS バージョン 1.0 で保存するチェック ボックスをオンにしないでください。Do not select the checkbox to save the trusted domain file in RMS version 1.0.

信頼された発行ドメインをすべてエクスポートしたら、このデータを Azure Information Protection にインポートする手順を開始できます。When you have exported all the trusted publishing domains, you’re ready to start the procedure to import this data to Azure Information Protection.

信頼された発行ドメインには、保護済みのファイルの暗号化を解除するサーバー ライセンス証明書 (SLC) キーが含まれているため、現在アクティブな信頼された発行ドメインだけではなく、すべての信頼された発行ドメインをエクスポートすること (そして後で Azure にインポートすること) が重要です。Note that the trusted publishing domains include the Server Licensor Certificate (SLC) keys to decrypt previously protected files, so it's important that you export (and later import into Azure) all the trusted publishing domains and not just the currently active one.

たとえば、暗号化モード 1 から暗号化モード 2 に AD RMS サーバーをアップグレードする場合、信頼された発行ドメインが複数になります。For example, you will have multiple trusted publishing domains if you upgraded your AD RMS servers from Cryptographic Mode 1 to Cryptographic Mode 2. 移行の最後に、暗号化モード 1 を使用してアーカイブされたキーを含む信頼された発行ドメインをエクスポートおよびインポートしない場合、ユーザーは暗号化モード 1 キーで保護されていたコンテンツを開けなくなります。If you do not export and import the trusted publishing domain that contains your archived key that used Cryptographic Mode 1, at the end of the migration, users will not be able to open content that was protected with the Cryptographic Mode 1 key.

構成データを Azure Information Protection にインポートするImport the configuration data to Azure Information Protection

正確な手順は、現在の AD RMS のデプロイ構成と、Azure Information Protection テナント キーの優先トポロジによって異なります。The exact procedures for this step depend on your current AD RMS deployment configuration, and your preferred topology for your Azure Information Protection tenant key.

現在の AD RMS のデプロイでは、次のいずれかの構成をサーバー ライセンス証明書 (SLC) キーに使用します。Your current AD RMS deployment is using one of the following configurations for your server licensor certificate (SLC) key:

  • AD RMS データベースでのパスワード保護。Password protection in the AD RMS database. これが既定の構成です。This is the default configuration.

  • NCipher ハードウェアセキュリティモジュール (HSM) を使用した HSM 保護。HSM protection by using a nCipher hardware security module (HSM).

  • NCipher 以外のサプライヤーのハードウェアセキュリティモジュール (HSM) を使用した HSM 保護。HSM protection by using a hardware security module (HSM) from a supplier other than nCipher.

  • 外部暗号プロバイダーを使用して保護されたパスワード。Password protected by using an external cryptographic provider.

注意

AD RMS でのハードウェア セキュリティ モジュールの使用に関する詳細については、「 AD RMS でのハードウェア セキュリティ モジュールの使用」を参照してください。For more information about using hardware security modules with AD RMS, see Using AD RMS with Hardware Security Modules.

Azure Information Protection テナント キー トポロジには、テナント キーを Microsoft が管理するか (マイクロソフト管理) または Azure Key Vault でユーザーが自分で管理するか (顧客管理) の 2 つのオプションがあります。The two Azure Information Protection tenant key topology options are: Microsoft manages your tenant key (Microsoft-managed) or you manage your tenant key (customer-managed) in Azure Key Vault. 独自の Azure Information Protection テナント キーを管理する場合は、“Bring Your Own Key” (BYOK) と呼ばれることもあります。When you manage your own Azure Information Protection tenant key, it’s sometimes referred to as “bring your own key” (BYOK). 詳細については、「Azure Information Protection テナント キーを計画して実装する」を参照してください。For more information, see Planning and implementing your Azure Information Protection tenant key article.

次の表を参考にして、移行に使用する手順を識別してください。Use the following table to identify which procedure to use for your migration.

現在の AD RMS のデプロイCurrent AD RMS deployment 選択した Azure Information Protection テナント キーのトポロジChosen Azure Information Protection tenant key topology 移行手順Migration instructions
AD RMS データベースでのパスワード保護Password protection in the AD RMS database マイクロソフト管理Microsoft-managed 後で説明される「ソフトウェアで保護されたキーからソフトウェアで保護されたキーへの移行」の手順を参照してください。See the Software-protected key to software-protected key migration procedure after this table.

これは最も簡単な移行パスであり、Azure Information Protection に構成データを転送するだけで済みます。This is the simplest migration path and requires only that you transfer your configuration data to Azure Information Protection.
NCipher nShield ハードウェアセキュリティモジュール (HSM) を使用した HSM 保護HSM protection by using a nCipher nShield hardware security module (HSM) お客様が管理 (BYOK)Customer-managed (BYOK) 後で説明される「HSM で保護されたキーから HSM で保護されたキーへの移行」の手順を参照してください。See the HSM-protected key to HSM-protected key migration procedure after this table.

Azure Key Vault の BYOK ツールセットが必要であり、3 つの一連の手順を実行する必要があります。最初にオンプレミスの HSM から Azure Key Vault の HSM にキーを転送し、次に Azure Information Protection からの Azure Rights Management サービスがテナント キーを使用するのを承認し、最後に構成データを Azure Information Protection に転送します。This requires the Azure Key Vault BYOK toolset and three sets of steps to first transfer the key from your on-premises HSM to the Azure Key Vault HSMs, then authorize the Azure Rights Management service from Azure Information Protection to use your tenant key, and finally to transfer your configuration data to Azure Information Protection.
AD RMS データベースでのパスワード保護Password protection in the AD RMS database お客様が管理 (BYOK)Customer-managed (BYOK) 後で説明される「ソフトウェアで保護されたキーから HSM で保護されたキーへの移行」の手順を参照してください。See the Software-protected key to HSM-protected key migration procedure after this table.

Azure Key Vault の BYOK ツールセットが必要であり、一連の 4 つの手順を実行する必要があります。最初にソフトウェア キーを抽出してオンプレミスの HSM にインポートし、次にオンプレミスの HSM から Azure Information Protection HSM にキーを転送し、さらに Key Vault データを Azure Information Protection に転送して、最後に構成データを Azure Information Protection に転送します。This requires the Azure Key Vault BYOK toolset and four sets of steps to first extract your software key and import it to an on-premises HSM, then transfer the key from your on-premises HSM to the Azure Information Protection HSMs, next transfer your Key Vault data to Azure Information Protection, and finally to transfer your configuration data to Azure Information Protection.
NCipher 以外のサプライヤーのハードウェアセキュリティモジュール (HSM) を使用した HSM 保護HSM protection by using a hardware security module (HSM) from a supplier other than nCipher お客様が管理 (BYOK)Customer-managed (BYOK) この HSM から nCipher nShield ハードウェアセキュリティモジュール (HSM) にキーを転送する方法については、HSM のサプライヤーに問い合わせてください。Contact the supplier for your HSM for instructions how to transfer your key from this HSM to a nCipher nShield hardware security module (HSM). 後で説明される「HSM で保護されたキーから HSM で保護されたキーへの移行」の手順に従います。Then follow the instructions for the HSM-protected key to HSM-protected key migration procedure after this table.
外部暗号プロバイダーを使用して保護されたパスワードPassword protected by using an external cryptographic provider お客様が管理 (BYOK)Customer-managed (BYOK) NCipher nShield ハードウェアセキュリティモジュール (HSM) にキーを転送する方法については、暗号化サービスプロバイダーの供給元にお問い合わせください。Contact the supplier for your cryptographic provider for instructions how to transfer your key to a nCipher nShield hardware security module (HSM). 後で説明される「HSM で保護されたキーから HSM で保護されたキーへの移行」の手順に従います。Then follow the instructions for the HSM-protected key to HSM-protected key migration procedure after this table.

エクスポートできない HSM で保護されたキーがある場合でも、読み取り専用モード用に AD RMS クラスターを構成することで、Azure Information Protection に移行できます。If you have an HSM-protected key that you cannot export, you can still migrate to Azure Information Protection by configuring your AD RMS cluster for a read-only mode. このモードでは、以前に保護されたコンテンツを引き続き開くことはできますが、新たに保護されたコンテンツでは、ユーザー (BYOK) または Microsoft によって管理されている新しいテナント キーが使用されます。In this mode, previously protected content can still be opened but newly protected content uses a new tenant key that is managed by you (BYOK) or managed by Microsoft. 詳細については、「AD RMS から Azure RMS への移行がサポートされている Office の更新プログラムが利用可能になりました」を参照してください。For more information, see An update is available for Office to support migrations from AD RMS to Azure RMS.

これらのキーの移行手順を開始する前に、信頼された発行ドメインをエクスポートしたときに作成した .xml ファイルにアクセスできることを確認します。Before you start these key migration procedures, make sure that you can access the .xml files that you created earlier when you exported the trusted publishing domains. たとえば、これらは、AD RMS サーバーからインターネットに接続されたワークステーションに移動する USB ドライブに保存される場合があります。For example, these might be saved to a USB thumb drive that you move from the AD RMS server to the internet-connected workstation.

注意

ただし、このデータは秘密キーを含むので、これらのファイルを保存し、セキュリティのベスト プラクティスを使用して保護します。However you store these files, use security best practices to protect them because this data includes your private key.

手順 4 を完了するには、移行パスに応じた手順を選択します。To complete Step 4, choose and select the instructions for your migration path:

手順 5.Step 5. Azure Rights Management サービスをアクティブにするActivate the Azure Rights Management service

PowerShell セッションを開き、次のコマンドを実行します。Open a PowerShell session and run the following commands:

  1. Azure Rights Management サービスに接続し、メッセージが表示されたら、グローバル管理者の資格情報を指定します。Connect to the Azure Rights Management service and when prompted, specify your global admin credentials:

     Connect-AipService
    
  2. Azure Rights Management サービスをアクティブにします。Activate the Azure Rights Management service:

     Enable-AipService
    

Azure Information Protection テナントが既にアクティブになっている場合はどうすればよいですか。What if your Azure Information Protection tenant is already activated? Azure Rights Management サービスが組織で既にアクティブ化されていて、移行後に使用するカスタム テンプレートを作成済みである場合は、そのテンプレートをエクスポートしてからインポートする必要があります。If the Azure Rights Management service is already activated for your organization, and you have created custom templates that you want to use after the migration, you must export and import these templates. これについては次の手順で説明します。This procedure is covered in the next step.

手順 6.Step 6. インポートされたテンプレートを構成するConfigure imported templates

インポートしたテンプレートは アーカイブ済みという既定の状態なので、ユーザーが Azure Rights Management サービスでこれらのテンプレートを使用できるようにする場合は、この状態を 公開済み に変更する必要があります。Because the templates that you imported have a default state of Archived, you must change this state to be Published if you want users to be able to use these templates with the Azure Rights Management service.

AD RMS からインポートしたテンプレートの外観と動作は、Azure Portal で作成するカスタム テンプレートと同じです。Templates that you import from AD RMS look and behave just like custom templates that you can create in the Azure portal. インポートしたテンプレートを公開に変更し、ユーザーがアプリケーションからそれらを表示して選択できるようにする方法は、「Azure Information Protection のテンプレートを構成して管理する」を参照してください。To change imported templates to be published so that users can see them and select them from applications, see Configuring and managing templates for Azure Information Protection.

新しくインポートしたテンプレートを公開するだけでなく、移行を続ける前に行う必要があるテンプレートの重要な変更が 2 つあります。In addition to publishing your newly imported templates, there are just two important changes for the templates that you might need to make before you continue with the migration. 移行プロセス中のユーザーに対するエクスペリエンスを一貫したものにするため、インポートしたテンプレートに変更を加えないでください。また、Azure Information Protection に付属する 2 つの既定のテンプレートを公開したり、この時点で新しいテンプレートを作成したりしないでください。For a more consistent experience for users during the migration process, do not make additional changes to the imported templates and do not publish the two default templates that come with Azure Information Protection, or create new templates at this time. 代わりに、移行プロセスが完了するまで待ち、AD RMS サーバーをプロビジョニング解除します。Instead, wait until the migration process is complete and you have deprovisioned the AD RMS servers.

この手順で必要な場合があるテンプレートの変更:The template changes that you might need to make for this step:

  • 移行前に Azure Information Protection カスタム テンプレートを作成した場合は、手動でエクスポートしてインポートする必要があります。If you created Azure Information Protection custom templates before the migration, you must manually export and import them.

  • AD RMS のテンプレートで ANYONE グループが使用されていた場合、ユーザーまたはグループを手動で追加することが必要になる場合があります。If your templates in AD RMS used the ANYONE group, you might need to manually add users or groups.

    AD RMS では、ANYONE グループはオンプレミスの Active Directory によって認証されたすべてのユーザーに権限を付与します。また、このグループは Azure Information Protection ではサポートされていません。In AD RMS, the ANYONE group granted rights to all users authenticated by your on-premises Active Directory, and this group is not supported by Azure Information Protection. 最も近いのは、Azure AD テナント内のすべてのユーザーに対して自動的に作成されるグループです。The closet equivalent is a group that's automatically created for all users in your Azure AD tenant. AD RMS テンプレートに対して ANYONE グループを使用していた場合、ユーザーおよびそのユーザーに付与したい権限を追加することが必要になる場合があります。If you were using the ANYONE group for your AD RMS templates, you might need to add users and the rights that you want to grant them.

移行前にカスタム テンプレートを作成した場合の手順Procedure if you created custom templates before the migration

Azure Rights Management サービスをアクティブ化する前でも後でも、移行前にカスタム テンプレートを作成した場合は、公開済みに設定してあっても、移行後にユーザーはテンプレートを使用できません。If you created custom templates before the migration, either before or after activating the Azure Rights Management service, templates will not be available to users after the migration, even if they were set to Published. ユーザーが使用できるようにするには、最初に次のようにする必要があります。To make them available to users, you must first do the following:

  1. Get AipServiceTemplateを実行して、これらのテンプレートを特定し、テンプレート ID をメモしておきます。Identify these templates and make a note of their template ID, by running the Get-AipServiceTemplate.

  2. Azure RMS PowerShell コマンドレットのexport-AipServiceTemplateを使用して、テンプレートをエクスポートします。Export the templates by using the Azure RMS PowerShell cmdlet, Export-AipServiceTemplate.

  3. Azure RMS PowerShell コマンドレットを使用して、テンプレートをインポートします。Import the templates by using the Azure RMS PowerShell cmdlet, Import-AipServiceTemplate.

その後は、移行後に作成した他のテンプレートと同様に、これらのテンプレートを発行したりアーカイブしたりできます。You can then publish or archive these templates as you would any other template that you create after the migration.

AD RMS のテンプレートが ANYONE グループを使用していた場合の手順Procedure if your templates in AD RMS used the ANYONE group

AD RMS のテンプレートで ANYONE グループが使用されていた場合、Azure Information Protection 内の最も近いグループは AllStaff-7184AB3F-CCD1-46F3-8233-3E09E9CF0E66@<tenant_name>.onmicrosoft.com という名前です。If your templates in AD RMS used the ANYONE group, the closest equivalent group in Azure Information Protection is named AllStaff-7184AB3F-CCD1-46F3-8233-3E09E9CF0E66@<tenant_name>.onmicrosoft.com. たとえば、Contoso の場合、このグループは AllStaff-7184AB3F-CCD1-46F3-8233-3E09E9CF0E66@contoso.onmicrosoft.com のようになります。For example, this group might look like the following for Contoso: AllStaff-7184AB3F-CCD1-46F3-8233-3E09E9CF0E66@contoso.onmicrosoft.com. このグループは、Azure AD テナントからのすべてのユーザーを含んでいます。This group contains all users from your Azure AD tenant.

Azure Portal でテンプレートとラベルを管理する場合、このグループは、Azure AD でのテナントのドメイン名として表示されます。When you manage templates and labels in the Azure portal, this group displays as your tenant's domain name in Azure AD. たとえば、Contoso の場合、このグループは contoso.onmicrosoft.com のようになります。For example, this group might look like the following for Contoso: contoso.onmicrosoft.com. このグループを追加するために、オプションの表示は [追加<組織名> - すべてのメンバー] となります。To add this group, the option displays Add <organization name> - All members.

AD RMS テンプレートに ANYONE グループが含まれるかどうかわからない場合は、次のサンプルの Windows PowerShell スクリプトを使用してこれらのテンプレートを識別できます。If you're not sure whether your AD RMS templates include the ANYONE group, you can use the following sample Windows PowerShell script to identify these templates. AD RMS での Windows PowerShell の使用に関する詳細については、「Using Windows PowerShell to Administer AD RMS 」 (Windows PowerShell を使用した AD RMS の管理) を参照してください。For more information about using Windows PowerShell with AD RMS, see Using Windows PowerShell to Administer AD RMS.

Azure Portal でテンプレートをラベルに変換すると、外部ユーザーをそれらのテンプレートに容易に追加できます。You can easily add external users to templates when you convert these templates to labels in the Azure portal. 次に、 [アクセス許可の追加] ウィンドウで、 [詳細の入力] を選択して、これらのユーザーの電子メールアドレスを手動で指定します。Then, on the Add permissions pane, choose Enter details to manually specify the email addresses for these users.

この構成の詳細については、「Rights Management による保護を適用するようにラベルを構成する方法」を参照してください。For more information about this configuration, see How to configure a label for Rights Management protection.

ANYONE グループを含む AD RMS テンプレートを識別するためのサンプル Windows PowerShell スクリプトSample Windows PowerShell script to identify AD RMS templates that include the ANYONE group

このセクションに含まれるサンプル スクリプトを使用すると、前のセクションで説明したように、ANYONE グループが定義されている AD RMS テンプレートを識別できます。This section contains the sample script to help you identify any AD RMS templates that have the ANYONE group defined, as described in the preceding section.

免責事項: このサンプル スクリプトは、Microsoft の標準サポート プログラムまたはサービスではサポートされません。Disclaimer: This sample script is not supported under any Microsoft standard support program or service. このサンプル スクリプトは、どのような種類の保証も伴わずそのままの状態で提供されます。This sample script is provided AS IS without warranty of any kind.

import-module adrmsadmin 

New-PSDrive -Name MyRmsAdmin -PsProvider AdRmsAdmin -Root https://localhost -Force 

$ListofTemplates=dir MyRmsAdmin:\RightsPolicyTemplate

foreach($Template in $ListofTemplates) 
{ 
                $templateID=$Template.id

                $rights = dir MyRmsAdmin:\RightsPolicyTemplate\$Templateid\userright

     $templateName=$Template.DefaultDisplayName 

        if ($rights.usergroupname -eq "anyone")

                         {
                           $templateName = $Template.defaultdisplayname

                           write-host "Template " -NoNewline

                           write-host -NoNewline $templateName -ForegroundColor Red

                           write-host " contains rights for " -NoNewline

                           write-host ANYONE  -ForegroundColor Red
                         }
 } 
Remove-PSDrive MyRmsAdmin -force

次のステップNext steps

フェーズ 3 - クライアント側の構成」に進みます。Go to phase 3 - client-side configuration.