Migrering fas 5 – efter migreringen

Gäller för:Active Directory Rights Management Services, Azure Information Protection, Office 365

Relevant för:AIP unified labeling client and classic client

Obs!

För att ge en enhetlig och smidig kundupplevelse är den klassiska Azure Information Protection-klienten och Etiketthantering i Azure-portalen inaktuella sedan den 31 mars 2021. Inget ytterligare stöd tillhandahålls för den klassiska klienten och underhållsversioner kommer inte längre att släppas.

Den klassiska klienten upphör officiellt och slutar fungera den 31 mars 2022.

Alla aktuella kunder med Azure Information Protection för klassiska klienter måste migrera till Microsoft Information Protection unified labeling-plattformen och uppgradera till den enhetliga etikettklienten. Läs mer i vår migreringsblogg.

Använd följande information för fas 5 av migreringen från AD RMS till Azure Information Protection. De här procedurerna täcker steg 10 till 12 från migrering från AD RMS till Azure Information Protection.

Steg 10. Återkalla AD RMS

Ta bort SCP (Service Connection Point) från Active Directory för att förhindra datorer från att upptäcka den lokala rättighetshanteringsinfrastrukturen. Det här är valfritt för de befintliga klienter som du har migrerat på grund av den omdirigering som du konfigurerat i registret (till exempel genom att köra migreringsskriptet). Att ta bort SCP förhindrar dock nya klienter och eventuellt RMS-relaterade tjänster och verktyg från att hitta SCP när migreringen är slutförd. I det här läget ska alla datoranslutningar gå till Tjänsten Azure Rights Management.

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

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

  2. Klicka på fliken SCP.

  3. Markera kryssrutan Ändra SCP.

  4. Välj Ta bort nuvarande SCPoch klicka sedan på OK.

Övervaka nu AD RMS-servrarna för aktivitet. Kontrollera till exempel begärandena i rapporten Systemhälsa,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 stegvisa steget att först stänga av servrarna under en viss tid. Det ger dig tid att kontrollera att det inte finns några rapporterade problem som kan innebära att du måste starta om servrarna för tjänstekontinuktion medan du undersöker varför klienter inte använder Azure Information Protection.

När du har avetablernat AD RMS-servrarna kan du behöva granska mallen och etiketterna. Du kan till exempel konvertera mallar till etiketter, konsolidera dem så att användarna har färre att välja bland eller konfigurera om dem. Det här är också ett bra tillfälle att publicera standardmallar.

För känslighetsetiketter och den enhetliga etikettklienten använder du Microsoft 365 Efterlevnadscenter. Mer information finns i Microsoft 365 dokumentation.

Om du använder den klassiska klienten använder du Azure Portal. Mer information finns i Konfigurera och hantera mallar för Azure Information Protection.

Viktigt

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

Om du använder den klassiska klienten med HYOK, på grund av de omdirigeringar som nu finns, måste det AD RMS-kluster som du använder ha olika licens-URL:er till dem i de kluster som du har migrerat.

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

Viktigt

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

Om migrerade klienter kör Office 2010 kan användare uppleva fördröjningar i att öppna skyddat innehåll efter att AD RMS-servrarna har avetablerats. Användare kan också se meddelanden om att de inte har autentiseringsuppgifter för att öppna skyddat innehåll. Lös problemen genom att skapa en nätverksomdirigering för dessa datorer, som omdirigerar AD RMS URL FQDN till den lokala IP-adressen för datorn (127.0.0.1). Det kan du göra genom att konfigurera filen med lokala värdar på varje dator eller genom att använda DNS.

  • Omdirigering via fil medlokala värdar : Lägg till följande rad i filen med lokala värdar och ersätt med värdet för AD RMS-klustret, utan prefix eller webbsidor:

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

Steg 11. Slutför klientmigreringsuppgifter

För klienter på mobila enheter och Mac-datorer: Ta bort DE DNS SRV-poster som du skapade när du distribuerade tillägget för mobila AD RMS-enheter.

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

För att tvinga Mac-datorer att köra identifieringsprocessen direkt söker du efter "adal" i nyckelringen och tar bort alla ADAL-poster. Kör sedan följande kommandon på följande 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 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 bort onboarding-kontrollerna först, och sedan kan du ta bort AIPMigrated-gruppen och alla programdistributionsmetod som du har skapat för att distribuera migreringsskripten.

Så här tar du bort onboarding-kontrollerna:

  1. I en PowerShell-session ansluter du till tjänsten Azure Rights Management och anger dina autentiseringsuppgifter som global administratör när du uppmanas att göra det:

    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 licenstvingande åtgärder för Azure Rights Management Protection-tjänsten, så att alla datorer kan skydda dokument och e-postmeddelanden.

  3. Kontrollera att onboarding-kontroller inte längre är inställda:

    Get-AipServiceOnboardingControlPolicy
    

    I resultatet ska Licensen visaFalsktoch inget GUID visas för SecurityGroupOjbectId

Slutligen, om du använder Office 2010 och du har aktiverat aktiviteten Mallhantering (Automatiserad) för AD RMS Rights Policy i biblioteket Windows Task Scheduler inaktiverar du den här aktiviteten eftersom den inte används av Azure Information Protection-klienten.

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

Viktigt

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

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

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

Nyckelningen resulterar i skydd som använder RMS Cryptographic Mode 2, vilket resulterar i en 2048-bitarsnyckel och SHA-256.

Även om AD RMS-distributionen använde Cryptographic Mode 2 rekommenderar vi att du fortfarande gör det här steget eftersom en ny nyckel hjälper till att skydda klientorganisationen från möjliga säkerhetsöverträdelser till AD RMS-nyckeln.

När du omnyckelar din Azure Information Protection-klientnyckel (kallas även att "lansera nyckeln") 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 tangent till en annan sker inte direkt, men över några veckor. Eftersom det inte är omedelbart bör du inte vänta tills du misstänker ett intrång i din ursprungliga nyckel, men utför det här steget så snart migreringen är klar.

Så här gör du om nyckel för Azure Information Protection-klientnyckeln:

  • Om din klientnyckelhanteras av Microsoft : Kör PowerShell-cmdleten Set-AipServiceKeyProperties och ange nyckelidentifierare för nyckeln som skapades automatiskt för din klientorganisation. Du kan identifiera det värde du vill ange genom att köra cmdleten Get-AipServiceKeys. Nyckeln som skapades automatiskt för klientorganisationen har det äldsta datum då den skapades, 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): Upprepa nyckelskapandeprocessen för Azure Information Protection-klienten i Azure Key Vault 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 Azure Information Protection-klientnyckeln finns i Åtgärder för Azure Information Protection-klientnyckeln.

Nästa steg

Nu när du har slutfört migreringen granskar du översikten över AIP-distribution för klassificering, märkning och skydd för att identifiera andra distributionsaktiviteter som du kan behöva göra.