How to use MFCMAPI to create a MAPI profile to connect to Office 365
I helped in a case recently where the customer needed to use Exchange’s MAPI to connect to Office 365. Now that Exchange’s MAPI supports RPC over HTTP (ROH) this is possible. I used my other post on connecting to Exchange 2013 as a base template and then just changed some things to connect. Here are the things that changed and some important notes along the way. Note: This is instructions for configuring Exchange’s MAPI to connect to Office 365. It will not work for Outlook’s MAPI.
First, Office 365 uses basic authentication over Secure Sockets Layer (SSL) for authentication. Therefore, I had to change the following properties to tell Exchange’s MAPI to use the right authentication protocol.
|Value: RPC_C_HTTP_AUTHN_SCHEME_BASIC (0x1)|
|Property: Instructs the MAPI subsystem to use Basic authentication when connecting to the RPC Proxy Server|
|Value: ROHFLAGS_USE_ROH (0x1) | ROHFLAGS_SSL_ONLY (0x2)|
|Property: Instructs the MAPI subsystem to use RPC over HTTP and to use SSL|
|Value: RPC_C_AUTHN_NONE (0x0)|
|Property: This property governs the authentication protocol that RPC uses.|
Now here is where it gets tricky. Basic authentication requires a username, password and realm / domain. However, the credential prompt present in Exchange’s MAPI did not allow me to specify the credentials needed for the tenant. This was because Office 365 does not support NetBIOS domain names and the tenant’s domain name was too long to fit in the edit box for username. Therefore, I had to specify the username and password in the profile. *** The password property for the profile requires that I encrypt the password and store the encrypted password as a stream of bytes (PT_BINARY). MFCMAPI does not currently support the ability to create this property in that way so I had to write a small little program to do it. Once I had that written, I set the properties as follows.
|Value: The User Principal Name (UPN) of a user who has access to the mailbox. For example, Jeremy@contoso.onmicrosoft.com|
|Value: The encrypted password|
|The data returned from the call to CryptProtectData() Crypto API then stored as a SBinary|
As far as the rest of the properties are concerned, they follow the same convention that I outlined in my previous post for Exchange 2013. The value of the RPC_PROFILE_RPC_PROXY_SERVER property is outlook.office365.com. The value of the property PR_PROFILE_UNRESOLVED_SERVER is the personalized server name. For example, <guid>@contoso.onmicrosoft.com. These settings can be retrieved using Autodiscover as I described before.
*** [Edit: 3/18/2014] This is not really true. I believe the issue is that if you don't specify the username and password in the profile upon initial connection to the proxy server no credentials will be passed. Once you are in this error state there is really no way to recover. Therefore, if you are using Basic Authentication you must specify the username and password in the profile.