Mar 21 2019
- last edited on
May 24 2021
I have applied the Do Not Forward information protection template to messages addressed to a shared mailbox. When a user who has full access rights to the shared mailbox tries to open one of these protected messages in outlook, she gets a message stating that she doesn't have permission to open it. If she opens the shared mailbox in OWA and opens the email from there, it opens and displays successfully.
Should she be able to open a protected message from a shared mailbox that she has full access rights to? Why would outlook say she doesn't have permission? What can I do to allow her access to the messages using Outlook?
Mar 22 2019 03:08 PM
Mar 22 2019 09:55 PM
The current model is that a user only has access to content that grants rights to the user's identity or a group that contains that user's identity. Since granting rights to a shared mailbox does not make the user a member of a group, this doesn't allow the user of a shared mailbox to gain access to content that grants rights only to that mailbox.
We are currently working on addressing this scenario (grant users of a shared mailbox access to protected content sent to the mailbox). Please note that this is only an issue for Do Not Forward since for labels with admin defined permissions it is easy to address by adding the users of the mailbox to the policy.
No ETA yet, but this work is well under way.
For other Delegated Access scenarios (e.g. admin assistant) we intend to provide administrator-level control to define whether access should be granted or not, but this is further down the road.
Hope this helps.
Mar 23 2019 12:11 PM
Thanks for the explanation @Enrique Saggese. I still have a couple of questions about this situation that I hope you can clarify.
Why is it that if the user opens Outlook on the web and opens the shared mailbox from there, they are able to view the protected email messages? If they don't have rights to access the content, I wouldn't expect it to work there either.
Second, you mentioned adding a user to a group as a way that they get rights to the content. If I assigned a group full access rights to the shared mailbox and added the users to the group, would that allow them access to the content? Based on what you've said, I don't think so, but wanted to be sure.
We had initially tried creating this mailbox as an O365 Group, which it sounds like would have worked better with the content protection. Unfortunately, we have a hybrid exchange environment configured with centralized mail flow. We couldn't get external email delivered to the group, and after searching through the documentation I discovered that is a known issue with this configuration. That's why we ended up deleting the group and going with a shared mailbox instead.
Mar 23 2019 06:50 PM
@Steve Whitcher I'm travelling right now so I cannot really test this, but here are some thoughts. When it comes to accessing shared mailboxes in Outlook, there are few different methods. You can access a given folder directly or use the Open another mailbox functionality or even have the shared mailbox automapped. All of these are practically the same, and they only expose some functionalities in Outlook. On the other hand, you can also add a mailbox as Additional account (via File -> Add account), which makes Outlook treat it the same as your primary account.
My point being, if you haven't tried this already, try adding the shared mailbox as additional account. Using the "open another mailbox" functionality in OWA is practically the same method, and since it works OK for you I suspect using the analog in Outlook should work as well.
I suspect it will only apply to features that do not explicitly depend on the AIP add-in though.
Mar 24 2019 03:01 AM
There are two primary ways to establish delegated access to a mailbox.
One is OWA delegation, in this case, the delegated user logs in as Delegated which does not grant access to the mailbox's email either in OWA or in Outlook.
The other scenario is mailbox delegation from ECP. In that case, when logging in through OWA the user will request licenses in the context of the mailbox and as such they user will get access to content protected for the mailbox.
We are working to bringing these behaviors into alignment, so both through OWA or through Outlook, you can control whether the user with delegated access to a mailbox is granted licenses to the content protected to the mailbox.
Regarding a group, what you describe would still not work, since even using a group, rights have only been granted to the mailbox, not to the group, so only the mailbox, and not the groups of which the mailbox is part, get access.
Yes, using an O365 group would have addressed this better than a shared mailbox, but we realize that solution is not ideal for all scenarios, so we are working to enable the shared mailbox users to get access to content in the mailbox regardless of the client. Hopefully we will have this ready in coming months.
Nov 25 2019 10:53 AM - edited Nov 25 2019 10:53 AM
Hi @Enrique Saggese,
I wanted to follow up on this thread as it has been several months now. You had mentioned in March of this year:
"For other Delegated Access scenarios (e.g. admin assistant) we intend to provide administrator-level control to define whether access should be granted or not, but this is further down the road.
Hope this helps."
Has there been any updates regarding development on this? Essentially, I'm curious if there is a way to PREVENT certain admin assistants who normally have full control as a delegate of the mailbox from reading certain messages. So emails marked with a certain policy would only be available to open by the user's mailbox, with the admin unable to read/view.
Thank you and I look forward to hearing from you.
Jan 07 2020 08:11 AM
I would also like to know if there has been any update to this. Thank you.
Jan 07 2020 04:31 PM
@ScottVAMT Access to protected content sent to a shared mailbox is in the market now for users directly being granted access to the mailbox. We still don't have a solution for users that are granted access to the mailbox via a group. We will continue working on it.
Jan 08 2020 07:39 AM
@Enrique Saggese Thank you for your response. I had tested this without error before putting out that Azure Rights Management was "OK" to use with shared mailboxes.. to our over 2000 users... but then received an inquiry from one, with older information that stated it wasn't. You've cleared up this question.
Jan 26 2020 11:13 PM
This still doesn't work for us. Is this implemented for all organizations already?
Mar 02 2020 09:03 AM
@Enrique SaggeseIf a target recipient is a "regular" mailbox, but not specifically configured as a "shared" mailbox, and multiple authenticated users have delegated access to this mailbox, is it expected these authenticated users should be able to open the message/document? Or is it important that the "shared" mailbox be a true shared mailbox? (I just want to be sure before we try to convert to a truly shared mailbox as there are automated processes that also pull content from the mailbox).
Mar 03 2020 02:28 PM
@Scott Wakeman I'm no longer working on that area but my understanding is that with the updates shipped last year if the user is directly assigned full access permissions to a mailbox, they should be able to view protected content to which the owner of that mailbox has rights. But there are some constraints, for example if rights are granted indirectly through a group that doesn't work. I recommend consulting in the Exchange forums for more details.
Apr 07 2020 06:38 AM
In my tests it must be a true shared mailbox and not a mailbox with delegated access.
And I think this is correct. If I give someone delegated access to my mailbox, I dont want that they also are able to open the critical protected information. Instead they have access to the usual stuff and other stuff is still protected for me.
May 05 2020 01:41 AM
I'd also like to follow up on this thread as we need to prevent our assistants with delegated full-access permissions from accessing another users (lawyers) protected Mails through OWA.
The issue is also referenced here:
Is there anything we can do about this other than completely disabling OWA access?!