Glen's Exchange and Office 365 Dev Blog

The default Access Control Entry ACE in an Exchange Mailbox Folder DACL controls the rights that all authenticated users have to a particularity mailbox folder. Generally from a security perspective its something you don't want users to use as they may not understand when then set this ACE they are giving all people access to certain information. Eg Giving the default user reviewer rights to your Inbox means everyone in the Exchange org can now read mailbox in you Inbox which may not provide much privacy to your email. The following script will enumerate the permissions on every folder in a Mailbox and then produce a report of the folders where the default ACE isn't set to none. For most users the only folder that should show up in the report in the calendar folder. This script uses EWS but you could also use the Exchange Management Shell Get-MailboxFolderPermission cmdlet. To run this script you need to feed is with a CSV file that contains the SMTPAddress of the Mailboxes y...

In this series so far I've covered a lot of ground in EWS covering all the everyday operations so its time now to look at some of the more interesting and useful things you can do. Folder permissions are one thing that can both affect the code you run if you don't have the correct or enough rights in a folder your accessing and are also something you may want to manage using EWS. As before in this series I should point out that folder permission can be managed within the Exchange Management Shell using the Get and Set-MailboxFolderPermissions cmdlets and this can be a better solution for managing permissions. Exchange Folder permission in a netshell Exchange uses the normal discretionary access control list (DACL) with Access Control Entries (ACE's) to control access to its resources but there are a few special things to keep in mind. (There are also SACL's on public folders which you can't set from EWS). Special ACE's in the Folder DACL : There are two s...

While Exchange 2010 provides some really good cmdlets now for setting and changing folder permissions such as Set-MailboxFolderPermission http://technet.microsoft.com/en-us/library/ff522363.aspx . Using EWS to do this can still be useful in circumstances where the cmdlets can't be used or your having problems with localized folder names or you want to take advantage of EWS Impersonation to get around any issues your having with acquiring the correct rights to make the changes you might need. I'll look at the example of changing the default calendar permissions of the default ACL on the calendar as this is one of the harder things to do and there are a few points that can catch you out. First point is that when you modify permissions with EWS you basically grab the DACL from the server make your changes locally to the DACL and the post it back in a Update Folder operation. This means the logic you use on the client side needs to be up to dealing with this. The permissions ob...

Although there are a few better methods of doing this these days this is still handy to have especially if your running older versions of Exchange or you want to audit the raw ACE's that are being added by RBAC in Exchange 2010. Extended rights get used for a number of things EWS Impersonation is one, SendAs is another anyway here's an old C# sample I tripped over today. using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Collections; using System.Security.AccessControl; using System.DirectoryServices; namespace showImpRights { class Program { static void Main(string[] args) { DirectoryEntry rootdse = new DirectoryEntry("LDAP://RootDSE"); DirectoryEntry cfg = new DirectoryEntry("LDAP://" + rootdse.Properties["configurationnamingcontext"].Value); DirectoryEntry exRights = new DirectoryEntry("LDAP://cn=Extended-rig...

One of the new cmdlets in Exchange 2010 SP1 is the Set-MailboxFolderPermission cmdlet which was an addition to the other Exchange 2010 RTM folder permission cmdlets get-MailboxFolderPermission and add-MailboxFolderPermission. What this cmdlet gives you the ability to do is update the permissions of any folder within a mailbox as long as you are a member of the RBAC roles that allows you set them as specified in http://technet.microsoft.com/en-us/library/dd638132.aspx . Another thing this cmdlet does is give me the ability to revisit the default calendar folder permission GUI from this post (which used EWS and will still work okay on 2010) and rewrite this to be able to be used in Remote powershell so it will work against any 2010 SP1 server as well as anything else that supports these cmdlets such as live@edu or Office365. If you don't really want a GUI and would rather just export the permissions to CSV modify them and then reimport them that's easy to do for example to expo...

One important and potentially frustrating point for anybody who wants to set permissions on the calendar folder in a mailbox with any Exchange API that allows you to modify the folder DACL’s is that you also need add the same ACE your adding (or modifying) to the FreeBusy Data folder which is one the NON_IPM_Subtree Root folders in a mailbox explained in this KB . Exchange Web Services is no exception to this rule and accessing the NON_IPM_Subtree folders isn’t as straight forward as normal mailbox folders but here’s a method for accessing the freebusy folder and modifying the DACL. The highest level you can get to easily with EWS is the DistinguishedFolderIdNameType.msgfolderroot which in the basically the Root of the IPM_Subtree if you get the parentfolderID of this folder using a GetFolder Operation this will represent the Root of the NON_IPM_Subtree you can then use this ID in FindFolder operation to discover all the NON_IPM_Subtree folder in this case I’ve used a restriction to ...

I’ve had a couple of questions about this one based on a previous post that no-one really seemed to understand (oh and there was a bug in the code in post). Permissions aren't an easy subject and EWS doesn’t really give a straight forward method of manipulating ACL's but once you understand the basics its generally functional. It’s one thing you do need to dedicate some time too to get your logic right. I posted a calendar permissions helper for powershell a couple of months back I thought this would be a pretty simple task but when I started to test the library it ended up taking a numbers of hours to get the logic right. To summarize the things to watch out for when setting permission via EWS two important points are. The first is that the ACE’s for the EWS security roles enumerations and Outlook roles don’t match. There are only sutle differences but if you need these roles to marry up in Outlook you need to include your own routines to do this. When you want to modify...