Exécution d’une migration de domaine Active Directory pour Dell Security Server

• Dell Security Management Server (anciennement Dell Data Protection | Enterprise Edition) est mis en place et lié à un domaine.
• Un domaine existant a été ajouté à la section « domain » dans la console de l'interface utilisateur Web.
• Les points de terminaison ont été activés sur le serveur.
• Une migration du domaine est requise.
• Nous prévoyons également de migrer l'historique SID des objets AD.
• Les points de terminaison disposent d'une connectivité complète au serveur et peuvent récupérer des stratégies sur l'ancien domaine avant que le processus de migration du domaine démarre.
• Les données chiffrées sur les points de terminaison sont entièrement accessibles, les points de terminaison sont activés et il est possible de les désactiver et de les réactiver. Nous pouvons confirmer que les activations se produisent sans problème en effectuant un rapide WSDeactivate des points de terminaison.

Les étapes globales ne sont pas trop complexes, mais il est nécessaire de comprendre que si l'ensemble du processus n'est pas correctement exécuté, les données peuvent être perdues ou une récupération des machines peut être nécessaire. Enfin, même si ce processus peut être effectué sur n’importe quelle version de Dell Security Management Server et du client, Dell Technologies recommande d’installer au moins un client 8.3.0 et un serveur 8.5, car plusieurs améliorations ont été apportées depuis, ce qui facilite le processus de migration global du côté de Dell Security Management Server. Vous trouverez ci-dessous une vue d’ensemble du fonctionnement du processus global et des réponses aux questions les plus pertinentes.

La première étape consiste à déterminer si une migration de domaine est requise. Dans certaines situations, comme lorsqu'une entreprise migre, par exemple, vers Office 365, il suffit d'ajouter un alias et de le définir comme UPN principal pour les utilisateurs AD. Il ne s'agit pas d'une véritable migration de domaine et aucune autre action n'est requise sur le serveur Dell Data Protection | Enterprise Edition que l'ajout d'un nouvel alias à la liste d'alias de domaine dans la section Paramètres, Liste d'alias de domaine. C'est lorsqu'un nouveau domaine est créé et que les objets AD doivent être déplacés de l'ancien domaine mis hors service vers le nouveau qu'une migration de domaine doit être planifiée.

Chaque fois qu'une migration de domaine est planifiée, la première étape consiste à migrer également l'historique SID. Pour que la migration du domaine réussisse du côté de Dell Security Management Server, il est nécessaire de conserver l’historique SID, sinon Dell Security Management Server considère les objets AD comme nouveaux et, par conséquent, après réactivation nous ne pouvons pas utiliser les mêmes clés de chiffrement. Dell exige de migrer l'historique SID. Nous n'allons pas consacrer du temps à décrire l'exécution d'une migration de domaine, car il ne s'agit pas d'une tâche Dell Data Protection | Encryption, mais sachez qu'il existe plusieurs outils comme ADMT de Microsoft qui permettent à une organisation de migrer un domaine A vers un domaine B. Comme indiqué ci-dessus, une migration de l'historique SiD est nécessaire pour conserver la persistance en termes de clés. La migration de l'historique SID signifie que nous ajoutons dans AD les données à l'attribut d'historique SID de l'ancien utilisateur SID, celui d'avant la migration, garantissant ainsi la continuité dans les objets migrés.

En règle générale, côté AD :

• Lorsqu'un objet est renommé, la valeur de l'attribut objectSID (le SID) n'est pas modifiée. Lorsque vous déplacez un objet d’un domaine à un autre, l’objectSID doit changer, car il est spécifique au domaine, et l’ancien SID est ajouté à l’attribut SIDHistory (en supposant qu’il soit migré). Vous pouvez afficher SIDHistory à l’aide de ADSI Edit (vous pouvez l’afficher en hexadécimal ou décimal). S'il n'y a aucune valeur, il n'y a pas d'historique SID ou l'objet n'a jamais été déplacé d'un autre domaine.
• SIDhistory est disponible uniquement lors de la migration de comptes entre des domaines ou des forêts.

Vous trouverez ci-dessous une capture d’écran expliquant comment déterminer si SIDHistory a été migré à l’aide de l’éditeur d’attributs :

Une fois que nous avons confirmé que les SIDHistory des utilisateurs et des machines migrés ont également été déplacés, nous pouvons procéder à la configuration de Dell Security Management Server. Si vous avez besoin d'informations supplémentaires sur l'exécution d'une migration de domaine et sur la conservation de l'historique SID, consultez la documentation Microsoft suivante :

• https://www.microsoft.com/fr-fr/download/details.aspx?id=19188
• https://technet.microsoft.com/fr-fr/library/cc974332(v=ws.10).aspx
• https://technet.microsoft.com/fr-fr/library/cc974384(v=ws.10).aspx

Vous trouverez ci-dessous des informations sur ce qui se passe lors d’une migration de domaine côté Dell Security Management Server.

1. Côté client :
   • Nous résolvons l'UPN utilisateur sur le SID. Nous recherchons son SID dans le fichier Vault. Nous ne le trouvons pas.
   • Nous décidons qu’il s’agit d’un nouvel utilisateur et nous contactons le serveur de sécurité, en transmettant l’UPN et le mot de passe comme pour une demande d’activation classique.
2. Côté serveur :
   • Nous obtenons la demande d'activation. Nous contactons Active Directory et cherchons l'UPN. Ensuite, nous trions l'utilisateur, et dans le cadre de ce processus de tri, nous constatons que le SID dans la table Entity ne correspond pas au SID dans AD. Nous examinons le SIDHistory pour rechercher le SID dans notre table Entity. Si nous ne le trouvons pas, nous créons une exception et l’activation échoue, car nous avons déjà ce SCID en place. Lorsque nous trouvons le SID, nous mettons à jour la table Entity avec le nouveau SID (dans la partie UID, la première partie est le domaine et nous le mettons à jour, ainsi que la partie domaine du point de terminaison).
   • Ensuite, nous transmettons au client les anciennes clés, la stratégie, le DCID, etc. (comme s'il s'agissait d'une réactivation).
3. Retour sur le client :
   • Le point de terminaison reçoit ces informations et ajoute une entrée dans le fichier credsys.vlt, voit que l'utilisateur est activé et que l'utilisateur à ce stade est connecté normalement.

L’un des points clés du côté de Dell Security Management Server est la compréhension de la nécessité d’ajouter un nouveau domaine dans l’interface utilisateur Web pour que les éléments fonctionnent avec les nouveaux et anciens utilisateurs lors de l’activation ou de la réactivation.

Lors d’une migration de domaine, nous n’ajoutons pas le nouveau domaine à la console Dell Security Management Server SI le parent du domaine racine de l’ancien et du nouveau domaine migré existe. Dans ce cas, il suffit d’ajouter le nouveau domaine sous la forme d’un alias dans la section « Settings », « Domain Alias List ». (Et nous supposons qu’il existe une relation de confiance bidirectionnelle entre le parent et le nouveau domaine enfant.) Le compte de service du domaine racine doit être configuré si possible dans le domaine parent. Si, au lieu de cela, nous migrons un domaine A.local vers B.local et que les deux domaines ne sont pas enfants du même domaine racine ou qu’ils appartiennent à une forêt différente, nous avons besoin d’un nouveau domaine ajouté sous notre console, car nous devons lier tous les points de terminaison existants au nouveau domaine et à un nouveau compte de service.

La compréhension des points ci-dessus concernant la configuration correcte de Dell Security Management Server est cruciale, afin de ne pas se confronter à plusieurs problèmes après la migration. Il est également essentiel de comprendre le type de confiance en place entre ces domaines et leurs domaines racine (le cas échéant) et la liste de leurs domaines actuels dans la console Dell Security Management Server. La règle est simple : si vous avez une sorte de confiance entre le parent et l'enfant, alors il suffit d'avoir en place dans le serveur Dell Data Protection | Enterprise Edition le domaine racine et les alias. Sinon, nous devons ajouter autant de domaines enfants sous Dell Security Management Server que leurs sous-domaines réels, et cette règle s'applique également à la migration de domaine.

Enfin, d’une manière plus générale, nous ne devrions *jamais* ajouter simultanément un domaine enfant et un domaine parent, car le fait que le même utilisateur soit potentiellement visible aux deux niveaux ne fonctionne pas pour nous. De plus, la suppression d’un domaine n’est pas (encore) une tâche entièrement prise en charge côté Dell Security Management Server.

Si la version du client est la version 8.2.1 ou une version antérieure et que la version du serveur est la version 8.3.1 ou une version antérieure, WSDeactivate est une étape requise car nous n’avons pas renommé automatiquement la partie du domaine de point de terminaison côté serveur. Cela ne s'applique pas aux dernières versions de Dell Security Management Server ou de nos points de terminaison.

Les anciens domaines ne peuvent pas être supprimés de la base de données Dell Security Management Server manuellement ou à l’aide de la console. Cela est dû au fait que Dell Security Management Server recherche un utilisateur ou un groupe, puis détermine qu'il s'agit d'une appartenance à un domaine. Pour cette raison, lorsqu'un domaine est supprimé, il est nécessaire que tous les objets qui font partie de ce domaine soient également supprimés. Aucune de ces options n'est prise en charge à ce stade. Dell cherche à modifier ce comportement dans les futures versions de Dell Security Management Server, mais à ce stade, il ne s'agit pas d'une tâche prise en charge ou viable. Notez également que si vous choisissez de marquer (manuellement) le domaine comme supprimé dans la base de données, une erreur s’affiche dans les journaux du serveur toutes les 15 minutes pour tous les utilisateurs et groupes orphelins associés.

Si Shield est désinstallé sur un point de terminaison migré, les mêmes étapes nécessaires pour appliquer une réactivation normale (autre que le domaine) à l'aide du même ID Shield sont alors nécessaires. Dans les fichiers communs chiffrés, nous devons appliquer le même DCID dans le registre avant de laisser le point de terminaison se réactiver par rapport à Dell Data Protection | Enterprise Edition Server ou Dell Security Management Server. Si vous avez des questions, contactez l'équipe de support technique pour obtenir de l'aide.

Non, aucune nouvelle licence de domaine n'est requise depuis Dell Data Protection | Enterprise Edition Server 8.x. Pour les anciennes versions de Dell Data Protection | Enterprise Edition Server, une nouvelle licence est toujours requise. Contactez l'équipe de support technique pour plus d'informations.