In the Admin console, you can configure device policies to restrict network connectivity under Device Management > Network > General Settings. This restriction can be done in two different ways:
Restrict devices to certain network interfaces. For example, restrict devices enrolled in a certain OU to connect only to Ethernet.
Restrict devices connecting to Wi-Fi to the set of managed Wi-Fi configurations. For example, restrict employees from connecting to a Wi-Fi hotspot running off their personal phones.
Note: This feature will only take effect on Chromebooks running Chrome version 49 or later.
As these policies are applied device-wide, they will apply to both managed and unmanaged users. They will also apply in different device modes like Public Sessions and Kiosks. In addition, these two policies will have some implications on your Chromebook deployment. This article will go through the full breadth of these implications.
Misconfiguration of these policies can lead to devices being starved of an Internet connection and hence of further policy delivery to rectify the situation. For example, if you configure a certain set of Wi-Fi configurations and restrict devices to connect only to them, and then (for example) switch the SSID of your network hardware, your users will not be able to connect to the new SSID and you will not be able to push new network policy to them since their devices are no longer connected to the Internet.
To ensure these policies do not cause major deployment errors, we do not apply the restrictions before user sessions start. This means the Chromebook sign-in screen will not enforce these restrictions. That way if the admin misconfigured the policy, a user can simply sign out, connect to any network from the sign-in screen, and sign back in to their session while connected to a valid network that allows them to download the amended policy.
To ensure a seamless experience in case of error, we recommend that you configure a valid device-wide network that the Chromebooks can automatically connect to on the sign-in screen. That way, in the case of a deployment error, users can sign out of their accounts and their devices will automatically connect to that configured device-wide network. A user would notice that the device cannot connect to the Internet, so that user would sign out, connect to the Internet (automatically), and then sign back in. This would relieve your organization of a range of support calls that are bound to be generated in case of misconfiguration.
Keeping the above caveat in mind, we recommend that you roll out these settings in a staged approach per organizational unit. That way, policy misconfiguration can be caught and fixed while the user base is still small.
Personal usage of corporate device
Since these policies are applied device-wide, your users might no longer be able to work with their corporate devices at home. This is because the devices might not be able to satisfy the policy restrictions outside the workplace. For example, users will not have the same Wi-Fi configurations at home as at work, or they might not have an Ethernet connection available if they want to use the device to work from a coffee shop.
Corporate usage of personal device
This applies in the converse situation as well: If network restrictions are obligatory for your managed accounts, then you will not be able to instruct your users to bring their own devices and use them at work. Since the policies apply to devices and not to users, users would still be able to sign in with their managed accounts to their personal devices where the network restrictions would not take effect, circumventing the restrictions you put in place for workplace compliance.