Recently, I’ve had a few different customers coming to me asking about Outlook’s interaction with the Credential Manager. If you’ve not looked at the Credential Manager before, you can read a bit about it here. Interaction with the Credential Manager is fairly straightforward. There’s one function, CredWrite, which is used to store credentials, and another, CredRead, which is used to retrieve them. The customers who contacted me both had the same goal: use CredWrite to cache a set of credentials for Outlook to use so the user isn’t prompted for a password.
While this seems a simple request, it turns out that once you start considering all the various scenarios for which Outlook has to cache credentials (O365, Exchange on-Premise, machine in the domain versus out of the domain, multiple profiles, multiple credentials for a single profile), it gets complicated real fast. Even if you figure out how to cache credentials for Outlook to use for one scenario, a slight change to that scenario means the credentials have to be cached differently. So while the set of functions to be used in managing credentials is simple, the logic that goes into making these calls is very complex. We ran this by development just to make sure, but the results were as we expected: We cannot support any third party manipulation of the credentials used by Outlook. If a user wants to cache credentials, they need to enter them at the credential prompt.
we can deal with the credentials, but how about documenting how a profile must be constructed from the autodiscover XML? I find myself tweaking the implementation on an almost daily basis - outlook.com changes its autodiscover XML, boom! My code does not work anymore. A customer uses a hosted Exchange provider, such as Intermedia or GoDaddy, and again, I need to spend another night comparing profiles created by Outlook and my code...