In what looks like another attempt to curtail unsanctioned use of shared mailboxes in Exchange Online, Microsoft has begun blocking the ability to grant folder-level permissions to shared mailbox principals via PowerShell. As a side effect, you will no longer be able to use the Add-MailboxFolderPermission cmdlet to designate a shared mailbox as “delegate” either. For some reason though, all other types of permissions can still be granted to a shared mailbox, so this change might turn out to be a bug instead. Or we are seeing the first step in adding additional restrictions to shared mailboxes… only time will tell.
As reminder, shared mailboxes are a type of mailbox that is not directly associated with any user within the directory. While a user object is still provisioned, no login credentials are generated for it and the account itself is blocked from login. Instead, you grant permissions to “regular” users to get access to the shared mailbox and use it as common workspace. Common uses for shared mailboxes include help desk/support scenarios, scenarios involving collaboration between a group of users, and so on.
Even though nowadays there are newer alternatives, such as Microsoft 365 Groups, shared mailboxes still offer benefits such as full support for rules, access subfolders, and more. Basically, they offer the same functionality as a “regular” user mailbox, although some features might only be available if you add the shared mailbox as additional account in Outlook. Combine this robust feature set with the fact that shared mailboxes do not requite an Exchange Online licenses, apart from some specific use cases, and you get a lucrative opportunity to “get free stuff” that continues to be exploited by some customers.
Microsoft has of course made it clear that shared mailboxes are indeed only intended to be used as shared resource, and not as a replacement for user mailboxes. Yet, no service side solution has been put in place to limit such use cases, following the general rule that Microsoft (usually) does not enforce licensing restrictions in code.
Which brings us back to the topic at hand. As mentioned above, it looks like we can no longer designate a shared mailbox as the “delegate” when using the Add-MailboxFolderPermission cmdlet. If you try to do so, you will be greeted with an error, as shown on the screenshot below. Yet, existing permission entries where a given shared mailbox was designated as folder-level delegate are still around, as the last cmdlet shows.
Add-MailboxFolderPermission sharednew -User shared-AccessRights Reviewer Add-MailboxFolderPermission sharednew -User shared@michev.info -AccessRights Reviewer
In the examples above, we used the “root” folder as the –Identity value, but you will get the same result with any other folder (i.e. sharednew:\Calendar will have the same effect). Now, it is worth mentioning that both error messages above are quite misleading. In fact, a quick check will confirm that the object does indeed exists in the directory, and so does its associated SMTP address. In addition, the shared mailbox remains a valid security principal, i.e. it can be used to assign permissions (more on this in a bit). Here are the corresponding checks:
#Check if the user exists Get-User shared Name RecipientType ---- ------------- shared UserMailbox #Check if it is a valid security principal Get-SecurityPrincipal shared SID : S-1-5-21-3675944716-2045640655-299186705-11523907 DisplayName : shared RecipientTypeDetails : SharedMailbox Type : User #Check the email address is valid one Get-Recipient sharednew@michev.info Name RecipientType ---- ------------- sharednew UserMailbox
To further illustrate the fallacy of the error messages thrown above, we can actually use the same exact object to grant some other permission types. The first example below shows the result of granting Send As permissions; the second one granting of Send on behalf of permissions; the third one granting Full Access permissions. As all of these completed successfully, we can indeed confirm that the shared mailbox object indeed exists and is a valid security principal.
#We can still grant Send As permissions to a shared mailbox principal
Add-RecipientPermission sharednew -Trustee shared -AccessRights SendAs
#We can still grant Send on behalf of permissions to a shared mailbox principal
Set-Mailbox sharednew -GrantSendOnBehalfTo @{add="shared"}
#We can still grant Full Access permissions to a shared mailbox principal
Add-MailboxPermission sharednew -User shared -AccessRights FullAccess
Based on the examples above, we can conclude that the Add-MailboxFolderPermission cmdlet is deliberately behaving like a shared mailbox is not a valid object to delegate permissions to. Thus, our suspicion that this is a scenario that Microsoft has targeted specifically. Interestingly enough though, only shared mailboxes are affected, and not room/equipment ones, which in fact can also be “leveraged” in the same fashion… but let’s not give you any ideas 🙂
Another interesting observation is that the change seems to only affect some endpoints. There are indeed multiple ways you can use to grant folder-level permissions. Apart from blocking this scenario for the Add-MailboxFolderPermission cmdlet, it looks like OWA (and thus the “new” Outlook) also prevent delegating permissions to a shared mailbox now, as shown on the screenshot above. But you can still grant folder-level permissions via Outlook classic, either via the Delegate Access dialog or the Folder properties one. I’m guessing Microsoft is relying on Outlook classic and EWS both being deprecated soon 🙂