Cet article décrit la procédure de migration d’une configuration single-forest de CoreView Hybrid Connector vers une topologie multi-forest Active Directory.
S’il s’agit de la première fois que vous installez CoreView Hybrid Connector, il ne s’agit pas d’une migration, mais d’une première installation ; veuillez donc consulter cet article : Installation de Hybrid Connector.
Si, au contraire, vous avez déjà configuré le Hybrid Connector pour l’une de vos forêts Active Directory et que vous devez maintenant en ajouter d’autres, en passant d’une configuration single-forest à une configuration multi-forest, alors la procédure suivante est faite pour vous.
Veuillez noter que le processus de migration détaillé dans cet article implique une période d’interruption pendant laquelle vous devrez mettre en place la nouvelle configuration. Pour cette raison, nous vous recommandons de planifier cette activité pendant une fenêtre de maintenance prévue.
Gardez à l’esprit que l’interruption affectera les actions de gestion on-premises, aussi bien personnalisées que natives. Il est donc essentiel, pendant la migration, de veiller à ce que la session de gestion soit correctement désactivée (comme nous le décrirons dans les étapes suivantes).
Enfin, rappelez-vous que la configuration multi-forest n’est prise en charge que sous Windows 2022 et 2019. Ainsi, si votre CoreView Hybrid Connector s’exécute sur un serveur Windows 2016, vous devrez prévoir la mise en place d’un nouveau serveur avec une version prise en charge. Veillez à tester toutes les activations réseau nécessaires décrites ici : Hybrid Connector : prérequis.
Comptes de service
La structure de la version multi-forest de CoreView Hybrid Connector reprend celle de Microsoft AD Connect. Bien qu’il n’y ait qu’un seul serveur on-premises hébergeant l’agent, ce serveur doit pouvoir joindre le contrôleur de domaine choisi pour chaque forêt que vous souhaitez intégrer.
La technologie de connexion repose systématiquement sur Remoting PowerShell (vous trouverez plus d’informations dans cet article Microsoft). Il est donc nécessaire d’équiper le contrôleur de domaine de chaque forêt d’un compte de service dédié. Cela signifie qu’il n’est pas nécessaire d’avoir un Active Directory Trust ou des Enterprise Admins.
Si une forêt possède plus d’un serveur Exchange, nous vous suggérons d’attribuer un compte de service supplémentaire à chaque organisation Exchange additionnelle.
Comme pour la version single-forest, nous recommandons d’utiliser un contrôleur de domaine de chaque forêt auquel le rôle Global Catalog est attribué. Cela est dû à l’exigence d’importer les membres de groupes répartis sur plusieurs domaines et forêts. Sans connexion à un Global Catalog, ceux-ci ne pourraient pas être importés.
Pour les forêts organisées en relations parent-enfant, vous n’avez besoin que d’un contrôleur de domaine du domaine parent. Le processus d’importation des données de CoreView peut découvrir chaque domaine enfant et importer les données associées.
Vérifications préalables
Comme pour la version single-forest, la mise en place d’une topologie multi-forest nécessite une préparation minutieuse ainsi qu’une vérification des règles réseau et des autorisations de compte pour chaque forêt.
Ces articles fournissent des instructions pour utiliser l’outil de diagnostic de CoreView Hybrid Connector : Outil de diagnostic.
Nous vous suggérons d’exécuter tous les tests pour chaque compte de service dans chaque forêt qui fera partie de la nouvelle configuration multi-forest. Si vous prévoyez également de changer le serveur exécutant CoreView Hybrid Connector, nous vous recommandons d’exécuter tous les tests sur le nouveau serveur avant de procéder aux étapes de migration décrites dans la section suivante. De cette façon, vous pouvez simuler le même comportement que Hybrid Connector et valider les connexions réseau en utilisant la même adresse IP source. En effet, Docker RTE pour Windows utilise NAT par conception, en s’appuyant sur la même IP que la machine hôte pour se connecter au réseau.
Migration
Si vous effectuez l’installation sur un nouveau serveur, assurez-vous de télécharger et d’installer la version la plus récente du package Hybrid Connector.
Cependant, si vous devez mettre à niveau la version single-forest de Hybrid Connector sur le même serveur, vous devez désinstaller la version actuelle puis la réinstaller.
Avant de désinstaller, assurez-vous de désactiver la fonctionnalité “Auto-enable management session”, comme indiqué ci-dessous :
Ensuite, désactivez la gestion :
Allez maintenant dans : C:\Temp
et ouvrez le fichier suivant : Forward365.Service.PowershellService.Agent.exe.config
Vous devrez copier-coller tous les paramètres de clé personnalisés trouvés dans la section appSettings dans le même fichier sur votre serveur Windows 2019.
Si le Hybrid Connector single-forest s’exécute sur un autre serveur, il est maintenant nécessaire d’arrêter le service “CoreView Agent” sur la machine on-premise et de le définir comme désactivé :
Vous devez maintenant vous connecter au portail CoreView, aller dans “Paramètres” > “My organization” > section “On-premises”, puis cliquer sur le bouton “delete configuration” :
À partir de là, vous devrez contacter votre interlocuteur CoreView pour demander la reconfiguration de votre Tenant vers la version multi-forest (FT:MULTIFOREST). Si vous utilisiez auparavant la version 2016, assurez-vous d’avoir mis à jour vers la version 2019 du système d’exploitation sur le backend (FT:HYBRIDOS2019).
Ensuite, installez la dernière version du package Hybrid Connector sur le serveur cible. Si vous utilisez le même serveur que pour la configuration single-forest, vous devrez d’abord désinstaller la version de l’agent via Panneau de configuration > Programmes et fonctionnalités :
Une fois la dernière version du package installée avec succès, une page s’ouvrira automatiquement sur votre serveur à l’adresse localhost:1234. Il s’agit d’une page de configuration de l’agent qui sera utilisée exclusivement à cette étape pour configurer la clé API, qui sera générée à l’étape suivante.
La page de configuration prend uniquement en charge Chrome et Edge ; assurez-vous donc d’utiliser un navigateur pris en charge.
Ensuite, assurez-vous de respecter toutes les exigences listées sur la page, que vous pouvez consulter ici. Une fois cela fait, cliquez sur le bouton “Configure API key” :
Déconnectez-vous de votre portail CoreView puis reconnectez-vous. Ensuite, accédez à “Paramètres” > “My organization” > ”On-premises” et cliquez sur le bouton “Configure on-premises”.
Sélectionnez l’option “Multi forest” en haut à droite, puis saisissez les adresses des contrôleurs de domaine, des serveurs Exchange pour chaque forêt, ainsi que les comptes de service créés de manière appropriée pour chaque forêt afin d’établir la connexion. Appuyez sur le bouton “Add” pour saisir la forêt ou le serveur Exchange suivant à intégrer :
Une fois que vous avez ajouté tous les contrôleurs de domaine et serveurs Exchange pour chaque forêt, vous pouvez cliquer sur le bouton “Generate API key”, copier la clé et l’insérer dans la section prévue à cet effet sur le serveur on-premises en attente de configuration :
Si vous voyez le message “Your API key is already configured”, vous pouvez passer à l’étape suivante :
À partir de ce moment, vous pouvez continuer uniquement sur le portail. Veuillez donc vous déconnecter du serveur on-premises et fermer toutes les fenêtres de configuration inutiles.
Maintenant, depuis le portail, appuyez sur le bouton “Verify session” pour terminer le processus de configuration et passer à la configuration du processus “Import”.
Cette phase est terminée avec succès si le message “Verified” s’affiche. Dans le cas contraire, vous devrez résoudre le problème décrit dans le journal disponible dans le répertoire du serveur on-premises à l’emplacement c:\temp\logs avant de reprendre la configuration.
Configuration de l’importation
Il est maintenant nécessaire de configurer l’importation des objets à partir des forêts configurées. Veuillez noter que, sans cette étape, la création de nouveaux objets ne sera pas possible, car CoreView ne connaîtra pas la structure d’OU dans laquelle les actions de gestion doivent être effectuées.
Accédez à “Paramètres” > “My organization” > ”On-premises”, puis développez la section “Import”. Ensuite, sélectionnez “Enable Import” et choisissez les types d’objets à importer. Comme indiqué, sans au moins les unités d’organisation sélectionnées, la création de nouveaux objets ne sera pas possible. Appuyez sur “Save and load tree view” une fois les types d’objets nécessaires sélectionnés :
Cliquez maintenant sur le bouton “Import now” pour inventorier les OU de chaque domaine dans chaque forêt configurée. Selon la taille de chaque domaine et forêt, vous devrez peut-être attendre plus ou moins longtemps.
Une fois l’inventaire terminé, le portail affichera les OU de chaque domaine et forêt après que vous aurez sélectionné la forêt de référence dans le menu déroulant :
Sélectionnez les forêts une par une et choisissez les OU qui vous intéressent. Ensuite, cliquez sur “Save” pour chaque forêt :
Vous pouvez maintenant activer la session de gestion :
Une fois que vous voyez le message “Management ON”, vous pouvez reconfigurer la session d’activation automatique et cliquer sur le bouton “Save changes” :
La migration est terminée.
Limitations
L’architecture multi-forest ne prend pas en charge gMSA. Vous trouverez plus d’informations ici : Renforcer la sécurité de votre environnement hybride.
Les actions personnalisées existantes dans votre Tenant CoreView qui ciblent des environnements on-premises devront être réécrites. En effet, l’interpréteur de commandes de l’agent hybride multi-forest ne peut pas distinguer la forêt cible sans indication spécifique. Ces indications sont gérées à l’aide de la technique “scriptblock”.
Pour toutes les actions personnalisées déjà présentes dans votre Tenant, vous devrez mettre en œuvre la configuration suivante. S’il n’existe pas déjà, créez un fichier et nommez-le “config.json” dans le répertoire d’installation : C:\Temp
{
"BackwardCompatibility.SingleForest.ActiveDirectory": "Your.domaincontroller.fqdn",
"BackwardCompatibility.SingleForest.Exchange": "https://yourexchangeserver.something.local/powershell"
}Cette configuration appliquera le domaine cible et l’Exchange cible définis dans ces paramètres à toutes les actions personnalisées existantes dans votre Tenant. Aucune action personnalisée mise en œuvre avec la logique “legacy” (c’est-à-dire sans scriptblock) ne pourra cibler des forêts différentes de celles déclarées.
Il est fortement recommandé de migrer vers la nouvelle logique toutes les actions personnalisées on-premises créées précédemment.
Vous trouverez ci-dessous les instructions nécessaires pour créer des actions personnalisées à l’aide de la logique “scriptblock”.
Action personnalisée multi-forest
Contrainte :
Étant donné que chaque runspace est ouvert pour une forêt spécifique, nous devons déterminer où exécuter le code de l’action personnalisée.
Solution :
Nous avons introduit le concept de “scriptblock”, qui correspond à des portions du script pouvant être exécutées sur un runspace à la fois. Vous pouvez exécuter plusieurs scriptblocks dans votre action personnalisée, en fonction de la forêt et des environnements que vous souhaitez cibler. Chaque scriptblock ne peut être associé qu’à un seul runspace. Ainsi, si vous devez effectuer deux actions — l’une pour l’Active Directory de la forêt Alpha et la seconde pour l’Exchange on-premises de cette même forêt — vous aurez besoin de deux scriptblocks.
Invoke-CvCommand
SYNOPSIS
Un wrapper de Invoke-Command avec gestion intégrée des sessions distantes.
PARAMÈTRE typeEnv
L’environnement sur lequel invoquer la commande. Il accepte deux valeurs : ActiveDirectory et Exchange.
PARAMÈTRE scriptBlock
Le code à exécuter.
PARAMÈTRE argumentLists
Spécifie les arguments à transmettre au script block.
PARAMÈTRE source
Spécifie une source utilisée pour ouvrir la session PowerShell distante appropriée. La source peut être :
• un distinguished name,
• un security identifier (SID)
• ou un fully qualified domain name (Fqdn).
Vous pouvez désormais utiliser la fonction Invoke-CvCommand pour gérer plusieurs scriptblocks et transmettre des variables entre eux.
scriptblock = {
param()
Get-AdUser -Identity "CN=test,OU=OU_1,DC=ALPHA,DC=LOC" | Select-Object UserPrincipalName
}
$job = Invoke-CvCommand -typeEnv ActiveDirectory -scriptBlock $scriptblock -source "CN=test,OU=OU_1,DC=ALPHA,DC=LOC"
return $job
sb = {
param()
Get-AdUser -Identity "CN=test,OU=OU_1,DC=ALPHA,DC=LOC" | Select-Object UserPrincipalName
}
$job = Invoke-CvCommand -typeEnv ActiveDirectory -scriptBlock $sb -source "CN=test,OU=OU_1,DC=ALPHA,DC=LOC"
return $jobPour contourner le problème de double-hop, il suffit de spécifier un paramètre nommé $cred dans les paramètres du script block.
$userDn = "CN=test,OU=OU_1,DC=ALPHA,DC=LOC"
$UserSid = "S-1-5-21-507672319-2510724776-1356001139-3178"
$sb = {
param($userDn, [System.Management.Automation.PSCredential]$cred)
Get-AdUser -Identity $userDn -Credential $cred | Select-Object UserPrincipalName
}
$job = Invoke-CvCommand -typeEnv ActiveDirectory -scriptBlock $sb -argumentLists $userDn -source $userSid
return $jobLorsque typeEnv est défini sur Exchange, vous devez préfixer les cmdlets on-premises avec "onprem". Par exemple, la cmdlet Get-User devient Get-onpremUser
$userDn = "CN=user test,OU=OU_1,DC=ALPHA,DC=LOC"
$sb = {
$user = Get-onpremUser -Identity "user test" | Select-Object DistinguishedName
Get-onpremRemoteMailbox -Identity $user.DistinguishedName | Select-Object RecipientTypeDetails
}
$job = Invoke-CvCommand -typeEnv Exchange -scriptBlock $sb -source $userDn
return $job