This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Circumvent SMC EAS control for Office 365

Currently SMC 7.0 EAS proxy works with "SMC Managed" devices only (Devices that it knows about); by SMC sending the appropriate PowerShell commands to Office 365 cloud to deny/allow EAS functionality on non-compliant/compliant devices accordingly.

However, the downside of this approach is that Exchange Autodiscover is set-up in DNS to point to Office 365 in the MS cloud (as this is where the users mailbox now exists) and not the SMC server on the customer premise / managed Sophos cloud.

The end result is that if a user wants to set-up their mobile device and connect to Office 365 without the intervention and control of SMC, then they can do this very easily. - They just set-up a new mail account, adding in their email address, all without having to go via SMC. 

Effectively bypassing SMC, resulting in uncontrolled access to corporate data

This is basically what our users are doing right now to circumvent the SMC controls.

Whilst one can set-up minimum EAS connectivity requirements in Office 365 directly (e.g. PIN requirement, etc.), these out of the box controls aren’t as granular and secure as a dedicated MDM/EMM solution.

The preferred approach would be to link the SMC solution to an Active Directory group of ALL Office 365 users, and pull the users email addresses from that group membership. In turn, SMC would have the required information to link these users to both SMC and Office 365, as they would have common attributes, and control devices whether they are in SMC or not.

Example 1: 
1. SMC to extract email address from AD group. Example user; Joe.bloggs@domain.com 
2. SMC to lookup that user in SMC and list their assigned and managed devices by Active Sync ID.
3. As normal, SMC would then manage EAS access on the known devices as appropriate – compliant / non-compliant 
4. *EXTRA STEP* SMC would lookup the user in Office 365 and simply deny EAS access to unmanaged devices (Devices it doesn't have listed under the control of SMC) – that is until they become both managed and compliant

 

As a side note; Office 365 sees the built-in mobile OS email client and the downloaded Outlook mobile email client as two separate devices in EAS because of a different Active Sync ID.

HOWEVER, this looks easier to implement in SMC than I originally thought...

Sophos SMC already holds the required information about unknown devices in the file 'accessLog_ProxyEAS.xml.' - Each unknown device is listed as:

<deniedMessage>unknown active sync id</deniedMessage>

So surely this is quite achievable by Sophos to stop people easily circumventing SMC!?

 I'm happy to demonstrate this to Sophos.

 

Sophos?



This thread was automatically locked due to age.
  • hello im currently looking at server integration as this is now a requirement within our organisation, this is quite an interesting read, have you received any further information on this? we currently use Sophos but are looking at additional products like airwatch.

  • Hi Andrew,

    I raised a case with Sophos support and here’s what they said...

    Regarding this issue with your users accessing corporate email on unmanaged devices, this is because our EAS Proxy only makes changes to devices that are managed by SMC (as a security precaution rather than us impacting all devices in O365 that may never have anything to do with SMC or become managed). The good news is that you can change the default ActiveSync access for devices in O365 itself, if that's the behaviour you are after.

    Log into the Exchange Admin Center and go into Mobile > Mobile Device Access > Edit > Block Access. This will disable ActiveSync access for any device by default (rather than allow all by default) so that, when a device is managed and becomes compliant with SMC, we will then enable ActiveSync for that device.

    To which I replied:

    I tried the whole block thing from EAS, but the problem there is the users who use Microsoft Outlook app... EAS gives this app it’s own Active Sync ID, which Sophos considers as an unknown Active Sync ID.

    Thus the Outlook app gets blocked. As far as the user is concerned their mobile device is compliant.

    So the issue here still comes down to Active Sync ID’s.

    In Short. Sophos / EAS / and Outlook app don’t play well together.

    ———

    The case got moved to Sophos engineering, but I feel that it will fall into the dark pit.

    I also have Airwatch on my radar, and Trend for AV - there are design issues and defects with Sophos end point protection that have been crippling us for over a year and Sophos have done nothing.

    I chased but was officially told on one of my cases that not many people use Apple Macs with Sophos and the case has low priority!

    Ridiculous!

    I’ve been a Sophos customer for over 15 years, have been a case ID, have helped Sophos out on numerous occasions with UX, and as far as I’m concerned they are not the Sophos of old. (Since the buy outs they’ve lost touch with their customer base). We’re just a $ sign to them.

    Rant over.  :)

    Good luck with the EAS issue. If I get any updates beyond here I’ll post them up.

  • I see no mention of utilizing the Sophos secure email app.  The secure email app is a well thought out part of the Sophos Mobile product and should be considered in your design. It would also containerize and protect your email data. Auto deployment using device profiles makes it a fairly air tight solution.

    Would that not give you what you are looking for?

    Cheers,

    Danny

  • Hi,

    I'm currently looking into methods of locking down Office365 access as well using MDM.  I have a few clients using Sophos SMC but am not comfortable with it being so easily bypassed.

    Have you tried the built in MDM that is provided as part of Office365?  It seems to allow lock down and prevent access for devices that dont have Intune (their MDM) installed.  If you manually configure a mail profile you only get a message telling you to install intune.  I have just started playing with it and so far the only downside seem to be that I can only apply MDM to security group (which I have to make sure each user is a member of) as there doesn't seem to be an all users security group in Azure AD.

    Interested to know though if there is a method of enforcing Sophos SMC on any mobile device that connects to Office365.

  • Up....

    Here the same question. We are just setting up Sophos Mobile through Central. This works nicely with EAS proxy, but indeed is easily bypassed and therefore kinda defeats the purpose of having an MDM solution.

    Anyone having a best-practice to circumvent bypassing SMC EAS by using [any] other mailclient (outlook or whatever) than Secure email while at the same time allowing these whenever the devices are compliant?


    Managing several Sophos firewalls both at work and at some home locations, dedicated to continuously improve IT-security and feeling well helping others with their IT-security challenges.

  • As far as I understand, there isn't a way to lock down autonomously at this time. I have a request in to Sophos product development, although, I am sure they have received similar requests in the past (Sophos partner conference is in a few weeks, maybe I can get updated information). In the meantime, the stance we have taken at our firm is to turn to individual company policy with the understanding that configuring a mobile device outside of the approved methods is not allowed. We then report on the mobile devices connected to O365 via powershell script and review client type periodically (working on automated alerts via RMM). 

    I will update after the partner conference if I find out more information.

    Thank you!

    Danny

  • Thanks for your reply and insights in how you are now managing mobile devices.


    Managing several Sophos firewalls both at work and at some home locations, dedicated to continuously improve IT-security and feeling well helping others with their IT-security challenges.