New contact sync scenario available with Outlook for iOS on enrolled devices

[Ross Smith IV]

As many of you know, Outlook for iOS supports a one-way contact export process whereby contacts from within Outlook can be exported into the native iOS Contacts app. This functionality enables Caller-ID, iMessage, and FaceTime integration for users’ Outlook contacts.

We recognize that there are limitations and/or concerns with our contact export process, such as:

• The lack of a two-way synchronization mechanism means that users must remember to manage (create, edit, or delete) contacts from within Outlook and not the native iOS Contacts app. Contact changes within the native iOS Contacts app don’t get synchronized back to the appropriate Outlook account, which may lead to data loss when Outlook’s contact export process is triggered as the exported contacts get overwritten.
• On enrolled devices, in order to leverage Outlook’s contact export process, several changes to device restrictions are required, as documented in Support Tip: Enabling Outlook iOS Contact Sync with iOS12 MDM Controls.
• On enrolled devices, the exported Outlook contacts are considered unmanaged and are accessible to unmanaged, personal apps.

Unfortunately, these issues are not something that Outlook for iOS can solve as we’re completely dependent on the operating system to provide a supported mechanism for bi-directional synchronization and for delivering managed contacts. However, with the Managed Exchange ActiveSync Profile improvements introduced in iOS13/iPadOS, organizations now have an additional capability to configure how users can manage contacts on mobile devices.

On enrolled devices, users can leverage an Exchange ActiveSync profile that only synchronizes contacts. With this contact synchronization model in place, users no longer need to leverage Outlook for iOS’s contact export synchronization process. This approach results in two synchronization paths – Outlook leverages the native Microsoft sync technology for synchronizing data within Outlook, and ActiveSync is leveraged by iOS to synchronize the contacts.

Organizations can adopt this approach by deploying the following policies:

1. Deploy a managed Exchange ActiveSync (EAS) profile for contact synchronization.
2. Deploy an Outlook App Configuration Policy (ACP) that disables Save Contacts.

However, this approach should not be performed until all user devices are upgraded to iOS 13+ or iPadOS. This is because the managed EAS profile recommendation utilizes functionality only available in iOS 13+ / iPadOS. For more information, see Managed Exchange ActiveSync Profile improvements introduced in iOS13/iPadOS.

Note: Due to app configuration delivery timing, some users may experience duplicate contacts in the native iOS Contacts app. Once Outlook for iOS contact synchronization is disabled, the duplicates are removed.

Deploy the managed EAS profile

Using the general instructions in Add e-mail settings for iOS devices in Microsoft Intune, configure and deploy the below managed EAS profile to your enrolled user base:

This managed EAS profile forces OAuth as the authentication method, only allows Contacts synchronization, and prevents the user from changing what data types are synchronized.

Note: Changing an existing EAS profile with these new settings results in a new profile being pushed to the device. Users will be forced to enter their credentials and the profile changes won’t take effect until authentication is complete.

Deploy the Outlook ACP

Using the general instructions in Deploying Outlook for iOS and Android app configuration settings, configure and deploy an Outlook managed apps App Configuration Policy to your enrolled user base that (at a minimum) disables Save Contacts and prevents the user from enabling the setting:

Note: A managed apps ACP requires the assigned users to have an App Protection Policy. For more information on recommended approaches to deploying Outlook general app configuration, see http://aka.ms/omappconfig.

With the above changes, Contacts for the user’s account synchronize into the native iOS Contacts app via the managed EAS profile. As these changes are driven by IT, end users do not need to take any action other than entering their credentials for the managed EAS profile.

What are the benefits of this approach?

• The user can use the native iOS Contacts app for all contact management, if they desire. Contacts synchronize back into the user’s Exchange mailbox via the ActiveSync protocol and synchronize into Outlook for iOS over the Microsoft sync technology. Likewise, if the user performs any contact management within Outlook for iOS, those changes propagate to the native iOS Contacts app through ActiveSync synchronization.
• From within the native iOS Contacts app, users can manually search the global address list.
• Scenarios that can result in contact duplication are minimized (if not removed completely).
• When coupled with other device enrollment restrictions, like Viewing corporate documents in unmanaged apps (allowOpenFromManagedToUnmanaged), the managed EAS profile’s contacts are inaccessible to unmanaged, personal apps.

What are the limitations and/or things to think through with this approach?

• This approach requires iOS 13+ / iPadOS. Older iOS versions ignore the data type restriction and sync all data types.
• Device enrollment is required. Many organizations use App Protection Policies and not full device or user enrollment on personally-owned devices.
• Conditional access policy changes are required. The “Require approved client app” or “Require app protection policy” grant controls cannot be targeted against the iOS platform and Office 365 Exchange Online cloud app for modern authentication capable clients. Instead, the “Require device to be marked as compliant” grant control must be used.
• IT organizations are not able to control which messaging apps are used. As the “Require app protection policy” or “Require approved client apps” grant controls are not applied to Exchange Online for iOS devices, any modern authentication capable messaging client will be able to connect (e.g., an Exchange Web Services or third-party ActiveSync client) and access messaging data on enrolled iOS devices.
• Users may be able to access work or school content before an app protection policy is applied. As the “Require app protection policy” grant control cannot be used with Exchange Online and iOS devices, policy assurance for Outlook for iOS is not guaranteed. Also, messaging apps that do not support App Protection policies will be able to access messaging data on enrolled iOS devices.

We believe that for the vast majority of organizations, the recommendations we’ve outlined in the Ignite 2019 session, Outlook mobile: The gold standard for secure communications in the enterprise​, and in our Outlook mobile security in the enterprise whitepaper provides IT and users a viable and secure contact management solution. This includes:

• Use of the “Require app protection policy” Azure Active Directory Conditional Access grant control to block Exchange ActiveSync and other modern authentication capable messaging protocol apps, by only allowing Outlook for iOS and Android.
• Use of Intune App Protection Policies to protect school or work content within the apps and between accounts.
• Use of Intune App Configuration Policies to enable Save Contacts and limit the exported contact data fields that are exported to the native iOS Contacts app.

With any solution you need to balance your security requirements with end user productivity. We recognize the need for this flexibility, so we hope you find the above scenario useful.

Ross Smith IV
Principal Program Manager
Customer Experience Engineering

[Frazzled]

Hi Ross, thanks for this update. We have been looking at InTune as a viable option move from an existing EMM provider with predominately enrolled corporate iOS devices.  Given the limitations highlighted above with this approach, and the limitations of the alternative option (one-way export to un-managed contacts requiring an iCloud account), we're left wondering why there are no plans to utilize the Apple Call Kit as per other EMM providers solution.    It still doesn't seem like a happy balance can be struck - with the approach above we'd need to be looking at having to whitleist/blacklist apps due to the issue of other app clients being able to communicate with EOL.   

[NickAtkins]

Thanks, my biggest fear around ActiveSync in the past had been Basic Auth, but it looks as though this method allows us to leverage OAuth. It's still certainly not a solution to this problem, but it seems a viable workaround.

[Tech_Mike]

Hello Ross, thanks for this guide on how to achieve caller-ID, iMessage, etc. while having a working two-way sync of contact details. But how about password changes, does the user needs to change the password in Outlook and in the native app / profile? Also why can´t there be some kind of solution on Apple´s end, to get caller-ID working with third party apps like Outlook? Our enterprise strictly separates company data and private data on iOS and Android devices (far better on Android because of work profiles), thus syncing to the native app also enables other un-managed apps to access company data like phone numbers (e.g. WhatsApp, WeChat, you name it). It´s kind of a struggle to handle company contacts, either you are following GDPR (we have several branches in Europe) and have it separated or you have the comfort of having caller-ID  I hope there will be a real solution and Apple gets something like Android Work Profiles 

Mike

[Frazzled]

@Tech_Mike similar requirements here, ideally we would like to apply the 'Account modification' restriction policy that blocks ability add all accounts including iCloud.   The issue with that is using the EAS Contact sync solution with username/password auth, you cannot change the update the password when it expires.  The only alternative as far as I can see is SCEP authentication, which is more unwanted complexity for a small capability, albeit we do use it against an existing on-prem EMM.  

[Ross Smith IV]

@Tech_Mike - Yes, when the user's password expires, the OAuth refresh token will be revoked and the user will be prompted to authenticate again once the active token expires. The user will have to authenticate separately in iOS and Outlook.

@Frazzled - Not sure I follow - the user will get prompted to authenticate once the token expires.

[Frazzled]

@Ross Smith IV To clarify, it is not viable for us to allow un-managed contacts via the Outlook App contact export (option 1).  To even get this to work you need to have an iCloud account enabled, so immediately you are in a data loss position, even if limiting the data fields that can be exported. 

The fallback is then the EAS profile as described in your article, which has two issues.  Firstly, it would be preferable (for us) on Corporate Owned devices to apply the MDM 'Account Restriction' with a block setting.  This has the effect of locking out the EAS account under iOS Settings - when the configuration is deployed the user cannot enter credentials.  The only way around this is using SCEP for authentication as far as I can see which is a lot of overhead unless there is a requirement elsewhere.    The 2nd issue is one of usability - the user has to enter credentials twice upon password resets / token expiry etc.

So, if Caller-ID were available using Apple CallKit capability through the Outlook App, it would require much less management and a deliver a better user experience as we would have less concerns about opening up the rest of the devices for personal usage.  In my opinion! 

[Ross Smith IV]

@Frazzled Outlook for iOS does not require an iCloud account for contact export. The prompt is somewhat misleading (mentioned here - https://techcommunity.microsoft.com/t5/Intune-Customer-Success/Support-Tip-Enabling-Outlook-iOS-Cont...). 

Outlook for iOS requires a contact container to exist in order to sync contacts into the native app. When you enable save contacts we attempt a read action, if that fails (either because Outlook has no capability to read due to MDM controls, or because there exists no container in which to read from), Outlook will prompt the user to enable iCloud sync for Contacts – this is because Outlook has no capability to create a container and iCloud sync will create one (iOS only supports three types of containers – local, Exchange, cardDAV – from their names you probably understand how they get created – Exchange is an EAS profile).

Since you've deployed supervised devices, it makes sense that you're seeing this prompt.

As for CallKit, it would provide caller-ID for phone numbers found within Outlook, that's it. If users want a complete end-to-end solution for all scenarios (e.g., text messaging), users will only get that by having the contact in the local contacts app, which means they are creating contacts to get that ease of use capability.

[Frazzled]

@Ross Smith IV noted thanks Ross, I appreciate you have to workaround the limitations of the OS.   I think the full contacts sync option is neat and a better user experience, however as noted in your article there is a security trade-off it seems around the conditional access policies. 

[Philip Kluss]

It's not clear to me what is stopping the user from creating their own mail-enabled profile of their own volition.  If I deploy a locked-down "Contacts-only" profile, they can still create an "Everything-but-contacts" profile to circumvent my controls, correct?  There are no conditional access policies that block authentication attempts only when using an unmanaged profile that I know of.

[Philip Kluss]

Oh, I think I see.  If you try to create a second Exchange profile on an iOS device with the same Email address as an existing profile, you are stopped with a message stating "Cannot Create Account An identical Exchange account already exists."  So a compliance policy requiring a managed email profile coupled, conditional access policies requiring compliant devices and the locked-down Contacts-only configuration profile should indeed do the trick.

Thanks.

[Mal_G]

@Philip Kluss, good point, however as I understand it if a user has an alias email addresses they maybe able to create a second iOS EAS profile and get around the "Cannot Create account, An identical Exchange account already exists.". Also, if a different host alias is used they would be able to create a second profile.

[Rob_Pasell]

Do you also have to enable EAS in the users Exchange profile, or are the policy and config enough?

[Rob_Pasell]

In reference to my previous question.  The reason I was asking was because many of the user in our test group were being presented with a "Need Admin Approval" screen after receiving the EAS profile, and trying to authenticate.  It turned out we had to have Integrated Apps allowed for the tenant in order for them to authenticate.  A few of us did not experience this.  Can you explain what the need is for Integrated Apps and why it wasn't consistent?

[Ross Smith IV]

@Rob_Pasell - EAS has to be enabled for the user within Exchange. I cannot speak to what "Need Admin Approval" screen is as I've never seen that before nor do I know what "Integrated Apps" references. Probably best to open a support case.

[Rob_Pasell]

@Ross Smith IV I think the fact that you need to turn on EAS for each user in the Exchange profile should be mentioned in the "What are the limitations and/or things to think through with this approach?" section.  In our initial reading we were generally okay with (though not thrilled about) the solution because we were under the impression the profile would bypass the Exchange profile setting for this one attribute.

[Simon Scharschinger]

Hi Ross,

thank you for sharing this very helpful article. I see many improvements in the end-to-end scenario.
Our customers still have an issue with some best practice MDM Controls and the Outlook app like you described here.

In the case, you block access from outlook to the native contact app, you will be not able to create contacts from within the Outlook app.
Did I miss anything?

[David_Az]

Is this a miss-type as they both state the same setting?  

• IT organizations are not able to control which messaging apps are used. As the “Require app protection policy” or “Require app protection policy” grant controls are not applied to Exchange Online for iOS devices, any modern authentication capable messaging client will be able to connect (e.g., an Exchange Web Services or third-party ActiveSync client) and access messaging data on enrolled iOS devices.

[reasonation]

1. Is there a way to set the Default Contacts to the Managed profile with Endpoint Manager?

2. Is there a way to prevent user's from creating Additional Contact containers in iOS (for example iCloud, Gmail, Local)

[reasonation]

When setting the Managed Contacts Profile as the default Contacts container, it switches overnight to a gmail container that I have setup on the iOS device. Anyone else seeing this? Is there a way to lock down the iOS contacts to the Managed Profile exclusively?

[DanielBoos]

Any plans on supporting CallKit for incoming call identification in the future?

The local sync through the Outlook app is a nightmare for us (GDPR). Third-party apps can read them and possibly store them outside the EU. There was a case a couple of years ago involving Whatsapp. A court decided the WhatsApp user should have gotten consent from everybody in the contacts before using the app and subsequently sending the private data of all the saved contacts to WhatsApp.

That why we still use a secure app for email, contacts, calendars which uses CallKit for incoming call identification and initiating outgoing calls. That what the director wanted.

I personally think a managed account in iOS on a company-owned and supervised device is sufficient. But then on the other hand, what do I need the Outlook app for anymore?!

[Tech_Mike]

+1 on this

Still waiting for a solution which is stable and business-proof like the use of Callkit...

@DanielBoos : Because there's no GDPDR conform solution, we finally enrolled all iOS devices to Apple Business Manager, restricted everything on that device, including the Apple App Store making it impossible for users to download any other apps then the ones approved in Apple BM and Intune Company Portal. 

Alltough this is the right solution (I admit), having real company-use only phones, on the other hand, our employees won´t use their phones in private because anymore because they can´t install personal apps, which stands in contrast to our philosophy and was a nice incentive for everyone.

Hope that someday an implementation of Callkit in combination with access rights to Outlook contacts can do the balancing act while still conform to local laws.

[powershellteams]

Is there a similar solution for Android? We have our contacts stored in a subfolder, but the "save contacts" option in Outlook does not work.

[e-aldo]

Hi @powershellteams,

As I know enabling outlook "Save contacts" on Android devices allows 2 ways synchronization so there is no limitation with android devices.

Did you already try "Save contacts" from Outlook then face the limitation ?

cc @Ross Smith IV 

[mafrank]

@DanielBoos @Tech_Mike I guess Secure Contacts App | Security through GDPR-compliant contact management (provectus.de) is what you are looking for.

[jrng]

sadly i cannot use this method because we want users to use outlook for their email and we are using requires approved clients app and compliant devices for our office 365 exchange online cloud apps in conditional access policy.

[LiobaH]

@jrng We use Secure Contacts App | Security through GDPR-compliant contact management (provectus.de) to use our CRM, AD and Global address book contacts on our iPhones. The app is completely AAD and Intune integrated. Our conditional access policies are targeted on compliant device and require app protection policy.

[jrng]

to achieve this and only allow user to use outlook mobile as the mail client only, could anyone share with me their conditional access grant controls for:
-office 365 exchange online

-office 365

do you also block exchange activesync client using conditional access?

thanks.