Sometimes, you might want to assign an already existing mailbox to another user. With on-prem Exchange, this can be easily achieved. In Exchange Online however, there are certain limitations that prevent you from doing this. For starter, you don’t have access to the Disable-Mailbox cmdlet (removing the Exchange license from the user is an entirely different process). If you are desperate enough however, there is a way to actually achieve this.
DISCLAIMER: Attempt these steps only if you are familiar with dirsync and have an understanding how the provisioning process works. There are much easier ways to ensure that the mailbox content can be accessed by another user. Those include converting the mailbox to shared one, granting permissions to another user (with ot without converting the mailbox), exporting the mailbox content to .pst file, copying the mailbox content to another mailbox using the Search-Mailbox cmdlet, etc. In addition, if the mailbox you are trying to ‘attach’ is already removed (i.e. you can see it with the Get-RemovedMailbox cmdlet), you can reconnect it by using the New-Mailbox -Removed mailbox cmdlet.
If you are still reading, I assume you are either too stubborn, desperate or curious to try the process. The key here is to (ab)use the directory synchronization process and the soft/hard match functionality. Those methods will only work if the targeted user object does not have an ImmutableID property, or if you are able to change it. In other words, the object must be a disconnector in the metaverse (or never been synced before). To demonstrate the process, I created a new user object in my local AD and synced it to WAAD:
Once the object was synced, I provisioned a mailbox for it and sent a message announcing my diabolical plans. I’ve also used PowerShell to gather some information I will later need. Here are the relevant attributes:
PS C:> Get-Mailbox swapmailbox | fl *guid* ExchangeGuid : 96658711-bdb8-4b78-a907-12f0e5cb60ca Guid : 6290c800-2879-4d99-8bd1-acb3ffe36d44 PS C:> Get-MsolUser -SearchString swap UserPrincipalName : email@example.com ObjectId : 151a4f28-fb9d-45ef-95bf-b3a7cccfeb2f ImmutableId : xiL1lf4nx0W6w4Ac/9qrTA==
The next steps was to force the object in the “disconnector” state. This can be done if you delete the object in the on-prem AD and restore it back from the O365 portal (but leave it deleted in AD!). The corresponding mailbox will then be pushed to the soft-deleted container, but once you recover the user object it will automatically be reconnected. Here are some screens of the process:
So, as you can see the mailbox was automatically reconnected to the recovered account and everything is back to where we started. With one small difference, though: the user object is now a disconnector! Which means, we can play with it’s ImmutableID attribute and match it against another user. Or we can just clear the attribute and use the soft-matching process, but why do it the easy way?
I created a new user in AD, appropriately named ‘mailboxthief’. I used the following cmdlet to convert the objectGUID attribute to ImmutableID:
Then, I replaced the ImmutableID of our disconnector user object swapmailbox with the ImmutableID of the mailboxthief object, thus ensuring that the hard-match process will take place with the next dirsync cycle. Here is the cmdlet:
Set-MsolUser -UserPrincipalName firstname.lastname@example.org -ImmutableId "1KlUci/w70u0mOz242tEPw=="
Here’s what happened after the next dirsync push:
And here’s how things looked up in Office 365:
Dirsync actually failed to update the UPN, but that can easily be arranged with the Set-MsolUserPrincipalName cmdlet. The important part is that the object is no longer a disconnector, it’s actually linked to the ‘mailboxthief’ object from local AD. And what better proof of that than comparing the GUIDs:
PS C:> Get-MsolUser -SearchString swap | fl UserPrincipalName,ObjectId,ImmutableId,LastDirSyncTime UserPrincipalName : email@example.com ObjectId : 151a4f28-fb9d-45ef-95bf-b3a7cccfeb2f ImmutableId : 1KlUci/w70u0mOz242tEPw== LastDirSyncTime : 01/10/2014 11:42:05 PS C:> Get-Mailbox swapmailbox | fl *guid* ExchangeGuid : 96658711-bdb8-4b78-a907-12f0e5cb60ca Guid : 6290c800-2879-4d99-8bd1-acb3ffe36d44
If you compare those with the values at the beginning, you will see that this is indeed the same mailbox. The WAAD user object linked to it is also the same (note the ObjectId parameter). That object however is now linked to a different object in my local AD, thus the ‘mailboxthief’ has claimed ownership of the ‘swapmailbox’.
Alternatively, the same end result can be achieved if you simply disable dirsync (which will make all objects disconnectors), change the ImmutableID (allowed for disconnectors), force the sync. In case the on-prem object has already been synced previously, you will have to get rid of the linked object in WAAD.