Setting Folder Permissions in Outlook – what really happens?


Someone asked the following, so I thought I would try and address the issue as I think it is one that is commonly misunderstood:


 


Could you enlighten us on what happens when an Outlook user uses the permissions tab on a folder to grant access to other users?  It apparently isn’t the same as when they use the Delegates.  I found a script to dump the delegates, but I have users who are out of control assigning folder permissions!


 


Setting Permissions on Folders


 


So when an Outlook User uses the Permissions tab to give another user access to their folder, they are doing just that, giving another user the specified amount of access to the specified folder (One could compare this action with modifying the NTFS permissions on an OS folder).  They are not giving the other user the ability to log into their mailbox and then only access the specified folders.  They are allowing the other users to use the “Open > Other User’s Folder…” functionality within Outlook and have some level of access to their folder(s).


 


Here is an example:


 


1.       I created a user named “User1”, created a mailbox for that user on an Exchange 2003 SP2 server, and then logged into that mailbox using Outlook 2003.


2.       I created a second user named “User2” and also gave that user a mailbox on the Exchange 2003 SP2 server.


3.       From Outlook 2003 logged into User1’s mailbox, I Right-Click on the Inbox folder and select Properties.  I then click on the Permissions tab.  The first thing that you should notice is that both “Default” and “Anonymous” have a Permission Level of None.


4.       I add User2 and give that user account the “Author” Permission Level.


5.       Now I log out of User1’s mailbox and now log into User2’s mailbox using Outlook 2003.  Again, I cannot log into User1’s mailbox using User2’s credentials.  User1 has not granted User2 any mailbox level permissions, just folder permissions.


6.       Once I am logged into User2’s mailbox, I go to the menu bar and click FILE > OPEN > OTHER USER’S FOLDER.  The first thing you should notice is that Outlook does not arbitrarily let you just access any folder.  You can only access the Calendar, Contacts, Inbox, Journal, Notes, and Tasks folders.  So I select the Inbox folder and click OK.  I can now see the contents of User1’s Inbox and perform the actions applicable to the permissions that User2 has been given.


 




Figure 1


 


Since Outlook only allows you to open the 6 enumerated folders, there is really no need for Users to be modifying the folder permissions to grant other users access to the “Sent Items”, “Deleted Items”, etc. folders because the other users probably don’t have a client that will allow them to even access those other folders.  However, I can see how this might lead to Helpdesk calls because the users are expecting that since they can apply Folder Permissions, then there is a way that the other Users’ can access their folders, and this just is not the case with Outlook.


 


Setting Delegate Access in Outlook


 


In Outlook under Tools > Options, there is a tab labeled “Delegates”.  Here is the description that Outlook gives:


 


Delegates can send items on your behalf. To grant permission to others to access your folders without also giving them send-on-behalf-of privileges, go to the Properties dialog box for each folder and change the options on the Permissions tab.


 


If you read this carefully, you will see that the “Delegates” tab is really doing two things:


 


1.       Modifying the “Send-on-Behalf-of” privileges for the user account which is stored in the “publicDelegates” property on user object in the Active Directory.  This privilege can also be modified by an Administrator by going into “Active Directory Users and Computers” (ADUC), viewing the properties of the appropriate User Account, clicking on the “Exchange General” tab, and then clicking on the “Delivery Options” button.  A new dialog box titled “Delivery options” will appear and within this new dialog box is an area labeled “Send on Behalf”.


2.       Modifying folder permissions so the delegated user account can have the appropriate access to the mailbox folders.  These folder permissions are stored on the folders within the Exchange Store.


 


So let’s walk through an example:


 


1.       I created a user named “User1”, created a mailbox for that user on an Exchange 2003 SP2 server, and then logged into that mailbox using Outlook 2003.


2.       I created a second user named “User2” and also gave that user a mailbox on the Exchange 2003 SP2 server.


3.       From Outlook 2003 logged into User1’s mailbox, I clicked on “Tools” in the menu bar and then selected “Options”.  From the “Options” dialog box, I then clicked on the Delegates Tab.   Of course this should be empty by default.


4.       Since I would like to add User2 as a delegate, I click the “Add…” button.  This pops up a new dialog box that wants me to select a user(s) to give Delegate Access to.  I select User2 and click OK.


5.       Now another new dialog box appears titled “Delegate Permissions: User2”.  One thing you should notice is that nowhere on this dialog box does it say anything about Send-on-Behalf-of.  What it does allow you to do, however, is to decide what level of permission you want to give the delegate to the 6 defined folders: Calendar, Tasks, Inbox, Contacts, Notes, and Journal.  Notice that it does not allow you set give the Delegate permission to any folder you want, nor does it allow you to give any level of permission.  Instead, you get to choose from None, Reviewer, Author, and Editor.


 




Figure 2


 


6.       I see that the default set of permissions are sufficient for what I want User2 to have on User1’s folders, so I click OK on this dialog box and then click OK on the “Options” dialog box.


7.       So what has happened is that User2 now has “Send-on-Behalf-of” privilege for User1 and User2 also has Editor permission on User1’s Calendar folder and Editor permission on User1’s Tasks folder.  You can verify the “Send-on-Behalf-of” privilege by opening up User1’s AD Object via Active Directory Users and Computers, click on the “Exchange General” Tab, and then click on the “Delivery Options” button.  You will see that User2 is listed as having “Send on Behalf” permission for User1.  To verify the folder permission, I just opened the properties for the “Calendar” and “Tasks” folders and view the Permissions tab.


NOTE: Even though User2 has not been granted any permission to the other four folders, Outlook still adds User2 to the folder permissions with a Permission Level of “None”.


8.       In reference to the “Delegate receives copies of meeting-related messages sent to me” check box, Outlook creates a server-side rule that forwards the appropriate messages to the delegate.


9.       In reference to the “Delegate can see my private items”, this setting is stored locally in the Manager’s mailbox.  Since the enforcement of “Private Items” is done on the client side, the Delegate’s Outlook checks for this setting to see if the enforcement of “Private Items” is to be enabled or disabled.


 


Modifying Folder Permissions for Delegates


 


OK, so now what happens if the user modifies the permissions of the Calendar or Tasks folder for User2?  Will that mess up their Delegate settings?  The answer, of course, is Yes and No.  Directly modifying the folder permissions is not going to change the Send-on-Behalf-of permissions that were granted for User2.  However, it will change what User2 is allowed to do in the Calendar folder.  If I now view the folder permissions for User2 on the “Calendar” folder, I see that the “Permission Level” given by Delegation is “Editor”.  However, I decide that I want User2 to be able to create subfolders under User1’s Calendar folder.  So I check the box next to “Create subfolders” which changes User2’s “Permission Level” to “Publishing Editor”.  If I know go back to the “Delegates”  tab and view the Permissions for User2, I see that User2 now has “Custom” permission on the Calendar folder.  This is to be expected since the “Publishing Editor” Permission Level is not enumerated in the drop down menus.


 




Figure 3


 


So it is apparent that when Outlook opens the Permissions for an existing Delegate, it goes to each of the folders and sees what permissions that Delegate has been given.  Therefore, if I now modify the Inbox folder to give User2 “Contributor” permission, modify the Contacts folder to give User2 “Review” permission, and modify the Journal folder to give User2 “Nonediting Author” permission; I will see the following as the Permissions for the Delegate User2.  You can see that Outlook has enumerated the permissions on all the folders and displayed the appropriate Permission Level in the drop down box.


 




Figure 4


 


So can you guess what happens if you remove a Delegated User?  If you said, “Remove the ‘Send-on-Behalf-of’ privilege and remove the folder permissions for the removed Delegated User from the Calendar, Tasks, Inbox, Contacts, Notes, and Journal folders,” then you are correct.   Removing a Delegated user will remove the Delegated User’s permissions for the six predefined folders, no matter how the folder permissions were granted.


 


Here is another trivia question, can you guess what happens if you have already given User2 the necessary folder permissions on the Inbox folder and then decide later to specify User2 as a Delegated User?  If you said, “The previously defined permissions on the Inbox folder for User2 will probably be changed,” then you are correct.  The unfortunate reality is that when you add a new Delegated User, Outlook does not iterate through the six folders to see if that account already has permissions.  Instead, it just assumes that it doesn’t and gives you the default dialog box (see Figure #2 above).  By default, the added Delegated User has a Permission Level of “None” on the Inbox.  If this is not changed to be what User2 has currently on the Inbox folder, then the folder permissions will change.


 


In Closing


 


Using the Delegate functionality of Outlook is not something that all users will need to do.  However, if users are adding Delegates, then they are adding an entry to each of the six folders’ permissions.  If users are out of control specifying Delegates, then they are probably out of control assigning folder permissions, and don’t even know it.


 


Chris Ahlers


Comments (33)
  1. Kn00p says:

    There is a way users can access other folders then the default ones.

    It works like this. Grant a user list and read permisions on the top level (Mailbox – Name). Then grant permissions to the folders you wish (Like Sent Items or some other custom folder).

    Now the other user can add the mailbox in the Advanced setting of the e-mail profile. In the folder view the mailbox will show up.

  2. Indy says:

    And all sorts of fun things happen when you remove a delegated user from AD.  NDR’s on appointments sent to the Manager’s mailbox.  Fun stuff.

  3. Marc C says:

    Users have a tendency to do anything they can to make sure a single person has permissions to their mailbox.  We need to audit the permissions on all mailboxes (about 40,000) we are particularly interested to find Inboxes or Calendars that have default or anonymous permissions set.  I did this back in the 5.5 days using MBinfo.exe, but it won’t run against Exchange 2003.  Any advice? I would really like to be able to script it but I can’t find a method.

  4. Exchange says:

    Marc,

    There are two things that you can do to get this information:

    1. Use MBINFO. I know you mention that "it does not work" but – we have used MBINFO against an Exchange 2003 server in Support, this should work. You do need to make sure that you have permissions, like when you are running Exmerge, however it should work.

    2. Use the PFDAVAMIN tool. When connecting, use the "Connect to mailboxes" option. If you have permissions, connect to "all mailboxes" and then go to Tools > Export Permissions. (logging will need to be turned on under Tools > Options). You can grab PFDAVADMIN
    here:

    http://www.microsoft.com/downloads/details.aspx?FamilyId=635BE792-D8AD-49E3-ADA4-E2422C0AB424&displaylang=en

  5. James Fields says:

    So what is the difference betwenn adding "Send-on-Behalf-of" privileges for the user account which is stored in the "publicDelegates" property on user object in the Active Directory and granted "Send As" permission on "Security" Tab in AD?

  6. Anonymous says:

    I ran across a very interesting blog entry from the Microsoft Exchange group explaining exactly what…

  7. Steve says:

    So how does this relate to Outlook’s Share My Calendar feature?

    I have a client that wants calendars shared but with different access for different users.  I have set all the permissions the way that seems to be correct (default and anonymous are None, specific users have Publishing Editor, others have read-only).  I also set specific permissions on the calendar folder. Despite those permissions every user has full access to the calendar.  Even worse is that they can all modify the permissions on the calendar.

  8. joe says:

    James: Send on behalf permission allows you to send an email that says it is from you and sent on behalf of the mailbox owner. Send As allows you to send a message that says it is from the mailbox owner.

  9. Chris Ahlers says:

    [Response to James Fields]

    In addition to Joe’s response, another difference is who can grant which permission.

    Both the mailbox owner and Administrator can grant another acocunt "Send on Behalf" permission to another account/mailbox.

    However, only the Administrator can grant the "Send As" permission.

  10. Chris Ahlers says:

    [Response to Steve]

    Steve-

    Have the users in question been given Full Mailbox Access?  If so, then the permissions are meaningless because once you log into a mailbox with an account that has Full Mailbox Access, the permissions are not checked.  One thing you might want to check is to make sure that these users cannot access any other folder in the mailbox other then the Calendar folder.  If they can, then something is up.

    Another thing that could cause a problem is if the Security Descriptor on the Calendar folder is no longer MAPI Canonical.  You can use the PFDAVADMIN tool mentioned in a previous comment to check to make sure that the Security Descritor is properly ordered.

    –Chris

  11. Anonymous says:

    Since there was no "weekend reading" last week, today’s list is abnormally long. If you don’t have the…

  12. jhanjon says:

    I have a situation whereby a user has assistants operate their outlook to respond to general emails, however, that user also needs to receive private messages. Is there a way whereby a portion of the message can be password locked persistently, meaning each time it is opened?

  13. Kees-Jan says:

    Ok, how about this one:

    we have a number of groups of users, for example: Service Desk or Service Management, who are using a "resource mailbox". When we create the mailbox we add modify permissons(via AD) to the requestor (for the system managers this is what we call the "owner" of the mailbox). Then the (so called) owner can modify permissions via Outlook to grant rights to other users. All that users add the mailbox via advanced settings to the Outlook view, so all of them see when new messages arrive in the mailbox. When they send messages, it’s going to be the "send on behalf of" way. But what if those users need to use the "send as" way? Do I (as Administrator) have to grant them "send as" permissions? And what if those users use their "send as" permissions to send mails as the CEO of the company? Or do I miss something here? Is something, someone, some… prohibiting them from doing this?

  14. James Fields says:

    So what is the difference betwenn adding "Send-on-Behalf-of" privileges for the user account which is stored in the "publicDelegates" property on user object in the Active Directory and granted "Send As" permission on "Security" Tab in AD?

  15. Steve says:

    So how does this relate to Outlook’s Share My Calendar feature?

    I have a client that wants calendars shared but with different access for different users.  I have set all the permissions the way that seems to be correct (default and anonymous are None, specific users have Publishing Editor, others have read-only).  I also set specific permissions on the calendar folder. Despite those permissions every user has full access to the calendar.  Even worse is that they can all modify the permissions on the calendar.

  16. joe says:

    James: Send on behalf permission allows you to send an email that says it is from you and sent on behalf of the mailbox owner. Send As allows you to send a message that says it is from the mailbox owner.

  17. Chris Ahlers says:

    [Response to James Fields]

    In addition to Joe’s response, another difference is who can grant which permission.

    Both the mailbox owner and Administrator can grant another acocunt "Send on Behalf" permission to another account/mailbox.

    However, only the Administrator can grant the "Send As" permission.

  18. Chris Ahlers says:

    [Response to Steve]

    Steve-

    Have the users in question been given Full Mailbox Access?  If so, then the permissions are meaningless because once you log into a mailbox with an account that has Full Mailbox Access, the permissions are not checked.  One thing you might want to check is to make sure that these users cannot access any other folder in the mailbox other then the Calendar folder.  If they can, then something is up.

    Another thing that could cause a problem is if the Security Descriptor on the Calendar folder is no longer MAPI Canonical.  You can use the PFDAVADMIN tool mentioned in a previous comment to check to make sure that the Security Descritor is properly ordered.

    –Chris

  19. jhanjon says:

    I have a situation whereby a user has assistants operate their outlook to respond to general emails, however, that user also needs to receive private messages. Is there a way whereby a portion of the message can be password locked persistently, meaning each time it is opened?

  20. Kees-Jan says:

    Ok, how about this one:

    we have a number of groups of users, for example: Service Desk or Service Management, who are using a "resource mailbox". When we create the mailbox we add modify permissons(via AD) to the requestor (for the system managers this is what we call the "owner" of the mailbox). Then the (so called) owner can modify permissions via Outlook to grant rights to other users. All that users add the mailbox via advanced settings to the Outlook view, so all of them see when new messages arrive in the mailbox. When they send messages, it’s going to be the "send on behalf of" way. But what if those users need to use the "send as" way? Do I (as Administrator) have to grant them "send as" permissions? And what if those users use their "send as" permissions to send mails as the CEO of the company? Or do I miss something here? Is something, someone, some… prohibiting them from doing this?

  21. Chris Ahlers says:

    Kees-Jan —

    “Send As” permission is a permission granted to a user or group on a specific user account.  If I wanted to give UserA the ability to “Send As” UserB, an administrator would have to go to UserB’s user object and add an ACE for UserA that grants the “Send As” permission.  I cannot go to UserA’s account and give UserA “Send As” permission for UserB.

    Therefore, if you don’t want someone to “Send As” the CEO, then don’t give that user account the “Send As” permission on the CEO’s mailbox/account.

    If I did not completely address your scenario, please let me know, I may not have understood it correctly.

    Here are some additional blogs about “Send As”
    http://blogs.technet.com/exchange/archive/2005/01/07/348596.aspx
    http://blogs.technet.com/exchange/archive/2006/01/13/417440.aspx
    http://blogs.technet.com/exchange/archive/2006/04/28/426707.aspx

  22. Richard says:

    I’ve always thought it a bit strange that folder permissions and delegates were rolled into the one dialog box. Why would you automatically assume someone wants to read someone’s Calendar/Inbox if all you need them to do is send email on their behalf?

    Otherwise it’s a great guide, thanks :)

  23. Nick says:

    Hi Chris,

    We have about 150 Executives in our Organisation, many of which have authorised over 20 EAs delegation to their mailboxes, as well as numerous levels of permissions across all of their folders. It is an absolute mess and appears to be affecting Calendaring operation across the enterprise.

    Most of the Calendaring problems are to do with updates to both single and reocurring meetings. Both with those sending and those receiving.

    Frequency and the type of occurrance is not constant. Unfortunately, Calendaring for EAs is one of their primary functions and it is currently very, very painfull.

    What we are thinking of doing is:

    1.  Clean up delegations and permissions for all Executives and EAs.

    2.  Establish best practice training and re-enforcement of that training over time.

    3.  Where possible and appropriate, impliment constraints in Exchange/Outlook which mitigates the damage that users can do regarding assigning incorrect delegation and permission levels.

    The 1st point is something that some in our company would like to do at a server level for selected groups staggered over time, as we will need to be available to provide help and training to reconfigure delegation and access using best practice. However, others are concerned with the impact on users. Yet, the clean-slate approach sounds appealing. What do you think? How hard is it to remove delegations and access from Exchange?

    The 3rd point is a big if. The basic thought is to provide a certain level of predefined delegation and access for EAs to their Executive mailboxes based on AD group membership. This is a pretty basic model of being able to use the infrastructure to simplify a process that is performed on the client and which generally becomes very messy over time. If anyone can provide more advanced/sophisticated means of managing delegation and access using the infrastructure, I would be gratefull.

    We are using Exchange 2003 SP2 and the Outlook 2002 SP3 client. We will soon be going to Outlook 2003 SP(latest).

    As it stands, Exchange looks very unreliable for Calendaring. Is it reasonable to expect Exchange to be able to perform like a workhorse, without problem? Is it likely that we are not implimenting it properly? We serve about 2500 users.

  24. Chris Ahlers says:

    Jhanjon–

    One way to submit a Private Message would be to have the sender of the Private Message use S/MIME and encrypt the message.  Of course this works as long as the private key to decrypt the message is only available to the mailbox owner.

    –Chris

  25. Chris Ahlers says:

    Nick–

    In reference to your first point, I am always a proponent for starting from a clean slate as you never really know what you are working with you are trying to clean up someone else’s mess.  Using ESM, you can remove Delegates and those accounts with "Full Mailbox Access" and/or "Send As" permission.  However, this will not clean up the folder permissions as this is done by Outlook when Delegates are removed.

    If you are having some serious issues with Calendaring in Exchange, I would strongly suggest that you contact Microsoft PSS.  They are going to be your greatest resource for trying to sort out your Calendaring issues.

    If you would like to do some initial investigation into the "health" of your Exchange Organization, you should download and run Exchange Best Practices Analyzer (ExBPA): http://www.microsoft.com/technet/prodtechnol/exchange/downloads/2003/analyzers/default.mspx

    –Chris

  26. Buddha says:

    jhanjon,

    You can always set a rule that takes any message marked with sensitivity of "Private" or "Personal" to a folder that the Delegate dosent have rights to.  

  27. Buddha says:

    jhanjon

    I forgot to mention that in the delegates there is a check box for delgate can see private items.  Which IS NOT checked by default.  So they shouldnt be able to see anyting marked as private.  If permissions are set up with delegate rights.

  28. jhanjon says:

    Thanks Buddah and Chris – The advice helps, though I’ve thought about the encryption option which requires a security cert o be  installed per user. The private option may work, though one thing is not solved which is an assistant sitting in front of someone’s computer. I know with Word, it’s possible to put a password for a file, likewise for Zips or I believe PDFs so why not a particular email? Also, I noticed that Word files sent as attachments can be passworded, but not Word when used as an ‘editor’ for Outlook which makes it cumbersome to always attach a file.

  29. Akessler says:

    I have an interesting problem.  A user has shared thier tasks and given permissins to all her co-workers as publishing authors.  Whenever a new task is created, as soon as it is assigned to a user all ability to modify the task is lost, even for the task originator and the assigned user?  If the task is created but not assigned, it remians editable.  Does anyone have any idea what is happening here?  Thanks.

  30. Chris Ahlers says:

    Akessler–

    I believe that the behavior you are seeing is caused by Outlook.  When you assign a task to another user, the creator of the task losses the ability to modify the task and only the person the task was assigned to has the ability to modify the task.  I am not sure if this segregation is done with permissions or logic within Outlook.

    Here is a website I found about Assigning Tasks, but it does not have specific details.

    http://www.microsoft.com/singapore/sme/english/themes/organise-your-work/tip-Outlook-to-Assign-Tasks.mspx).

    –Chris

  31. Robbie says:

    Chris–

    In your answer to Nick you didn’t respond to his 3rd point about providing predefined delegation and permission at the AD level.  I would love to find some way to set some basic permisions on Outlook folders through GPO’s or AD.

    Thanks

  32. Chris Ahlers says:

    Robbie–

    Looking at the policy template files in the Office 2003 Resource Kit (http://office.microsoft.com/en-us/assistance/HA011513601033.aspx), I do not see
    anything that allows for permissions or delegates to be specified.

    I also looked into the capabilities of the Outlook Security Features (http://office.microsoft.com/en-us/assistance/HA011402911033.aspx) that ships with
    the Office 2003 Resource Kit and I didn’t see anything there as well.

    If all you wanted to do was modify folder permissions and not do anything with delegates, then you might be able to use the PFDAVAdmin tool (http://www.microsoft.com/downloads/details.aspx?FamilyId=635BE792-D8AD-49E3-ADA4-E2422C0AB424&displaylang=en)
    to set the appropriate permissions across multiple mailboxes.  Of course this is not automatically done like GPO is, but it might work for what is needed.

    I did try looking through some of the Outlook Newsgroups about this, but did not find anything more.  I don’t know of any Outlook specific Blogs, so I did not check there.

    –Chris

Comments are closed.