Supporting the unsupported platforms

This week is all about supporting the unsupported platforms. More specifically, working with the limitations of the platforms that are unsupported by (parts of) the Microsoft 365 solution. Those platforms are Chrome OS and the different Linux distributions. Often those platforms are around in an organization during the introduction of a Microsoft 365 solution. In many components of the Microsoft 365 solution, those platforms are currently not supported. Think about Microsoft 365 Apps for Enterprise, Microsoft Intune, Conditional Access and so on. Basically nothing is really working and/or supported on those platforms at this moment. From that perspective Chrome OS is maybe even worse than the different Linux distributions. That doesn’t mean that there is no story at all. In this post, I want to start with an introduction to the actual challenge, followed by going through the most common options that are available to address that challenge. The scope for this post is limited to Microsoft 365 E3 license functionalities.

An introduction

When introducing a Microsoft 365 solution, the strength is the completeness of the solutions and the security and management capabilities that it brings. Especially the security of the solution goes as far as to were it’s a closed solution. For that, think about Conditional Access, the front door protection towards the company apps and data. Basically the first line to protect the access to the company apps and data. However, that’s also were the first challenge is that arises. Conditional Access, the protection at the front door, doesn’t support Chrome OS and the different Linux distributions. That means that it’s still possible to protect at our front door, but it’s not possible to take everything into account. It’s not possible to require anything of those platforms, besides multi-factor authentication (MFA) for the user using that platform. That’s not always sufficient. In the ideal world an organization wants to make sure that either the app, or device, that is used to access the company apps and data, is managed. However, that’s simply currently not supported for all platforms. That’s also were the second challenge arises, as Chrome OS and the different Linux distributions are not supported by Microsoft Intune. So, it wouldn’t even be possible to get those platforms managed. And I could go on in that chain, by looking at the Microsoft 365 apps for Enterprise (with the exception of Chrome OS devices that are capable of using Android apps) and all the other different components of the Microsoft 365 solution, but the result would be the same for Chrome OS and the different Linux distributions. Of course there are small exceptions, like the Microsoft Teams app and Microsoft Defender ATP for specific Linux distributions (in that case an E3-license is not sufficient), but those platforms are simply currently not a good fit in a Microsoft 365 solution. Especially when focusing on functionalities that are available within a Microsoft 365 E3 license.

The options

However, that doesn’t mean that there is completely no place for Chrome OS and the different Linux distributions in a Microsoft 365 solution. It will just not be the complete experience as on Windows, Android, macOS and iOS devices. Let’s have a look at the most common options that are available for those platforms, within the Microsoft 365 E3 license functionalities, and let’s go high-over through those options.

  1. Block access for unsupported platforms
  2. Provide access based on the location of the devices
  3. Provide limited access to SharePoint Online and Exchange Online
  4. Provide access via Windows Virtual Desktop
  5. Provide access via a Virtual Machine

Option 1 – Block access for unsupported platforms

When an organization has strict requirements regarding the management of the device and/or app that the user is using for accessing company apps and data (for example to limit the possibility of loosing data, or having company data on personal devices), the Chrome OS devices and the different Linux distributions can’t be part of the Microsoft 365 solution. In that case the best option might be to completely block access to company apps and data, by using Conditional Access. Even though Conditional Access doesn’t support those platforms, Conditional Access can be used to block those platforms. The idea is similar to what I’ve described here, which is to create a Conditional Access policy that will block access to all cloud apps and is assigned to all platforms with the exception of the platforms that the organization does want to allow. The main difference is that the UI changed a little bit over the last year.

This option will completely block access to company apps and data on Chrome OS devices and on the different Linux distributions (see Figure 1 for an example).

Option 2 – Provide access based on the location of the devices

When an organization has separately managed Chrome OS devices and/or different managed Linux distributions and can pinpoint those devices to a specific location, it can be an option to exclude those devices based on their location. The idea is similar to what I’ve described here, just the UI and experience changed over the years. This option could be an addition to the Conditional Access policy described in the first option. In this case there will be an exclusion for unsupported platforms coming from a specific location. The only thing that should be kept in mind is that it’s not possible to control which devices will actually be used by the user when accessing company apps and data on that specific location. We simply can’t differentiate between a separately managed Chrome OS device and a personal Chrome OS device from that specific location. That risk should be assessed.

This option will provide the user with full access to company apps and data on Chrome OS devices and on the different Linux distributions (see Figure 2 for an example).

Option 3 – Provide limited access to SharePoint Online and Exchange Online

When an organization is trying to find a balance between security and usability, it might be an option to allow a limited experience via the browser. That limited experience is only be available for Exchange Online and SharePoint Online and provides the user with the ability to at least perform some basic activities on company apps and data, without the major risk of loosing data or getting data on personal devices. This experience can be created across all platforms, whether those platforms are supported by the different Microsoft 365 components, or not. The idea is similar to what I’ve described here, and something similar is also applicable to Exchange Online. If needed the limited experience can be further limited to a true read only experience. In addition, it’s even possible to differentiate the behavior between SharePoint sites as explained here.

This option will provide the user with limited access to company apps and data on Chrome OS devices and on the different Linux distributions (see Figure 3 for an example).

Option 4 – Provide access via Windows Virtual Desktop

When an organization has strict requirements regarding the management of the device and/or app that the user is using for accessing company apps and data (for example to limit the possibility of loosing data), Windows Virtual Desktop (WVD) might also be an option on basically any platform. WVD is the exception when talking about cross-platform availability. The web client should work with any HTML5-capable browser and is officially supported on the default browsers of Chrome OS (Google Chrome) and the different Linux distributions (Mozilla Firefox). The good thing is that it’s possible to make sure that WVD is part of the Conditional Access policy, by either making sure WVD is hybrid Azure AD joined or by excluding WVD based on their location. Those are both valid options, when configured correctly, for making sure that it can be safely said that only WVD can access company apps and data. For basic account protection it’s still possible to use Conditional Access to require MFA on any platform that is used by the user for accessing WVD.

This option would provide the user with full access to company apps and data within WVD on Chrome OS devices and on the different Linux distributions (see Figure 4 for an example).

Option 5 – Provide access via a Virtual Machine

When an organization has many more advanced users, a last resort could also be to use a Virtual Machine (VM). That VM can exist on the host, can enroll into Microsoft Intune and can be compliant with the company policy. That would enable the user to access company apps and data, without the need for the administrator to create holes in the Conditional Access policy. The VM will be managed and secured in a similar way as any other physical device. This option is mainly applicable to the different Linux distributions.

My conclusion

Even though there are some unsupported platforms within most of the components of a Microsoft 365 solution, that doesn’t mean that an organization can’t use those platforms at all. I wouldn’t advise an organization to choose Chrome OS devices and/or different Linux distributions, when choosing for a Microsoft 365 solution, simply because of the currently limited support within a Microsoft 365 solution. However, when devices with those platforms are already within the organization, there are still options to somehow provide some support for those platforms. That’s the main point of this post. It’s just not a perfect story, yet.

7 thoughts on “Supporting the unsupported platforms”

  1. Umm, it pretty much does mean that effectively those platforms are unusable or much less usable in a Microsoft eco-system. I think if you need ChromeOS or Linux support, you should look elsewhere. MS doesn’t have a great track record of supporting Linux.

    Reply
  2. Thanks for the Blog, nice workaround to include or exclude “Other” devices like linux.

    We noticed Microsoft Windows 10 Surface Hub, Logitect SmartDocks and some application using exchange that also did not report device type. unfortunately was a bit hard to find because the “sign-in” log only has an filter ‘contains’ for Devices.

    But we managed to find all and exclude them from the BLOCK rule.

    Reply

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.