Phase de migration 2 : configuration côté serveur pour AD RMS

Article
12/29/2023

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

Étape 4 : Exporter des données de configuration à partir d’AD RMS et les importer dans Azure Information Protection

Ce processus comprend deux étapes :

Exportez les données de configuration à partir d’AD RMS en exportant les domaines de publication approuvés (TPD) vers un fichier .xml. Ce processus est le même pour toutes les migrations.
Importez les données de configuration dans Azure Information Protection. Il existe différents processus pour cette étape, en fonction de votre configuration de déploiement AD RMS actuelle et de votre topologie préférée pour votre clé de locataire Azure RMS.

Exportez les données de configuration à partir d’AD RMS

Effectuez la procédure suivante sur tous les groupements AD RMS, pour tous les domaines de publication approuvés qui ont du contenu protégé pour votre organisation. Vous n'avez pas besoin d'exécuter cette procédure sur des groupements sous licence uniquement.

Pour exporter les données de configuration (informations de domaine de publication approuvées)

Connectez-vous au groupement AD RMS en tant qu’utilisateur disposant des autorisations d’administration AD RMS.
À partir de la console de gestion AD RMS (services AD RMS (Active Directory Rights Management Services)), développez le nom du groupement AD RMS, développez Stratégies d’approbation, puis cliquez sur Domaines de publication approuvés.
Dans le volet des résultats, sélectionnez le domaine de publication approuvé, puis, dans le volet Actions, cliquez sur Exporter le domaine de publication approuvé.
Dans la boîte de dialogue Exporter le domaine de publication approuvé :
- Cliquez sur Enregistrer sous et enregistrez sous le chemin d’accès et le nom de fichier de votre choix. Veillez à spécifier .xml comme extension de nom de fichier (cela n’est pas ajouté automatiquement).
- Spécifiez un mot de passe fort et confirmez-le. N’oubliez pas ce mot de passe, car vous en aurez besoin ultérieurement lorsque de l’importation des données de configuration dans Azure Information Protection.
- Ne cochez pas la case pour enregistrer le fichier de domaine approuvé dans RMS version 1.0.

Lorsque vous avez exporté tous les domaines de publication approuvés, vous êtes prêt à démarrer la procédure pour importer ces données dans Azure Information Protection.

Notez que les domaines de publication approuvés incluent les clés de certificat de licence de serveur (SLC) pour déchiffrer les fichiers précédemment protégés. Il est donc important d'exporter (et d'importer ultérieurement dans Azure) tous les domaines de publication approuvés et pas seulement celui actuellement actif.

Par exemple, vous aurez plusieurs domaines de publication approuvés si vous avez mis à niveau vos serveurs AD RMS du mode de chiffrement 1 vers le mode de chiffrement 2. Si vous n'exportez pas et n'importez pas le domaine de publication approuvé qui contient votre clé archivée utilisant le mode de chiffrement 1, à la fin de la migration, les utilisateurs ne pourront pas ouvrir le contenu protégé par la clé du mode de chiffrement 1.

Importez les données de configuration dans Azure Information Protection

Les procédures exactes de cette étape dépendent de votre configuration de déploiement AD RMS actuelle et de votre topologie préférée pour votre clé de locataire Azure Information Protection.

Votre déploiement AD RMS actuel utilise l’une des configurations suivantes pour votre clé de certificat de licence serveur (SLC) :

Protection par mot de passe dans la base de données AD RMS. Il s’agit de la configuration par défaut.
Protection HSM à l’aide d’un module de sécurité matériel (HSM) nCipher.
Protection HSM à l’aide d’un module de sécurité matériel (HSM) d’un fournisseur autre que nCipher.
Mot de passe protégé à l’aide d’un fournisseur de chiffrement externe.

Remarque

Pour plus d’informations sur l’utilisation de modules de sécurité matériels avec AD RMS, consultez Utilisation d’AD RMS avec des modules de sécurité matérielle.

Les deux options de topologie de clé de locataire Azure Information Protection sont : Microsoft gère votre clé de locataire (gérée par Microsoft) ou vous gérez votre clé de locataire (gérée par le client) dans Azure Key Vault. Lorsque vous gérez votre propre clé de locataire Azure Information Protection, ce système est parfois appelé « bring your own key » (BYOK). Pour plus d’informations, consultez l’article Planification et implémentation de votre clé de locataire Azure Information Protection.

Utilisez le tableau suivant pour identifier la procédure à utiliser pour votre migration.

Déploiement AD RMS actuel	Topologie de clé de locataire Azure Information Protection choisie	Instructions de migration
Protection par mot de passe dans la base de données AD RMS	Microsoft-managed	Consultez la procédure de migration d’une clé protégée par logiciel vers une clé protégée par logiciel après ce tableau. Il s’agit du chemin de migration le plus simple et il nécessite uniquement que vous transfériez vos données de configuration vers Azure Information Protection.
Protection HSM à l’aide d’un module de sécurité matériel (HSM) nShield nCipher	Géré par le client (BYOK)	Consultez la procédure de migration d’une clé protégée par HSM vers une clé protégée par HSM après ce tableau. Cela nécessite l'ensemble d'outils Azure Key Vault BYOK et trois séries d'étapes pour d'abord transférer la clé de votre HSM local vers les HSM Azure Key Vault, puis autoriser le service Azure Rights Management d'Azure Information Protection à utiliser votre clé de locataire, et enfin pour transférer vos données de configuration vers Azure Information Protection.
Protection par mot de passe dans la base de données AD RMS	Géré par le client (BYOK)	Consultez la procédure de migration d’une clé protégée par logiciel vers une clé protégée par HSM après ce tableau. Cela nécessite l'ensemble d'outils Azure Key Vault BYOK et quatre séries d'étapes pour d'abord extraire votre clé logicielle et l'importer dans un HSM local, puis transférer la clé de votre HSM local vers les HSM Azure Information Protection, puis transférer ensuite vos données de coffre de clés vers Azure Information Protection, et enfin pour transférer vos données de configuration vers Azure Information Protection.
Protection HSM à l'aide d'un module de sécurité matériel (HSM) provenant d'un fournisseur autre que nCipher	Géré par le client (BYOK)	Contactez le fournisseur de votre HSM pour savoir comment transférer votre clé de ce HSM vers un module de sécurité matériel (HSM) nCipher nShield. Suivez ensuite les instructions de la procédure de migration d’une clé protégée par HSM vers une clé protégée par HSM après ce tableau.
Mot de passe protégé à l’aide d’un fournisseur de chiffrement externe	Géré par le client (BYOK)	Contactez le fournisseur de votre fournisseur de chiffrement pour obtenir des instructions sur le transfert de votre clé vers un module de sécurité matériel (HSM) nShield. Suivez ensuite les instructions de la procédure de migration d’une clé protégée par HSM vers une clé protégée par HSM après ce tableau.

Si vous disposez d’une clé protégée par HSM que vous ne pouvez pas exporter, vous pouvez toujours migrer vers Azure Information Protection en configurant votre groupement AD RMS pour un mode lecture seule. Dans ce mode, le contenu précédemment protégé peut toujours être ouvert, mais le contenu nouvellement protégé utilise une nouvelle clé de locataire gérée par vous (BYOK) ou gérée par Microsoft. Pour plus d’informations, consultez Une mise à jour est disponible pour Office afin de prendre en charge les migrations d’AD RMS vers Azure RMS.

Avant de démarrer ces procédures de migration de clés, assurez-vous que vous pouvez accéder aux fichiers .xml que vous avez créés précédemment lors de l'exportation des domaines de publication approuvés. Par exemple, ceux-ci peuvent être enregistrés sur une clé USB que vous déplacez du serveur AD RMS vers le poste de travail connecté à Internet.

Remarque

Quelle que soit la manière dont vous stockez ces fichiers, utilisez les meilleures pratiques de sécurité pour les protéger, car ces données incluent votre clé privée.

Pour terminer l’étape 4, choisissez et sélectionnez les instructions de votre chemin de migration :

Étape 5 : Activation du service Azure Rights Management

Ouvrez une session PowerShell et exécutez les commandes suivantes :

Connectez-vous au service Azure Rights Management et quand vous y êtes invité, spécifiez vos informations d’identification d’administrateur général :
```
Connect-AipService
```
Activation du service Rights Management Azure :
```
Enable-AipService
```

Que se passe-t-il si votre locataire Azure Information Protection est déjà activé ? Si le service Azure Rights Management est déjà activé pour votre organisation et que vous avez créé des modèles personnalisés que vous souhaitez utiliser après la migration, vous devez exporter et importer ces modèles. Cette procédure est traitée dans l’étape suivante.

Étape 6 : Configuration des modèles importés

Étant donné que les modèles que vous avez importés ont un état par défautArchivé, vous devez modifier cet état pour qu’il soit Publié si vous souhaitez que les utilisateurs puissent utiliser ces modèles avec le service Azure Rights Management.

Les modèles que vous importez à partir d’AD RMS ressemblent et se comportent comme des modèles personnalisés que vous pouvez créer dans le portail Azure. Pour modifier les modèles importés à publier afin que les utilisateurs puissent les voir et les sélectionner dans des applications, consultez Configuration et gestion des modèles pour Azure Information Protection.

Outre la publication de vos modèles nouvellement importés, il n’existe que deux modifications importantes pour les modèles que vous devrez peut-être apporter avant de poursuivre la migration. Pour une expérience plus cohérente pour les utilisateurs pendant le processus de migration, n’apportez pas de modifications supplémentaires aux modèles importés et ne publiez pas les deux modèles par défaut fournis avec Azure Information Protection, et ne créez pas de nouveaux modèles pour le moment. Au lieu de cela, attendez que le processus de migration soit terminé et que vous avez déprovisionné les serveurs AD RMS.

Les modifications de modèle que vous devrez peut-être effectuer pour cette étape :

Si vous avez créé des modèles personnalisés Azure Information Protection avant la migration, vous devez les exporter et les importer manuellement.
Si vos modèles dans AD RMS utilisaient le groupe TOUT LE MONDE, vous devrez peut-être ajouter manuellement des utilisateurs ou des groupes.

Dans AD RMS, le groupe TOUT LE MONDE a accordé des droits à tous les utilisateurs authentifiés par votre Active Directory local, et ce groupe n’est pas pris en charge par Azure Information Protection. L'équivalent le plus proche est un groupe créé automatiquement pour tous les utilisateurs de votre client Microsoft Entra. Si vous utilisiez le groupe TOUT LE MONDE pour vos modèles AD RMS, vous devrez peut-être ajouter des utilisateurs et les droits que vous souhaitez leur accorder.

Procédure si vous avez créé des modèles personnalisés avant la migration

Si vous avez créé des modèles personnalisés avant la migration, avant ou après l’activation du service Azure Rights Management, les modèles ne seront pas disponibles pour les utilisateurs après la migration, même s’ils étaient définis sur Publié. Pour les rendre accessibles aux utilisateurs, vous devez d’abord effectuer les opérations suivantes :

Identifiez ces modèles et notez leur ID de modèle en exécutant Get-AipServiceTemplate.
Exportez les modèles à l’aide de l’applet de commande PowerShell Azure RMS, Export-AipServiceTemplate.
Importez les modèles à l’aide de l’applet de commande PowerShell Azure RMS, Import-AipServiceTemplate.

Vous pouvez ensuite publier ou archiver ces modèles comme vous le feriez pour tout autre modèle que vous créez après la migration.

Procédure si vos modèles dans AD RMS utilisaient le groupe TOUT LE MONDE

Si vos modèles dans AD RMS utilisaient le groupe TOUT LE MONDE, le groupe équivalent le plus proche dans Azure Information Protection est nommé AllStaff-7184AB3F-CCD1-46F3-8233-3E09E9CF0E66@<tenant_name>.onmicrosoft.com. Par exemple, ce groupe peut ressembler à ce qui suit pour Contoso : AllStaff-7184AB3F-CCD1-46F3-8233-3E09E9CF0E66@contoso.onmicrosoft.com. Ce groupe contient tous les utilisateurs de votre locataire Microsoft Entra.

Lorsque vous gérez des modèles et des étiquettes dans le portail Azure, ce groupe s’affiche en tant que nom de domaine de votre locataire dans Microsoft Entra ID. Par exemple, ce groupe peut ressembler à ce qui suit pour Contoso : contoso.onmicrosoft.com. Pour ajouter ce groupe, l’option affiche Ajouter <un nom d’organisation> - Tous les membres.

Si vous ne savez pas si vos modèles AD RMS incluent le groupe TOUT LE MONDE, vous pouvez utiliser l’exemple de script Windows PowerShell suivant pour identifier ces modèles. Pour plus d’informations sur l’utilisation de Windows PowerShell avec AD RMS, consultez Utilisation de Windows PowerShell pour administrer AD RMS.

Vous pouvez facilement ajouter des utilisateurs externes aux modèles lorsque vous convertissez ces modèles en étiquettes dans le portail Azure. Ensuite, dans le volet Ajouter des autorisations, choisissez Entrer les détails pour spécifier manuellement les adresses e-mail de ces utilisateurs.

Pour plus d’informations sur cette configuration, consultez Comment configurer une étiquette pour la protection de Rights Management.

Exemple de script Windows PowerShell pour identifier les modèles AD RMS qui incluent le groupe TOUT LE MONDE

Cette section contient l'exemple de script pour vous aider à identifier les modèles AD RMS pour lesquels le groupe TOUT LE MONDE est défini, comme décrit dans la section précédente.

Exclusion de responsabilité : cet exemple de script n’est pris en charge dans le cadre d’aucun programme ou service de support standard de Microsoft. Cet exemple de script est fourni TEL QUEL sans garantie d’aucune sorte.

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

Étapes suivantes

Passez à la phase 3 - configuration côté client.

Partager via