Migreringsfas 5 – uppgifter efter migrering

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

Steg 10: Avetablera AD RMS

Ta bort tjänstens Anslut ionspunkt (SCP) från Active Directory för att förhindra att datorer identifierar din lokala Rights Management-infrastruktur. Det här är valfritt för de befintliga klienter som du migrerade på grund av omdirigeringen som du konfigurerade i registret (till exempel genom att köra migreringsskriptet). Om du tar bort SCP:n förhindras dock nya klienter och potentiellt RMS-relaterade tjänster och verktyg från att hitta SCP när migreringen är klar. Nu ska alla datoranslutningar gå till Azure Rights Management-tjänsten.

Om du vill ta bort SCP:en kontrollerar du att du är inloggad som domänföretagsadministratör och använder sedan följande procedur:

1. Högerklicka på AD RMS-klustret i Active Directory Rights Management Services-konsolen och klicka sedan på Egenskaper.

2. Klicka på fliken SCP .

3. Markera kryssrutan Ändra SCP .

4. Välj Ta bort aktuell SCP och klicka sedan på OK.

Övervaka nu AD RMS-servrarna för aktivitet. Kontrollera till exempel begäranden i rapporten System Health, tabellen ServiceRequest eller granska användaråtkomst till skyddat innehåll.

När du har bekräftat att RMS-klienter inte längre kommunicerar med dessa servrar och att klienterna använder Azure Information Protection kan du ta bort AD RMS-serverrollen från dessa servrar. Om du använder dedikerade servrar kanske du föredrar det varnande steget att först stänga av servrarna under en viss tid. Detta ger dig tid att se till att det inte finns några rapporterade problem som kan kräva att du startar om servrarna för tjänstkontinuitet medan du undersöker varför klienter inte använder Azure Information Protection.

När du har avetablerad dina AD RMS-servrar kanske du vill ta tillfället i akt att granska mallen och etiketterna. Konvertera till exempel mallar till etiketter, konsolidera dem så att användarna har färre att välja mellan eller konfigurera om dem. Detta skulle också vara ett bra tillfälle att publicera standardmallar.

Använd efterlevnadsportal i Microsoft Purview för känslighetsetiketter och klienten för enhetlig etikettering. Mer information finns i Microsoft 365-dokumentationen.

Viktigt!

I slutet av den här migreringen kan inte ditt AD RMS-kluster användas med Azure Information Protection och alternativet håll din egen nyckel (HYOK).

Ytterligare konfiguration för datorer som kör Office 2010

Viktigt!

Utökad support för Office 2010 upphörde den 13 oktober 2020. Mer information finns i AIP och äldre Windows- och Office-versioner.

Om migrerade klienter kör Office 2010 kan det uppstå fördröjningar i öppnandet av skyddat innehåll när våra AD RMS-servrar har avetablerats. Eller så kan användarna se meddelanden om att de inte har autentiseringsuppgifter för att öppna skyddat innehåll. Lös dessa problem genom att skapa en nätverksomdirigering för dessa datorer, som omdirigerar AD RMS URL FQDN till datorns lokala IP-adress (127.0.0.1). Du kan göra detta genom att konfigurera den lokala värdfilen på varje dator eller med hjälp av DNS.

• Omdirigering via en lokal värdfil: Lägg till följande rad i den lokala värdfilen och ersätt <AD RMS URL FQDN> med värdet för DITT AD RMS-kluster utan prefix eller webbsidor:

  127.0.0.1 <AD RMS URL FQDN>
  

• Omdirigering via DNS: Skapa en ny värdpost (A) för ditt AD RMS URL FQDN, som har IP-adressen 127.0.0.1.

Steg 11: Slutför klientmigreringsuppgifter

För mobila enhetsklienter och Mac-datorer: Ta bort de DNS SRV-poster som du skapade när du distribuerade ad RMS-tillägget för mobila enheter.

När dessa DNS-ändringar har spridits identifierar och börjar dessa klienter automatiskt att använda Azure Rights Management-tjänsten. Mac-datorer som kör Office Mac cachelagrar dock informationen från AD RMS. För dessa datorer kan den här processen ta upp till 30 dagar.

Om du vill tvinga Mac-datorer att köra identifieringsprocessen omedelbart söker du efter "adal" i nyckelringen och tar bort alla ADAL-poster. Kör sedan följande kommandon på dessa datorer:

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

När alla dina befintliga Windows-datorer har migrerats till Azure Information Protection finns det ingen anledning att fortsätta använda onboarding-kontroller och underhålla den AIPMigrated-grupp som du skapade för migreringsprocessen.

Ta först bort registreringskontrollerna och sedan kan du ta bort gruppen AIPMigrated och valfri programdistributionsmetod som du skapade för att distribuera migreringsskripten.

Så här tar du bort registreringskontrollerna:

1. I en PowerShell-session ansluter du 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. Kör följande kommando och ange Y för att bekräfta:

   Set-AipServiceOnboardingControlPolicy -UseRmsUserLicense $False
   

   Observera att det här kommandot tar bort alla licenstillämpningar för Azure Rights Management-skyddstjänsten, så att alla datorer kan skydda dokument och e-postmeddelanden.

3. Bekräfta att onboarding-kontroller inte längre har angetts:

   Get-AipServiceOnboardingControlPolicy
   

   I utdata ska Licensen visa False och det finns inget GUID som visas för SecurityGroupOjbectId

Om du använder Office 2010 och har aktiverat uppgiften AD RMS Rights Policy Template Management (automatiserad) i Windows Task Scheduler-biblioteket inaktiverar du den här uppgiften eftersom den inte används av Azure Information Protection-klienten.

Den här uppgiften aktiveras vanligtvis med hjälp av en grupprincip och stöder en AD RMS-distribution. Du hittar den här uppgiften på följande plats: Microsoft>Windows>Active Directory Rights Management Services Client.

Viktigt!

Utökad support för Office 2010 upphörde den 13 oktober 2020. Mer information finns i AIP och äldre Windows- och Office-versioner.

Steg 12: Nyckel för Azure Information Protection-klientnyckeln

Det här steget krävs när migreringen är klar om AD RMS-distributionen använde KRYPTOGRAFIläge 1 för RMS eftersom det här läget använder en 1024-bitarsnyckel och SHA-1. Den här konfigurationen anses erbjuda en otillräcklig skyddsnivå. Microsoft stöder inte användning av lägre nyckellängder, till exempel 1024-bitars RSA-nycklar och tillhörande användning av protokoll som erbjuder otillräckliga skyddsnivåer, till exempel SHA-1.

Nyckelning resulterar i skydd som använder KRYPTOGRAFIläge 2 för RMS, vilket resulterar i en 2048-bitarsnyckel och SHA-256.

Även om din AD RMS-distribution använde kryptografiskt läge 2 rekommenderar vi fortfarande att du gör det här steget eftersom en ny nyckel hjälper till att skydda din klientorganisation från potentiella säkerhetsöverträdelser till din AD RMS-nyckel.

När du återställer din Azure Information Protection-klientnyckel (kallas även "rullande din nyckel" arkiveras den aktiva nyckeln och Azure Information Protection börjar använda en annan nyckel som du anger. Den här andra nyckeln kan vara en ny nyckel som du skapar i Azure Key Vault, eller standardnyckeln som skapades automatiskt för din klientorganisation.

Att flytta från en nyckel till en annan sker inte omedelbart utan under några veckor. Eftersom det inte är omedelbart ska du inte vänta tills du misstänker ett brott mot din ursprungliga nyckel, men gör det här steget så fort migreringen är klar.

Så här löser du om din Azure Information Protection-klientnyckel:

• Om din klientnyckel hanteras av Microsoft: Kör PowerShell-cmdleten Set-AipServiceKeyProperties och ange nyckelidentifieraren för nyckeln som skapades automatiskt för din klientorganisation. Du kan identifiera det värde som ska anges genom att köra cmdleten Get-AipServiceKeys . Nyckeln som skapades automatiskt för din klientorganisation har det äldsta skapandedatumet, så att du kan identifiera den med hjälp av följande kommando:

  (Get-AipServiceKeys) | Sort-Object CreationTime | Select-Object -First 1
  

• Om din klientnyckel hanteras av dig (BYOK): I Azure Key Vault upprepar du processen för att skapa din Azure Information Protection-klient och kör sedan cmdleten Use-AipServiceKeyVaultKey igen för att ange URI:n för den nya nyckeln.

Mer information om hur du hanterar din Azure Information Protection-klientnyckel finns i Åtgärder för din Azure Information Protection-klientnyckel.

Nästa steg

Nu när du har slutfört migreringen läser du AIP-distributionsöversikten för klassificering, etikettering och skydd för att identifiera andra distributionsuppgifter som du kan behöva utföra.