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
