Phase de migration 5 : tâches post-migration

Utilisez les informations suivantes pour la phase 5 de la migration d’AD RMS vers Azure Information Protection. Ces procédures couvrent les étapes 10 à 12 de la migration d’AD RMS vers Azure Information Protection.

Étape 10 : Déprovisionner AD RMS

Supprimez le point de connexion de service (SCP) d'Active Directory pour empêcher les ordinateurs de découvrir votre infrastructure Rights Management locale. Ceci est facultatif pour les clients existants que vous avez migrés en raison de la redirection que vous avez configurée dans le registre (par exemple, en exécutant le script de migration). Toutefois, la suppression du SCP empêche les nouveaux clients et potentiellement les services et outils liés à RMS de trouver le SCP une fois la migration terminée. À ce stade, toutes les connexions informatiques doivent être dirigées vers le service Azure Rights Management.

Pour supprimer le SCP, vérifiez que vous êtes connecté en tant qu’administrateur de domaine d’entreprise, puis utilisez la procédure suivante :

1. Dans la console services AD RMS (Active Directory Rights Management Services), cliquez avec le bouton droit sur le groupement AD RMS, puis cliquez sur Propriétés.

2. Cliquez sur l’onglet SCP.

3. Cochez la case Modifier le SCP.

4. Sélectionnez Supprimer le SCP actuel, puis cliquez sur OK.

Surveillez maintenant l’activité de vos serveurs AD RMS. Par exemple, vérifiez les demandes dans le rapport sur l'intégrité du système, la table ServiceRequest ou auditez l'accès des utilisateurs au contenu protégé.

Lorsque vous avez confirmé que les clients RMS ne communiquent plus avec ces serveurs et que les clients utilisent correctement Azure Information Protection, vous pouvez supprimer le rôle serveur AD RMS de ces serveurs. Si vous utilisez des serveurs dédiés, vous préférerez peut-être la mesure de précaution consistant à arrêter d'abord les serveurs pendant un certain temps. Cela vous donne le temps de vous assurer qu’aucun problème n’a été signalé qui pourrait vous obliger à redémarrer ces serveurs pour assurer la continuité du service pendant que vous recherchez les raisons pour lesquelles les clients n’utilisent pas Azure Information Protection.

Après avoir supprimé le provisionnement de vos serveurs AD RMS, vous souhaiterez peut-être profiter de l'occasion pour revoir votre modèle et vos étiquettes. Par exemple, convertissez des modèles en étiquettes, consolidez-les afin que les utilisateurs aient moins de choix ou reconfigurez-les. Cela serait également le bon moment pour publier des modèles par défaut.

Pour les étiquettes de confidentialité et le client d’étiquetage unifié, utilisez le portail de conformité Microsoft Purview. Pour plus d’informations, consultez la documentation de Microsoft 365.

Important

À la fin de cette migration, votre groupement AD RMS ne peut pas être utilisé avec Azure Information Protection et l’option « hold your own key » (HYOK).

Configuration supplémentaire pour les ordinateurs qui exécutent Office 2010

Important

Le support étendu d'Office 2010 a pris fin le 13 octobre 2020. Pour plus d’informations, consultez AIP et les anciennes versions de Windows et d’Office.

Si les clients migrés exécutent Office 2010, les utilisateurs peuvent rencontrer des retards dans l'ouverture du contenu protégé après le déprovisionnement de nos serveurs AD RMS. Les utilisateurs peuvent également voir des messages indiquant qu'ils ne disposent pas d'informations d'identification pour ouvrir du contenu protégé. Pour résoudre ces problèmes, créez une redirection réseau pour ces ordinateurs, qui redirige le nom de domaine complet de l’URL AD RMS vers l’adresse IP locale de l’ordinateur (127.0.0.1). Pour ce faire, configurez le fichier hosts local sur chaque ordinateur ou à l’aide de DNS.

• Redirection via le fichier hosts local : ajoutez la ligne suivante dans le fichier hosts local, en remplaçant <AD RMS URL FQDN> par la valeur de votre groupement AD RMS, sans préfixes ni pages web :

  127.0.0.1 <AD RMS URL FQDN>
  

• Redirection via DNS : créez un enregistrement hôte (A) pour votre nom de domaine complet d’URL AD RMS, dont l’adresse IP est 127.0.0.1.

Étape 11 : Effectuer les tâches de migration du client

Pour les clients d’appareils mobiles et les ordinateurs Mac : supprimez les enregistrements DNS SRV que vous avez créés lors du déploiement de l’extension d’appareil mobile AD RMS.

Une fois ces modifications DNS propagées, ces clients découvriront automatiquement et commenceront à utiliser le service Azure Rights Management. Toutefois, les ordinateurs Mac qui exécutent Office Mac mettent en cache les informations d’AD RMS. Pour ces ordinateurs, ce processus peut prendre jusqu’à 30 jours.

Pour forcer les ordinateurs Mac à exécuter immédiatement le processus de découverte, dans le trousseau, recherchez « adal » et supprimez toutes les entrées ADAL. Exécutez ensuite les commandes suivantes sur ces ordinateurs :

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

Lorsque tous vos ordinateurs Windows existants ont migré vers Azure Information Protection, il n’existe aucune raison de continuer à utiliser des contrôles d’intégration et à gérer le groupe AIPMigrated que vous avez créé pour le processus de migration.

Supprimez d’abord les contrôles d’intégration, puis vous pouvez supprimer le groupe AIPMigrated et toute méthode de déploiement de logiciels que vous avez créée pour déployer les scripts de migration.

Pour supprimer les contrôles d’intégration :

1. Dans une session PowerShell, connectez-vous au service Azure Rights Management et, lorsque vous y êtes invité, spécifiez vos informations d’identification d’administrateur général :

   Connect-AipService
   
   

2. Exécutez la commande suivante et entrez Y pour confirmer :

   Set-AipServiceOnboardingControlPolicy -UseRmsUserLicense $False
   

   Notez que cette commande supprime toute application de licence pour le service de protection Azure Rights Management, afin que tous les ordinateurs puissent protéger les documents et les e-mails.

3. Vérifiez que les contrôles d’intégration ne sont plus définis :

   Get-AipServiceOnboardingControlPolicy
   

   Dans le résultat, Licence doit afficher Faux et aucun GUID n’est affiché pour SecurityGroupOjbectId

Enfin, si vous utilisez Office 2010 et que vous avez activé la tâche Gestion des modèles de stratégie de droits AD RMS (automatisée) dans la bibliothèque du planificateur de tâches Windows, désactivez cette tâche car elle n'est pas utilisée par le client Azure Information Protection.

Cette tâche est généralement activée à l’aide de la stratégie de groupe et prend en charge un déploiement AD RMS. Vous trouverez cette tâche à l’emplacement suivant : Microsoft>Windows>Services AD RMS (Active Directory Rights Management Services) Client.

Important

Le support étendu d'Office 2010 a pris fin le 13 octobre 2020. Pour plus d’informations, consultez AIP et les anciennes versions de Windows et d’Office.

Étape 12 : Rekeyisez votre clé de locataire Azure Information Protection

Cette étape est requise lorsque la migration est terminée si votre déploiement AD RMS utilise le mode de chiffrement RMS 1, car ce mode utilise une clé 1024 bits et SHA-1. Cette configuration est considérée comme offrant un niveau de protection insuffisant. Microsoft n'approuve pas l'utilisation de clés de longueur inférieure, telles que les clés RSA de 1024 bits, ni l'utilisation associée de protocoles offrant des niveaux de protection inadéquats, tels que SHA-1.

La rekeying résulte en une protection qui utilise le mode de chiffrement RMS 2, ce qui donne une clé 2048 bits et SHA-256.

Même si votre déploiement AD RMS utilise le mode de chiffrement 2, nous vous recommandons néanmoins d’effectuer cette étape, car une nouvelle clé permet de protéger votre locataire contre les failles de sécurité potentielles de votre clé AD RMS.

Lorsque vous rekeyisez votre clé de locataire Azure Information Protection (également appelée « déploiement de votre clé »), la clé active est archivée et Azure Information Protection commence à utiliser une autre clé que vous spécifiez. Cette clé différente peut être une nouvelle clé que vous créez dans Azure Key Vault ou la clé par défaut qui a été créée automatiquement pour votre locataire.

Le passage d’une clé à une autre ne se fait pas immédiatement, mais sur quelques semaines. Étant donné qu’il n’est pas immédiat, n’attendez pas que vous suspectiez une violation de votre clé d’origine, mais effectuez cette étape dès que la migration est terminée.

Pour rekeyiser votre clé de locataire Azure Information Protection :

• Si votre clé de locataire est gérée par Microsoft : exécutez l’applet de commande PowerShell Set-AipServiceKeyProperties et spécifiez l’identificateur de clé pour la clé créée automatiquement pour votre locataire. Vous pouvez identifier la valeur à spécifier en exécutant l’applet de commande Get-AipServiceKeys. La clé qui a été créée automatiquement pour votre locataire a la date de création la plus ancienne. Vous pouvez donc l’identifier à l’aide de la commande suivante :

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

• Si votre clé de locataire est gérée par vous (BYOK) : dans Azure Key Vault, répétez votre processus de création de clé pour votre locataire Azure Information Protection, puis réexécutez l’applet de commande Use-AipServiceKeyVaultKey pour spécifier l’URI de cette nouvelle clé.

Pour plus d’informations sur la gestion de votre clé de locataire Azure Information Protection, consultez Opérations pour votre clé de locataire Azure Information Protection.

Étapes suivantes

Maintenant que vous avez terminé la migration, passez en revue la feuille de route de déploiement AIP pour la classification, l’étiquetage et la protection pour identifier les autres tâches de déploiement que vous devrez peut-être effectuer.