Apr 10 2019 05:31 AM
Apr 10 2019 05:31 AM
There are several ways to block auto forwarding of email to external recipients via Exchange Online. However there's also an option to create a flow for new email enabling auto forwarding to external recipients using Microsoft Flow!
Problem with this method is that none of the existing methods of blocking these emails is applicable. These emails are directly sent form the users mailbox and therefor not apply to the existing rules.
The DLP option for flow is also not able to prevent this because it only blocks sharing data between connectors.
Because everyone with enabled Azure AD account is able to use Microsoft Flow (even if they don't have the feature enabled within their license plan), there's no way to block this (as far as I know).
Is there any way to avoid this?
Apr 10 2019 11:27 AM
That's most likely because Flow doesn't do an actual "forward" action, but simply prepares a new message and copies all the relevant details. You as the admin are able to see the types of Flows your users are using, and delete them if needed.
Apr 11 2019 06:48 AM
@Vasil MichevI agree that as an Admin you're able to (re)view flows which users have created but the problem with that is that it will always be reactive. We need to be able to prevent users to use this functionality and with that prevent all mailbox data to leave the organization.
Apr 11 2019 09:26 AM
Well you've proactively enabled the users to use Flow :)
I don't disagree with you, it would be nice to be able to control such flows, but as you noted above this one doesn't seem to be captured by the Flow DLP capabilities. You can crawl the Unified audit log for any events corresponding to the Flow or even attach an alert to them, but that's still reactive. Then again, there are potentially dozen other Flows that can be abused to send/save data to an external location, so you might as well re-evaluate the need to enable Flow.
Apr 11 2019 01:09 PM
@Vasil Michevthat's just it. Like I explained in the post, we've not actively enabled Flow (feature is not enabled within the licensing plan) but users are still able to use Flow.
The only way, I currently see, to proactively prevent users from using Flow to auto forward messages, is to block acces using Conditional Access for example. There's no known other way to disable the service?!
And more importantly there's no way to block the users from auto forwarding using Flow without completely blocking access.
Or is there?
Apr 11 2019 11:34 PM
Disabling the license should at least remove the app tiles for Flow, but yeah that's security by obscurity. Let me ping few folks...
Apr 11 2019 11:40 PM
So looking at the audit logs, it seems that Flow makes direct connection to the mailbox in order to forward each message, meaning you can just block the IP ranges by any feature that allows such control (CA, auth policies, etc): https://docs.microsoft.com/en-us/flow/limits-and-config#ip-address-configuration
Apr 12 2019 09:47 AM
Apr 15 2019 02:59 AM
@Akshay_ManeThe Exchange part is clear (and in place) but this does not prevent Flow form using EXO to forward emails to external recipients.
Apr 15 2019 03:03 AM
@Vasil Michevthanks for the suggestion. The downside of going down this road is that when IP addresses/rangers change (or are added) these are not automatically reflected tot the block configuration, which leaves gaps. And we'd like to only block forwarding to external recipients but let users be able to forward to internet recipients.
Apr 26 2019 12:59 AM
@Vasil MichevAfter several test scenario's it seems there's no way to block the connection from Flow to Exchange Online using Conditional Access policies.
However, I managed to get an active block for Flow using a Client Access Rule within Exchange Online.
I used the following PowerShell code to block the US en Europe IP addresses from Flow:
New-ClientAccessRule -Name "Block Flow Access" -Action DenyAccess -AnyOfClientIPAddressesOrRanges $IPRanges
Apr 26 2019 10:40 AM
With CA policies you can block those exact IP ranges, although it's a tedious process. CARs are indeed another option, as is blocking the connectors' user-agent string: https://docs.microsoft.com/en-us/connectors/office365/