MIM 2016 SP2: An Alternative Way to Set Credentials and Associated Parameters in a Pinch

How can you set up MIM 2016 SP2 for an Office 365 Mailbox with modern authentication – without the MIM installation disc?

I was faced with having to convert an installation of MIM 2016 SP2 to use an Azure application ID instead. Normally I would use the MIM installation bits and run a change installation (see here for guidance). However, the bits were not available in the client’s test environment and there was no easy way to download until a specific admin returned from vacation. I was familiar with the registry entries that govern authentication to Azure. It became a matter of setting the right values.

This blog will lay out the steps you can take in order to set up MIM for an Office 365 Mailbox with modern authentication when you don’t have access to the MIM installation disc.

First, I followed the instructions in the “Registering application using Azure AD portal” section of the above document. A typical App registration for a MIM Exchange Online (Office 365) Mailbox is:

There are five registry entries required by MIM to access an Office 365 mailbox with modern authentication using an application ID. The goal is to set the following registry keys under HKEY_LOCAL_MACHINE\SOFTWARE/Microsoft\Forefront Identity Manager\2010\Service.

I recalled that Microsoft published a document titled, “Update of MIM Specific Service account for notifications to gMSA“ that stated, “Update the password to stored accounts, below is the PowerShell so customers do not have to run change mode.” Having previously reviewed the script, I remembered that it did the same for non-gMSA accounts.

After inspecting the registry, I predicted that the EncryptedExchangeOnlineAccountPassword and EncryptedExchangeOnlineClientSecret might be encrypted using the same mechanism. As it turns out, it was a good prediction.

Registry Keys for Modern Authentication to Azure

The App ID and the Tenant ID values can be entered into the registry directly. Additionally, two other keys, MailAuthType and MailServerType, should also be updated.

I modified the script to write the encrypted value to EncryptedExchangeOnlineClientSecret. The only difference is the last line which writes to client secret key to a different registry key.

For the script to run successfully, it should be run in the context of the FIMService account, and the account should be a member of the local Administrators group to save the values to the registry. Note: the script will also accommodate cases where the FIMService account is a group Managed Service Account (gMSA).

Running the script

Steps to follow:

• Add the MIM Service account to the Local Administrators group if it is not already a member.
• Launch an elevated PowerShell window in the context of the MIM Service account.
• Navigate to the folder where the script resides.
• At the PowerShell command line, execute .\O365Update.ps1
• The script asks if MIM Service runs as a managed service account. Answer appropriately.
• The script then provides a pop-up text box in which to enter the password to be encrypted. Enter the client secret.
• A second, confirming text box appears. Enter the same client secret. The script should complete without error.

Troubleshooting

While using this method, the only error I identified came about when I encrypted the password via the wrong account. The FIMService would not start, and the event log clearly stated it could not decrypt the password.

If your organization needs assistance with MIM, our expert team can help! Contact us here.