1
votes

In our organization we are trying to use EWS Managed API to access mailboxes from a custom UI client on Exchange 2010. We have a .NET 4.0 WCF service running on IIS 7.5 calling the EWS methods on behalf of the UI client. Client and WCF service communicate over https, so does the WCF service and EWS. We now want to create service accounts (basically AD accounts with impersonation rights on certain email inboxes) and run the WCF service under these service accounts. However, when I run the WCF service under a particular AD user in IIS (Anonymous authentication enabled with Anonymous user identity set to the specific AD user), EWS throws a 401 Unauthorized exception. Upon examining the ExchangeService object, the Credentials object is null. If I hardcode the credentials, the service can access EWS. Below is the code that I am using to create the ExchangeService object.

var service = new ExchangeService(ExchangeVersion.Exchange2010)
 {
     Url = new Uri(ConfigurationManager.AppSettings["EWSUrl"]),
     // If I uncomment the below line, the service can access EWS. However, I want the user under which the service is running to access EWS.
     //Credentials = new NetworkCredential("ImpersonatingUser", "secretPwd", "TESTDOMAIN"),
     ImpersonatedUserId = new ImpersonatedUserId { Id = emailAddress, IdType = ConnectingIdType.SmtpAddress },
 };

I read somewhere that the System.ServiceModel.ServiceSecurityContext.Current.WindowsIdentity object will have the current user under which the service is running. However, the System.ServiceModel.ServiceSecurityContext.Current context is null in my case.

How do I get the service account's credentials (without hardcoding it in the code) and pass it to EWS? Please let me know if you need more details.

Edit: In IIS 7.5, I have created a separate app pool running under the impersonating AD user's identity, and configured my WCF service to run in this app pool. Still can't get the service credentials.

Thanks in advance.

1

1 Answers

1
votes

Unless your WebService runs on the Exchange box, you'll need to configure Kerberos. NTLM does not allow credential delegation.

Another option is to switch to Basic authentication secured with SSL. But this means to loose single sign on in your client application.