How to Detach and Attach Office365 Accounts to Hybrid User

Nowadays most companies utilizing Office65 have a hybrid on-prem - cloud environment setup.

This means on-premises users have a (kind of) exact copy of their user accounts in the cloud system that is regularly (every 30 minutes) synchronized with the on-prem version. If their name, address, phone number, office location changes that change is reflected in the cloud too that's to this synchronization process.

Because Single Sing-On (SSO) is implemented between the regular and their Office365 environments, users only have to log in to their computer once and when they use their cloud mailboxes, Teams accounts or OneDrive storages they do that seamlessly. No need to worry about cloud logins. SSO handles it behind the scenes.

This also means that it's possible to detach or unlink user cloud accounts from their on-prem account. An existing or new account can also be linked to cloud user accounts easily.

In this guide we go through the process of detaching a random user's Office365 account (Alice) and create her a brand new, fresh cloud account. We keep her old cloud account just in case we needed files from her OneDrive or Exchange Online mailbox. It's possible to just delete the cloud account and create her a fresh one but that case all of the files, messages she had stored in the old account would be lost.

For simplification purposes we refer to on-prem environments by AD (Active Directory), while AAD (Azure Active Directory) will mean the cloud system.

I. The Baseline

Alice works for a company called Protectigate LLC. The firm has an on-premises Active Directory domain, protectigate.com. They also set up an Office365 tenant protectigate.onmicrosoft.com, and Azure Active Directory synchronization is set up to keep user accounts synced automatically.

Alice has an account on-prem. UserPrincipalName alice.protectigate.com, synced normally.

AD and AAD accounts are linked together via an anchor property. To make it easier to understand we use exact examples here. Protectigate uses the default AD sync configuration, where the AD user ObjectGUID property is the anchor object. During initial sync the AAD Dirsync tool checks Alice's ObjectID, encode it in Base64 and create a corresponding cloud object where the immutableId gets this encoded value.

From this point on the sync process knows which on-prem accounts belong to which cloud account by checking this immutableId.

Let's check Alice's ObjectGUID first:

PS C:\> Get-ADUser alice

Now create the Base64 encoded string value from this ID.

$GUID = '06653306-cf7e-4285-8a7c-a993622d5d0e'
[Convert]::ToBase64String([guid]::New($GUID).ToByteArray())

BjNlBn7PhUKKfKmTYi1dDg==

Now connect to the MicrosoftOnline service using the Connect-MsolService cmdlet and check Alice's AAD account. The immutableId should match this encoded string.

PS C:\> Get-MsolUser -UserPrincipalName alice@protectigate.com | Select-Object UserPrincipalName, DisplayName, ImmutableId, LastDirSyncTime

Exact match, as expected.

Out of plain curiosity, we can convert the immutableId back to a Base64 decoded format that should match the on-prem ObjectID value perfectly.

$immutableID = 'BjNlBn7PhUKKfKmTYi1dDg=='
[GUID]([system.convert]::FromBase64String($immutableID))

So this is how the directory synchronization process knows that these two accounts belong together. The accounts are properly linked. Let's call this state Phase 1.

II. Detach User from Original Account

A user is connected to its cloud account by the immutableID, so in theory wiping that property would disconnect the AD and AAD accounts.

There are two caveats with this approach. One being while the on-prem account is synced you cannot modify the immutableID of the cloud account. You can convert the cloud account to cloud-only type by moving the AD account to a non-syncing Organizational Unit and do a sync cycle.

This is where caveat number two come into the picture. Microsoft changed the syncing process and now the AAD account has another property called OnPremiseSecurityIdentifier that also keeps track of the link between the two accounts. Unfortunately that ID cannot be edited, not even after converting the cloud account to cloud-only type (* check Troubleshooting section for details).

To get around this issue, we do a trick: creating a new on-prem 'dummy' account, changing the immutableID to this account then syncing it to the cloud will make the AAD Sync program refresh the OnPremiseSecurityIdentifier, changing it to the dummy account.

The procedure is represented as Phase II. and Phase III. below:

So the process:

1. First, create a new user account on-prem to link the original cloud account to at a later step.

# Create "Alice DUMMY" to link the original AAD account to:
New-ADUser -Name "Alice DUMMY" -UserPrincipalName alice.dummy@protectigate.com -SamAccountName alice.dummy

2. When done, generate the immutableID that we'll use to add to the cloud account.

# Generate immutableId:
PS C:\> [Convert]::ToBase64String([guid]::New((Get-ADUser alice.dummy).ObjectGUID.Guid).ToByteArray())

JoIygYW8vEquzfq7YBk8iQ==

3. Move the original AD user account to a non-syncing OU, then initiate a sync cycle or wait for an automatic sync happen.

# Run a delta sync cycle (no need for an initial sync)
PS C:\> Start-ADSyncSyncCycle -PolicyType delta

4. Restore the cloud user.

By not syncing the user, AAD sync put the cloud account in a soft-deleted state. Restoring the account using PowerShell automatically converts it to cloud-only type:

# Restore Alice user in the cloud
PS C:\> Get-MsolUser -UserPrincipalName alice@protectigate.com -ReturnDeletedUsers | Restore-MsolUser

5. Change the immutableId of the cloud account to the dummy on-prem user:

# Change immutableId
PS C:\> Get-MsolUser -UserPrincipalName alice@protectigate.com | Set-MsolUser -ImmutableId "JoIygYW8vEquzfq7YBk8iQ=="

6. Sync the dummy user to the cloud

Move the dummy user to a syncing OU, and initiate a sync cycle.

This step will accomplish two things:

1. Detaches the old account from the on-prem account
2. Attaches it to the dummy account automatically.

7. Last step is to move the old on-prem user account to a syncing OU and let it sync to AAD.

Once done, a brand new AAD user account is created for Alice (Phase IV.) You just need to sort licensing and the basic setup procedure for the new account.

III. Verify

Now if we query MSOL users we can see both the old Alice user, now with a fresh account (just created), and the dummy account with the old AAD account connected to it!

V. Troubleshooting

1. When trying to alter the immutableId of a syncing user, you get the following error. Move user to a no syncing OU or delete the on-prem account (only if you have AD Recycle Bin enabled so you can restore it later), and do a sync cycle. Then restore the O365 account from the Deleted Users container.

2. If user is unlinked and immutableId is removed, the OnPremisesSecurityIdentifier stays unchanged in the cloud account, linking the account to the on-prem account still.