Outlook and the Credential Manager
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.
Comments
Anonymous
May 17, 2013
Steve, 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...Anonymous
October 27, 2015
Hi Steve and Dmitry, has such a documentation to set up Outlook MAPI profiles from autodiscover been published anywhere? Plus: I cannot get MFCMAPI to open shared mailboxes from an Outlook 2013 profile with a primary mailbox on Exchange 2016. Outlook has no troubles to open additional inbox folders - all without credential popups, because FullAccess to additional mailboxes and send-as,receive-as,ms-exch-store-admin on mailboxdatabases was given - so ownerlogon and adminlogon should both work. Any update on how to create an EntryID for an OpenMsgStore call on secondary mailboxes on Exchange 2016? Regards Sven