Comment intégrer rapidement vos filiales dans Office 365 – Partie 2

Suite de la partie 1 publiée ici.

Dans l’environnement 0ffice 365, l’intégration la plus aisée s’inscrit sans doute dans le scénario de migration d’un environnement Active Directory / Exchange « On-premise » vers les services cloud de Microsoft. Le plus complexe restant l’intégration d’annuaires de type Ldap et des données de messagerie, telles que Lotus Notes / Groupwise ou Linux.

Le premier scenario bénéficie d’une part des solutions techniques développées par l’éditeur Microsoft permettant de déplacer les données vers ou depuis l’environnement sur site, et d’autre part de la compatibilité des formats de données. En effet, Microsoft a développé une coexistence à long terme appelée hybridation, ainsi la migration des environnements sur site vers le Cloud peut être progressive sans réellement gêner les utilisateurs dans leurs opérations quotidiennes. Pour autant, cela n’exclut pas le fait que cette d’hybridation a des conséquences sur votre organisation et sur votre architecture réseau.

Dans le cas de l’intégration d’environnements autres que Microsoft (Lotus Notes, Linux etc.), les défis sont plus importants car vous devrez gérer un mode de coexistence plus complexe mais aussi moins riche fonctionnellement. Environnement qui aura un impact significatif sur les utilisateurs que vous devrez accompagner et former. En outre, vous devrez appréhender les conséquences liées à la conversion de données entre des environnements hétérogènes. Ces types de migration sont généralement plus complexes et exigent plus de temps.

Dans cette deuxième partie, nous allons par conséquent nous intéresser au premier scenario, le plus courant, consistant à intégrer une filiale possédant un environnement Active Directory et un environnement Exchange, et passer en revue les scenarios d’intégration d’identités possibles.

Comme précisé dans la première partie, l’intégration d’une filiale doit prendre en compte qu’à terme, l’environnement source doit disparaître au profit de l’environnement de la maison mère. L’environnement Active Directory et l’organisation Exchange, ainsi que les services de fichiers doivent donc être « solubles » dans l’espace Office 365. Cela implique que vous ne devez pas synchroniser les identités de la filiale mais bien migrer les ressources associées (Boîtes aux lettres, service de fichiers etc.) et les « connecter » à des comptes utilisateurs appartenant à la maison mère. Le premier chantier dont vous devez donc vous préoccuper est sans nul doute l’identité.

Pour fusionner l’identité, vous avez plusieurs solutions. L’une consiste à utiliser l’Azure AD connect et l’outil ADMT de Microsoft (https://www.microsoft.com/en-us/download/details.aspx?id=56570), l’autre consiste à recourir à des outils du marché, tels que ceux vendus Par Binary Tree ou Quest. Mais revenons à notre premier scenario.

Utilisation des outils Microsoft ADMT & Azure Ad Connect pour la fusion d’identité

Comme votre environnement source doit disparaître, il faut provisionner dans la forêt Active Directory de la maison mère les futurs comptes utilisateurs des personnes de votre filiale. Le plus simple est donc d’utiliser ADMT qui va non seulement recopier vos comptes utilisateurs depuis votre forêt source vers la forêt cible, mais sera également capable de migrer vos mots de passe. Autre avantage, ADMT conservera les informations de sécurité (Voir Sid History) de vos utilisateurs leur permettant d’utiliser leurs nouveaux comptes Active Directory tout en gardant accès à leurs anciennes ressources Microsoft. L’utilisation d’ADMT, outre les privilèges de lecture et d’écriture, vous demandera une connexion entre les deux Active Directory, celle de votre filiale et celle de votre maison mère. Une fois les comptes créés, vous devrez les transformer en « mailuser » puis les synchroniser en premier dans votre environnement Office 365. Notez qu’à partir de ce moment précis, les utilisateurs de votre filiale vont apparaître dans le carnet d’adresse Outlook. Un premier pas dans l’intégration.

L’utilisation d’Azure AD connect est ensuite possible pour fusionner les identités : celles de vos comptes utilisateurs sources avec ces nouvelles identités présentes dans l’environnement AD de la maison mère et dans Azure AD. En déclarant dans Azure AD connect les deux forêts et en jointant les utilisateurs sur un champ commun (email, SamAccountName etc.), l’outil de synchronisation Microsoft va fusionner les deux identités dans Azure AD. Certains attributs de messagerie nécessaires aux déplacements de boîtes aux lettres entre les deux environnements (Exchange sur site de votre filiale et Exchange Online) vont alors être présents. Ces informations permettront de déplacer la boîte aux lettres via une requête de « move mailbox » en conservant l’identité de la boîte aux lettres, évitant ainsi la recréation sur chaque poste de travail du profil Outlook et la resynchronisation de la boîte aux lettres en local (Fichier OST).

Une fois en place, vous devrez créer a minima un point de terminaison du proxy MRS qui permettra, par un canal sécurisé en Https, de « tirer » la boîte aux lettres depuis Exchange online. Pour ce faire je vous renvoie à la présentation du Point de Terminaison du Proxy MRS ici : https://docs.microsoft.com/fr-fr/exchange/architecture/mailbox-servers/mrs-proxy-endpoint?view=exchserver-2019

Depuis Powershell ou depuis Exchange Online, vous aurez la possibilité de générer des demandes de déplacement de boîtes aux lettres qui vont automatiquement se rattacher aux comptes utilisateurs de votre maison mère. Une fois migrée, la nature des objets utilisateurs de votre forêt source anciennement de type « mailbox user », passera à « Mailuser ». Une adresse de redirection (Target Address) sera positionnée, assurant une redirection pour le client Outlook vers Office 365. Vous aurez ainsi déplacé des ressources (ici Boîtes aux lettres) sans synchroniser les comptes utilisateurs de la forêt source ; qui je vous le rappelle va disparaître.

Côté utilisateur, le client Outlook tentera de se connecter localement et sera redirigé vers 0365 grâce à la « target address » locale positionnée par les opérations de déplacement de boîte aux lettres.

Avantages et inconvénients

L’avantage de cette méthode est naturellement sa gratuité puisque tous les outils utilisés sont gratuits et supportés par Microsoft. Mais, au-delà de sa relative simplicité, son application est délicate pour les raisons suivantes :

• Le paramétrage et le fonctionnement d’Azure AD connect jouent un rôle clef dans l’environnement de production de l’entreprise. Chaque changement de configuration est délicat et en cas d’erreur de paramétrage les effets sur les comptes utilisateurs peuvent être importants. Si vous envisagez de recourir à cette méthode, la validation approfondie en maquette est indispensable.
• D’autre part, la configuration de la synchronisation peut s’avérer complexe si vous avez à migrer plusieurs entités en même temps.
• Son fonctionnement est limité aux comptes utilisateurs et, dans votre environnement, vous aurez à gérer d’autres objets comme les listes de distribution.

Autrement dit, je ne suis pas certain que l’utilisation, en tant qu’outil de fusion d’identité et de migration d’un module aussi important dans l’environnement Office 365 que l’Azure Ad Connect, soit opportune. Néanmoins, pour l’avoir mis en place, cette solution fonctionne correctement.

Utilisation de solutions tierces

La solution alternative est de recourir à des solutions du marché commercialisées par des éditeurs comme Quest et Binary Tree. Le scenario est un peu différent mais aura l’avantage de ne pas demander de changement au niveau de la configuration d’Azure Ad Connect et donc de la production. De ce fait, la surface de risque est plus limitée.

D’une façon générale, les outils tiers spécialisés dans la migration vers Office 365 utilisent deux modules. Le premier gère l’identité, le second le déplacement des ressources (Service de fichiers, boîtes aux lettres etc.)

Dans la gestion d’identité, l’outil de synchronisation entre les deux forêts Active Directory va lire les informations d’annuaire source pour les transposer ou les dupliquer dans l’environnement cible. Il va également maintenir ces informations synchronisées de part de d’autre des deux annuaires (très utile dans le cadre des listes de distributions et leurs membres). Ces outils tiers de synchronisation peuvent être paramétrés soit pour créer des objets dans la forêt de la maison mère soit pour peupler des attributs de messagerie qui permettront l’association lors des opérations de déplacement de boîtes aux lettres entre le compte utilisateurs de la maison mère et le compte source.

Doté d’un module permettant la sélection multiple via des critères LDAP ainsi que d’un mode de fonctionnement dit « à blanc », ces outils permettent une réelle anticipation des changements qui vont être apportés à l’environnement cible. Ils sont généralement capables de s’adapter à des configurations d’annuaire particulières ce qui en fait des solutions relativement souples et très prisées des intégrateurs.

Les modules additionnels vont, quant à eux, prendre en charge les ressources comme les boîtes aux lettres, les dossiers publics, les listes de distribution, les services de fichiers etc. Ici l’outillage sera très apprécié car il permet véritablement d’orchestrer les lots de migration, de pouvoir les compléter via l’exécution de scripts (ante et post migration), de prévenir par messagerie les personnes concernées et de générer des rapports de migration automatiques. Certains possèdent également des fonctionnalités de gestion de conflit d’identité.

Bien sûr, la plupart des opérations réalisées par ces outils le sont manuellement, principalement par script mais cela vous demandera des temps de développement et de validation très importants ainsi qu’un suivi au quotidien plus important. Je ne suis pas certain qu’il faille dans ce cas réinventer la roue.

Avantages et inconvénients

Le principal avantage de ces solutions est qu’elles permettent de s’adapter à vos particularités et à vos scénarios de migration. Là où l’utilisation de l’Azure Ad Connect impose un cadre restrictif, les solutions tierces ont su s’adapter aux besoins des clients

Leurs inconvénients restent leur prix et la nécessité d’installer des serveurs de migration en connexion locale avec les environnements sources et cibles.

Comme nous avons pu le voir, l’identité joue un rôle très important dans le cadre d’une migration et sa fusion vers le système d’information de la maison mère constitue une étape primordiale conditionnant la suite des opérations.

Viendront ensuite d’autres problématiques comme l’authentification et le déplacement de données, ce qui naturellement ferait un excellent sujet.