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.

How to install clients on Linux computers, when the Site Roles require HTTPS communication in ConfigMgr 2012

Linux_PKI_2About four years ago I did a post about installing the ConfigMgr client on a WORKGROUP computer, when the ConfigMgr Site is in Native Mode. On the certificate side of it, this post will have a lot of similarities with that post. Installing a ConfigMgr client on a Linux computer is a nice challenge, when the ConfigMgr site is configured to require HTTPS. I think I am not the only one working with ConfigMgr and only uses a little tiny bit of Linux. So to make this process for everyone a bit easier I wrote down these four steps for implementing the correct certificates and installing the ConfigMgr client on a Linux computer. Of course these same certificate configuration steps can also be used for WORKGROUP clients and separate forests (just keep in mind that in those cases also the root certificate is required).

Prerequisites

  1. A Microsoft public key infrastructure (PKI) has to be in place.
  2. A Linux client has to be available, including the content of the ConfigMgr Client for Linux. The latest version is available for download here: http://www.microsoft.com/en-us/download/details.aspx?id=39360 

Step 1. Create a Certificate Template for Client Authentication with exportable private key.

  1. Linux_PKI_3On the Certification Authority server, open the Certification Authority Console, right-click Certificate Templates, and click Manage to load the Certificates Templates console.
  2. Right-click the Workstation Authentication template and click Duplicate Template and the Properties of New Template dialog box will show.
  3. On the Compatibility tab, make sure the Certification Authority is set to Windows Server 2003 and the Certificate recipient is set to Windows XP / Server 2003.
  4. On the General tab, set the Template display name to ConfigMgr Client Certificate for Export.
  5. On the Request Handling tab, select Allow private key to be exported.
  6. On the Subject Name tab, select Supply in the request.
  7. Click OK to close the Properties of New Template dialog box and close the Certificates Template Console.
  8. In the Certification Authority Console, right-click Certificate Templates, click New, click Certificate Template to Issue, select ConfigMgr Client Certificate for Export and click OK.

Step 2. Request and Install the Client Certificate for the Linux client

  1. Linux_PKI_4On a Windows domain joined machine, open Notepad and copy and paste the following text into the file (replace <NetBiosName> with the name of the client/ server that has to use this certificate):

    [NewRequest]
    Subject = “CN=<NetBiosName>
    MachineKeySet = True
    Exportable = TRUE
    KeyLength = 2048
    [RequestAttributes]
    CertificateTemplate = ConfigMgrClientCertificateforExport

  2. Save the file as ConfigMgrClientCertificate.inf in a folder on the machine.
  3. Open a Command Prompt and navigate to the same folder as the saved file.
  4. Use the following command to create a certificate request: certreq –new ConfigMgrClientCertificate.inf ConfigMgrClientCertificate.req
  5. Use the following command to submit the certificate request: certreq –submit ConfigMgrClientCertificate.req ConfigMgrClientCertificate.cer
  6. In the Select Certification Authority dialog box, select the CA, and then click OK.
  7. Use the following command to accept the requested certificate: certreq –accept ConfigMgrClientCertificate.cer

Step 3. Export the client certificate for the Linux client

  1. Open the Certificates Console, right-click the certificate that is issued to <NetBiosName>, click All Tasks, and then click Export to launch the Certificate Export Wizard.
  2. On the Welcome page, click Next.
  3. On the Export Private Key page, select Yes, export the private key and click Next.
  4. On the Export File Format page, confirm that Personal Information Exchange – PKCS #12 (.PFX) is selected and click Next.
  5. On the Password page, specify a password and click Next.
  6. On the File to Export page, specify the path and name of the file and click Next.
  7. On the Summary page click Finish and click OK to close the confirmation popup.

Step 4. Install the ConfigMgr client on the Linux client

  1. On the Linux client, in my case CentOS 6.4, copy the exported certificate to the folder with ConfigMgr client installation files.
  2. Open a Terminal and navigate to the location of the ConfigMgr client installation files.
  3. Use the following, or a similar, command to install the ConfigMgr client:Linux_PKI_5
  4. This will result in the installation of the client and an imported and validated certificate.Linux_PKI_6

For a complete list of all client installation parameters, see: http://technet.microsoft.com/en-us/library/jj573939.aspx#BKMK_CmdLineInstallLnUClient

Result

The best place to look at the end result is, in this case, the ConfigMgr console. This will show information about the client, activity, edition and certificate.Linux_PKI_1