When merging or acquiring companies, the question of information systems integration arises. In most cases, several scenarios are possible. The most logical but sometimes the most complicated is the merger, the second, generally faster integration, consists in interconnecting this information system via mutual approvals between the different environments. In both cases, it will be necessary, at some point, to establish a cohabitation, a coexistence of systems that will quickly allow users of acquired subsidiaries to access the group’s business applications.
Generally, this coexistence is not an objective in itself, but rather a transitional step that allows sales forces and business managers to integrate the group’s applications directly. This coexistence will then have to give way to a real merger, which may eventually include the removal of the new subsidiary’s information system. The objective in this case is to obtain, through a single directory, homogeneous services for the group (messaging, intranet, collaborative portals, telephony, etc.). In addition to Data Migration, the question of identities will then arise. Without Identity, there is no migration project.
In the Microsoft environment, the company’s technical directory is represented by the Active Directory. When acquiring new companies, the question arises of integrating all its users, their workstations, their servers but sometimes their Office 365 environment into the group’s infrastructures. The first project to be addressed is undoubtedly identity. How many user accounts are to be taken over? How are subcontractor accounts managed, what is the identity management policy in the new subsidiary?
Without the definition of the merger or identity integration project, other services will not be able to migrate. This is the first project that will have to be addressed. This is precisely what we propose you to study
Possible scenarios
There are actually 2 main scenarios that can be considered when a company acquisition occurs.
Integration: The first scenario, known as integration, assumes that the environment of this new society will continue. In this case, the directory identities will have to be kept and synchronized to Azure AD if the group has an Office 365 environment. The establishment of approval relationships between its two environments will make it possible to easily share resources, via mono or bidirectional authentication processes. This scenario can of course be repeated, allowing new acquisitions to quickly integrate the group’s resources. This is sometimes the case when the acquired company retains its own identity or brands. In this case, integration is simple, users keep their own identity, their email address, their instant messaging ID etc… etc… etc…
From an architectural point of view, the two forests coexist on both sides with domain controller servers deployed in each respective agency. It should be noted in passing that this mode of operation may, however, raise some mobility concerns when a group user tries to connect from a subsidiary’s network.
In our case, directory synchronization processes such as Azure Ad Connect to Office 365 support these scenarios, and are perfectly adapted to these situations.
Despite this, and despite this relative simplicity, adaptations are often desirable and undertaken, such as the homogenization of email addresses, the standardization of resource naming as meeting rooms, distribution lists, security groups can be. The objective is then to offer users a single and homogeneous directory in which they can find their way and address resources between the various entities.
This integration can also be improved if both companies have messaging systems based on the same technologies such as Microsoft Exchange. In this case, so-called « rich » interactions are possible, such as being able to search the busy free slots of employees located in another subsidiary. More simply, if the group has chosen Microsoft Exchange Online messaging, with the subsidiary’s identities synchronized, it will then be quite simple to migrate the subsidiary’s messaging data to this new environment.
In this scenario, the group’s Identity and Access Management (IAM) processes will also be updated. They will have to take this new environment into account a posteriori, and be able to address it when new identities have to be created or deleted. This generally involves bringing this new directory up to group standards, by « populating » in particular unique identifiers (Personnel numbers, Identifier) on objects such as user accounts, subcontractor accounts, etc… Here again, the objective is not to eliminate the subsidiary’s directory but to integrate it into the group’s identity management processes.
Merger: The second scenario, which we will call a merger, consists in considering that the directory of the acquired subsidiary has the objective of disappearing. Only user data will be included, and the identities specific to the subsidiary environment will therefore have to be ignored in the synchronization processes. In most cases, all users as well as their workstations and server resources (to name a few) will have to migrate to the group’s Active Directory environment.
This scenario is obviously more complex and longer, but the integration in the long term will be more successful. Everyone will be integrated into the Group’s one and only Active Directory forest.In this case, the question is how to achieve this identity fusion, while integrating the migration of the related data. Again, without an identity, there is no migration project. How can you integrate the data of a new company into the Office 365 & Active Directory environment of a group, without synchronizing your directory data, knowing that data and access are closely linked?
The first thing to do is to create these same identities in the destination environment (Group environment) and synchronize them if necessary, in the Office 365 environment. A common key will have to be established between the two directory environments to ensure that a one-to-one relationship for user accounts in particular can be established. Users will have two accounts, one in their original forest, one in the group’s forest.
In most cases, the creation of these new identities is based on the group’s current standards, so it is not uncommon for the login names to be different for the subsidiary. If the group uses Office 365, the user’s login name (UPN) will generally be identical to their main email address (@agency.com for example), which will force the subsidiary in the event of two-way approval relationships to no longer use it for the benefit of the group directory. (Deletion of the UPN in the source forest in case of a bidirectional approval relationship).
For reasons of access to the agencies’ resources, the creation of these user accounts will also have to take into account their old identity and more particularly what is known as the Sid History. This Sid History will allow users who need to use their identity within the group to continue to have access to their old resources such as file services.
As the agency directory must disappear, and therefore must not be synchronized around 0365, it will also be necessary to recreate all the inherited security and distribution groups to the group directory, taking care here too to keep their Sid History (Security Group only). Most companies often use this opportunity to rename them so that they follow the current nomenclature (this is called directory data transposition rather than duplication). As the fusion scenario is a process that will last, until all workstations integrate the new forest, this transposition will have to be maintained to allow resources to move to these new identities.
Once this transposition is implemented and maintained, the displacement of resources can take place. The latter will have to rely on and take into account this identity transposition to modify the inherited authorizations and replace them with the group’s identities. This is what migration tools generally do by integrating as Sharegate an identity mapping table as part of the migration of Sharepoint resources whether they are hosted on site or on 0365. (Migration Tenant à Tenant)
Once migrated, users connected with their accounts in the group’s forest will find their accesses on their Sharepoint sites.
For mailbox & public folder migration, if the subsidiary uses the Exchange environment, the migration is more complex and would deserve a thorough publication. However, by duplicating the email attributes of users in the Source environment to the destination forest, you should be aware that it is possible to move mailboxes from the subsidiary to the group environment by attaching these mailboxes to group identities. This mailbox movement having as a particularity the preservation of the Mailbox Guid attribute, it will allow the automatic update of your users’ Outlook profile, avoiding you an intervention on each workstation.
Identity, as we have tried to demonstrate to you, often underestimated, therefore plays a decisive role in integration projects and, depending on the level of complexity, can call into question your migration strategy. Analyzing how these mergers, adaptations and the consequences of their modifications on the application environment will be carried out is essential to build a realistic project plan. This should be one of the first steps to be taken into account. Without an identity, there is no migration.
Regards
Laurent TERUIN
Anthony Costeseque
cbopenhost
Teruin laurent
Marion Diné
David ANDRE
David PEKMEZ
Yohan Boullier
