Migration d’AD RMS vers Azure Information Protection

Utilisez l’ensemble d’instructions suivant pour migrer votre déploiement des services AD RMS (Active Directory Rights Management Services) vers Azure Information Protection.

Après la migration, les serveurs AD RMS ne sont plus utilisés, mais les utilisateurs ont toujours accès aux documents et e-mails que votre organisation a protégés à l’aide d’AD RMS. Le contenu nouvellement protégé utilisera le service Azure RMS (Azure Rights Management Service) à partir d’Azure Information Protection.

Bien que ceci ne soit pas obligatoire, il peut s’avérer utile de lire ce qui suit avant de commencer la migration, ceci pour une meilleure compréhension du fonctionnement de la technologie quand elle s’applique à votre étape de migration.

  • Planification et implémentation de votre clé de locataire Azure Information Protection : découvrez les options de gestion clés dont vous disposez pour votre locataire Azure Information Protection où votre clé SLC équivalente dans le cloud est gérée par Microsoft (l’option par défaut) ou gérée par vous (la configuration BYOK).

  • Découverte de service RMS : cette section des notes de déploiement du client RMS explique que l’ordre de découverte de service est registre, puis le point de connexion de service (SCP), puis le cloud. Pendant le processus de migration, alors que le point de connexion de service est toujours installé, vous configurez les clients avec des paramètres de Registre pour votre locataire Azure Information Protection de façon à ce qu’ils n’utilisent pas le cluster AD RMS retourné depuis le point de connexion de service.

  • Vue d’ensemble du connecteur Microsoft Rights Management : cette section de la documentation du connecteur RMS explique comment vos serveurs locaux peuvent se connecter au service Azure Rights Management pour protéger des documents et des e-mails.

En outre, si vous n’êtes pas familiarisé avec le fonctionnement d’AD RMS, vous pouvez trouver utile de lire comment Fonctionne Azure RMS ? Sous le capot pour vous aider à identifier les processus technologiques qui sont identiques ou différents pour la version cloud.

Conditions préalables à une migration d’AD RMS vers Azure Information Protection

Avant de procéder à la migration vers Azure Information Protection, assurez-vous que les conditions préalables suivantes sont réunies et que vous comprenez les limitations de ce processus.

  • Un déploiement RMS pris en charge :

    • Les versions suivantes d’AD RMS prennent en charge une migration vers Azure Information Protection :

      • Windows Server 2012 (x64)

      • Windows Server 2012 R2 (x64)

      • Windows Server 2016 (x64)

    • Toutes les topologies AD RMS valides sont prises en charge :

      • Forêt unique, cluster RMS unique

      • Forêt unique, plusieurs clusters RMS dédiés uniquement à la gestion des licences

      • Plusieurs forêts, plusieurs clusters RMS

      Notes

      Par défaut, plusieurs clusters AD RMS migrent vers un seul locataire pour Azure Information Protection. Si vous voulez des locataires séparés pour Azure Information Protection, vous devez les traiter comme des migrations différentes. Une clé d’un cluster RMS ne peut pas être importée dans plusieurs locataires.

  • Toutes les conditions requises pour exécuter Azure Information Protection, y compris un abonnement pour Azure Information Protection (le service Azure Rights Management n’est pas activé) :

    Consultez Configuration requise pour Azure Information Protection.

    Le client Azure Information Protection est requis pour la classification et l’étiquetage, et facultatif, mais recommandé si vous souhaitez uniquement protéger les données.

    Pour plus d’informations, consultez les guides d’administration pour le client d’étiquetage unifié Azure Information Protection.

    Bien que vous deviez disposer d’un abonnement pour Azure Information Protection avant de pouvoir effectuer une migration à partir d’AD RMS, nous vous recommandons de ne pas activer le service Rights Management pour votre locataire avant de démarrer la migration.

    Le processus de migration inclut cette étape d’activation après l’exportation des clés et modèles à partir d’AD RMS, et leur importation dans votre locataire pour Azure Information Protection. Toutefois, si le service Rights Management est déjà activé, vous pouvez toujours migrer à partir d’AD RMS en suivant quelques étapes supplémentaires.

    Office 2010 uniquement :

    Si vous avez des ordinateurs qui exécutent Office 2010, vous devez installer le client Azure Information Protection pour fournir la possibilité d’authentifier les utilisateurs auprès des services cloud.

    Important

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

  • Préparation d’Azure Information Protection :

  • Si vous avez utilisé la fonctionnalité IRM (Gestion des droits relatifs à l’information) d’Exchange Server (par exemple, règles de transport et Outlook Web Access) ou SharePoint Server avec AD RMS :

    • Prévoyez une courte période pendant laquelle cette fonctionnalité ne sera pas disponible sur ces serveurs.

      Vous pouvez continuer à utiliser la fonctionnalité IRM sur ces serveurs après la migration. Toutefois, une des étapes de migration consiste à désactiver temporairement le service IRM, à installer et à configurer un connecteur, à reconfigurer les serveurs, puis à réactiver le service IRM.

      Il s'agit de l'unique interruption de service durant le processus de migration.

  • Si vous voulez gérer votre propre clé de locataire Azure Information Protection en utilisant une clé protégée par HSM :

    • Cette configuration facultative nécessite Azure Key Vault et un abonnement Azure qui prend en charge Key Vault avec des clés protégées par HSM. Pour plus d’informations, consultez la page tarification d’Azure Key Vault.

Considérations relatives au mode de chiffrement

Si votre cluster AD RMS est actuellement en mode de chiffrement 1, ne le mettez pas à niveau vers le mode de chiffrement 2 avant de commencer la migration. Au lieu de cela, effectuez la migration en mode de chiffrement 1. Vous pouvez alors renouveler votre clé une fois la migration terminée (dans le cadre des tâches suivant la migration).

Pour confirmer le mode de chiffrement AD RMS pour Windows Server 2012 R2 et Windows 2012 : onglet Général des propriétés > du cluster AD RMS.

Limites de la migration

  • Si vous disposez de logiciels et de clients non pris en charge par le service Rights Management qui est utilisé par Azure Information Protection, ceux-ci ne peuvent pas protéger ou utiliser du contenu protégé par Azure Rights Management. Veillez à vérifier les sections applications et clients prises en charge à partir des conditions requises pour Azure Information Protection.

  • Si votre déploiement des services AD RMS est configuré pour collaborer avec des partenaires externes (par exemple, en utilisant des domaines d’utilisateurs approuvés ou une fédération), ceux-ci doivent également migrer vers Azure Information Protection, soit au moment de votre migration, soit dès que possible par la suite. Pour continuer à accéder au contenu que votre organisation protégeait précédemment à l’aide d’Azure Information Protection, les utilisateurs doivent apporter à la configuration du client des modifications similaires à celles que vous apportez, qui sont incluses dans ce document.

    En raison de la diversité des configurations possibles de vos partenaires, des instructions précises pour cette reconfiguration sortent du cadre de ce document. Toutefois, consultez la section suivante pour obtenir des conseils sur la planification et contactez le support technique Microsoft pour une aide supplémentaire.

Planification de la migration si vous collaborez avec des partenaires externes

Ajoutez vos partenaires AD RMS dans votre phase de planification de la migration, car ils doivent également migrer vers Azure Information Protection. Avant d’effectuer l’une des étapes de migration ci-après, vérifiez que les conditions suivantes sont réunies :

  • Ils ont un locataire Azure Active Directory qui prend en charge le service Azure Rights Management.

    Par exemple, ils disposent d’un abonnement Office 365 E3 ou E5, ou Enterprise Mobility + Security, ou autonome pour Azure Information Protection.

  • Leur service Azure Rights Management n’est pas encore activé, mais ils connaissent leur URL de service Azure Rights Management.

    Ils peuvent obtenir ces informations en installant l’outil Azure Rights Management, en se connectant au service (Connect-AipService), puis en affichant les informations de leur locataire pour le service Azure Rights Management (Get-AipServiceConfiguration).

  • Ils vous fournissent les URL de leur cluster AD RMS et l’URL de service Azure Rights Management pour que vous puissiez configurer les clients migrés afin de rediriger les demandes de contenu protégé AD RMS vers le service Azure Rights Management de leur locataire. Les instructions pour la configuration de la redirection des clients figurent à l’étape 7.

  • Ils importent leurs clés racines de cluster (SLC) AD RMS dans leur locataire avant que vous ne commenciez à migrer vos utilisateurs. De même, vous devez importer vos clés racines de cluster AD RMS avant qu’ils ne commencent à migrer leurs utilisateurs. Les instructions d’importation de la clé sont décrites dans ce processus de migration, étape 4. Exportez les données de configuration à partir d’AD RMS et importez-les dans Azure Information Protection.

Présentation des étapes de migration d’AD RMS vers Azure Information Protection

Les étapes de migration peuvent être divisées en cinq phases qui peuvent être effectuées à des moments différents et par des administrateurs différents.

Phase 1 : Préparation de la migration

Pour plus d’informations, consultez LA PHASE 1 : PRÉPARATION DE LA MIGRATION.

Étape 1 : Installer le module PowerShell AIPService et identifier l’URL de votre locataire

Le processus de migration vous oblige à exécuter une ou plusieurs applets de commande PowerShell à partir du module AIPService. Vous devez également connaître l’URL du service Azure Rights Management de votre locataire pour pouvoir réaliser différentes étapes de migration, et vous pouvez identifier cette valeur à l’aide de PowerShell.

Étape 2. Préparer la migration des clients

Si vous ne pouvez pas migrer tous les clients à la fois et que vous allez les migrer par lots, utilisez les contrôles d’intégration et déployez un script de prémigration. Toutefois, si vous les migrez tous à la fois au lieu d’effectuer une migration en plusieurs phases, vous pouvez ignorer cette étape.

Étape 3 : Préparer le déploiement Exchange pour la migration

Cette étape est nécessaire si vous utilisez la fonctionnalité IRM d’Exchange Online ou Exchange sur site afin de protéger les e-mails. Toutefois, si vous les migrez tous à la fois au lieu d’effectuer une migration en plusieurs phases, vous pouvez ignorer cette étape.

Phase 2 : Configuration côté serveur pour AD RMS

Pour plus d’informations, consultez PHASE 2 : CONFIGURATION CÔTÉ SERVEUR POUR AD RMS.

Étape 4. Exporter les données de configuration d’AD RMS, puis les importer dans Azure Information Protection

Vous exportez les données de configuration (clés, modèles, URL) d’AD RMS vers un fichier XML, puis chargez ce fichier dans le service Azure Rights Management à partir d’Azure Information Protection, à l’aide de l’applet de commande PowerShell Import-AipServiceTpd. Ensuite, identifiez la clé de certificat de licence serveur (SLC) importée à utiliser comme clé de locataire pour le service Azure Rights Management. Des étapes supplémentaires peuvent être nécessaires en fonction de la configuration de votre clé AD RMS :

  • Migration de clé protégée par logiciel à clé protégée par logiciel :

    De clé basée sur un mot de passe et gérée de façon centralisée dans AD RMS à clé de locataire Azure Information Protection gérée par Microsoft. Ce chemin de migration le plus simple ne nécessite aucune étape supplémentaire.

  • Clé protégée par HSM vers la migration de clé protégée par HSM :

    De clé stockée par un module HSM pour AD RMS à clé de locataire Azure Information Protection gérée par le client (scénario BYOK, « Bring Your Own Key »). Cela nécessite des étapes supplémentaires pour transférer la clé de votre HSM nCipher local vers Azure Key Vault et autoriser le service Azure Rights Management à utiliser cette clé. Votre clé protégée par HSM existante doit être protégée par module. Les clés protégées par OCS ne sont pas prises en charge par les services RMS.

  • Migration de clé protégée par logiciel à clé protégée par HSM :

    De clé basée sur un mot de passe et gérée de façon centralisée dans AD RMS à clé de locataire Azure Information Protection gérée par le client (scénario BYOK, « Bring Your Own Key »). Cela nécessite la configuration la plus importante, car vous devez d’abord extraire votre clé logicielle et l’importer dans un HSM local, puis effectuer les étapes supplémentaires pour transférer la clé de votre HSM de chiffrement local vers un HSM Azure Key Vault et autoriser le service Azure Rights Management à utiliser le coffre de clés qui stocke la clé.

Étape 5. Activer le service Azure Rights Management

Si possible, effectuez cette étape après le processus d'importation et non avant. Des étapes supplémentaires sont nécessaires si le service a été activé avant l’importation.

Étape 6. Configurer les modèles importés

Lorsque vous importez vos modèles de stratégie de droits, leur état est archivé. Si vous souhaitez que les utilisateurs puissent voir et utiliser ces modèles, vous devez changer leur état en publié dans le portail Azure Classic.

Phase 3 : Configuration côté client

Pour plus d’informations, consultez PHASE 3 : CONFIGURATION CÔTÉ CLIENT.

Étape 7 : Reconfigurer les ordinateurs Windows pour qu’ils utilisent Azure Information Protection

Les ordinateurs Windows existants doivent être reconfigurés pour utiliser le service Azure Rights Management au lieu d’AD RMS. Cette étape s'applique aux ordinateurs de votre organisation ainsi qu'à ceux des organisations partenaires avec lesquelles vous avez collaboré lorsque vous exécutiez AD RMS.

Phase 4 : Prise en charge de la configuration des services

Pour plus d’informations, consultez PHASE 4 : PRISE EN CHARGE DE LA CONFIGURATION DES SERVICES.

Étape 8 : Configurer l’intégration de l’IRM pour Exchange Online

Cette étape termine la migration AD RMS pour Exchange Online pour à présent utiliser le service Azure Rights Management.

Étape 9 : Configurer l’intégration d’IRM pour Exchange Server et SharePoint Server

Cette étape termine la migration AD RMS pour Exchange ou SharePoint sur site pour à présent utiliser le service Azure Rights Management, qui nécessite le déploiement du connecteur Rights Management.

Phase 5 : Tâches post-migration

Pour plus d’informations, consultez PHASE 5 : TÂCHES POST MIGRATION.

Étape 10 : Annuler l’approvisionnement d’AD RMS

Après avoir vérifié que tous les ordinateurs Windows utilisent le service Azure Rights Management et n’accèdent plus aux serveurs AD RMS, vous pouvez annuler l’approvisionnement de votre déploiement AD RMS.

Étape 11 : Effectuer les tâches de migration des clients

Si vous avez déployé l’extension d’appareil mobile pour prendre en charge des appareils mobiles tels que des iPad et téléphones iOS, des téléphones et tablettes Android, des téléphones et tablettes Windows et des ordinateurs Mac, vous devez supprimer les enregistrements SRV dans le système DNS qui redirigeaient ces clients pour utiliser AD RMS.

Les contrôles d’intégration que vous avez configurés au cours de la phase de préparation ne sont plus nécessaires. Toutefois, si vous n’utilisez pas de contrôles d’intégration parce que vous avez choisi de tout migrer à la fois au lieu d’effectuer une migration en plusieurs phases, vous pouvez ignorer les instructions pour supprimer les contrôles d’intégration.

Si vos ordinateurs Windows exécutent Office 2010, vérifiez si vous devez désactiver la tâche de gestion des modèles de stratégie de droits AD RMS (automatique).

Important

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

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

Cette étape est recommandée si vous n’utilisiez pas le mode de chiffrement 2 avant la migration.

Étapes suivantes

Pour démarrer la migration, accédez à Phase 1 : Préparation.