Exchange Web Services (EWS), GetItem() call produces AccessDenied error


  • Hello.  I am very new to Exchange web services development, so any help would be appreciated.  I am looking at an application (via an aspx page) that is attempting to use the GetItem method, but every time this method is called, it receives and Access Denied error, unless a set of credentials is forced in, like this:


    binding.Credentials = new NetworkCredential("userid", "password", "domain");


    However, I have no way of getting the password, unless there is Basic authentication on the site, and it would be in the Request["AUTH_PASSWORD"] object, but in the real world I have no way of knowing the authentication model that each customer will use.  So what I'm wondering is when I create my Exchange Services Binding object, is there a way to set the credentials using the CredentialCache?  Similar to:


    binding.UseDefaultCredentials = true;

    binding.Credentials = CredentialCache.DefaultCredentials;




    binding.Credentials = CredentialCache.DefaultNetworkCredentials;


    When I attempt to use either of these methods, I get the AccessDenied error from the GetItem() call.  But before that call, there is a call to ConvertId which doesn't seem to cause any problems.


    In addition to any expertise anyone might have on setting the credentials, can anyone point me towards sample code that demonstrates Exchange Web Services usage via an ASPX page?


    thanks for any help you can provide.

    Friday, August 15, 2008 9:14 PM

All replies

  • What account is your web page running as? Likely the problem you are having is what we call the "two hop" problem.  For auth schemes such as NTLM, Kerberos, etc... the token that you receive will not have network creds, so if you impersonate the caller and try to make a call off box, it will likely go out as anonymous resulting in an Access Denied.  Given that you don't want to store passwords for the callers or require them to send you a password, your best bet is to do one of the following:


    1.  Give the account that is running your aspx page "Exchange Impersonation" rights and then send the request using default creds, but add the ExchangeImpersonation header to your request to indicate that you are "acting as" another user.  There are lots of docs/MSDN articles/posts/etc... on this.

    2.  Give the account that is running your aspx page delegate access rights to the mailboxes you want it to access.  This is a little more dangerous as it will also give the account such rights to use apps like Outlook whereas EI is only usable via EWS.



    Sunday, August 17, 2008 11:20 AM
  • David,


    Thank you for your response.  To answer your question, I'm not quite sure what account the page would be running is the flow:  User opens OWA, and the standard OWA login screen prompts the user for credentials.  They supply them, and are now viewing their Inbox let's say.  When double-clicking an item to open, if the item's type matches the one we've set up for OWA customization, OWA recognizes this via the registry.xml file, and sends the user to the form specified for the "Open" action (hopefully you're familiar with OWA customizations and this makes sense to you).  So the aspx page in question was opened in a sense by OWA via some Server.transfer method, even though our original user requested it.  This page would be contained in a Virtual Directory that I've tried with Anonymous Access allowed via Directory Security tab in IIS, and several other options as well.  So, your "two-hop" description makes sense, and hopefully what I've described can help you confirm that.  If that is indeed what you meant, then can you refer me to an article or two that you mentioned in order to accomplish "Exchange Impersonation"?  I'm not clear as to where this would be implemented...via IIS on my custom site, via IIS on OWA site, my aspx page, etc.?  Or if you could give me a few keywords to search that would be great too.  Thanks again.


    Monday, August 18, 2008 2:49 AM
  • Ah - so you are using the OWA forms registry.  If your page is outside of the OWA vdir/app pool, the you will have the 2 hop problem and further requests will come across as anonymous since the token in your request will not have network creds.


    You configure Exchange Impersonation using the Exchange Management Shell (power shell).  Here are some articles that talk about it:




    Also, in the Inside Microsoft Exchange Server 2007 Web Services book, we have an entire chapter dedicated to Exchange Impersonation (chapter 19).


    Tuesday, August 19, 2008 3:01 PM
  • I appreciate the references, but I'm afraid that requiring all customers to modify each account to perform Exchange Impersonation is not a viable solution.


    How should things change if the registry.xml entry points to an aspx page which is not a URL pointing to a virtual directory, but simply a page that resides within the same folder (i.e., one that resides under ..\Owa\forms\ and contains the registry.xml file)?  Because we are seeing the same behavior when this is the case.  Wouldn't everything then still be contained within the OWA vdir/app pool?  And if so, wouldn't I expect to have credentials in the CredentialCache objects?


    It appears that OWA by default is installed with Basic authentication, which would mean that the aspx page would in fact have access to the AUTH_PASSWORD parameter of the Request object, but if an Exchange admin removes basic authentication via either the Exchange Management Console or IIS, then I'm back to square one, and anything I've tried with regard to the .NET CredentialCache produces nothing in this scenario, and therefore I have nothing to provide the Exchange Web Services binding object for credentials.


    Any other thoughts?  Thanks again.



    Tuesday, August 19, 2008 9:19 PM