MM&M UG UK

We have had so many generic requests for what has come to be known simply as “Delegate Access” that I’ve put a guide together for the project, and hopefully it will be of some use to other people so I thought I’d share it.

Let me start by taking a step backwards.  

Outlook 2003 and Exchange 2003 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.

The Internet is full of custom guides on how to set up delegate access to mailboxes, and various ways to open other user’s folders, or open additional mailboxes.

What we have struggled to find for this project is less technical and more business oriented guidance on when each of the various options is best used, and what the main differences between them are.

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.

I haven’t mentioned resource mailboxes where the mailbox calendar is used to establish free/busy information for meeting rooms or equipment. These are a bit more mainstream once you get your head around the fact that you now need a user object called “Meeting Room 1” that never actually log’s in, but that does have a shared calendar.

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, and obviously any folders that have been created by the mailbox owner or any plug-in or add-on components such as AV, Archive, or Anti-Spam software.

Each one of these folders is an object, owned by the mailbox owner. You can verify this by opening DSA.MSC, and selecting a user object with a mailbox. Right click and select Properties, go to the Exchange Advanced tab and select Mailbox Rights...

The mailbox rights include the SELF object, which is allowed full mailbox access

As the owner of the mailbox, 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 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 either get to this by right clicking on the mailbox root and selecting Properties for “Mailbox – Declan Conroy“, or you go thru the more long winded Tools, Account Settings..., Change..., More Settings..., Advanced

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.

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:

Delegate Access, Send-on-Behalf-of

So what is delegate access all about then?

Well, like it says on the Delegate Access tab from the Tools, Options... menu 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.

You can verify this by looking up your user object in ADSIEDIT.MSC under the domain partition and right clicking it to get Properties. Tick the box to Show only attributes that have values and scroll down till you see publicDelegates.

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 attribute called publicDelegatesBL is a list of the DN’s of all the user objects who have delegated access to you.

You can use the following AD search to list all of the users in 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))"

The publicDeleagetes attribute values can been seen in AD users and computers. Open DSA.MSC and find your user object. Right click and select Properties. Clicking on the Exchange General tab and open Delivery Options... Your delegates are listed under Grant this permission to: in the send of behalf box

A blog for another day, but don’t modify the user attribute properties using ADSIEDIT.MSC, bad things will happen....

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 grant no access to any of the folders via the delegate access wizard (set them all to None) the publicDelegates attribute is still populated, but the user you have delegated to has no access to your inbox, so 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.

Making some kind of sense of the options

To make some sense of the various options available in shared folder access, delegate mailbox access, open other user’s folder, open additional mailboxes, and send-on-behalf-of, here’s what we came up with.

·         Resource mailboxes. If you want to use a resource mailbox, either for a meeting room, or a piece of equipment you simply need to create the resource mailbox and change the default permissions on the Calendar to something like Author, which allows people to create and read appointments, and delete their own appointments.

      Anybody can now use File, Open, Other User’s Folder... or use a Free/Busy search to book an appointment in the diary for the resource mailbox. (There are two other options for shared calendars in Exchange 2003, which are Public Folders and Moderated Public Folders, but if you want to use automatic free/busy searches you need to use the resource mailbox)

You may want to restrict the Author permissions based on security group membership, and the options here are limitless, in terms of granting certain groups Author and other groups Reviewer etc

·         Shared or departmental calendars. If you want to more easily use a resource mailbox as a departmental or shared calendar you then need to add Reviewer permission for the department security group to the top level “Mailbox -” folder so that department staff can Open these additional mailboxes: and have more permanent access to the calendar. This also applies to any other folder, but I can’t think of any folder apart from Calendar that really requires a mailbox of its own.

·         Delegated mailboxes. There isn’t really any call for shared access to a mailbox unless you need to send mail on behalf of somebody. I’m sure there are situations out there where this is being done, but from a business logic or work flow perspective if you can’t respond to the mail that’s arriving what use is reading it?

In this situation you have to jump thru all the hoops. Delegate the access to the default six, then manually modify the permissions on any remaining folders including the top level “Mailbox -” so that your delegates can use the Open these additional mailboxes:

Finally

It’s worth pointing out that the delegate access wizard doesn’t do any kind of 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 have set manually on other folders.

You also will come across a situation where you reapply permissions via the wizard and they will overwrite any you had manually specified at the folder level.

There is a lot you can do, but most of the complexity is in deciding what solution fits what purpose and then maintaining some control over it.

I haven’t touched on Send-as, I’ve restricted the options to those at the users fingertips and in my case Send-as violates an e-mail policy that mandates all outbound e-mail must be attributable to the sender, and I’m sure there are dozens of questions about specifics that I haven’t covered but hopefully my many hours of experimentation and Googling will save somebody else some time.

 Declan