Migratiefase 2 : configuratie aan serverzijde voor AD RMS

  • Artikel

Gebruik de volgende informatie voor fase 2 van de migratie van AD RMS naar Azure Information Protection. Deze procedures hebben betrekking op stap 4 tot en met 6 van migreren van AD RMS naar Azure Information Protection.

Stap 4: configuratiegegevens exporteren uit AD RMS en deze importeren in Azure Information Protection

Deze stap bestaat uit twee delen:

  1. Exporteer de configuratiegegevens van AD RMS door de vertrouwde publicatiedomeinen (TPD's) te exporteren naar een XML-bestand. Dit proces is hetzelfde voor alle migraties.

  2. Importeer de configuratiegegevens in Azure Information Protection. Er zijn verschillende processen voor deze stap, afhankelijk van uw huidige AD RMS-implementatieconfiguratie en uw voorkeurstopologie voor uw Azure RMS-tenantsleutel.

De configuratiegegevens exporteren uit AD RMS

Voer de volgende procedure uit op alle AD RMS-clusters voor alle vertrouwde publicatiedomeinen met beveiligde inhoud voor uw organisatie. U hoeft deze procedure niet uit te voeren op clusters met alleen licenties.

De configuratiegegevens exporteren (informatie over het vertrouwde publicatiedomein)

  1. Meld u aan bij het AD RMS-cluster als gebruiker met AD RMS-beheermachtigingen.

  2. Vouw in de AD RMS-beheerconsole (Active Directory Rights Management Services) de naam van het AD RMS-cluster uit, vouw vertrouwensbeleid uit en klik vervolgens op Vertrouwde publicatiedomeinen.

  3. Selecteer in het resultatenvenster het vertrouwde publicatiedomein en klik vervolgens in het deelvenster Acties op Vertrouwd publicatiedomein exporteren.

  4. In het dialoogvenster Trusted Publishing Domain exporteren:

    • Klik op Opslaan als en sla het pad op en een bestandsnaam naar keuze. Zorg ervoor dat u .XML opgeeft als de bestandsnaamextensie (dit wordt niet automatisch toegevoegd).

    • Geef een sterk wachtwoord op en bevestig dit. Onthoud dit wachtwoord, omdat u dit later nodig hebt wanneer u de configuratiegegevens importeert in Azure Information Protection.

    • Schakel het selectievakje niet in om het vertrouwde domeinbestand op te slaan in RMS versie 1.0.

Wanneer u alle vertrouwde publicatiedomeinen hebt geëxporteerd, kunt u de procedure starten om deze gegevens te importeren in Azure Information Protection.

Houd er rekening mee dat de vertrouwde publicatiedomeinen de SLC-sleutels (Server Licentiecertificaat) bevatten voor het ontsleutelen van eerder beveiligde bestanden, dus het is belangrijk dat u alle vertrouwde publicatiedomeinen exporteert (en later importeert in Azure) en niet alleen de momenteel actieve.

U hebt bijvoorbeeld meerdere vertrouwde publicatiedomeinen als u uw AD RMS-servers hebt bijgewerkt van cryptografische modus 1 naar cryptografische modus 2. Als u het vertrouwde publicatiedomein dat uw gearchiveerde sleutel bevat die cryptografische modus 1 heeft gebruikt, niet exporteert en importeert, kunnen gebruikers aan het einde van de migratie geen inhoud openen die is beveiligd met de cryptografische modus 1-sleutel.

De configuratiegegevens importeren in Azure Information Protection

De exacte procedures voor deze stap zijn afhankelijk van de huidige configuratie van uw AD RMS-implementatie en de topologie van uw Azure Information Protection-tenantsleutel.

Uw huidige AD RMS-implementatie gebruikt een van de volgende configuraties voor de SLC-sleutel (serverlicentiecertificaat):

  • Wachtwoordbeveiliging in de AD RMS-database. Dit is de standaard configuratie.

  • HSM-beveiliging met behulp van een nCipher Hardware Security Module (HSM).

  • HSM-beveiliging met behulp van een HSM (Hardware Security Module) van een andere leverancier dan nCipher.

  • Met een wachtwoord beveiligd met een externe cryptografische provider.

Notitie

Zie AD RMS gebruiken met Hardware Security Modules voor meer informatie over het gebruik van hardwarebeveiligingsmodules met AD RMS.

De twee topologieopties voor azure Information Protection-tenantsleutels zijn: Microsoft beheert uw tenantsleutel (door Microsoft beheerd) of u beheert uw tenantsleutel (door de klant beheerd) in Azure Key Vault. Wanneer u uw eigen Azure Information Protection-tenantsleutel beheert, wordt deze soms 'Bring Your Own Key' (BYOK) genoemd. Zie het artikel Over het plannen en implementeren van uw Azure Information Protection-tenantsleutel voor meer informatie.

Gebruik de volgende tabel om te bepalen welke procedure moet worden gebruikt voor uw migratie.

Huidige AD RMS-implementatie Gekozen topologie voor Azure Information Protection-tenantsleutel Migratie-instructies
Wachtwoordbeveiliging in de AD RMS-database Door Microsoft beheerd Zie de procedure voor migratie van met software beveiligde sleutel naar met software beveiligde sleutel na deze tabel.

Dit is het eenvoudigste migratiepad en vereist alleen dat u uw configuratiegegevens overbrengt naar Azure Information Protection.
HSM-beveiliging met behulp van een nCipher nShield Hardware Security Module (HSM) Door de klant beheerd (BYOK) Zie de migratieprocedure voor met HSM beveiligde sleutel naar met HSM beveiligde sleutel na deze tabel.

Hiervoor zijn de BYOK-hulpprogramma's van Azure Key Vault en drie sets stappen vereist om eerst de sleutel van uw on-premises HSM over te dragen naar de HSM's van Azure Key Vault, en vervolgens de Azure Rights Management-service van Azure Information Protection te autoriseren om uw tenantsleutel te gebruiken en ten slotte uw configuratiegegevens over te dragen naar Azure Information Protection.
Wachtwoordbeveiliging in de AD RMS-database Door de klant beheerd (BYOK) Zie de migratieprocedure voor met software beveiligde sleutel naar met HSM beveiligde sleutel na deze tabel.

Hiervoor zijn de BYOK-hulpprogramma's van Azure Key Vault en vier sets stappen vereist om eerst uw softwaresleutel te extraheren en te importeren in een on-premises HSM, en vervolgens de sleutel over te dragen van uw on-premises HSM naar de Azure Information Protection-HSM's, vervolgens uw Key Vault-gegevens over te dragen naar Azure Information Protection en ten slotte om uw configuratiegegevens over te dragen naar Azure Information Protection.
HSM-beveiliging met behulp van een HSM (Hardware Security Module) van een andere leverancier dan nCipher Door de klant beheerd (BYOK) Neem contact op met de leverancier voor uw HSM voor instructies over het overdragen van uw sleutel van deze HSM naar een nCipher nShield Hardware Security Module (HSM). Volg vervolgens de instructies voor de migratieprocedure van de met HSM beveiligde sleutel naar met HSM beveiligde sleutel na deze tabel.
Met een wachtwoord beveiligd met een externe cryptografische provider Door de klant beheerd (BYOK) Neem contact op met de leverancier van uw cryptografische provider voor instructies over het overdragen van uw sleutel naar een nCipher nShield Hardware Security Module (HSM). Volg vervolgens de instructies voor de migratieprocedure van de met HSM beveiligde sleutel naar met HSM beveiligde sleutel na deze tabel.

Als u een met HSM beveiligde sleutel hebt die u niet kunt exporteren, kunt u nog steeds migreren naar Azure Information Protection door uw AD RMS-cluster te configureren voor een modus met het kenmerk Alleen-lezen. In deze modus kan eerder beveiligde inhoud nog steeds worden geopend, maar nieuwe beveiligde inhoud maakt gebruik van een nieuwe tenantsleutel die wordt beheerd door u (BYOK) of beheerd door Microsoft. Zie Een update is beschikbaar voor Office voor ondersteuning van migraties van AD RMS naar Azure RMS voor meer informatie.

Voordat u deze belangrijke migratieprocedures start, moet u ervoor zorgen dat u toegang hebt tot de XML-bestanden die u eerder hebt gemaakt toen u de vertrouwde publicatiedomeinen hebt geëxporteerd. Deze kunnen bijvoorbeeld worden opgeslagen op een USB-duimstation dat u van de AD RMS-server naar het met internet verbonden werkstation verplaatst.

Notitie

U slaat deze bestanden echter op door de aanbevolen beveiligingsprocedures te gebruiken om ze te beveiligen, omdat deze gegevens uw persoonlijke sleutel bevatten.

Als u stap 4 wilt voltooien, kiest en selecteert u de instructies voor uw migratiepad:

Stap 5: De Azure Rights Management-service activeren

Open een PowerShell-sessie en voer de volgende opdrachten uit:

  1. Verbinding maken naar de Azure Rights Management-service en geef desgevraagd uw globale beheerdersreferenties op:

    Connect-AipService

  2. Activeer de Azure Rights Management-service:

    Enable-AipService

Wat gebeurt er als uw Azure Information Protection-tenant al is geactiveerd? Als de Azure Rights Management-service al is geactiveerd voor uw organisatie en u aangepaste sjablonen hebt gemaakt die u na de migratie wilt gebruiken, moet u deze sjablonen exporteren en importeren. Deze procedure wordt behandeld in de volgende stap.

Stap 6: Geïmporteerde sjablonen configureren

Omdat de sjablonen die u hebt geïmporteerd een standaardstatus gearchiveerd hebben, moet u deze status wijzigen in Publiceren als u wilt dat gebruikers deze sjablonen kunnen gebruiken met de Azure Rights Management-service.

Sjablonen die u vanuit AD RMS importeert, zien eruit en gedragen zich net als aangepaste sjablonen die u in Azure Portal kunt maken. Als u geïmporteerde sjablonen wilt wijzigen die moeten worden gepubliceerd, zodat gebruikers ze kunnen zien en selecteren in toepassingen, raadpleegt u Sjablonen configureren en beheren voor Azure Information Protection.

Naast het publiceren van uw zojuist geïmporteerde sjablonen, zijn er slechts twee belangrijke wijzigingen voor de sjablonen die u mogelijk moet aanbrengen voordat u doorgaat met de migratie. Voor een consistentere ervaring voor gebruikers tijdens het migratieproces moet u geen aanvullende wijzigingen aanbrengen in de geïmporteerde sjablonen en de twee standaardsjablonen die bij Azure Information Protection worden geleverd, niet publiceren of op dit moment nieuwe sjablonen maken. Wacht in plaats daarvan totdat het migratieproces is voltooid en u de inrichting van de AD RMS-servers ongedaan hebt gemaakt.

De sjabloonwijzigingen die u mogelijk moet aanbrengen voor deze stap:

  • Als u aangepaste Azure Information Protection-sjablonen hebt gemaakt vóór de migratie, moet u deze handmatig exporteren en importeren.

  • Als uw sjablonen in AD RMS de groep IEDEREEN hebben gebruikt, moet u mogelijk handmatig gebruikers of groepen toevoegen.

    In AD RMS heeft de groep IEDEREEN rechten verleend aan alle gebruikers die zijn geverifieerd door uw on-premises Active Directory. Deze groep wordt niet ondersteund door Azure Information Protection. Het equivalent van de kast is een groep die automatisch wordt gemaakt voor alle gebruikers in uw Microsoft Entra-tenant. Als u de groep IEDEREEN voor uw AD RMS-sjablonen gebruikt, moet u mogelijk gebruikers en de rechten toevoegen die u hen wilt verlenen.

Procedure als u aangepaste sjablonen hebt gemaakt vóór de migratie

Als u aangepaste sjablonen hebt gemaakt vóór de migratie, vóór of na het activeren van de Azure Rights Management-service, zijn sjablonen na de migratie niet beschikbaar voor gebruikers, zelfs niet als ze zijn ingesteld op Gepubliceerd. Als u ze beschikbaar wilt maken voor gebruikers, moet u eerst het volgende doen:

  1. Identificeer deze sjablonen en noteer de sjabloon-id door get-AipServiceTemplate uit te voeren.

  2. Exporteer de sjablonen met behulp van de Azure RMS PowerShell-cmdlet Export-AipServiceTemplate.

  3. Importeer de sjablonen met behulp van de Azure RMS PowerShell-cmdlet Import-AipServiceTemplate.

U kunt deze sjablonen vervolgens publiceren of archiveren zoals elke andere sjabloon die u na de migratie maakt.

Procedure als uw sjablonen in AD RMS de groep IEDEREEN hebben gebruikt

Als uw sjablonen in AD RMS de groep IEDEREEN hebben gebruikt, heeft de dichtstbijzijnde equivalente groep in Azure Information Protection de naam AllStaff-7184AB3F-CCD1-46F3-8233-3E09E9CF0E66@<tenant_name.onmicrosoft.com>. Deze groep kan er bijvoorbeeld als volgt uitzien voor Contoso: AllStaff-7184AB3F-CCD1-46F3-8233-3E09E9CF0E66@contoso.onmicrosoft.com. Deze groep bevat alle gebruikers uit uw Microsoft Entra-tenant.

Wanneer u sjablonen en labels beheert in Azure Portal, wordt deze groep weergegeven als de domeinnaam van uw tenant in Microsoft Entra-id. Deze groep kan er bijvoorbeeld als volgt uitzien voor Contoso: contoso.onmicrosoft.com. Als u deze groep wilt toevoegen, wordt met de optie Organisatienaam> toevoegen <- Alle leden weergegeven.

Als u niet zeker weet of uw AD RMS-sjablonen de groep IEDEREEN bevatten, kunt u het volgende Windows PowerShell-voorbeeldscript gebruiken om deze sjablonen te identificeren. Zie Windows PowerShell gebruiken om AD RMS te Beheer ister AD RMS voor meer informatie over het gebruik van Windows PowerShell met AD RMS.

U kunt eenvoudig externe gebruikers toevoegen aan sjablonen wanneer u deze sjablonen converteert naar labels in Azure Portal. Kies vervolgens in het deelvenster Machtigingen toevoegen details invoeren om handmatig de e-mailadressen voor deze gebruikers op te geven.

Zie Een label configureren voor Rights Management-beveiliging voor meer informatie over deze configuratie.

Windows PowerShell-voorbeeldscript om AD RMS-sjablonen te identificeren die de groep IEDEREEN bevatten

Deze sectie bevat het voorbeeldscript waarmee u AD RMS-sjablonen kunt identificeren waarvoor de groep IEDEREEN is gedefinieerd, zoals beschreven in de vorige sectie.

Disclaimer: dit voorbeeldscript wordt niet ondersteund in een standaardondersteuningsprogramma of -service van Microsoft. Dit voorbeeldscript wordt geleverd ALS IS zonder enige garantie.

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

Volgende stappen

Ga naar fase 3: configuratie aan de clientzijde.