Upcoming Exchange Online Device Access and Conditional Access changes with Outlook mobile
Published Jun 19 2020 09:00 AM 70.5K Views

Update: the change mentioned in this article has been rolled out to all commercial tenants.

Many of you may rely on Exchange Online mobile device access rules to ensure that only approved devices (or apps) access your messaging data. By default, an Exchange Online tenant allows access for all mobile devices. Admins can change this behavior to either block or quarantine devices with the following cmdlet:

 

Set-ActiveSyncOrganizationSettings -DefaultAccessLevel <Allow,Quarantine,Block>

 

Exchange mobile device access rules can even be used to manage Outlook for iOS and Android; see Block all email apps except Outlook for iOS and Android for examples.

Likewise, many of you have moved away from leveraging Exchange mobile device access rules and moved to a more comprehensive solution – Azure AD Conditional Access policies.

What you may not know is the interaction between Exchange’s mobile device access rules and Azure Active Directory Conditional Access policies when using Outlook for iOS and Android. This article describes how these policies work today and what is changing in August 2020.

Current behavior

Today, if you configure any conditional access policy (regardless of its applicability to mobile devices), Exchange Online will skip mobile device access rules’ processing for Outlook for iOS and Android devices.

For example, let’s say in your tenant you have no conditional access policies targeting iOS or Android devices, but you have a policy that ensures Windows devices are managed. This conditional access policy targets the Windows platform and leverages the following grant access controls:

CAChanges01.jpg

With this configuration, you may expect that Outlook for iOS and Android would be subject to Exchange’s mobile device access policies because there are no conditional access policies in play for iOS and Android devices. However, that’s not the case. When Outlook for iOS and Android connects to Exchange Online, Exchange Online executes a Graph API call to Azure AD and determines that there are conditional access policies associated with the user and skips the processing of the Exchange device access policies. You can see this by querying the device in Get-MobileDeviceStatistics as the DeviceAccessStateReason is set to ExternallyManaged:

 

Get-MobileDeviceStatistics -mailbox Natasha | where {$_.DeviceModel -eq "Outlook for iOS and Android"} | fl LastSuc*,DeviceAccess*
LastSuccessSync         : 6/9/2020 10:35:13 PM
DeviceAccessState       : Allowed
DeviceAccessStateReason : ExternallyManaged
DeviceAccessControlRule :

 

Future behavior

Obviously, that is not the desired behavior. Beginning in August 2020, we are rolling out changes in Exchange Online to ensure that only certain Conditional Access policies bypass Exchange’s mobile device access rules for Outlook for iOS and Android devices. Specifically, only Conditional Access policies configured with the following conditions and grant access controls will prevent Exchange mobile device access rules being applied to Outlook for iOS and Android:

  • Cloud app condition: Exchange Online or Office 365
  • Device platform condition: iOS and/or Android
  • Client apps condition: Mobile apps and desktop clients
  • One of the following Grant access controls: Require device to be marked as compliant, Require approved client app, Require app protection policy

For more information on these grant access controls, see Conditional Access: Grant.

The good news is that if you are utilizing one (or more of) these grant access controls with the appropriate conditions, your Outlook for iOS and Android users will not be affected.

However, if you are utilizing Conditional Access policies that do not leverage the appropriate conditions and grant access controls and have configured the mobile device access level within Exchange Online to block or quarantine devices, users using Outlook for iOS and Android will be blocked or quarantined by Exchange Online after this change is implemented. By default, the mobile device access level in Exchange Online is set to allow. You have a few different options on how you can remediate this prior to the change:

  1. Implement Microsoft Endpoint Manager and one of the above grant access controls. For more information, see Leveraging Enterprise Mobility + Security suite to protect corporate data with Outlook for iOS and A....
  2. Create an Exchange Online device access rule that allows Outlook for iOS and Android. For more information, see Block all email apps except Outlook for iOS and Android.
  3. Manually add the user’s Outlook for iOS and Android Device ID to the user’s ActiveSyncAllowedDeviceIDs property. To obtain the Device ID, use Get-MobileDeviceStatistics. To add the Device ID to the user’s ActiveSyncAllowedDeviceIDs property, see Set-CASMailbox. An example script is provided that can be modified to automate this:

 

$mbxs = Get-CASMailbox -Filter { HasActiveSyncDevicePartnership -eq $true } -ResultSize 10000
foreach($mbx in $mbxs)
{
$IDList = Get-EXOMobileDeviceStatistics -Mailbox $mbx.id | where {$_.LastSuccessSync -ge "2020-06-01" -and $_.DeviceModel -eq "Outlook for iOS and Android"}
If(!$IDList) { continue }
foreach($ID in $IDList) {$mbx.ActiveSyncAllowedDeviceIDs += $ID.DeviceID}
Set-CasMailbox $mbx.Id -ActiveSyncAllowedDeviceIDs $mbx.ActiveSyncAllowedDeviceIDs
}

 

  1. Change the default access level to Allow. For more information, see Set-ActiveSyncOrganizationSettings. This change allows all mobile devices, regardless of type, to connect.
  2. Alternatively, organizations can retain their default mobile device access level and wait for this change to take place and manually allow each device as they are quarantined/blocked.

Important: Because Outlook for iOS and Android’s device IDs are not governed by any physical device ID, the ID can change without notice. When this happens, it can cause unintended consequences when device IDs are used for managing user devices, as existing 'allowed' devices may be unexpectedly blocked or quarantined by Exchange. Therefore, we recommend administrators only set mobile device access policies for Outlook for iOS and Android that allow/block devices based on device type or device model.

We believe the changes we’re implementing are the right approach for improving the overall security for Outlook for iOS and Android devices by only skipping Exchange mobile device access rules when the device is managed by Intune. If you have any questions, please let us know.

Ross Smith IV

58 Comments
Brass Contributor

Hello, this is a welcome change! I wrote an article about the current behaviour last year (https://www.gurot.com/blog/eas-access-rules-exchange-online) and the fact that ABQ rules in the current implementation are pretty much useless... :( Also, the current implementation is very vaguely described in the documentation and does cause a lot of confusion. Thanks for making this change!

 

Deleted
Not applicable

Microsoft mobile solutions are becoming mess.

 

Customers looking to manage Outlook for iOS and Android have the following options:

  1. Recommended: The Enterprise Mobility + Security suite, which includes Microsoft Intune and Azure Active Directory conditional access.

  2. Mobile Device Management (MDM) for Office 365 (free/builtin?). "MDM for Office 365 provides device management capabilities at no additional cost"

  3. Third-party Mobile Device Management solutions.

  4. Mobile Device Access and Mobile Device Mailbox Policies (free/builtin?).

https://docs.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/outlook-for-ios-and-...

 

"Create rules that allow Outlook on Windows devices for Exchange ActiveSync connectivity (WP refers to Windows Phone, WP8 refers to Windows Phone 8 and later, and WindowsMail refers to the Mail app included in Windows 10)"

https://docs.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/outlook-for-ios-and-...

 

3 solutions from Microsoft for managing mobile devices, but there is no good diagnostics tool explaining what's going on.

 

@The_Exchange_Team 

my question: The Microsoft built-in Mail app (Mail and Calendar in MS Store) - will it be affected? how it should be managed? Which Conditional Access policy should be used? Yes, this is enough for some of our users, as they don't need full Office package price (security bonus: all Excel/Word macros are "blocked" :smiling_face_with_smiling_eyes:).

Microsoft

@Deleted I don't consider providing customers with options with varying degrees of different features and capabilities, a mess. #2 and #4 are built-in and available to customers, while #1 and #3 require additional licensing/cost.

 

The Windows 10 Mail/Calendar apps do use the same sync technology that Outlook mobile leverages. However, Windows 10 Mail/Calendar doesn't support Exchange device access rules, so that enforcement is skipped for those clients. The CA grant controls, Require approved client app and Require app protection policy, are only applicable to iOS and Android devices. The Require device to be marked as compliant can be used, though.

Steel Contributor

Thanks and glad to hear this is being addressed (the current state is news to me anyway).  I have a hopefully quick question, about the current state, and I guess the same question applies to the future state.

Current behavior

Today, if you configure any conditional access policy (regardless of its applicability to mobile devices), Exchange Online will skip mobile device access rules’ processing for Outlook for iOS and Android devices.

By "any", does that mean, even regardless of any other conditions.  What I mean is, does the policy at least have to apply to Exchange Online as the cloud app?

 

I'm assuming yes, but I'm not sure exactly how Exchange Online and Azure AD are talking back and forth about this stuff.  I assume the response/token that AAD gives the user when sending them back to Exchange Online (after authenticating through Azure AD) must contain info that tells EXO what grant controls were required?  Or does Exchange Online do some kind of recurring analysis of AAD Conditional Access policies?

 

Thanks in advance.

 

Microsoft

@Jeremy Bradshaw no, EXO does not have to be specified as a cloud app in CA. Effectively, what's happening is that EXO is is making a graph API call. The API returns that there are CA policies in play (e.g., a broad policy that ensures MFA is required), which triggers EXO to not apply the device access rules.  The change rolling out in August ensures that we evaluate a particular claim (enfpolids) returned by the graph API and only skips device access rules if that claim is non-empty.

Steel Contributor

@Ross Smith IV Thanks for the explanation.  Neato.

Deleted
Not applicable

@Ross Smith IV 

I got a few more questions regarding this Windows 10 Mail app:

 

"The Windows 10 Mail/Calendar apps do use the same sync technology that Outlook mobile leverages."

So it is not ActiveSync I assume.

(relevant for https://docs.microsoft.com/en-us/microsoft-365/enterprise/secure-email-recommended-policies?view=o36...

 

And this Windows 10 Mail app is using modern authentication or not?

it is not listed here: https://docs.microsoft.com/en-us/Office365/Enterprise/office-365-client-support-modern-authenticatio...

(relevant for https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/block-legacy-authenticati...

 

(please forgive my confusion)

"The Require device to be marked as compliant can be used, though"

Compliant with fully-blown Windows 10 compliance policy from Intune, yes?

 

or you mean this compliance?

"You can manage Windows 10 devices by enrolling them as mobile devices. After an applicable policy is deployed, users with Windows 10 devices will be required to enroll in Mobile Device Management for Microsoft 365 Business Standard the first time they use the built-in email app to access their Microsoft 365 email (requires Azure AD premium subscription)."

https://support.microsoft.com/en-us/office/capabilities-of-built-in-mobile-device-management-for-mic...

+

https://support.microsoft.com/en-us/help/3144451/a-windows-10-device-is-enrolled-as-mobile-when-you-...

Microsoft

No, Windows 10 mail does not use ActiveSync (for EXO mailboxes). It uses the Microsoft sync technology.

 

Yes, the Windows 10 mail app supports modern authentication. It's considered a "Windows 10 Modern Apps" in https://docs.microsoft.com/en-us/Office365/Enterprise/office-365-client-support-modern-authenticatio....

 

Yes, the "require device to be marked as compliant" grant access control can be used to ensure Windows devices are enrolled. This section - https://docs.microsoft.com/en-us/microsoft-365/enterprise/identity-access-policies?view=o365-worldwi...

Deleted
Not applicable

@Ross Smith IV

 

Hmm, but Microsoft Corp. knows better :p

 

WindowsMail is listed in https://outlook.office365.com/ecp/ in Exchange ActiveSync Device Access rules:

Adnotacja 2020-07-01 082509.png

 

"Create rules that allow Outlook on Windows devices for Exchange ActiveSync connectivity (WindowsMail refers to the Mail app included in Windows 10)"

https://docs.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/outlook-for-ios-and-...

 

it looks like Mail app is "forgotten" in all Microsoft documentation, but from admin point of view it is "better" than other email clients - it auto-updates without admin rights in background.

 

Definitely Mail app needs some love from you guys.

Copper Contributor

Hi, does the change rolling out Aug 2020 impact the native iOS Mail app configured with Exchange Activesync or just Outlook for iOS and Android devices?

 

Thanks,

Pablo

Microsoft

@PCH1-IT This change only affects Outlook for iOS and Android.

Copper Contributor

@Ross Smith IV is this change only applicable for tenants with Azure AD conditional access policies in place? If there is no CA policy in place, there will be no impact? 

Microsoft

@lwood50 - yes this is only applicable if CA is in use. Note that Azure AD security defaults (https://docs.microsoft.com/azure/active-directory/fundamentals/concept-fundamentals-security-default...) like MFA are using conditional access behind the scenes.

Microsoft

@The_Exchange_Team @Ross Smith IV 
Earlier Send to OneNote was not working on devices with Conditional Access policy is in place. Will it address that issue too?

Similar to Insert Meeting Details, Send to OneNote add-in in Outlook is implemented as Office dialogue API. It wasn't supported with Intune policies on Android or iOS devices?

Microsoft

@Gaurav0327 Random question on a random blog article, eh? :) Not sure what issue you are referring this, but it has nothing to do with this change. If the question is how can a user authenticated in Outlook mobile to use the Send to OneNote feature. Then the answer is that Send to OneNote in Outlook mobile does not allow users to sign into the add-in. They must sign-in to the OneNote add-in using Outlook desktop, Outlook for Mac, or Outlook web app from a PC/Mac. This is a design choice to ensure that work or school account data cannot be exfiltrated to personal OneNote account via the add-in. Add-ins in Outlook mobile are not protected by the Intune App Protection Policy - they are considered unmanaged. 

Brass Contributor

Hi,

 

how is the this case handled:

ADD Conditional Access: A rule that grant "Approved Client Apps" in Condition with -> Client Apps -> Browser (only) (User can just access with Edge or Intune Browser). No rule for apps.

 

Does this AAD CA rule bypass the Exchange CA with the new behaviour?

 

best regards

Copper Contributor

@Ross Smith IV  and @The_Exchange_Team  I'm looking into our CA policies to check which would start processing the device access rules and pose an issue (have the org setting on quarantine) Initially you mention that the CA policy does not even have to be targeted to mobile devices. 

 

Is it than correct from august onward

If your User is targeted in any CA policy which does not have Grant access controls selected will process the Device access rules ?  

Device access rules are also applied if the one of the CA policy is set to Block or use Session controls ?

Is the webbased access to exchange online  also blocked if a device is quarantined or only the outlook app on IOS and Android ?

Copper Contributor

Hello, very nice article.

I do have a question. I have a CA that has Grant Access if the device is Compliant for a smaller subset of users. Does this satisfy the requirement as stated above for all of our users (the statement above: "The good news is that if you are utilizing one (or more of) these grant access controls, your Outlook for iOS and Android users will not be affected.")?

 

Or does that only satisfy the CA requirements the users within that particular group? 

 

 

Microsoft

@RayTheil2112 - only those users who have that CA policy will now have Exchange device access rules excluded for Outlook mobile.

Copper Contributor

Any idea when this will go into effect for all users

Microsoft

@Gudhery - hard to say as we're going to roll this out slowly and ensure there are no issues and or increase in support tickets before deploying broadly.

Copper Contributor

I'm currently chasing the ghost of Get-MobileDevice and Get-MobileDeviceStatistics / Get-EXOMobileDeviceStatistics for the exact same device (usually Outlook for iOS) showing different access states after manually approving said device out of quarantine.  The former showing allowed with the latter two showing quarantined.  We're only leveraging Exchange Online Device access (with our default ActiveSync Organization Settings set to quarantine).

 

Perhaps this change might help prevent this situation.

Copper Contributor

@Ross Smith IV  @The_Exchange_Team 

 

If i have a CA policy assigned to the user with Session control or Block the exchange device access rules will still be processed ?

It seems the skipping is only done on specific Grant Access

Copper Contributor

August has gone and I still don't see the change in behavior.

Copper Contributor

Hello,

If I have the following output of the command Get-MobileDeviceStatistics :

DeviceAccessState       : Quarantined

DeviceAccessStateReason : AadBlockDueToAccessPolicy    

How can I retrieve the ID of the CA policy that is blocking the device ?

Kind regards,

Kostadin

Copper Contributor

Did this change ever happen? I still see the old behaviour.

Copper Contributor

@JordanMalcolmUK 

 

From top of page:

Update: the change mentioned in this article did not roll out in August 2020 as planned; the update will occur later in Q4 calendar year 2020."

 

It didn't occur  yet. I really don't understand Microsoft. This is a critical security bug that has been unfixed for over a year.

 

Our workaround is we have a Powershell script which wipes any Outlook Mobile device for users that arent allowed to have them

 

 

Copper Contributor

@davudullu 

 

Thanks, spotted that just after posting this comment. I suspect there are a lot of organisations out there completely oblivious that this is happening.

 

I think I may utilise the -OutlookMobileEnabled flag on Set-CASMailbox (e.g. Set-CASMailbox username -OutlookMobileEnabled $False). It's a shame this can't be enabled globally though.

Steel Contributor

Even if they had made the change, it's still not good enough.  It's very band-aid to start but worse is that it has no way to know if the policies would even target the user anyway.  The idea that EXO is sending that many requests to MS Graph for this kind of thing is a little crazy.  They mustn't have any MS Graph throttling to worry about, and that likely spills over causing additional throttling for regular customers using MS Graph.

 

It's just a bad solution all around.  I wouldn't be surprised if these points I'm mentioning have at least some part in the reason for the postponement.

 

EDIT: I shouldn't just gripe and give no suggestions.  It's definitely a difficult situation I'm sure.  But I think device access rules should just be left as they are, and customers need to know not to make conflicting settings between CA policies and device access rules.  I also think ALL get-AvtiveSync*** cmdlets should have gotten new replacements, not just some.  It reveals the tendency to only get things half done.  Its been long enough now that that initiative should have been finished off.

Copper Contributor

So is this going to happen in 2020?

Microsoft

Yes this has started (as of Dec 9th).

Copper Contributor

@Jeremy Knight Should this change have affected everyone by now or is Microsoft still rolling it out?

Copper Contributor

Hi all - did this happen?  Please answer MS.  We are based in AUS and noticed that users that had been working were suddenly quarantined (as planned) but then it has stopped.  New users being allowed through because of MFA.  Was this patch rolled back?  Some information would be much appreciated.

 

regards,

David

 

Microsoft

@hollierose @campbed1145 As Jeremy indicated, we began a small rollout of 10% of worldwide tenants prior to the holiday. We increased rollout to 20% this week.

Copper Contributor

Still not finished???

 

My Outlook Mobile is still not quarantining when allowed when Exchange access is allowed  through CA.

Copper Contributor

@Ross Smith IV @Jeremy Knight 

Still not finished???

 

My Outlook Mobile is still not quarantining when allowed when Exchange access is allowed  through CA.

Microsoft

We've rolled this out to 100% of commercial tenants as of yesterday.

Brass Contributor

I do see that change happened last night for me. My fault for not reviewing the message center.

We had a process in place to quarantine device and allow them one by one (we needed each employee to agree to a hipaa form before allowing the mail apps to sync). 

Is that no longer possible? I see rules to allow Outlook for iOS and Android all together but not for each phone/user? 

Also, if I try to allow an outlook app now it goes right back to quarantine.

Microsoft

@Carlos Cordeiro I have no idea what process you were using to get a user to agree to a HIPAA form before sync, so can't comment on that. As the article indicates you can allow on a per-device capability, however as the Outlook app uses a virtual device ID, the ID can change for a variety of reasons (e.g., user uninstalls and reinstalls the app) which will quarantine the app again. While supported, it's not the recommended path. If you need advance management capability, we recommend Intune.

Copper Contributor

Very disappointed with the way this was rolled out.

 

We had checked our CA rules leading up to this change and all were compliant so we should have had no impact. That being said, we were part of the first group, had to mitigate with the script to add devices back to our allowactivesyncdeviceIDS which was somewhat acceptable but then with each subsequent roll out to the remaining waves, had to do so again causing us three outages.

 

Why was it not just rolled out to the new waves and not the tenants that already had it introduced?

 

Will we see any more updates that will wipe out our allow lists again?

Copper Contributor

Good day to all,

 

unfortunately the underlying issues that have been introduced due to this "bug" in Conditional Access are not addressed at all by the changes that Microsoft has been rolling out.  I may have missed it - but what I am not seeing in Microsoft's communication on this topic is that, specifically for ActiveSync-based mailbox access, Exchange Online was not just "ignoring" or "bypassing" any configured restrictions such as ActiveSync quarantine!  Instead, unauthorized ActiveSync clients were actively being authorized.  And they therefore still are! 

 

Organizations that were using ActiveSync quarantining will be able to see that the Mobile Device Status for any instance of "Outlook mobile" that was used during the period that this "bug" in Conditional Access has existed was automatically changed from "Quarantined" to "Access granted".  Those entries still exist today - and they will continue to be valid until removed!

 

When you take into consideration that the "device id" for an instance of the Outlook mobile app may change when the app is upgraded, that also means that when the app is not upgraded the "device id" stays the same - and therefore the "Access granted" status for that "device id" continues to be valid...

 

So with pushing out these changes Microsoft is only preventing that MORE unauthorized instances of Outlook mobile get added to your tenants - but they are not cleaning up the mess they created in the first place.

 

Now I have put that word “bug” between quotes because I do not believe this was a mistake.  The timing / period over which this has happened and some of the other things Microsoft has done make me think that this was all part of a deliberate campaign to boost usage and acceptance of the Outlook for mobile app.  Maybe it is just me being cynical.  But this issue has been in place since at least December 2019 and it nicely overlaps with campaigns Microsoft has been running to promote the use of Outlook for mobile.  Remember the unsolicited banners that showed up in Outlook on the desktop last spring?  That's just one example.  The fact that Outlook mobile uses it's own "device id"?  That's crazy.  It's an app - not a device.  These are choices.  Bad choices.  One could argue these choices were made deliberately in an attempt to circumvent the capabilities of non-Microsoft MDM solutions like AirWatch.

Microsoft

@Brentchy808 I suspect your issue was related to an issue we discovered during the rollout by including certain tenants. Now that we are at 100% rollout, there won't be any further changes to this functionality. With that said, as I wrote in the article (and as documented in https://aka.ms/secureom), we do not recommend managing Outlook mobile connectivity through device ID, as the device ID can change.

Microsoft

@Martijn Tigchelaar Let me clear up some misconceptions.

  1. Outlook mobile does not utilize the Exchange ActiveSync protocol. It uses the Microsoft sync technology (https://docs.microsoft.com/exchange/clients-and-mobile-in-exchange-online/outlook-for-ios-and-androi...). The change in this article is specific to Outlook mobile and does not affect mobile clients utilizing the ActiveSync protocol.
  2. With the change highlighted in this article, if an Outlook mobile was previously allowed to connect by an incorrect Conditional Access policy, with this change, that same Outlook mobile client would be blocked by the Exchange Online mobile device access policy (if set to quarantine/block) and that device ID was not already defined in the user's ActiveSyncAllowedDeviceIDs.
  3. The reason that Outlook mobile utilizes a virtual device ID is because apps are prevented by the OS platform from accessing certain physical device parameters that would make obvious ID choices. As a result, the app has to generate its own device ID. For example, since iOS7, certain hardware information is restricted from third-party apps (e.g., https://code.i-harness.com/en/q/2f29e and https://forums.developer.apple.com/thread/7560).
Copper Contributor

@Ross Smith IV well... If Outlook mobile does not use Exchange ActiveSync then you should have introduced different terminology and not refer to the "Set-ActiveSyncOrganizationSettings" commandlet in this original post.

Allow me to share what we are seeing.  Outlook mobile may not be using ActiveSync, but it sure looks and smells the same in the portal.  This is from just one of our many users / mailboxes:

 

Mobile Devices.png

The first entry with a status of "Access granted" is dated January 18 and shows "Access set by External Mobile Device Management" (recognize that?)  The second entry with status "Quarantined" is from February 3 and shows "Access set by Global Permissions".  Both of these entries also show "ActiveSync version 1.0"...  So if Outlook mobile does not use ActiveSync - then what is it that we are looking at here?  Yet another platform bug?

 

Either way - that "Access granted" entry from January 18 was not approved by our 3rd-party MDM solution - nor was it manually approved, nor is there any log entries we can find that explain this.  The second entry showing "quarantined" only came to exist because the user upgraded the Outlook mobile app.  This second entry is actually how things should have been all along.  But as you can see - the old entry is still there.

 

So - if Outlook mobile does not use ActiveSync then I think the introduction of new terminology is long overdue.  Until then, I will continue to use the same terminology because that sure appears to be what the platform is actually using.

 

 

 

 

Microsoft

@Martijn Tigchelaar yes, some of the cmdlets naming conventions were not updated, some where (e.g., *-ActiveSyncMailboxPolicy was replaced with *-MobileDeviceMailboxPolicy). I can't answer why the *-ActiveSyncOrganizationSettings wasn't rebranded, but the cmdlet (like those mailbox policy cmdlets) support other protocols than ActiveSync. Perhaps it will be renamed in the future. Regardless, Outlook mobile does not use ActiveSync as connectivity protocol.

Copper Contributor

@Ross Smith IV whether or not Outlook mobile uses the Exchange ActiveSync protocol did become irrelevant when you continued to use the term "ActiveSync" all over the place.  At least when using the terms "activesync" and "quarantine" most people who have been around for a while will know where to look in their environments.


The point I was making is that this statement from the original posting above does appear to be incorrect:

 

Today, if you configure any conditional access policy (regardless of its applicability to mobile devices), Exchange Online will skip mobile device access rules’ processing for Outlook for iOS and Android devices.

It appears to be the case that Exchange Online did not just "skip" the processing of any mobile device access rules.  Instead, the mobile device access was actually permanently approved.  A new entry was added to the list of devices / apps to explicitly and permanently grant access to the device ID in question for the particular Outlook mobile instance.  Those entries still exist today and will continue to exist until cleaned up.  And that means that any Outlook mobile instance that was granted access due to this mishap, will continue to have access until either the app is upgraded or the explicitly granted access is removed.

 

So it makes me wonder about this part of your response:

 

With the change highlighted in this article, if an Outlook mobile was previously allowed to connect by an incorrect Conditional Access policy, with this change, that same Outlook mobile client would be blocked by the Exchange Online mobile device access policy (if set to quarantine/block) and that device ID was not already defined in the user's ActiveSyncAllowedDeviceIDs.

You appear fairly certain that what we are seeing in our environment did not actually happen - or has nothing to do with the CA issue that has been resolved.  But we have plenty of reason to believe that it did.  One clear indicator is that over the past 2 days, after a new version of the Outlook mobile app was released on February 2, we suddenly have hundreds of users reporting that their (unauthorized) Outlook mobile app has stopped working.  I am pretty certain that their Outlook mobile app has stopped working because of the combination of the following two things:

  1. The issue in Conditional Access has been resolved, and access using any version or instance of Outlook mobile is no longer automatically granted (but existing access that was added due to the CA issue was still valid)
  2. The Outlook mobile app was upgraded - and uses a new device id, making any access that was previously granted due to the CA issue, invalid.

The information provided by Microsoft, combined with what we are actually seeing "in the field" appear to indicate that you are wrong.  There is more to the story than what you are revealing.  The fix that has been deployed may have put out the fire - but the customer environments still need urgent cleanup because there is no guarantee that all users of Outlook mobile will upgrade their app instance - and that in turn will mean that they will continue to have unauthorized access because your bug in Conditional Access granted it in the first place.

 

Copper Contributor

This is hurting us right now. As far as i can tell our options are:

 

1. Use InTune. Which sounds nice, but we are heavily invested into Airwatch at the moment. 

2. Setup Allow rule for all Outlook IOS/Android to bypass quarantine. 

3. Manually add device IDs to user accounts every time this changes. 

 

We need a better solution. 

Copper Contributor

@Feffen you have the solution.  AirWatch.  The fact that you have AirWatch in the first place probably means that your users should not be using Outlook mobile. 

Brass Contributor

@Ross Smith IV Thank you for your reply. 
Its hard for us to buy Intune as we are nonprofit with 1200 users. And its also hard for us to keep approving Outlook ActiveSync requests over and over. Its also not an option for us to just auto approve Outlook app for HIPAA reasons. We are kind of stuck. I guess we will need to figure out another option. I am curious to see what other organizations are doing with this change.  

Microsoft

@Martijn Tigchelaar There's no conspiracy or nefarious subterfuge going on here. If CA approves the connection, then Exchange mobile device access processing is skipped and the device is marked with the following access state:

 

DeviceAccessState : Allowed
DeviceAccessStateReason : ExternallyManaged

 

With the change implemented in this article, those devices that were once considered externally managed are no longer such and now have Exchange mobile device access processing applied. That's why the devices get blocked/quarantine.

 

An app update did not change the device ID. What happened on February 2nd was that we increased the rollout to 100%. Your tenant had this policy change applied.

Co-Authors
Version history
Last update:
‎Feb 08 2021 01:33 PM
Updated by: