A first look at the Chrome Cloud managed browser.
In a previous series of posts we looked at how you could manage Chrome and other Google products such as File Stream using Microsoft InTune in a school that has no servers.
At Next 19 Google announced a cloud managed browser capability which makes the whole process much simpler. The two approaches are not mutually exclusive and using both together can bring dividends to the network admin.
In this post we’ll take a look at what the new managed browser feature brings to the table, show how the technology integrates with InTune and then follow up with a more in-depth look at the G Suite management console in a later post.
The introduction of a managed Chrome browser is a big event for the Google administrator.
Up until now the G Suite organizational structure could only contain two types of object, a user or a chromebook. Now it has a third - a instance of Chrome running on a Windows, MacOS or Linux platform The Chrome browser has finally taken its rightful place as a fully managed object within the console.
In the past it was possible to manage Chrome on the desktop but it always involved a third party system such as Microsoft Active Directory, Managed Preferences on Mac or, as we have seen, an MDM like InTune.
This approach has two major weaknesses.
First, there isn’t a unified policy set for the Chrome browser. For organisations adopting Chromebooks the user environment is governed through the G Suite admin console while the Windows/MacOS Chrome desktop experience is controlled through an entirely different mechanism.
Second, there isn’t a single reporting console for Chrome. The G Suite admin console can access Chromebook information but it’s completely blind to Chrome browser metrics. Tasks like examining what extensions are installed or reporting on the versions of Chrome deployed across various platforms was simply not possible.
Second, there isn’t a single reporting console for Chrome. The G Suite admin console can access Chromebook information but it’s completely blind to Chrome browser metrics. Tasks like examining what extensions are installed or reporting on the versions of Chrome deployed across various platforms was simply not possible.
For schools this might be an irritation but for enterprise it can be a deal breaker so Google have solved the problem in a pretty elegant fashion. There are no licencing implications and the feature is free across all recent G Suite offerings. It’s also very easy to get started and there are only a couple of prerequisites.
- The admin console must have the feature pushed out. More than likely you already have the update. If your Chrome management tab reads User and browser instead of just User and you can see the new group icon shown above you’re good to go.
- You must have Chrome V73 or later running on Windows, Mac and Linux computers. Android and iOS are not currently supported.
Preparing the Console.
Managed Chrome needs to be turned ON as it’s OFF by default. It’s important to realise that none of these actions will affect Chromebooks. User-level policies apply to Chrome devices even if Managed Chrome is turned off. Also you can turn this on at the root without any immediate effect as the browser has to be enrolled before anything happens.
Note: If you’d like to play around first, create an OU called “Managed Browsers” and set it here.
From the G Suite admin console Home page, go to Device management and then Chrome management. Click on User and browser settings.
Go to the Chrome Management for Signed-in Users section and change the setting to Apply all user policies when users sign into Chrome.
This policy is little misleading. It should really read Chrome Management for Signed-in users and managed browsers. As we'll see quite a few of the console policies descriptions need to be updated to reflect the new responsibility.
Preparing Desktop Chrome.
Just like Chromebooks, desktop browsers have to be enrolled into G Suite and to do that you need to create an enrollment key.
From the Admin console home page, go to Device management and select Managed Browsers.
At the bottom, click + to generate an enrollment token.
A couple of important points to note about the key.
It’s only useful at the point of enrollment and has no function after the event. Once the key is presented to the browser (we’ll come to that later) and the browser taken under management the key can be deleted or updated without affecting devices already enrolled. In some respect it works like the joiners code in Google Classroom.
The generated key is specific to the OU level. Any chromebook enrolled with this key will be placed at the same point in the tree and take policy from that level. In this case the analogy would be the ‘follow the user’ feature for chromebook enrollment.
Note: If you are just testing at this stage create the key for the new “Managed Browser” OU and set your policies here.
A browser under management will display a new information tag at the base of the About dialog.
Managed Chrome Browser Policies.
For organisations running Chromebooks it’s worth noting that none of the policies under the Device section have any bearing on Managed Chrome. Device policies are strictly limited to Chromebooks, no red line has been crossed. All policies relating to Managed Chrome are to be found in the User and browser section, hence the change of name.
So how does Managed Chrome differ from a simple synchronised Chrome user session ?
Put simply, once enrolled a user policy can be applied to the Chrome browser without the user having to authenticate with Google. The policies are set in the Chrome User and Browser OU that the browser object lives in.
If user attempts to access a resource such as GMail they will be presented with a logon box in the normal way but at this point the browser is already under cloud user policy control so you’re able define things such as valid logon domains - but not using the policy you might expect.
.
The domain filter for Chromebook authentication is set in the Device policy but as we know Device policies have nothing to do with managed browsers. Therefore the policy you need to set is User and Browser - Sign-in Within the Browser in the OU that the managed Chrome browser resides in.
Using the settings shown above the user will only be able to authenticate using a stmichaels.org.uk account, the value being controlled by a Google cloud policy and not local platform policy.
Note: Clearly the description of this policy isn’t entirely accurate and neither is the little light bulb which says the policy only applies to Chrome devices. Some housekeeping is required on the console to bring everything into line.
Policy Precedence.
You now have three policy sets for the Chrome user experience. Using Google's own terminology they are ;
- Platform Policy - These are the old policies pushed out locally through GPO or MDM.
- Cloud Policy - Managed Browser. User and Browser set at the browser OU.
- Cloud Policy - Authenticated User. User and Browser set at the user OU
So what happens if you set the same policy in all three areas - which one applies ?
The rule is (pretty) simple.
The Cloud Policy - Managed Browser policy will always apply except for two situations.
- A policy set at the Platform level will trump any Cloud Policy.
- Any policy explicitly set at the User level and not explicitly set at Managed Browser level will be applied.
The browser takes the full user policy set from the Cloud Policy - Managed Browser OU with the understanding that any Local Platform Policies will overwrite individual settings.
When a user logs onto Chrome any policies that are locally applied on the user OU will override policies inherited at the Managed Browser level so long as they don’t clash with a Local Platform Policy which always wins out.
If a Cloud and Managed Browser policy is Locally applied in both areas the Managed Browser version is used. At no stage are list based policies merged.
You can clearly see the effect of the policy interactions if you run chrome://policy
First thing to note is the enrollment token is now shown as part of the machine policy. The only platform policy is the one that applies the Cloud Management Enrollment Key, all the others are set directly from the cloud from the User and browser policy of the OU that holds the browser object.
The only exception is one policy that has come down as part of the user sync process because it’s set as ‘Locally applied’ in the user OU but only ‘Inherited’ in browser OU and so it has precedence.
Enrolling a Chrome browser.
As mentioned earlier enrolling a Chrome browser is very straightforward - you just need to present the enrollment key either as a platform policy or through the execution of a .reg file.
In our serverless school the platform policy will be delivered by InTune so let’s see how easy this is.
Note: If need you need a refresher on using InTune to push policies to Chrome please refer to the earlier posts.
Managing Chrome on Windows is now reduced to the deployment of a single platform policy which tells Chrome to look to your Google organization for all other settings.
In this case the OMA-URI value is;
./Device/Vendor/MSFT/Policy/Config/Chrome~Policy~googlechrome/CloudManagementEnrollmentToken
with the value set to ;
<enabled/> <data id="CloudManagementEnrollmentToken" value="1f5e6ab4-3ebe-4e0c-b959-86a3eeb4e0c"/>
Obviously you need you insert your own value for the Enrollment Token but after that you can manage Chrome using G Suite using the same policy set that controls Chromebooks.
Now you have Chrome on a Windows 10 desktop, fully managed from the cloud using an unified policy set within G Suite. Cool or what!
Next we’ll take a closer look at the features of the admin console that relate to managed browsers and see how the story gets even better for the serverless school.
Addendum
Taking feedback from other early users (Kim Nilsson and Roger Nixon) I've checked back on the policy application logic and there's one point that needs clarifying.
As described the process does indeed 'loopback' on the user policy looking for the Locally Applied status but only if the policy for the User OU has
Chrome Management for Signed in Users set to Apply all user policies when users sign into Chrome.
This has to be set at the browser and user account OU. If not you only ever see browser policies.
>>> Managed Chrome from the Cloud (p2)
