I recently was asked to advise on how cloud identities can be converted to federated identities such that when Dirsync is ran, the on-premises Active Directory becomes the new source of authority.
Dirsync will attempt a soft match if the primary email address attribute exists on both sides AND (the immutable ID matches the ObjectGUID on-premises OR the cloud immutableID is empty) <- see note below for an explanation why this matters. This is best documented on MS KB 2641663 and on Stephanie Kahlam’s blog (here).
However, what if the cloud identity is not enabled for Exchange Online? In that case, there is no primary address for a cloud identity to use for soft matching. For example, if the user was only configured for CRM Online or another O365 service.
In those cases, the work-around is to use a “hard match” technique. This is performed by updating the cloud identities to use the same user principal name (UPN) as the on-premises AD account. This is performed in Windows Azure Powershell for Office 365 with this command:
Set-MsolUserPrincipalName -UserPrincipalName [email protected] -NewUserPrincipalName [email protected]
Without doing this step, Dirsync will create a duplicate object in the cloud. The second step is to update the immutableID value of the Office365 object to match the on-prem ObjectGUID. This is where it gets interesting. You can find out the ObjectGUID easily enough with the get-Aduser powershell command. However, this is not in the format expected by O365 and therefore must be converted. There is a free script available to perform the conversion available on the Technet Gallery (here). You can also use the Quest Powershell module for Active Directory and follow the steps in this blog post (here).
Now in Windows Azure Powershell for Office 365 you can run this command:
Set-MsolUser -UserPrincipalName [email protected] -ImmutableId RDHiRneDPkiofrZ2nbYu7Q==
Then force dirsync to run and that should convert the cloud identity to be sourced from on-premises Active Directory.
[Update 1/29/2016 – big lesson learned here is that if the cloud identity ever pre-existed from a previous dirsynced existence (for example, if prior to an ADMT migration, if the account originated from a separate AD forest than where the account exists presently) then soft match will never work – it will throw a bogus error about duplicate proxy addresses in the MIIS GUI. The only solution is to hard match by updating the cloud identity with the new on-prem ObjectGUID (following conversion from the steps above]