Assigned to Naveen for prioritization.

This requirement is already taken care by the Network setting's Device Policy.

When adding a network designated to be connected only by managed device, select Apply network "by device" instead of the default "by user".  Remove the existing network configured for "by user".  Result is only a managed device can connect to the internal network while an unmanaged device cannot.

Please respond if this answers your need.

Device policy definitely is a way to prevent a network from going to an unmanaged device; however, it is not practical for us to use only a device policy for the reason I will explain below.

Please consider this situation:
1)  A device-level network is deployed.  This network has a static username/password and decryption is disabled on our firewall.  QUIC protocol is also allowed.
2)  When users sign in, we need to do decryption - so we define a user-level network.  This network is 802.1x and will ultimately use the Google user's username and password for authentication.  We're currently using SAML because 802.1x is still broken with using variables for the username and password.  This must be deployed at the user level so we can identify who the user is on the device.

This design works fine for our devices.  The problem is on devices that we do not own (unmanaged devices).  We need to be able to restrict this user-level network from deploying to these devices.  Currently, a user will have their own device - they connect to our BYOD or Guest network and then they sign in with a managed user account.  Because we have the user network deployed, the device ends up on our ntework that is intended only for our internal devices - not BYOD or Guest devices.  No other device does this.  These devices need to stay as BYOD or Guest as intended.

Think about this situation too.  Because this is deployed at the user level - we are also deploying a certificate to a device that we do not own.  This means we can do decryption on that device.  Our policy is to not decrypt personal devices.  Google makes it impossible for us to exclude these devices.  We only want our devices on our internal network - not someone's personal device.  This needs to be fixed.

Here is another scenario where this setup would be very undesirable.  Let's say an organization allows Chromebooks to print and/or access file shares on their internal network.  The gateway to that internal network is the network credential provided by the user-level network policy.  A company is only going to want to allow a device that they actually have control over to access these resources.  Under the present design, anyone can gain access to that secured network by simply signing in with a Google credential from that domain on their own device.  That is clearly not desirable behavior.  Due to this design flaw, we have our Chrome network highly segmented from the rest of our network and will never open it up further unless this can be fixed.

We also deploy a management tool to our Chromebooks that allow us to watch screens on those devices.  Because these non-managed Chromebooks are connecting to our managed netowrk - they end up connecting to our server for screen sharing.  We should not be able to see devices that we do not own.  Our users have an expectation of privacy when they bring in their own device and we cannot provide for that with this design.

Please let me know if you require any further details.  Also, I would be happy to get some other IT admins from schools on this post to echo my sentiments.  I'm sure I'm not the only one that feels this way about this issue.  I honestly couldn't believe it the first time I signed in with a district credential on a non-district Chromebook and it auto-connected to our network - not cool at all.

naveenv@ please look into this. Thanks!

Now that 802.1x is finally fixed on M68, this is the next most logical thing to tackle.  While there are likely some users who want network policies to go to managed users on unmanaged devices, I would imagine that anyone using a BYOD setup would much prefer that devices they do not own never end up on a network that is reserved for internally-managed devices.
By not being able to restrict this, we are also put in a very awkward situation.  Users are not expecting to have encryption enabled on their BYOD devices and we have no way to prevent this currently because of this policy oversight.
Also, until Google can fix the DHCP issues we have been struggling with since December, this is even more important.  For our devices that we own, I simply created Static DHCP leases.  I am unable to do this for BYOD devices and it's very annoying to have to keep deleting duplicated DHCP leases from our table for devices that I can't create Static DHCP for.
Please update on the status of this request.  If this can be fixed, this might be the first year that I don't have major complaints about Chromebooks on our network (which has pretty much been since day 1 of implementation because of the 802.1x issues).

This bug has an owner, thus, it's been triaged. Changing status to "assigned".