My organization has an in-house user authentication system shared between a very large number of internal systems.

One of these systems needs to retrieve information from the logged in user's exchange account. Logged in here means logged into the system - the client is not necessarily a windows machine on our domain. However, the mapping to a valid windows user is known.

I'm trying to find a secure way to handle this without requiring the user to authenticate manually with both sets of credentials. The two suggestions are:

  • Store the users' plain-text exchange password in either the client or server of the service used to access exchange. Obviously if that service were to be compromised, this would result in the passwords being compromised.
  • Use an account allowed to impersonate all users. If this were compromised, then all exchange data would be compromised.

Neither is exactly appealing. Is there any way to pass our existing token to exchange and have an exchange plugin or service call to verify it?


1 Answer 1


I found a Microsoft blog (link) that addresses the problem.

Code needs to obtain credentials at runtime based-upon its runtime security context AND that context needs to be valid with the server/app its code is going against. This is what is used when default credentials with EWS are used – ie windows authentication. However, UseDefaultCredentials won’t work with Exchange 365.

A link to the proposed property

This would allow your application to connect as the current user and it would make sure you wouldn't have to modify the file every time the user changes the password, however, there are some limitations:

You cannot use the default credentials of the logged on user if the user’s mailbox is hosted in Exchange Online or Exchange Online as part of Office 365. Instead, use the Credentials property to set the user’s credentials. The user’s credentials must be in user principal name (UPN) form for Exchange Online.

As for other authentication mechanisms, microsoft describes these:

  • OAuth 2.0 (Exchange Online only)
  • NTLM (Exchange on-premises only)
  • Basic (no longer recommended)

Here's a link with pro's and cons about the 3 methods above.

I honestly think having to store passwords when you are already authenticated with the Domain Controller in a way is a design flaw of the application.

  • 1
    Thanks! Unfortunately the client they are working from isn't necessarily a windows box on the domain - I've updated the question to clarify. The system they are logged into can map them to a valid exchange user but ideally wouldn't know their password.
    – Hector
    Apr 11, 2018 at 7:29

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .