none
Exchange web service accessing private items RRS feed

  • Question

  • I am using Exchange Web Services at the office in order to get Calendar appointments for all colleagues. After I created a service account to use EWS and configured the Exchange server for impersonation... I got unexpected results. I noticed that even thou some users had set some Calendar items to private the EWS still has access to them.

    I can assume that since EWS is impersonating that user it has the same permissions when executing. Basically I want to find out how to prevent this from happening.

    On the other hand after some research, I found the following article: http://stackoverflow.com/questions/4861350/exchange-web-services-can-delegates-access-private-contacts/6295486#6295486

    The writer explains that he was trying to understand how EWS handles Delegates when accessing private items. Basically he develop a routine in order to view Delegate access for different users. It work for him against Exchange 2007 but not against Exchange 2010. He noticed that with Exchange 2010 the results always brought private items.

    Is this an Exchange 2010 bug? Is something wrong with the writer's routine? Is there a work around?

    Thanks,

    ASP Force

    Thursday, June 9, 2011 4:45 PM

All replies

  • With impersonating the behaviour your reporting is to be expected because when impersonating you are accessing the mailbox as the user which is what impersonation means and there is no way to change this. A very easy fix is because you control the code that is accessing the mailbox you can very easily check yourself within your code whether a item is private and don't show this to the user this then allows you to go on using impersonation which has a number of advantages over delegation.

    EWS implements security the same as Outlook if you really want to test security logic you should first setup and test it through outllook as there are a number of misconfigurations that could cause the behaviour being reported in the SO thread it looks like bad test logic to me. To really test this you should enable auditing to let you see what security context is being used to access the mailbox is the SO case i would say he's still accessing under the context of the user (eg probably been granted full access to the mailbox).

    Cheers
    Glen

    Monday, June 13, 2011 3:39 AM