Delegates, shared folders, and sending mail as somebody else.
I’ve have had many generic requests for what has come to be known simply as “Delegate Access” so I’ve put some thoughts together.
Let me start by taking a step backwards.
Outlook and Exchange are only 30% of the solution.
People, Process, Technology. I know it’s a cliché, but it’s very true. Out of the box Outlook and Exchange can do some very clever things, but unless you put a bit of thought into what you are trying to achieve, then no amount of ticked boxes or level of granular permission is guaranteed to work for you.
In the Beginning
Everything in a Microsoft world depends on principle based security.
A security principle is an Active Directory object with a security identifier or SiD.
Microsoft recognises three security principles, the user, the computer and the security enabled group. These are the only three Active Directory objects that have SiD’s, and these are the only objects that can be assigned security tokens.
A security token is used to allow or restrict access to resources based on Access Control Entries (ACE’s) stored in Access Control Lists (ACL’s)
Way back in 1993 Microsoft decided that a username and password uniquely identified an individual, and today with Active Directory a mailbox is simply an extension of a user object. It’s owned by the uniquely identified individual.
I digress a little bit here but it becomes relevant in the whole delegate access mailbox conversation because many requests for delegate access evolve from an attempt to implement role based security. For example, on Monday the helpdesk support function is performed by Joe, on Tuesday it’s performed by Fred, on Wednesdays it’s either Joe or Fred, and John actually does the role all week.
So we have multiple people, multiple unique usernames, but with a desired public perception of a function, not an individual. There are countless examples, admissions, enquiries, complaints etc.
Now this can be achieved in some cases by creating a “Helpdesk” username and a “Helpdesk” mailbox and simply having the helpdesk staff log into this mailbox, but more often than not people turn to shared folder access or delegated permissions as a solution.
Anything we can do with Exchange and Outlook to solve this problem or address this need is a principle based security approach to a role based security requirement, and as such it usually requires a little thought from the user in question as to exactly what they are trying to achieve, and what the best way to do that would be.
So, history lesson out of the way, what options do we have.
Granting Access to Shared Folders
Each mailbox contains a set of folders. Out of the box these include Calendar, Contacts, Drafts, Inbox, Junk Mail, Notes, Sent Items, Tasks and a few others.
As the owner of the folder, you have the rights to share any of your folders, exactly the same way you would folders on your local hard disk.
You simply right click, Properties and use the Permissions tab to assign granular permissions to the folder.
There are several levels of pre-defined permissions you can set most of which are pretty self explanatory, but just note for the minute the following, Reviewer, Author, Editor. I’ll come back to these in a second.
What you are doing here is modified the ACE’s on your folder ACL’s to grant or deny users granular access to your mailbox folders based on their Security Identifiers.
Gaining Access to Shared Folders
There are two ways to gain access to folders once permissions have been granted to you. You either use File, Open, Other User’s Folder…
if you want temporary access to one of the six default folders which are Calendar, Contacts, Inbox, Journal, Notes, or Tasks.
Or you Open these additional mailboxes: from the Advanced tab, of the mailbox properties. You get to this by right clicking on the mailbox root and selecting Properties for “Mailbox – Declan Conroy”.
In order to be able to open an additional mailbox, you must have a minimum of reviewer access to the top level mailbox folder itself. This differs from File, Open, Other User’s Folder… where you are opening a folder within the mailbox to which you have been granted specific access.
Exchange Resources (rooms or equipment) also fall into the mix here, you may have access to the Free Busy details in the calendar of the resource, but if you want to open it as a mailbox, you need a minimum of reviewer to the top level also.
What have we got so far.
For varying levels of granular permission, ranging from Reviewer thru to Owner, we can grant access to any folder within any mailbox, and have other users either temporarily open these individual folders (File, Open, Other User’s Folder…) or automatically open all of the shared folders to which they have permissions each time they open outlook using Open these additional mailboxes:
The Auto-mapping feature of Full-Access in Exchange 2010 SP1 onwards, 2013 and Exchange Online can automatically add mailboxes to your profile, although you can turn that off.
Delegate Access, Send-on-Behalf-of
So what is delegate access all about then?
Delegate access goes a step further than shared access, in that it grants send on behalf rights to the mailbox delegate. To be more accurate, it populates the publicDelegates attribute of the AD user object for the user who is delegating access to his/her mailbox.
The publicDeleagetes attribute values can been seen in the Attribute Editor tab in AD users and computers. A blog for another day, but don’t modify the user attributes directly, bad things can happen.
This attribute is a multi-valued attribute that will contain the DN of every object you have assigned delegate access to.
Interesting point to note, the following back linked attribute called publicDelegatesBL is a list of the DN’s of all the user objects who have delegated access to you.
Note also that the delegate access wizard doesn’t do any kind or enumeration or checking of permissions.
You can get into trouble very fast. In a situation where you remove delegate access using the wizard, users can still File, Open, Other User’s Folder… or even Open these additional mailboxes: because the wizard does not undo any granular permissions that you may have set manually!
You also will come across a situation where you reapply permissions via the wizard they will overwrite any you had manually specified at the folder level
You can use the following AD search to list all of the users with a domain who have delegated mailbox access and the mailboxes they have delegated access to: (The line has been word wrapped for readability)
LDIFDE.EXE -F DELEGATES.TXT -D “DC=DOMAIN,DC=COM” -L NAME,PUBLICDELEGATES,PUBLICDELEGATESBL -R “(|(PUBLICDELEGATES=*)(PUBLICDELEGATESBL))”
OK, so back to Outlook.
There are a couple of things here.
There are only six folders listed by the delegate access wizard when you click Tools, Options …, Delegates, Add. These are the same six folders you can gain access to using File, Open, Other User’s Folder…
There are only three levels of permissions you can grant directly via the delegate access wizard, Reviewer, Author and Editor.
You will find many references to shared folder permissions on the Internet and Microsoft documentation that list and describe the various granular permissions that can be assigned, and most of these descriptions are accompanied by the rather vague references that this permission (Does not apply to delegates.)
All this simply means is that you can only assign one of the three levels of permissions above via the delegate access wizard.
It doesn’t quite hang together
I have to be honest I don’t think the various options hang together well. Here’s why.
When you use the delegate access wizard, you are limited to six folders, and three permissions. These folders don’t include the top level mailbox, and the permissions don’t include Owner.
So your mailbox delegate can gain temporary access to your inbox, and can send mail on your behalf.
Interesting point to note here, if you don’t grant any access to any of the folders via the delegate access wizard ie. set them all to None, the publicDelegates attribute is still populated, but the user you have delegated to has no access to your inbox.
Even though they are authorised to send mail on your behalf they have no access to your inbox to actually do it.
That’s just odd!
The answer really is on the tab, if you use the delegate access wizard, you are granting people the authority to send on your behalf!
What delegate access doesn’t do is allow your delegates to Open these additional mailboxes: as the top level mailbox folder permissions aren’t modified by the wizard.
Now in most cases I’ve come across, if you are granting send on behalf rights to somebody they will usually want to spend a lot of time in your Inbox, and as such temporary access using File, Open, Other User’s Folder… just isn’t the best way to work.
So to craft a working solution you have to assign delegate access for everybody that you may want to send mail on your behalf in order to populate the publicDelegates attribute, and then manually, granularly set folder permissions at the top level mailbox folder, and also Sent Items and any other folder that is not one of the default six, so that they can automatically and permanently access your mailbox thru Open these additional mailboxes:
Worth pointing out, if you set the top level mailbox folder permissions to Owner for one of your delegates he or she can then Open these additional mailboxes: and once logged in to his/her own mailbox have the option to right click on your mailbox in his/her profile folder list, access the permissions tab and modify folder permissions for other people.
Finally, unless you grant a minimum of Reviewer access at the top level “Mailbox -” to your delegates there is no point in granting any shared access permissions to any mailbox folder other than the default six.
Without top level Reviewer permissions the only access to the shared or delegated folders is via File, Open, Other User’s Folder… and File, Open, Other User’s Folder… is hardcoded to only list these six folders.
A final can of worms.
If you migrate to Exchange Online from Exchange on prem using a third party tool, ie not using the Native Exchange Hybrid approach, and you have DirSync set up the mailbox owners in your local AD will still have the publicDelegates and publicDelegatesBL attribute values set post migration, because these are set in AD, not in Exchange, but the new mailboxes in Office 365 may not have the permissions that were previously assigned to these delegates.