Identités et le défi sous-estimé d’une intégration Office 365

Le plus logique mais parfois le plus compliqué, se trouve être la fusion, le second dit intégration généralement plus rapide consiste à interconnecter ce système d’informations via des approbations mutuelles entre les différents environnements. Dans les deux cas il faudra, à un moment, établir une cohabitation, une coexistence des systèmes qui  permettra rapidement aux utilisateurs des filiales acquises de pouvoir accéder aux applications métiers du groupe.

Généralement, cette coexistence n’est pas un but en soi, il s’agit plutôt d’une étape transitoire qui permet aux forces de vente, aux responsables métiers d’intégrer directement les applications du groupe. Cette coexistence devra ensuite céder la place à une véritable fusion qui peut comprendre à terme la suppression du système d’informations de la nouvelle filiale.

L’objectif dans ce cas est d’obtenir, à travers un annuaire unique, des services homogènes pour le groupe (messagerie, intranet, portails collaboratifs, téléphonie, etc.). Outre la migration des données, la question des identités va alors se poser. Sans Identité, pas de projet de migration.

Dans l’environnement Microsoft, l’annuaire technique de l’entreprise est représenté par l’Active Directory. Lors de l’acquisition de nouvelles sociétés la question se pose donc d’intégrer l’ensemble de ses utilisateurs, leurs stations de travail, leurs serveurs mais parfois leur environnement Office 365 vers les infrastructures du groupe. Le premier chantier qu’il faudra donc adresser est sans nul doute l’identité. Combien de compte utilisateurs sont à reprendre ? Comment sont gérés les comptes de sous-traitants, quelle est la politique de gestion des identités dans la nouvelle filiale ?

Sans la définition du projet de fusion ou d’intégration des identités, les autres services ne pourront pas migrer Cliquez pour tweeter. C’est le premier chantier qu’il faudra adresser. C’est précisément ce que nous vous proposons d’étudier

Les scénarios possibles

Il existe en réalité 2 grands scénarios envisageables lorsqu’une acquisition de société se produit.

L’intégration 

Le premier scénario dit d’intégration, part du principe que l’environnement de cette nouvelle société va perdurer. Dans ce cas, les identités d’annuaire devront être conservées et devront être synchronisées vers Azure AD si le groupe possède un environnement Office 365. La mise en place de relations d’approbation entre ses deux environnements permettra de pouvoir facilement partager des ressources, via des processus d’authentification mono ou bidirectionnel.

Ce scénario peut bien évidemment se répéter, permettant aux nouvelles acquisitions, de rapidement intégrer les ressources du groupe. C’est parfois le cas lorsque la société rachetée conserve sa propre identité ou ses propres marques. Dans ce cas, l’intégration est simple, les utilisateurs conservent leur identité propre, leur adresse de messagerie, leur identifiant de messagerie instantanée etc. etc…

D’un point de vue architecture, les deux forêts coexistent de part et d’autre avec des serveurs contrôleurs de domaine déployés dans chaque agence respective. On notera au passage que ce mode de fonctionnement peut cependant poser quelques soucis de mobilité lorsqu’un utilisateur du groupe tentera de se connecter depuis un réseau de la filiale.

Dans notre cas, les processus de synchronisation des annuaires comme Azure Ad Connect vers Office 365, prennent en charge ces scénarios, et sont parfaitement adaptés à ces situations.

Malgré cela, et malgré cette relative simplicité, des adaptations sont souvent souhaitables en entreprises, comme par exemple, l’homogénéisation des adresses de messagerie, l’uniformisation du nommage des ressources comme peuvent l’être les salles de réunion, les listes de distribution, les groupes de sécurités. L’objectif est alors d’offrir aux utilisateurs un annuaire unique et homogène dans lequel ils pourront se repérer et adresser des ressources entre les diverses entités.

Cette intégration, peut être également améliorée si les deux entreprises possèdent notamment des systèmes de messagerie basés sur les mêmes technologies comme Microsoft Exchange. Dans ce cas, des interactions dites « riches » sont possibles comme le fait de pouvoir rechercher les plages libres occupées des collaborateurs situés dans une autre filiale. Plus simplement si le groupe a choisi la messagerie Exchange Online de Microsoft, les identités de la filiale étant synchronisées, il sera alors assez simple de migrer les données de messagerie de cette dernière vers ce nouvel environnement.

Dans ce scénario, les processus de Gestion des Identités et des Accès (IAM) du groupe seront également mis à jour. Ils devront prendre en compte a posteriori ce nouvel environnement, et pouvoir l’adresser lorsque que des nouvelles identités devront être créés ou supprimées. Cela passe généralement, par une remise aux normes du groupe de ce nouvel annuaire, en « populant » notamment des identifiants uniques (Matricules, Identifiant) sur les objets tels que les comptes utilisateurs, les comptes sous-traitants etc… Là encore, l’objectif n’est de ne pas faire disparaître l’annuaire de la filiale mais bel et bien de l’intégrer dans les processus de gestion d’identité du groupe.

La fusion 

Le second scénario que nous nommerons fusion, consiste à considérer que l’annuaire de la filiale acquise, a pour objectif de disparaître. Seules les données utilisateurs seront reprises, les identités propres à l’environnement filiales devront par conséquent être ignorées des processus de synchronisation. Dans la plupart des cas, l’ensemble des utilisateurs ainsi que leurs stations de travail et les ressources serveurs (pour ne citer que celles-ci) devront migrer vers l’environnement Active Directory du groupe.

Ce scénario est bien évidemment plus complexe, plus long mais l'intégration à terme sera plus aboutie Cliquez pour tweeter

Tout le monde sera intégré dans la seule et unique forêt Active Directory du Groupe.

Dans ce cas précis, la question est donc de savoir comment réaliser cette fusion d’identité, tout en intégrant la migration des données s’y rattachant.

Là encore, sans identité pas de projet de migration.

Comment, par conséquent, intégrer les données d’une nouvelle société dans l’environnement Office 365 & Active Directory d’un groupe, sans synchroniser ses données d’annuaire, sachant que les données et leur accès sont intimement liés ?

La première des choses à faire, est de créer dans l’environnement destination (environnement Groupe) ces mêmes identités et de les synchroniser le cas échéant dans l’environnement Office 365. Une clé commune devra être établie entre les deux environnements d’annuaire pour s’assurer qu’une relation de type un à un pour les comptes utilisateurs notamment peut être établie. Les utilisateurs posséderont deux comptes, un dans leur forêt d’origine, un dans la forêt du groupe.

Dans la plupart des cas, la création de ces nouvelles identités se fait en fonction des normes en vigueur du groupe ainsi, il n’est pas rare que le formalisme des noms de connexion soit différent vis-à-vis de la filiale. Si le groupe utilise Office 365, le nom de connexion des utilisateurs (UPN) sera généralement identique à leur adresse de messagerie principale (@agency.com par exemple), ce qui obligera la filiale en cas de relations d’approbation bidirectionnelle à ne plus l’utiliser au profit de l’annuaire groupe. (Suppression de l’UPN dans la forêt source en cas de relation d’approbation bidirectionnelle).

Pour des questions d’accès aux ressources des agences, la création de ces comptes utilisateurs, devra également prendre en compte leur ancienne identité et plus particulièrement ce que l’on nomme le Sid History. Ce Sid History permettra aux utilisateurs devant utiliser leur identité au sein du groupe de continuer à avoir accès à leurs anciennes ressources comme par exemple les services de fichiers.

Comme l’annuaire de l’agence doit disparaître, et par conséquent ne doit pas être synchronisé vers 0ffice 365, il va être également nécessaire de récréer l’ensemble des groupes de sécurité et de distribution hérités vers l’annuaire du groupe en prenant soins là aussi de conserver leurs Sid History (Groupe de sécurité uniquement). La plupart des entreprises en profite souvent pour les renommer de façons à ce qu’ils suivent la nomenclature en vigueur, (on parle alors de transposition des données d’annuaire plutôt que de duplication). Comme le scenario de fusion est un processus qui va durer, le temps que toutes les stations de travail intègrent la nouvelle forêt, cette transposition devra être maintenue pour permettre le déplacement des ressources vers ces nouvelles identités.

Une fois cette transposition mise en place et maintenue, le déplacement des ressources peut avoir lieu. Ce dernier devra s’appuyer et prendre en compte cette transposition d’identité pour modifier les autorisations héritées et les remplacer par les identités du groupe. C’est ce que font généralement les outils de migration en intégrant comme Sharegate une table de correspondance des identités dans le cadre de la migration des ressources Sharepoint qu’elles soient hébergées sur site ou sur 0ffice 365. (Migration Tenant à Tenant)

Une fois migrés, les utilisateurs connectés avec leurs comptes dans la forêt du groupe retrouveront leurs accès sur leurs sites Sharepoint.

Pour la migration des boîtes aux lettres & des dossiers publics, si la filiale utilise l’environnement Exchange, la migration est plus complexe et mériterait à elle seule une publication approfondie. Cependant, en dupliquant les attributs messageries des utilisateurs de l’environnement Source, vers la forêt de destination, sachez qu’il est possible d’effectuer des déplacements de boîtes aux lettres (Move Mailbox) depuis la filiale vers l’environnement du groupe en rattachant ces boites aux lettres vers les identités groupe. Ce déplacement des boîtes aux lettres ayant comme particularité la conservation de l’attribut Mailbox Guid, il permettra la mise à jour automatique du profil Outlook de vos utilisateurs vous évitant une intervention sur chaque poste de travail.

L’identité comme nous avons essayé de vous le démontrer, bien souvent sous-estimée, joue par conséquent un rôle déterminant dans les projets d’intégration et selon le niveau de complexité, peut remettre en cause votre stratégie de migration.

Analyser comment se feront ces fusions, ces adaptations et les conséquences de leurs modifications sur l’environnement applicatif est primordial pour construire un plan projet réaliste Cliquez pour tweeter Cela doit constituer une des premières étapes à prendre en compte.

Sans identité pas de migration !