Identity Transfer

Installing Azure AD Connect

In addition to the .NET Framework, service accounts are required in the AD. For the example of Azure AD Connect, you just need the service account to be a member of the domain users group. Depending on which edition of Azure AD Connect you install, however, other rights are needed – especially if information from Azure AD needs to be written back to the local AD. An overview of the necessary setup configurations with the respective rights is also available on TechNet [4]. The Azure AD Connect setup on the server is unspectacular and does not involve any real pitfalls.

After the installation wizard has completed, you will find various programs on the server. They include Azure AD Connect. You are offered the possibility to view the current configuration or edit it, if necessary. The Synchronization Rules Editor allows fine tuning of what it synchronizes and how; transformations are also possible here. The most important program is the Synchronization Service Manager, your command center. This is where the MA and run profiles are defined; you can also browse the connector spaces and the metaverse.

You must be absolutely sure of what you are doing before changing anything in Synchronization Service Manager. In the case of the Azure AD Connect server, all the important settings are taken from the setup routine, and the synchronization service is set up with the local information in place and ready for action, unlike at manual MIM setup, which I will show later. If changes are necessary, again use the Azure AD Connect wizard, which configures the synchronization service with the new settings, this actually eliminates the need for direct adjustments – fine-tuning apart.

The setup also configures the scheduling service and is thus synchronized by default every three hours. In the case of urgent changes that must be immediately available in Office 365, you can use the DirectorySyncClientCMD.exe tool to trigger an immediate sync. After the first run, the users in the online portal are synchronized and can be enabled and provided with licenses there.

Clean up Before Running Setup

It is recommended that you clean up your AD before you start synchronizing with Office 365. Duplicate email addresses or non-standard characters in important user attributes, for example, can cause problems, which will be time-consuming to eliminate later. An Office 365 article [5] shows which preparations are useful. It describes the pitfalls and lets you download the IdFix tool. This is a utility that not only checks AD but also draws attention to potential problems and offers steps for eliminating them. It installs without a time-consuming setup and does not require extensive rights, apart from write privileges for any corrections.

Installing MIM Synchronization

Commissioning the MIM synchronization service on the second server requires more manual work. I'll look at the service accounts first. Because the MIM setup takes place independently of Azure AD Connect, and the two services run separately on their own servers, you need to choose a service account in the KBCORP domain for the MIM server. Again, this does not require wide-ranging administrative rights, either in the domain or on the MIM synchronization server. A domain user is sufficient. For access to the two domains that you want to synchronize when configuring the MA, a separate user account is also needed in the respective domain. Both accounts must have the "replicate directory changes" privilege in their domains. You can assign this in the security settings at domain level. Other rights are not necessary at this point.

The MA in the KBDEST domain additionally requires permissions to create the replicated user accounts in the target organizational unit (OU) of KBDEST. Before you start the MIM setup, you need to install the SQL client on the server. The installation wizard is largely self-explanatory. It is launched via splash file on the MIM Setup DVD. This is also where you will see the remaining products from the aforementioned MIM portfolio.

The setup dialog itself is worth mentioning; you use it to set up the security groups so that you can later associate administrative tasks with user roles. It makes sense to prepend the domain name to the group; this ensures that the setup uses the groups in the domain. Otherwise, these groups are created locally on the server. This is not a big deal, but group management – in particular of administrative groups – should be part of your AD. When you install a hot-standby server for MIM, as described later, you will not get far with local groups anyway, because they are not automatically created and populated with accounts on the second server. AD thus makes far more sense.

Otherwise, the installation wizard is self-explanatory. Even a backup of the encryption key is created at the end. You will want to keep this backup file because it is used for a new installation with the same database or if a second MIM synchronization server, such as a hot standby, enters the scene.