Comment migrer d’une configuration single forest à une configuration multi-forêts

Cet article décrit la procédure de migration d’une configuration CoreView Hybrid Connector single forest vers une topologie Active Directory multi-forêts.

Si vous installez CoreView Hybrid Connector pour la première fois, il ne s’agit pas d’une migration mais d’une première installation. Veuillez alors consulter l’article suivant : Installation du Hybrid Connector. 

En revanche, si vous aviez déjà configuré le Hybrid Connector pour l’une de vos forêts Active Directory et que vous souhaitez maintenant en ajouter d’autres, afin de passer d’une configuration single forest à multi-forêts, la procédure suivante est pour vous.

Gardez à l’esprit que cette interruption impactera les actions de gestion sur site, qu’elles soient natives ou personnalisées. Il est donc essentiel de veiller à désactiver correctement la session de gestion lors de la migration (comme nous l’expliquons dans les étapes suivantes).

Enfin, souvenez-vous que la configuration multi-forêts n’est prise en charge que sur Windows 2022 et 2019. Si votre Hybrid Connector fonctionne sur un serveur Windows 2016, il vous faudra prévoir l’installation d’un nouveau serveur sous une version supportée. Veillez à tester toutes les autorisations et configurations réseaux nécessaires décrites ici : Hybrid Connector : prérequis.

Comptes de service

La structure de la version multi-forêts du Hybrid Connector CoreView s’apparente à celle de Microsoft AD Connect. Un seul serveur sur site héberge l’agent, mais il doit pouvoir se connecter à un contrôleur de domaine de chaque forêt à intégrer.

La connexion utilise PowerShell Remoting (plus d’informations dans cet article Microsoft). Chaque contrôleur de domaine de chaque forêt doit donc disposer d’un compte de service dédié. Ainsi, il n’est pas nécessaire d’établir de relation de confiance Active Directory ni d’utiliser des comptes Enterprise Admins.

Si une forêt comporte plusieurs serveurs Exchange, il est conseillé d’attribuer un compte de service supplémentaire à chaque organisation Exchange supplémentaire.

Comme pour la version single forest, il est recommandé d’utiliser dans chaque forêt un contrôleur de domaine disposant du rôle Global Catalog, nécessaire pour importer les membres des groupes couvrant plusieurs domaines et forêts. Sans liaison à un Global Catalog, ces membres ne seront pas importés.

Pour les forêts en relation parent-enfant, un seul contrôleur de domaine du domaine parent suffit. Le processus d’import CoreView détectera chaque domaine enfant et importera les données associées.

Pré-vérifications

Comme pour la version single forest, la mise en place d’une topologie multi-forêts implique une préparation minutieuse et la vérification des règles réseau ainsi que des droits de chaque forêt.

Ces articles fournissent les instructions pour utiliser l’outil diagnostic du Hybrid Connector CoreView : Outil de diagnostic.

Nous recommandons d’exécuter tous les tests pour chaque compte de service dans chaque forêt qui fera partie de la nouvelle configuration multi-forêts. Si vous prévoyez également de changer le serveur hébergeant le Hybrid Connector, exécutez tous les tests sur le nouveau serveur avant d’entamer la migration ci-dessous. Ainsi, vous simulerez le même comportement que le Hybrid Connector et validerez la connectivité réseau depuis la même adresse IP source. Ceci est important car Docker RTE Windows utilise le même IP pour les connexions réseau (NAT).

Migration

Si vous installez sur un nouveau serveur, téléchargez et installez la version la plus à jour du package Hybrid Connector.

Si vous devez mettre à niveau la version single forest sur le même serveur, désinstallez d’abord la version actuelle avant de réinstaller.

Avant de désinstaller, veillez à désactiver la fonction “Activation auto session de gestion” comme illustré ci-dessous :

Désactivez ensuite la gestion :

Rendez-vous maintenant sur : C:\Temp

et ouvrez le fichier : Forward365.Service.PowershellService.Agent.exe.config

Vous devrez copier-coller toutes les clés personnalisées de la section appSettings dans le même fichier sur le serveur Windows 2019.

Si le Hybrid Connector single forest fonctionne sur un autre serveur, il faut arrêter le service “CoreView Agent” sur la machine on-premise et le passer en mode désactivé :

Connectez-vous ensuite au portail CoreView, allez dans “Paramètres” > “Mon organisation” > ”Sur site” et cliquez sur “supprimer la configuration” :

Contactez ensuite votre référent CoreView pour demander la reconfiguration de votre tenant en mode multi-forêts (FT:MULTIFOREST). Si vous utilisiez auparavant la version 2016, vérifiez que vous avez migré vers Windows Server 2019 côté backend (FT:HYBRIDOS2019).

Installez maintenant 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, désinstallez d’abord l’agent via Panneau de configuration > Programmes & fonctionnalités :

Après installation, une page localhost:1234 s’ouvre automatiquement sur votre serveur. Il s’agit de la page de configuration de l’agent, utilisée exclusivement ici pour renseigner la clé API générée à l’étape suivante.

Veillez à valider tous les prérequis affichés sur la page (voir ici). Cliquez ensuite sur “Configurer la clé API” :

Déconnectez-vous du portail CoreView puis reconnectez-vous. Naviguez à “Paramètres” > “Mon organisation” > “Sur site” et cliquez sur “Configurer sur site”.

Sélectionnez l’option “Multi-forêts” en haut à droite et renseignez les adresses des contrôleurs de domaine, des serveurs Exchange pour chaque forêt, ainsi que les comptes de service appropriés pour chaque forêt à connecter. Appuyez sur “Ajouter” pour entrer la forêt ou le serveur Exchange suivant à intégrer :

Après avoir renseigné tous les contrôleurs de domaine et serveurs Exchange de chaque forêt, cliquez sur le bouton “Générer la clé API”, copiez cette clé puis collez-la dans la section dédiée du serveur sur site en attente de configuration :

Si vous voyez le message “Votre clé API est déjà configurée”, vous pouvez passer à l’étape suivante :

À partir de là, poursuivez uniquement sur le portail et fermez toutes les fenêtres de configuration superflues sur le serveur on-premises.

Depuis le portail, cliquez sur “Vérifier la session” pour finaliser la configuration et passer à la configuration du “Processus d’import”.

L’étape est validée si le message “Vérifiée” s’affiche. Sinon, corrigez les problèmes décrits dans le fichier log du serveur sur site (c:\temp\logs) avant de recommencer la configuration.

Configuration de l’import

Configurez maintenant l’import des objets des forêts configurées. Sans cette étape, la création de nouveaux objets ne sera pas possible, car CoreView n’aura pas connaissance de la structure des OU où effectuer les actions de gestion.

Naviguez vers “Paramètres” > “Mon organisation” > “Sur site” puis développez la section “Importer”. Cochez “Activer l’import” puis sélectionnez les types d’objets à importer. Comme précisé, sans au moins la sélection des Unités d’Organisation, il sera impossible de créer de nouveaux objets. Cliquez sur “Enregistrer et charger l’arborescence” après avoir sélectionné les types d’objets nécessaires :

Cliquez sur “Importer maintenant” pour inventorier les OU de chaque domaine de chaque forêt configurée. Selon la taille de chaque domaine et forêt, l’attente sera plus ou moins longue.

Une fois l’inventaire effectué, le portail affichera les OU de chaque domaine et forêt sélectionnés, après avoir choisi la forêt de référence dans le menu déroulant :

Sélectionnez les forêts l’une après l’autre et choisissez les OU souhaitées. Cliquez sur “Enregistrer” pour chaque forêt :

Vous pouvez maintenant activer la session de gestion :

Lorsque vous voyez le message “Gestion ACTIVÉE”, vous pouvez reconfigurer l’activation automatique et cliquer sur le bouton “Enregistrer les modifications” :

La migration est terminée.

Limitations

L’architecture multi-forêts ne prend pas en charge gMSA. Plus d’infos ici : Renforcement de votre environnement hybride.

Toutes les actions personnalisées existantes dans votre tenant CoreView ciblant des environnements sur site devront être réécrites. En effet, l’interpréteur de commandes de l’agent hybride multi-forêts ne peut pas distinguer la forêt cible sans indication spécifique, laquelle doit être gérée en “scriptblock”.

Pour toutes les actions personnalisées déjà présentes sur votre tenant, appliquez la configuration suivante. Sinon, créez un fichier “config.json” dans le dossier d’installation : C:\Temp

 {    
"BackwardCompatibility.SingleForest.ActiveDirectory": "Your.domaincontroller.fqdn",    
"BackwardCompatibility.SingleForest.Exchange": "https://yourexchangeserver.something.local/powershell"
}

Cette configuration fixera la forêt cible et l’instance Exchange définies ici pour toutes les actions personnalisées legacy de votre tenant. Aucune action personnalisée utilisant l’ancienne logique (hors scriptblock) ne pourra s’exécuter sur une forêt autre que celle déclarée.

Il est indispensable de migrer toutes les actions personnalisées existantes vers la nouvelle logique.

Voici les instructions pour créer des actions personnalisées avec la logique “scriptblock”.

Action personnalisée multi-forêts

Contrainte :

Chaque espace d’exécution est ouvert pour une forêt spécifique, il faut donc indiquer où exécuter le code de l’action personnalisée.

Solution :

Nous avons introduit le concept de “scriptblock” : des morceaux de script pouvant être exécutés sur un seul espace d’exécution à la fois. Vous pouvez utiliser plusieurs scriptblocks dans votre action personnalisée, selon les forêts/environnements ciblés. Chaque scriptblock est attribué à un seul espace d’exécution. Ainsi, pour réaliser deux actions — l’une sur l’Active Directory de la forêt Alpha, l’autre sur Exchange sur site de la même forêt — il vous faudra deux scriptblocks.

Invoke-CvCommand

SYNOPSIS  
Wrapper de Invoke-Command avec gestion intégrée des sessions distantes.

PARAMÈTRE typeEnv
Environnement cible de la commande (ActiveDirectory ou Exchange).

PARAMÈTRE scriptBlock
Code à exécuter.

PARAMÈTRE argumentLists
Arguments transmis au scriptblock.

PARAMÈTRE source  
Identifie la source à utiliser pour ouvrir la session PowerShell distante (distinguished name, SID ou FQDN).

Vous pouvez maintenant utiliser la fonction Invoke-CvCommand pour gérer plusieurs scriptblocks et passer 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 $job

Pour éviter le double saut Kerberos, vos scriptblocks doivent définir explicitement un paramètre $cred :

$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 $job

Lorsque typeEnv = Exchange, préfixez les cmdlets on-prem avec “onprem”. Exemple : 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