One use case for us, we have an open Wifi network named "School District Guests" that uses a captive portal login page once you connect to it. So if/when a student "accidentally" connects to that network, it pops up the login page but they don't know what to do from there.

This might be better as a separate request, but regarding your comment about connecting to phone hotspots... Rather than an SSID blacklist, I would love to see an option like "Do not allow disconnecting from managed networks if available" - So that when they're in the school, it will connect automatically and won't let them connect to anything else, but when they take it home the school network isn't there so they can connect to whatever they want.

Got it - I like this "Always force-connect to managed networks when available" option, I wonder how feasible it would be. pmarko: fyi, in case you have any insights.

I was just going to put in almost this exact request today.  We have the exact same request.

We want our managed Chromebooks to connect to a specific network only when in district.  When out of district, since these are 1:1 devices that students can take home, the students must be able to connect to their home networks.  Therefore, restricting the Chromebook to connect to only a certain SSID does not work - we need to be able to blacklist our networks we don't want them connecting to.

If you want to see a well-designed blacklisting ability (that has been there forever), look on Windows in GPO policies.  You can configure Network Permissions.  Each SSID can be set to either Allow or Deny and the SSID won't even show up as an available network on the device when it is blocked.  You can also set custom names on the profile - so if you have a network called School-Secured - it will show up as SCHOOL, for example.

Please consider implementing this.  Our students continually try to connect to our Guest or BYOD networks on their managed devices and this has gone on long enough.  Right now, we have to create profiles for each SSID and set them to not auto-connect - very painful and only a workaround - not a solution to this big problem that I am sure plagues many school districts.

We are in the same boat.  We broadcast two SSID's: 1) production network (WPA2-PSK, SSL decryption with Securly), and 2) BYOD network (open, no decryption).  We allow anyone to connect to the BYOD network to a basic connection to the internet, but it's much, much slower than the production network, many of our internal resources are blocked on the BYOD network, and it's filtered differently.  We want to blacklist that BYOD network on our Chromebooks so users always connect to the production network.  We do not want to restrict users to specific SSID's because they are allowed to take them home and connect them to any wifi network (they are filtered with Securly, a forced Chrome extension).

We did change one thing that helps keep Chromebooks on our production network... under Device management > Networks > Wi-Fi, I added our BYOD network, but I unchecked the option to Auto-Connect.  This means the user has to purposely change wifi networks to the BYOD network.  That's useful, but still not achieving my goal of blocking them from the BYOD network.

One idea I might try for now is to create a captive portal page on our BYOD network (something I've been needing to do anyway for users to agree to TOS), and add the URL of the captive portal page to the URL blacklist (https://support.google.com/chrome/a/answer/2657289?hl=en) for a certain group of users.  Then when they try to connect to the BYOD network, Chrome will display the "ERR_BLOCKED_BY_ADMINISTRATOR" message and they wouldn't be able to authenticate.

My coworker Matt also came up with a good idea... under Device management > Networks > Wi-Fi, add the BYOD network but manually configure a proxy that is either fake (i.e. a fake IP that just drops the connection), or a real proxy that forwards all traffic to a site saying they should switch back to the production network.

Both of those ideas are dirty workarounds in my opinion, and I would prefer to have an SSID blacklist in google admin.  Ideally, this would be a policy we can apply to OU's, and we would be able to blacklist names of SSID's.  If the user connects to it, they would get something like this (attached pic).

Deleted: example.png 21.0 KB

	example.png 21.0 KB View Download

agreed.  this is a feature we would certainly like as well.  As mentioned, there are some "dirty workarounds" but we would really like some official admin settings to limit specifc SSID access when a production school network is within range and available.

In complete agreement!

Yes this is needed. I have the same issue here. Even though I have our student wifi pushed to our Chromebooks somehow they end up trying to connect to the guest wifi at random times.

I tried two different ideas to block access via google admin console that didn't work:

1) Moved a chromebook to test OU.  Under Device Management > Networks > Wi-Fi, added the BYOD network with a fake proxy server.  I hoped this would force the chromebook to try and pass all traffic to the fake proxy upon connecting to the BYOD ssid and just fail to connect to anything on the internet, but it connected to the internet just fine.  I double checked in chrome://policy to make sure the policy was pushed.

2) Moved a chromebook to test OU.  Under Device Management > Networks > Wi-Fi, added the BYOD network but with a bogus WPA2 PSK.  Since the network is wide open, the Chromebook ignored the WPA2 PSK and connected.

My third idea of creating a captive portal page for the BYOD network, and then blocking the URL of the captive portal page in the URL blacklist, will probably work but it's not something I have time to work on right now (yay SOL testing season).

If this policy is developed by google, it should not apply the restrictions before user sessions start.  It should only be applied after the user logs in. 
 For the reasons specified in the "Policy misconfiguration" section of https://support.google.com/chrome/a/answer/6326250?hl=en

It makes sense to me to make it user-based as well.  Being able to hop on a Guest / BYOD network makes enrollment easy - but it isn't desirable once the user signs in to have those networks available.

Agreed, a user policy makes the most sense.

I agree that this is needed. Our student Chromebooks are set to join our secure wi-fi SSID, but my wayward students end up trying to connect to the guest wifi because our web filter assigns a different level of internet access to devices on the guest VLAN. While I could block access from the guest VLAN to everything that I block on the student VLAN, my guests in the district are not going to appreciate that when they come on campus and join the wi-fi.

Being able to set Chromebooks to ignore open, guest networks is needed.

Is there a PM on this and a design doc?

I would like to at least consider options other than adding an "AllowToConnect" option to WiFi networks. We have to balance the desire for new features with the cost of maintaining each of these properties.

I would prefer to just allow policy to enforce "AutoConnect" = false. From the discussion that solution may not be perfect, but it seems that it would address most scenarios without requiring an additional property to support.

Found the design document:

https://docs.google.com/document/d/1DW8CXY-zNuivMxE3jZVbZoMK323utJydccVBek1o6sM/edit

I will chime in again on this to reiterate what we need this feature to accomplish.

If we have 3 networks:
School-Guest
School-BYOD
School-Secure

And we want our managed devices to only connect to School-Secure, we need it so that our devices don't even see the option of connecting to School-Guest or School-BYOD.  Anything else and it isn't even worth implementing.  We can already do Auto-Connect=False, but that doesn't solve the problem.  Ideally, the interface should allow a Permission of Allow or Deny to be set for each SSID.  When set to Allow, it will show the network on the list.  When set to Deny, it will hide it.

Please see the attached screenshot from Microsoft GPO policies.  They have had this feature forever and it works great.  On the wireless profiles creation - it could have the top option say: Permission - Allow / Deny - then only show the settings if you have it set to Allow.  Microsoft chose to split Permissions from the profiles themselves, but either way could work.

Deleted: screenshot.png 17.3 KB

	screenshot.png 17.3 KB View Download

stevenjb: no explicit PM on this but happy to answer your questions about it. Use cases are pretty well called out on this bug. If you have an option in mind that can explicitly prevent a user from connecting to a specific network while still letting them connect to arbitrary networks at home, happy to discuss further.

I added my comments to the DD, which is mostly what I was looking for. I got hit with this all at once and in reverse order, CL then issue, then DD :)

@atwilson: Got added to this very late. Are we implementing a "dynamic policy enforcement" here where the policy being applied changes based on whether the client sees network X (the school's secure network) in the environment or not? 

scan shows network X: change policy to "only allow connecting to X and nothing else"

scan does not show network X: change policy to "allow connecting to anything" ?

If this is the proposed solution, ideally the policy change should happen at the policy level, and not at the shill level. 
i.e. the bit about "whether client is allowed to connect to anything" should be stored in the policy cache and not shill. 

Ping - any thoughts on comment #24. 
Please lets not push any CLs through without resolving the intent here - there are side-effects to this approach that will make debugging harder for the platform team. 

In my opinion the option should be applied to device OU's.  A good place to add it would be under Device management > Network > Wi-Fi, choose an OU, and then click 'Add Wi-Fi", add the SSID, but you have an option for "Block access to this SSID" right under where the option for "Automatically connect" is.  Then if a user tries to connect to an SSID with that name, they get a message like the one I attached in comment #7, or something similar. 

Follow up from my comment #26: If an admin checks the "Block access to this SSID" it should automatically choose the 'restrict to chromebooks' and 'apply network by device' options

Regardless of how it's implemented, we need the ability to control this for user-level networks ultimately.

The only time we ever want our managed Chromebooks connecting to something other than our 802.1x network is when they are being enrolled initially.  Otherwise, they always are supposed to connect to our 802.1x SSID - which is deployed at the user-level (but also the device-level since we use a shared credential at the login screen so we can disable decryption and allow QUIC).
This unfortunately brings up another issue I have mentioned in the past.  If Google continues to deploy user-level networks to non-managed computers, a setting to restrict SSIDs might cause undesirable behavior for devices that we don't own.

For example, a student bringing in a BYOD Chromebook - we want them to connect to our BYOD network ultimately.  Currently, if they sign in with their school credentials, they automatically get connected to whatever network we have in the Admin console at the user level (which is undesirable considering we don't own that device).  If we're permitted to restrict connecting to that SSID at the user level, but we're unable to stop the network from going to an unmanaged device, that will create a problem.

So - in other words - if you're going to implement this at the device level - do it only at the device level and allow the setting to propagate only to managed systems at both the user and device level.  If you permit it at the user level, we need the ability to stop networks that are at the user level from deploying to non-managed devices.

Excellent feedback from comment #28.  It seems my ideas from comments #26 and #27 would meet those needs since they are device policies and would only apply to chromebooks enrolled in the domain.  

OK, interesting points, and you make a good argument around exposing this as a device policy instead of/in addition to a user policy, to deal with BYOD cases. I'll discuss with the developers and PM about how best to address this.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e6e3030d9a5f2114fb63e6d691acfbed366fcc87

commit e6e3030d9a5f2114fb63e6d691acfbed366fcc87
Author: Alexander Hendrich <hendrich@chromium.org>
Date: Wed Jun 20 15:30:05 2018

Blacklist WiFi SSIDs through ONC policy

This CL adds a list attribute 'BlacklistedHexSSIDs' to ONC's global
configuration. This attribute can be used to block connections to
certain WiFi SSIDs. Current connections to blacklisted networks are
disconnected, once the policy is applied.
This policy is only enforced in Chrome. However, by disabling
auto-connect for all blacklisted networks, we can prevent Shill from
re-connecting to those networks while searching for the best network to
connect.

DesignDoc: http://go/cros-blacklist-ssids

Bug:  837205 
Change-Id: I1d80929a00dd042db7aef877d663febc3f170d05
Reviewed-on: https://chromium-review.googlesource.com/1091053
Commit-Queue: Alexander Hendrich <hendrich@chromium.org>
Reviewed-by: Cait Phillips <caitkp@chromium.org>
Reviewed-by: Steven Bennetts <stevenjb@chromium.org>
Reviewed-by: Maksim Ivanov <emaxx@chromium.org>
Cr-Commit-Position: refs/heads/master@{#568850}
[modify] https://crrev.com/e6e3030d9a5f2114fb63e6d691acfbed366fcc87/chromeos/network/auto_connect_handler.cc
[modify] https://crrev.com/e6e3030d9a5f2114fb63e6d691acfbed366fcc87/chromeos/network/auto_connect_handler.h
[modify] https://crrev.com/e6e3030d9a5f2114fb63e6d691acfbed366fcc87/chromeos/network/auto_connect_handler_unittest.cc
[modify] https://crrev.com/e6e3030d9a5f2114fb63e6d691acfbed366fcc87/chromeos/network/managed_network_configuration_handler.h
[modify] https://crrev.com/e6e3030d9a5f2114fb63e6d691acfbed366fcc87/chromeos/network/managed_network_configuration_handler_impl.cc
[modify] https://crrev.com/e6e3030d9a5f2114fb63e6d691acfbed366fcc87/chromeos/network/managed_network_configuration_handler_impl.h
[modify] https://crrev.com/e6e3030d9a5f2114fb63e6d691acfbed366fcc87/chromeos/network/mock_managed_network_configuration_handler.h
[modify] https://crrev.com/e6e3030d9a5f2114fb63e6d691acfbed366fcc87/chromeos/network/network_connection_handler.cc
[modify] https://crrev.com/e6e3030d9a5f2114fb63e6d691acfbed366fcc87/chromeos/network/network_connection_handler.h
[modify] https://crrev.com/e6e3030d9a5f2114fb63e6d691acfbed366fcc87/chromeos/network/network_connection_handler_impl.cc
[modify] https://crrev.com/e6e3030d9a5f2114fb63e6d691acfbed366fcc87/chromeos/network/network_connection_handler_impl.h
[modify] https://crrev.com/e6e3030d9a5f2114fb63e6d691acfbed366fcc87/chromeos/network/network_connection_handler_impl_unittest.cc
[modify] https://crrev.com/e6e3030d9a5f2114fb63e6d691acfbed366fcc87/chromeos/network/onc/onc_signature.cc
[modify] https://crrev.com/e6e3030d9a5f2114fb63e6d691acfbed366fcc87/chromeos/network/onc/onc_validator.cc
[modify] https://crrev.com/e6e3030d9a5f2114fb63e6d691acfbed366fcc87/chromeos/network/onc/onc_validator.h
[modify] https://crrev.com/e6e3030d9a5f2114fb63e6d691acfbed366fcc87/components/onc/onc_constants.cc
[modify] https://crrev.com/e6e3030d9a5f2114fb63e6d691acfbed366fcc87/components/onc/onc_constants.h
[modify] https://crrev.com/e6e3030d9a5f2114fb63e6d691acfbed366fcc87/components/sync_wifi/wifi_config_delegate_chromeos_unittest.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e0588bf3fcb2d38b6957d06c0cb9d423b2d87eb1

commit e0588bf3fcb2d38b6957d06c0cb9d423b2d87eb1
Author: Alexander Hendrich <hendrich@chromium.org>
Date: Thu Jun 21 08:47:17 2018

Blacklist WiFi SSIDs through ONC policy [UI]

This CL implements the UI changes for blacklisted WiFi networks.

DesignDoc: http://go/cros-blacklist-ssids

Bug:  837205 
Cq-Include-Trybots: luci.chromium.try:closure_compilation
Change-Id: I2e830c5d25a756b7e20fcc9b75f79e8d24f7c6f3
Reviewed-on: https://chromium-review.googlesource.com/1101204
Commit-Queue: Alexander Hendrich <hendrich@chromium.org>
Reviewed-by: Steven Bennetts <stevenjb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#569193}
[modify] https://crrev.com/e0588bf3fcb2d38b6957d06c0cb9d423b2d87eb1/ash/ash_strings.grd
[modify] https://crrev.com/e0588bf3fcb2d38b6957d06c0cb9d423b2d87eb1/ash/system/network/network_list.cc
[modify] https://crrev.com/e0588bf3fcb2d38b6957d06c0cb9d423b2d87eb1/ash/system/network/network_list.h
[modify] https://crrev.com/e0588bf3fcb2d38b6957d06c0cb9d423b2d87eb1/chrome/browser/resources/settings/internet_page/internet_detail_page.html
[modify] https://crrev.com/e0588bf3fcb2d38b6957d06c0cb9d423b2d87eb1/chrome/browser/resources/settings/internet_page/internet_detail_page.js
[modify] https://crrev.com/e0588bf3fcb2d38b6957d06c0cb9d423b2d87eb1/chrome/browser/resources/settings/internet_page/internet_subpage.js
[modify] https://crrev.com/e0588bf3fcb2d38b6957d06c0cb9d423b2d87eb1/extensions/common/api/networking_onc.idl
[modify] https://crrev.com/e0588bf3fcb2d38b6957d06c0cb9d423b2d87eb1/extensions/common/api/networking_private.idl
[modify] https://crrev.com/e0588bf3fcb2d38b6957d06c0cb9d423b2d87eb1/third_party/closure_compiler/externs/networking_private.js

The client implementation is finished now.
We added a list of 'BlacklistedHexSSIDs' into ONC's global configuration (device policy only, but only enforced in user sessions).

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

Since this is now marked as fixed, when will this feature be exposed in the Google console?  if it's already there, how do we access it?  If it isn't yet available, when should we expect to see it?

It'll be a long ways off - probably at least another 6 months.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/36435cb6d3e7e81cc696438d93bebe6b73d6c770

commit 36435cb6d3e7e81cc696438d93bebe6b73d6c770
Author: Alexander Hendrich <hendrich@chromium.org>
Date: Tue Sep 25 17:18:47 2018

Update ONC documentation (GlobelNetworkConfiguration & Recommended)

This CL updates the ONC documentation and adds a section + examples for
GlobalNetworkConfiguration policies
(AllowOnlyPolicyNetworksToAutoconnect, AllowOnlyPolicyNetworksToConnect,
AllowOnlyPolicyNetworksToConnectIfAvailable, BlacklistedHexSSIDs,
DisableNetworkTypes) and recommended values.

Bug:  426390 ,  837205 ,  280146 ,  208378 ,  848719 
Change-Id: I9b573f4dd8533b8d7fe83da2e7e5e45e2eb18573
Reviewed-on: https://chromium-review.googlesource.com/1238584
Reviewed-by: Steven Bennetts <stevenjb@chromium.org>
Commit-Queue: Alexander Hendrich <hendrich@chromium.org>
Cr-Commit-Position: refs/heads/master@{#593977}
[modify] https://crrev.com/36435cb6d3e7e81cc696438d93bebe6b73d6c770/components/onc/docs/onc_spec.md