Comment intégrer rapidement vos filiales dans Microsoft Office 365

Nous verrons qu’il existe plusieurs niveaux d’intégration selon la stratégie retenue à court ou moyen terme et que les niveaux de complexité technique peuvent varier, selon l’environnement de transition et l’outillage retenu.

L’objectif de cet article est, par conséquent, de préciser les différentes étapes d’intégration, les risques inhérents et les outillages possibles pour ce genre d’opérations.

Intégration et cohabitation

L’acquisition d’une nouvelle entité va potentiellement générer des changements importants au niveau de son système d’information, et ce, au profit de la maison mère. Les applications métiers de la filiale vont être abandonnées au profit des applications « Corporate ». Le premier sujet adressé par cette contrainte métier va concerner l’identité.

Gestion des identités

Première brique permettant l’authentification des utilisateurs vers le système d’information et les applications métiers, l’ensemble des identités est, bien souvent, créé rapidement introduisant la notion d’un double compte pour les utilisateurs de la filiale.

Les utilisateurs de la filiale acquise se connectent alors traditionnellement à leurs environnements puis de nouveaux, sont authentifiés par celui de la maison mère. Cette double authentification peut être partiellement transparente pour les accès Microsoft s’il est possible d’établir des relations de confiance entre les forêts Active Directory respectives.

Forêts Active Directory

La plupart du temps la mise en place de ces relations d’authentification permet aux nouveaux comptes créés de conserver l’accès aux anciennes ressources Microsoft mais toutes les applications métiers ne savent pas gérer ses relations de confiance. Elles demanderont, alors, aux utilisateurs une connexion additionnelle avec le compte de la maison mère.

Une des questions importantes à se poser est la question de la cible définitive.

Devrez-vous à terme conserver l’environnement de compte de la filiale ou au contraire, devrez-vous la faire disparaitre au profit de celui de la maison mère ?

Dans le premier cas (Conservation) :

on ne parle pas véritablement d’intégration mais de cohabitation. Les deux environnements Active Directory vont cohabiter sur le long terme, se faire confiance et les utilisateurs des deux mondes resteront dans leurs domaines respectifs.

Dans le second cas (Intégration) :

le système d’information de la filiale doit être « soluble » dans celui de la maison mère. Les stations de travail vont être intégrées dans la ou les forêts de la maison mère et les données de messagerie devront migrées vers le tenant 0365 de cette dernière.

Etape 1 : Donnez l’impression

Dans le cas d’acquisition, une des problématiques est de permettre rapidement aux personnes de la filiale de pouvoir envoyer avec le même domaine SMTP (ex :@coporate.com)  que celui de la maison mère. Cela revient à partager un espace de nom SMTP sur plusieurs entités (la maison mère et la ou les filiales) ce qui vous allez le voir n’est pas forcement évident, surtout si la filiale utilise Exchange Online.

Si la filiale que vous devez intégrer vient avec son Tenant 0365, il ne vous sera pas possible d’étendre le nom de votre domaine SMTP sur ce dernier. Ceci en raison d’une limitation fonctionnelle qui limite l’usage d’un nom de domaine à un seul et unique Tenant 0365.

Pour l’envoi, il vous faudra, par conséquent utiliser un service de réécriture d’adresses depuis votre filiale. Service, qui va convertir tous les messages envoyés en tant que @filiale.com en @corporate.com. Pour des questions de sécurité nous vous conseillons d’acheminer ce flux sortant vers les équipements de messagerie de la maison mère ayant la responsabilité déclarée sur internet (SPF, MX) d’envoyer et de recevoir les messages. Vous éviterez ainsi que vos messages soient considérés comme Spam.

Le diagramme suivant (1)

Il décrit la façon dont sont organisés les services d’envoi dans un scénario où le domaine Corporate est partagé par la maison mère et deux autres filiales (Filiale-1 & Filiale-2). Dans ce scénario, la maison mère et la filiale 1 possèdent toutes les deux un tenant 0365.

Le service de récriture d’adresse est présent sur un serveur Edge Exchange. Ce service n’existe pas encore sur l’environnement Microsoft Exchange Online.

Pour la réception, les équipements de la maison mère devront rester en en place et devront réacheminer les messages pour les utilisateurs de la filiale vers leur tenant. Cette redirection peut être faite de deux façons.

Routage via l’annuaire

La première consiste à faire du routage par le biais de l’annuaire, le second est une simple configuration SMTP via les services de réécriture d’annuaire.

Routage par le biais de l’annuaire:

Dans ce cas, des entrées dans l’annuaire de la maison mère sont créés (« Mailuser » ou Contact de messagerie). Ces entrées d’annuaire de messagerie portent l’adresse SMTP corporate (Ex : doe@corporate.com) mais également une adresse de redirection (Target Address) Exemple john.doe@filiale-1.com. Cette adresse de redirection sera utilisée par Exchange online ou Onpremise pour acheminer le message dans la boîte aux lettres de la filiale. Ce système peut être utilisé avec plusieurs filiales en même temps si celles-ci ne portent pas le même nom de domaine SMTP. Voir schéma 2. L’intérêt d’utiliser des objets de type mail user (Utilisateurs AD avec extension de messagerie), permet aux utilisateurs de la filiale de disposer d’un compte utilisateur dans l’environnement Corporate et par conséquent de pouvoir se connecter aux diverses applications métiers qui utilisent l’annuaire Active Directory.

Routage par configuration:

Le routage par configuration consiste à utiliser le serveur Edge pour réécrire les adresses dans le sens inverse de l’envoi.  De @corporate.com à @filiales.com.

Le diagramme précise une topologie de routage entrant basé sur l’annuaire et l’utilisation de « Target Address » et de ces fameux « Mailuser ».

Ces deux solutions fonctionnent parfaitement et sont documentées par Microsoft. J’ai cependant une petite préférence pour le Routage par le biais de l’annuaire car d’une part, il s’inscrit plus adroitement dans le scénario d’intégration que le premier (nous verrons pourquoi par la suite) puis il permet d’autre part, la création de liste de distribution gérées par la maison mère au sein de son Exchange online (la cible définitive ne l’oublions pas) adressant des boîtes aux lettres des deux environnements.

Quoiqu’il en soit ce « renommage à la volée » va donc permettre de donner l’illusion extérieurement d’une intégration mais ne doit être considérée que comme un pis-aller temporaire. Une étape avant l’intégration ou plutôt la dissolution de l’entité filiale dans l’environnement de la maison mère.

Etape 2

celle qui va impliquer de rattacher aux comptes de la filiale déjà présents dans l’environnement de la maison mère (Les fameux « mail users » cités plus haut), les ressources et les accès hérités. Comme le scénario de départ est de supprimer l’environnement Active Directory de la filiale, vous ne devez pas synchroniser ce dernier dans l’Azure AD Corporate. Si vous le faites pour migrez dans Office 365 les ressources associées, celles-ci resteront liées à la forêt locale. Cette dernière devra par conséquent rester en production ce qui n’est pas l’objectif.

L’étape suivante donc consister à s’assurer que pour chaque compte présent dans la filiale correspond un compte dans l’environnement Corporate, son clone en quelque sorte que nous nommerons pour des raisons de praticité : Surrogate

L’étape 2, qui est conséquente, consiste à préparer l’intégration, et comporte deux chemins possibles. Le premier consistant à s’appuyer sur les fonctions d’Azure AD connect pour effectuer cette fusion d’identité, le second consistant à s’appuyer sur des outils tiers.

Mais nous verrons cela dans la partie 2 à venir.