The synchronization of users, groups, and contacts between directory services can be a challenge. Windows Server and Active Directory (AD) do not provide any functions for this out of the box. Microsoft Identity Manager (MIM) 2016 can help to sync not only identities in the local AD, and between a variety of sources, but even in Azure AD and Office 365.

MIM 2016 is a classic identity and access management (IAM) tool. It is strongly linked with AD and Exchange and offers features for provisioning identities, role-based access management, certificate management, and self-service tasks, such as resetting passwords, managing smart cards, and synchronizing objects. All MIM tools deal with the life cycle of identities. The key feature is the MIM portal. This is where many of the suite's identity management-related functions and tools are controlled.

The synchronization service in the background is used, for example, to implement the rules defined in the portal for creating new users. But even without the portal, the synchronization service can be meaningfully used. Starting from a central location, it lets you synchronize various connected sources without having to use the parent portal. This article looks at how to handle local synchronization between directory services and how to include Azure AD, if you happen to use Office 365.

The product family was launched in 2007 under the name Identity Lifecycle Manager (ILM) 2007 and was a merger of the Microsoft Identity Integration Server (MIIS) and Certificate Lifecycle Manager (CLM) tools. In 2010, Microsoft integrated the products into the Forefront range and Forefront Identity Manager (FIM) was born. Because the Forefront portfolio was discontinued, Microsoft announced in 2014 that it had renamed FIM and that it would now be developed under a new name as MIM. The current version, released in 2015, is MIM 2016, which includes the above-mentioned synchronization service.

This has survived all product cycles almost unchanged. The history of MIM or FIM is also important, because the technical documentation for the synchronization service on TechNet still often refers to the "FIM synchronization service," although the description is just as applicable to MIM because the service remains the same at its core. If you install Azure AD Connect, then a version adapted to Azure AD ends up on the intended server to handle the user information in Office 365.

Structure of the Synchronization Service

If you look at the synchronization service's elements, it soon becomes clear that it is more than a minor service. It is installed on a member server in AD; you also always need an SQL server. SQL can run on the MIM server if you like. Later, I will look at the requirements for commissioning in more detail.

In many cases, AD is likely to be where you will find most of the objects to be transferred, but MIM can also work with other data sources. This does not need to be a directory service such as the Microsoft AD or Novell eDirectory. Text files, or an SQL Server that contains user data, are just as conceivable. Wherever the objects to be synchronized reside, a corresponding management agent (MA) is always needed to access a data source (Figure 1).

Figure 1: The rights required for a management agent are manageable.

Each MA has its own connector space, containing all the imported objects, on the SQL Server. Depending on the requirements, several MAs can be set up so that multiple connector space exist. In this context, the "metaverse" also enters into play; there is only one of these, independent of the scenario. The metaverse is a conglomeration of tables in SQL Server and basically forms the heart of the MIM synchronization service. It is deployed at a central point to keep outbound and inbound-defined objects logically in sync with the connector space. This depends on how the "run profiles" are set up – another important element for the administrator. Via a scheduling service, run profiles are executed regularly; they define imports, exports, and also synchronization for each MA. You will find some very good articles on TechNet [1] with in-depth coverage of the dependencies.

You can thus set up constructs, such as directly creating corresponding user objects in AD from the data of an SQL-based HR application. Or, in case of implementations that have a separate resource forest for an Exchange environment, you could keep the forests synced and populate several ADs. The corresponding disabled user accounts are automatically synchronized and end up in the resource forest – to mention just two examples.

Synchronizing with the Cloud

Office 365 uses an internal directory service in the form of Azure AD that is similar to the local AD. To use Office 365 in a meaningful way in a larger context, AD synchronization is essential. For example, a user account created in Azure AD must be able to license users for the Office 365 services.

Synchronization does not depend on whether the users log on to Azure with the same username and password (same sign-on) or whether a single sign-on is possible via an AD FS implementation. Although you could create the users manually, this makes little sense in larger environments. The administrator's life is simplified if the local AD is coupled with the Azure AD and newly created users are automatically synchronized with the Azure AD.

If this includes synchronized passwords, it simplifies user logins in Office 365. Changes and deletions are also naturally kept in sync. Microsoft offered several tools for this in the past. The current tool is called Azure AD Connect. It is somewhat confusing that Microsoft does quick product changes and frequently changes the name of the synchronization tool. The first version was called DirSync and was replaced at the end of 2014 by its successor, Azure AD Sync. Less than a year later, it was again obsolete and Azure AD Connect (June 2015) was released. Under the hood of Azure AD Connect, you will find a customized version of the FIM or MIM synchronization service, by the way.

One downside is that the MIM synchronization and Azure AD Connect services cannot be run together on a server – they use the same technology at the core. If you already have an FIM or MIM-server and want to additionally set up synchronization with Azure AD, there would be the possibility of using the Windows Azure AD connector on the MIM server. This saves you a server license, but you need to bear in mind that the connector is no longer under active development. Support is still provided, but it does not make much sense to use the connector.

Apart from that, the last new features only made their way into Azure AD Connect (e.g., the ability write passwords back to the local AD) if users change these in Office 365. It remains to be seen how Microsoft will manage the software zoo of synchronization tools in the future. The aim can only be to have a single solution, but it is still not foreseeable today.

MIM in Action

Suppose you have a scenario with an AD forest named KBCORP.DE and a second forest named KBDEST.DE. KBCORP is the user domain in which the users log in. In the KBDEST domain, you need to keep selected user accounts for testing purposes, for example. The domains are not connected by a trust relationship. You also want users from KBCORP to be able to log into Office 365 with their normal user accounts and passwords.

All told, you'll need three servers: one for Azure AD Connect, one for the MIM 2016 synchronization service, and one for SQL Server. Azure AD Connect would also be fine with Microsoft SQL Server 2012 Express LocalDB, for MIM needs SQL Server. It could be installed on the MIM server, but in this example, the two synchronization servers share a single SQL Server 2012; this has no influence on the setup for the two servers. For the software and hardware requirements, see TechNet for Azure AD Connect [2] [3] for the synchronization service.

For this example, you can assume that the SQL Server is available, the KBCORP.DE domain is already registered in Office 365, and the AD domains are also available. Thus, you can turn directly to the Azure AD Connect server, assuming that .NET Framework is installed there. Its version depends on the version of the server operating system on which Azure AD is installed.