Migrationsphase 5 – Aufgaben nach der Migration
Verwenden Sie die folgenden Informationen für Phase 5 der Migration von AD RMS zu Azure Information Protection. Diese Vorgehensweise umfasst die Schritte 10 bis 12 der Migration von AD RMS zu Azure Information Protection.
Schritt 10: Aufheben der Bereitstellung von AD RMS
Entfernen Sie den Dienstverbindungspunkt (SCP) aus Active Directory, um zu verhindern, dass Computer Ihre lokale Rights Management-Infrastruktur erkennen können. Das ist für die von Ihnen migrierten vorhandenen Clients optional wegen der in der Registrierung konfigurierten Umleitung (z. B. durch Ausführen des Migrationsskripts). Durch das Entfernen des SCP wird jedoch verhindert, dass neue Clients und potenziell RMS-bezogene Dienste und Tools den SCP finden können, wenn die Migration abgeschlossen ist. Zu diesem Zeitpunkt sollten alle Computerverbindungen zum Azure Rights Management-Dienst führen.
Stellen Sie zum Entfernen des SCP sicher, dass Sie als Domänenadministrator des Unternehmens angemeldet sind, und gehen Sie dann folgendermaßen vor:
Klicken Sie in der Active Directory Rights Management Services-Konsole mit der rechten Maustaste auf den AD RMS-Cluster und klicken Sie dann auf Eigenschaften.
Klicken Sie auf die Registerkarte SCP.
Aktivieren Sie das Kontrollkästchen SCP ändern.
Wählen Sie Aktuellen SCP entfernen aus und klicken Sie dann auf OK.
Überwachen Sie nun Ihre AD RMS-Server auf Aktivität. Überprüfen Sie z. B. die Anforderungen im Systemintegritätsbericht, die ServiceRequest-Tabelle oder den Benutzerzugriff auf geschützte Inhalte.
Wenn Sie sich vergewissert haben, dass RMS-Clients nicht mehr mit diesen Servern kommunizieren und dass Clients Azure Information Protection erfolgreich verwenden, können Sie die AD RMS-Serverrolle von diesen Servern entfernen. Wenn Sie dedizierte Server verwenden, sollten Sie die Server vorsichtshalber zunächst für eine gewisse Zeit abschalten. Das verschafft Ihnen Zeit, sicherzustellen, dass keine gemeldeten Probleme vorliegen, die möglicherweise einen Neustart dieser Server für die Dienstkontinuität erfordern, während Sie untersuchen, warum Clients Azure Information Protection nicht verwenden.
Nachdem Sie die Bereitstellung Ihrer AD RMS-Server aufgehoben haben, sollten Sie die Gelegenheit nutzen, Ihre Vorlagen und Bezeichnungen zu überprüfen. Sie können beispielsweise Vorlagen in Etiketten umwandeln, sie konsolidieren, damit die Benutzer weniger zur Auswahl haben, oder sie neu konfigurieren. Dies wäre auch ein guter Zeitpunkt, um Standardvorlagen zu veröffentlichen.
Verwenden Sie für Vertraulichkeitsbezeichnungen und für den Unified Labeling-Client das Microsoft Purview-Complianceportal. Weitere Informationen finden Sie in der Dokumentation zu Microsoft 365.
Wichtig
Am Ende dieser Migration kann Ihr AD RMS-Cluster nicht mit Azure Information Protection und der Option "Halten Sie Ihren eigenen Schlüssel" (HYOK) verwendet werden.
Zusätzliche Konfiguration für Computer, die Office 2010 ausführen
Wichtig
Der erweiterte Support für Office 2010 endete am 13. Oktober 2020. Weitere Informationen finden Sie unter AIP und ältere Windows- und Office-Versionen.
Wenn migrierte Clients Office 2010 ausführen, treten möglicherweise Verzögerungen beim Öffnen geschützter Inhalte auf, nachdem unsere AD RMS-Server nicht bereitgestellt wurden. Oder Benutzer sehen möglicherweise Nachrichten, die nicht über Anmeldeinformationen zum Öffnen geschützter Inhalte verfügen. Um diese Probleme zu beheben, erstellen Sie eine Netzwerkumleitung für diese Computer, die den AD RMS-URL-FQDN an die lokale IP-Adresse des Computers umleitet (127.0.0.1). Sie können dies tun, indem Sie die lokale Hostdatei auf jedem Computer oder mithilfe von DNS konfigurieren.
Umleitung über lokale Hosts-Datei: Fügen Sie die folgende Zeile in die lokale Hosts-Datei ein und ersetzen Sie
<AD RMS URL FQDN>
durch den Wert für Ihren AD RMS-Cluster, ohne Präfixe oder Webseiten:127.0.0.1 <AD RMS URL FQDN>
Umleitung über DNS: Erstellen Sie einen neuen Host-(A)-Eintrag für den FQDN Ihrer AD RMS-URL, der die IP-Adresse 127.0.0.1 hat.
Schritt 11: Ausführen von Aufgaben zur Clientmigration
Für Mobilgeräte-Clients und Mac-Computer: Entfernen Sie die DNS-SRV-Einträge, die Sie beim Bereitstellen der AD RMS-Mobilgeräteerweiterung erstellt haben.
Sobald sich diese DNS-Änderungen verbreitet haben, werden diese Clients den Azure Rights Management-Dienst automatisch erkennen und nutzen. Auf Mac-Computern, auf denen Office Mac ausgeführt wird, werde die Informationen aus AD RMS jedoch zwischengespeichert. Bei diesen Computer kann dieser Prozess bis zu 30 Tage dauern.
Um zu erzwingen, dass Mac-Computer den Ermittlungsprozess sofort ausführen, müssen Sie in der Keychain nach „adal“ suchen und alle ADAL-Einträge löschen. Führen Sie dann auf diesen Computern die folgenden Befehle aus:
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
Wenn alle Ihre vorhandenen Windows-Computer zu Azure Information Protection migriert wurden, gibt es keinen Grund, weiterhin Onboarding-Steuerelemente zu verwenden und die für den Migrationsprozess erstellte Gruppe AIPMigrated beizubehalten.
Entfernen Sie zuerst die Onboarding-Steuerelemente. Anschließend können Sie die Gruppe AIPMigrated und die zum Bereitstellen der Migrationsskripts erstellten Softwarebereitstellungsmethoden löschen.
Entfernen der Onboarding-Steuerelemente:
Stellen Sie in einer PowerShell-Sitzung eine Verbindung zum Azure Rights Management-Dienst her und geben Sie bei der entsprechenden Aufforderung Ihre Anmeldedaten als globaler Administrator an:
Connect-AipService
Führen Sie den folgenden Befehl aus und gegen Sie zum Bestätigen Y ein:
Set-AipServiceOnboardingControlPolicy -UseRmsUserLicense $False
Beachten Sie, dass dieser Befehl jede Lizenzerzwingung für den Azure Rights Management-Schutzdienst entfernt, sodass alle Computer Dokumente und E-Mails schützen können.
Vergewissern Sie sich, dass keine Onboarding-Steuerelemente mehr festgelegt sind:
Get-AipServiceOnboardingControlPolicy
In der Ausgabe sollte für LizenzFalse angezeigt werden, und für SecurityGroupOjbectId wird keine GUID angezeigt.
Wenn Sie Office 2010 verwenden und die Aufgabe AD RMS-Richtlinienvorlagenverwaltung (Automatisiert) in der Windows Taskplaner-Bibliothek aktiviert haben, müssen Sie diese Aufgabe deaktivieren, weil sie vom Azure Information Protection-Client nicht verwendet wird.
Diese Aufgabe wird in der Regel anhand von Gruppenrichtlinien aktiviert und unterstützt eine AD RMS-Bereitstellung. Sie finden diese Aufgabe an der folgenden Stelle: Microsoft>Windows>Active Directory Rights Management Services Client.
Wichtig
Der erweiterte Support für Office 2010 endete am 13. Oktober 2020. Weitere Informationen finden Sie unter AIP und ältere Windows- und Office-Versionen.
Schritt 12: Geben Sie den Schlüssel Ihres Azure Information Protection-Mandanten neu ein
Dieser Schritt ist nach Abschluss der Migration erforderlich, wenn Ihre AD RMS-Bereitstellung den RMS-Kryptomodus 1 verwendet hat, da dieser Modus einen 1024-Bit-Schlüssel und SHA-1 verwendet. Diese Konfiguration wird als unzureichender Schutzfaktor betrachtet. Microsoft unterstützt nicht die Verwendung niedrigerer Schlüssellängen, z. B. 1024-Bit-RSA-Schlüssel und die zugehörige Verwendung von Protokollen, die unzureichende Schutzebenen wie SHA-1 bieten.
Die Neuschlüsselung führt zum Schutz, der RMS-Kryptografiemodus 2 verwendet, was zu einem 2048-Bit-Schlüssel und SHA-256 führt.
Selbst wenn Ihre AD RMS-Bereitstellung den Kryptografiemodus 2 verwendet hat, empfehlen wir Ihnen dennoch diesen Schritt, da ein neuer Schlüssel dazu beiträgt, Ihren Mandanten vor potenziellen Sicherheitsverletzungen bei Ihren AD RMS-Schlüssel zu schützen.
Wenn Sie für Ihren Azure Information Protection-Mandantenschlüssel einen neuen Schlüssel vergeben (auch bekannt als „Schlüssel-Rollover“), wird der derzeit aktive Schlüssel archiviert, und Azure Information Protection beginnt mit der Verwendung eines anderen von Ihnen angegebenen Schlüssels. Dieser andere Schlüssel kann ein neuer Schlüssel sein, den Sie in Azure Key Vault erstellen, oder der Standardschlüssel, der für Ihren Mandanten automatisch erstellt wurde.
Der Wechsel von einem Schlüssel zum anderen erfolgt nicht sofort, sondern erst nach einigen Wochen. Da das nicht sofort erfolgt, sollten Sie nicht abwarten, bis Sie einen Verstoß gegen Ihren ursprünglichen Schlüssel vermuten, sondern diesen Schritt ausführen, sobald die Migration abgeschlossen ist.
Vergabe eines neuen Schlüssels für Ihren Azure Information Protection-Mandantenschlüssel:
Wenn Ihr Mandantenschlüssel von Microsoft verwaltet wird: Führen Sie das PowerShell-Cmdlet Set-AipServiceKeyProperties aus und geben Sie den Schlüsselbezeichner für den Schlüssel an, der automatisch für Ihren Mandanten erstellt wurde. Sie können den anzugebenden Wert ermitteln, indem Sie das Cmdlet Get-AipServiceKeys ausführen. Der Schlüssel, der für Ihren Mandanten automatisch erstellt wurde, hat das älteste Erstellungsdatum, sodass Sie ihn mit dem folgenden Befehl ermitteln können:
(Get-AipServiceKeys) | Sort-Object CreationTime | Select-Object -First 1
Wenn Ihr Mandantenschlüssel von Ihnen verwaltet wird (BYOK): Wiederholen Sie in Azure Key Vault den Prozess der Schlüsselerstellung für Ihren Azure Information Protection-Mandant und führen Sie dann das Cmdlet Use-AipServiceKeyVaultKey erneut aus, um den URI für diesen neuen Schlüssel anzugeben.
Weitere Informationen zum Verwalten Ihres Azure Information Protection-Mandantenschlüssels finden Sie unter Vorgänge für Ihren Azure Information Protection-Mandantenschlüssel.
Nächste Schritte
Nachdem Sie die Migration abgeschlossen haben, sollten Sie sich den AIP-Bereitstellungsplan für Klassifizierung, Bezeichnung und Schutz ansehen, um festzustellen, welche weiteren Bereitstellungsaufgaben noch zu erledigen sind.