Migreringsfas 2 – konfiguration på serversidan för AD RMS

Använd följande information för fas 2 av migrering från AD RMS till Azure Information Protection. De här procedurerna omfattar steg 4 till och med 6 från Migrera från AD RMS till Azure Information Protection.

Steg 4: Exportera konfigurationsdata från AD RMS och importera dem till Azure Information Protection

Det här steget är en process i två delar:

  1. Exportera konfigurationsdata från AD RMS genom att exportera betrodda publiceringsdomäner (TPD) till en .xml-fil. Den här processen är densamma för alla migreringar.

  2. Importera konfigurationsdata till Azure Information Protection. Det finns olika processer för det här steget, beroende på din aktuella AD RMS-distributionskonfiguration och önskad topologi för din Azure RMS-klientnyckel.

Exportera konfigurationsdata från AD RMS

Gör följande i alla AD RMS-kluster för alla betrodda publiceringsdomäner som har skyddat innehåll för din organisation. Du behöver inte köra den här proceduren på endast licensieringskluster.

Exportera konfigurationsdata (information om betrodd publiceringsdomän)

  1. Logga in på AD RMS-klustret som en användare med AD RMS-administrationsbehörigheter.

  2. Från AD RMS-hanteringskonsolen (Active Directory Rights Management Services) expanderar du AD RMS-klusternamnet, expanderar Förtroendeprinciper och klickar sedan på Betrodda publiceringsdomäner.

  3. I resultatfönstret väljer du den betrodda publiceringsdomänen och klickar sedan på Exportera betrodd publiceringsdomän i fönstret Åtgärder.

  4. I dialogrutan Exportera betrodd publiceringsdomän:

    • Klicka på Spara som och spara till sökvägen och ett valfritt filnamn. Se till att ange .xml som filnamnstillägg (detta läggs inte till automatiskt).

    • Ange och bekräfta ett starkt lösenord. Kom ihåg det här lösenordet eftersom du behöver det senare när du importerar konfigurationsdata till Azure Information Protection.

    • Markera inte kryssrutan för att spara den betrodda domänfilen i RMS version 1.0.

När du har exporterat alla betrodda publiceringsdomäner är du redo att påbörja proceduren för att importera dessa data till Azure Information Protection.

Observera att de betrodda publiceringsdomänerna innehåller SLC-nycklarna (Server Licensor Certificate) för att dekryptera tidigare skyddade filer, så det är viktigt att du exporterar (och senare importerar till Azure) alla betrodda publiceringsdomäner och inte bara den för närvarande aktiva.

Du kommer till exempel att ha flera betrodda publiceringsdomäner om du uppgraderade AD RMS-servrarna från kryptografiskt läge 1 till kryptografiskt läge 2. Om du inte exporterar och importerar den betrodda publiceringsdomänen som innehåller din arkiverade nyckel som använde kryptografiläge 1 kan användarna i slutet av migreringen inte öppna innehåll som har skyddats med nyckeln Kryptografiläge 1.

Importera konfigurationsdata till Azure Information Protection

De exakta procedurerna för det här steget beror på din aktuella AD RMS-distributionskonfiguration och önskad topologi för din Azure Information Protection-klientnyckel.

Din aktuella AD RMS-distribution använder någon av följande konfigurationer för din SLC-nyckel (Server Licensor Certificate):

  • Lösenordsskydd i AD RMS-databasen. Det här är standardkonfigurationen.

  • HSM-skydd med hjälp av en nCipher-maskinvarusäkerhetsmodul (HSM).

  • HSM-skydd med hjälp av en maskinvarusäkerhetsmodul (HSM) från en annan leverantör än nCipher.

  • Lösenord som skyddas med hjälp av en extern kryptografiprovider.

Kommentar

Mer information om hur du använder maskinvarusäkerhetsmoduler med AD RMS finns i Använda AD RMS med maskinvarusäkerhetsmoduler.

De två topologialternativen för Azure Information Protection-klientnyckeln är: Microsoft hanterar din klientnyckel (Microsoft-hanterad) eller så hanterar du din klientnyckel (kundhanterad) i Azure Key Vault. När du hanterar din egen Azure Information Protection-klientnyckel kallas den ibland för BYOK (Bring Your Own Key). Mer information finns i artikeln Planera och implementera din Azure Information Protection-klientnyckel .

Använd följande tabell för att identifiera vilken procedur som ska användas för migreringen.

Aktuell AD RMS-distribution Vald topologi för Azure Information Protection-klientnyckel Migreringsanvisningar
Lösenordsskydd i AD RMS-databasen Microsoft-hanterad Se migreringsproceduren Programvaruskyddad nyckel till programvaruskyddad nyckel efter den här tabellen.

Det här är den enklaste migreringsvägen och kräver bara att du överför dina konfigurationsdata till Azure Information Protection.
HSM-skydd med hjälp av en nCipher nShield-maskinvarusäkerhetsmodul (HSM) Kundhanterad (BYOK) Se migreringsproceduren HSM-skyddad nyckel till HSM-skyddad nyckel efter den här tabellen.

Detta kräver AZURE Key Vault BYOK-verktygsuppsättningen och tre uppsättningar steg för att först överföra nyckeln från din lokala HSM till Azure Key Vault HSMs, sedan auktorisera Azure Rights Management-tjänsten från Azure Information Protection för att använda din klientnyckel och slutligen överföra dina konfigurationsdata till Azure Information Protection.
Lösenordsskydd i AD RMS-databasen Kundhanterad (BYOK) Se migreringsproceduren Programvaruskyddad nyckel till HSM-skyddad nyckel efter den här tabellen.

Detta kräver Azure Key Vault BYOK-verktygsuppsättningen och fyra uppsättningar steg för att först extrahera din programvarunyckel och importera den till en lokal HSM, sedan överföra nyckeln från din lokala HSM till Azure Information Protection HSM, sedan överföra dina Key Vault-data till Azure Information Protection och slutligen överföra dina konfigurationsdata till Azure Information Protection.
HSM-skydd med hjälp av en maskinvarusäkerhetsmodul (HSM) från en annan leverantör än nCipher Kundhanterad (BYOK) Kontakta leverantören för din HSM för instruktioner om hur du överför din nyckel från denna HSM till en nCipher nShield maskinvarusäkerhetsmodul (HSM). Följ sedan anvisningarna för migreringen av HSM-skyddad nyckel till HSM-skyddad nyckel efter den här tabellen.
Lösenord som skyddas med hjälp av en extern kryptografiprovider Kundhanterad (BYOK) Kontakta leverantören för din kryptografiska provider för att få instruktioner om hur du överför din nyckel till en nCipher nShield-maskinvarusäkerhetsmodul (HSM). Följ sedan anvisningarna för migreringen av HSM-skyddad nyckel till HSM-skyddad nyckel efter den här tabellen.

Om du har en HSM-skyddad nyckel som du inte kan exportera kan du fortfarande migrera till Azure Information Protection genom att konfigurera AD RMS-klustret i skrivskyddat läge. I det här läget kan tidigare skyddat innehåll fortfarande öppnas, men nyligen skyddat innehåll använder en ny klientnyckel som hanteras av dig (BYOK) eller hanteras av Microsoft. Mer information finns i En uppdatering är tillgänglig för Office för migrering från AD RMS till Azure RMS.

Innan du påbörjar de här nyckelmigreringsprocedurerna måste du se till att du kan komma åt .xml-filerna som du skapade tidigare när du exporterade de betrodda publiceringsdomänerna. Dessa kan till exempel sparas på en USB-tumenhet som du flyttar från AD RMS-servern till den Internetanslutna arbetsstationen.

Kommentar

Men du lagrar dessa filer, använd rekommenderade säkerhetsmetoder för att skydda dem eftersom dessa data innehåller din privata nyckel.

Slutför steg 4 genom att välja och välja anvisningarna för migreringssökvägen:

Steg 5: Aktivera Azure Rights Management-tjänsten

Öppna en PowerShell-session och kör följande kommandon:

  1. Anslut till Azure Rights Management-tjänsten och när du uppmanas till det anger du dina autentiseringsuppgifter för global administratör:

    Connect-AipService
    
  2. Aktivera Azure Rights Management-tjänsten:

    Enable-AipService
    

Vad händer om din Azure Information Protection-klientorganisation redan är aktiverad? Om Azure Rights Management-tjänsten redan är aktiverad för din organisation och du har skapat anpassade mallar som du vill använda efter migreringen måste du exportera och importera dessa mallar. Den här proceduren beskrivs i nästa steg.

Steg 6: Konfigurera importerade mallar

Eftersom de mallar som du har importerat har standardtillståndet Arkiverad måste du ändra det här tillståndet så att det publiceras om du vill att användarna ska kunna använda dessa mallar med Azure Rights Management-tjänsten.

Mallar som du importerar från AD RMS ser ut och fungerar precis som anpassade mallar som du kan skapa i Azure-portalen. Information om hur du ändrar importerade mallar som ska publiceras så att användarna kan se dem och välja dem från program finns i Konfigurera och hantera mallar för Azure Information Protection.

Förutom att publicera dina nyligen importerade mallar finns det bara två viktiga ändringar för mallarna som du kan behöva göra innan du fortsätter med migreringen. Om du vill ha en mer konsekvent upplevelse för användare under migreringsprocessen ska du inte göra ytterligare ändringar i de importerade mallarna och inte publicera de två standardmallarna som medföljer Azure Information Protection eller skapa nya mallar just nu. Vänta i stället tills migreringsprocessen är klar och du har avetablerade AD RMS-servrarna.

De malländringar som du kan behöva göra för det här steget:

  • Om du skapade anpassade Azure Information Protection-mallar före migreringen måste du exportera och importera dem manuellt.

  • Om dina mallar i AD RMS använde gruppen VEM SOM HELST kan du behöva lägga till användare eller grupper manuellt.

    I AD RMS beviljar gruppen ALLA rättigheter till alla användare som autentiseras av din lokal Active Directory, och den här gruppen stöds inte av Azure Information Protection. Motsvarande garderob är en grupp som skapas automatiskt för alla användare i din Microsoft Entra-klientorganisation. Om du använder gruppen VEM som helst för dina AD RMS-mallar kan du behöva lägga till användare och de rättigheter som du vill bevilja dem.

Procedur om du skapade anpassade mallar före migreringen

Om du skapade anpassade mallar före migreringen, antingen före eller efter aktiveringen av Azure Rights Management-tjänsten, kommer mallar inte att vara tillgängliga för användare efter migreringen, även om de har angetts till Publicerade. För att göra dem tillgängliga för användare måste du först göra följande:

  1. Identifiera dessa mallar och anteckna deras mall-ID genom att köra Get-AipServiceTemplate.

  2. Exportera mallarna med hjälp av Azure RMS PowerShell-cmdleten Export-AipServiceTemplate.

  3. Importera mallarna med hjälp av Azure RMS PowerShell-cmdleten Import-AipServiceTemplate.

Du kan sedan publicera eller arkivera dessa mallar på samma sätt som andra mallar som du skapar efter migreringen.

Procedur om dina mallar i AD RMS använde gruppen ANYONE

Om dina mallar i AD RMS använde gruppen ANYONE får den närmaste motsvarande gruppen i Azure Information Protection namnet AllStaff-7184AB3F-CCD1-46F3-8233-3E09E9CF0E66@<tenant_name.onmicrosoft.com>. Den här gruppen kan till exempel se ut så här för Contoso: AllStaff-7184AB3F-CCD1-46F3-8233-3E09E9CF0E66@contoso.onmicrosoft.com. Den här gruppen innehåller alla användare från din Microsoft Entra-klientorganisation.

När du hanterar mallar och etiketter i Azure-portalen visas den här gruppen som din klientorganisations domännamn i Microsoft Entra-ID. Den här gruppen kan till exempel se ut så här för Contoso: contoso.onmicrosoft.com. Om du vill lägga till den här gruppen visar alternativet Lägg till <organisationsnamn> – Alla medlemmar.

Om du inte är säker på om dina AD RMS-mallar innehåller gruppen VEM som helst kan du använda följande Exempel på Windows PowerShell-skript för att identifiera dessa mallar. Mer information om hur du använder Windows PowerShell med AD RMS finns i Använda Windows PowerShell för att administrera AD RMS.

Du kan enkelt lägga till externa användare i mallar när du konverterar dessa mallar till etiketter i Azure-portalen. I fönstret Lägg till behörigheter väljer du Ange information för att manuellt ange e-postadresserna för dessa användare.

Mer information om den här konfigurationen finns i Konfigurera en etikett för Rights Management-skydd.

Exempel på Windows PowerShell-skript för att identifiera AD RMS-mallar som innehåller gruppen ALLA

Det här avsnittet innehåller exempelskriptet som hjälper dig att identifiera eventuella AD RMS-mallar som har definierat någon-gruppen, enligt beskrivningen i föregående avsnitt.

Ansvarsfriskrivning: Det här exempelskriptet stöds inte under microsofts standardsupportprogram eller -tjänst. Det här exempelskriptet tillhandahålls som is utan garanti av något slag.

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

Nästa steg

Gå till fas 3 – konfiguration på klientsidan.