Migration depuis AD RMS vers Azure Information Protection

  • Article

Suivez les instructions ci-dessous pour migrer votre déploiement d’Active Directory Rights Management Services (AD RMS) vers Azure Information Protection.

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

Bien que cela ne soit pas obligatoire, il peut être utile de lire la documentation suivante avant de commencer la migration. Ces connaissances vous permettront de mieux comprendre le fonctionnement de la technologie lorsqu'elle est pertinente pour votre étape de migration.

  • Planification et implémentation de votre clé de locataire Azure Information Protection : comprenez les options de gestion des 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 (par défaut) ou gérée par vous (la configuration « Bring your own key » ou BYOK).

  • Découverte des services RMS : cette section des notes de déploiement du client RMS explique que l’ordre de découverte des services est le registre, puis le point de connexion de service (SCP), puis le cloud. Pendant le processus de migration lorsque le SCP est toujours installé, vous configurez les clients avec des paramètres de registre pour votre locataire Azure Information Protection afin qu’ils n’utilisent pas le groupement AD RMS renvoyé par le SCP.

  • Présentation 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 les documents et les e-mails.

En outre, si vous n’êtes pas familiarisé avec le fonctionnement d’AD RMS, il peut être 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.

Prérequis pour la migration d’AD RMS vers Azure Information Protection

Avant de commencer la migration vers Azure Information Protection, vérifiez que les prérequis suivants sont en place et que vous comprenez les limitations.

  • 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, groupement RMS unique

      • Forêt unique, groupements RMS à licences multiples

      • Plusieurs forêts, plusieurs groupements RMS

      Remarque

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

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

    Voir 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 de l’administrateur pour le client d’étiquetage unifié Azure Information Protection.

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

    Le processus de migration inclut cette étape d’activation après avoir exporté des clés et des modèles à partir d’AD RMS et les avoir importés 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 avec quelques étapes supplémentaires.

    Office 2010 uniquement :

    Si vous disposez d'ordinateurs exécutant Office 2010, vous devez installer le client Azure Information Protection pour permettre 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 les anciennes versions de Windows et d’Office.

  • Préparation pour Azure Information Protection :

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

    • Prévoir une courte période pendant laquelle l’IRM ne sera pas disponible sur ces serveurs

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

      Il s’agit de la seule interruption du service pendant le processus de migration.

  • Si vous souhaitez gérer votre propre clé de locataire Azure Information Protection à l’aide d’une clé protégée par HSM :

    • Cette configuration facultative nécessite Azure Key Vault et un abonnement Azure qui prend en charge le coffre de clés 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 groupement AD RMS est actuellement en mode chiffrement 1, ne mettez pas à niveau le groupement vers le mode de chiffrement 2 avant de commencer la migration. Au lieu de cela, migrez à l’aide du mode de chiffrement 1 et vous pouvez rekeyiser votre clé de locataire à la fin de la migration, dans le cadre d’une des tâches post-migration.

Pour confirmer le mode de chiffrement AD RMS pour Windows Server 2012 R2 et Windows 2012 : Propriétés du groupement AD RMS Onglet >général.

Limitations de la migration

  • Si vous avez des logiciels et des clients qui ne sont pas pris en charge par le service Rights Management utilisé par Azure Information Protection, ils ne pourront pas protéger ou consommer du contenu protégé par Azure Rights Management. Veillez à consulter les sections relatives aux applications et clients pris en charge dans la section Configuration requise pour Azure Information Protection.

  • Si votre déploiement AD RMS est configuré pour collaborer avec des partenaires externes (par exemple, à l’aide de domaines d’utilisateur ou de fédération approuvés), ils doivent également migrer vers Azure Information Protection en même temps que votre migration, ou dès que possible. Pour continuer à accéder au contenu précédemment protégé par votre organisation à l’aide d’Azure Information Protection, ils doivent apporter des modifications à la configuration du client qui sont similaires à celles que vous apportez et qui sont incluses dans ce document.

    En raison des variantes de configuration possibles que vos partenaires peuvent avoir, les instructions exactes de cette reconfiguration ne font pas partie du champ d'application du présent document. Toutefois, consultez la section suivante pour obtenir des conseils de planification et pour obtenir de l’aide supplémentaire, contactez le support Microsoft.

Planification de la migration si vous collaborez avec des partenaires externes

Incluez 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 suivantes, vérifiez que les éléments suivants sont en place :

  • Ils disposent d’un locataire Microsoft Entra qui prend en charge le service Azure Rights Management.

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

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

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

  • Ils vous fournissent les URL de leur groupement AD RMS et de leur service Azure Rights Management, afin que vous puissiez configurer vos clients migrés pour qu’ils redirigent les demandes de contenu protégé par AD RMS vers le service Azure Rights Management de leur locataire. Les instructions de configuration de la redirection du client sont à l’étape 7.

  • Ils importent leurs clés racines de groupement AD RMS (SLC) dans leur locataire avant que vous ne commenciez à migrer vos utilisateurs. De même, vous devez importer vos clés racine de groupement AD RMS avant de commencer à migrer leurs utilisateurs. Les instructions d’importation de la clé sont abordées 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 à différents moments et par différents administrateurs.

Phase 1 : Préparation de la migration

Pour plus d’informations, consultez 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 connaître l’URL du service Azure Rights Management de votre locataire pour effectuer la plupart des étapes de migration, et vous pouvez identifier cette valeur à l’aide de PowerShell.

Étape 2. Préparation de la migration du client

Si vous ne pouvez pas migrer tous les clients en même temps et que vous le ferez par lots, utilisez des contrôles d'intégration et déployez un script de pré-migration. Toutefois, si vous allez migrer tout en même temps plutôt que d’effectuer une migration par phases, vous pouvez ignorer cette étape.

Étape 3 : Préparez votre déploiement Exchange pour la migration

Cette étape est requise si vous utilisez actuellement la fonctionnalité IRM d’Exchange Online ou Exchange en local pour protéger les e-mails. Toutefois, si vous allez migrer tout en même temps plutôt que d’effectuer une migration par 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 des données de configuration à partir d’AD RMS et 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 vous 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 votre configuration de clé AD RMS :

  • Migration d'une clé protégée par logiciel à une autre clé protégée par logiciel :

    Gestion centralisée des clés basées sur des mots de passe dans AD RMS vers une clé de locataire Azure Information Protection gérée par Microsoft. Il s’agit du chemin de migration le plus simple et aucune étape supplémentaire n’est nécessaire.

  • Migration d’une clé protégée par HSM à une autre clé protégée par HSM :

    Clés stockées par un HSM pour AD RMS vers une clé de locataire Azure Information Protection gérée par le client (le scénario « bring your own key » ou BYOK). 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 Rights Management.

  • Migration d'une clé protégée par logiciel vers une clé protégée par HSM :

    Des clés gérées de manière centralisée et basées sur des mots de passe dans AD RMS vers des clés de locataire Azure Information Protection gérées par le client (le scénario « bring your own key » ou BYOK). C'est cette option qui nécessite le plus de configuration, 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 nCipher sur site 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. Vérification du service Azure Rights Management

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

Étape 6. Configurer des 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 les voir et les utiliser, vous devez modifier l’état du modèle à publier 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 utiliser 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 et aux ordinateurs des organisations partenaires si vous avez collaboré avec eux pendant l’exécution d’AD RMS.

Phase 4 : Configuration des services de prise en charge

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

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

Cette étape termine la migration AD RMS pour Exchange Online afin d’utiliser désormais le service Azure Rights Management.

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

Cette étape termine la migration AD RMS pour Exchange ou SharePoint localement pour utiliser désormais 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 : Déprovisionner AD RMS

Lorsque vous avez confirmé que tous les ordinateurs Windows utilisent le service Azure Rights Management et n’accèdent plus à vos serveurs AD RMS, vous pouvez déprovisionner votre déploiement AD RMS.

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

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

Les contrôles d’intégration que vous avez configurés pendant la phase de préparation ne sont plus nécessaires. Toutefois, si vous n’avez pas utilisé de contrôles d’intégration, car vous avez choisi de migrer tout en même temps plutôt que d’effectuer une migration par 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 Gestion des modèles de stratégie de droits AD RMS (automatisée).

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 recommandée si vous ne fonctionniez pas en mode de chiffrement 2 avant la migration.

Étapes suivantes

Pour démarrer la migration, accédez à laPhase 1 - préparation.