Issue metadata
Sign in to add a comment
|
802.1x network deployed to unmanaged device results in failed connection attempts
Reported by
defo...@kmsd.edu,
Apr 25 2018
|
||||||||||||||||||||||||
Issue description
UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36
Steps to reproduce the problem:
1. Create a wireless policy with the variables ${LOGIN_ID} and ${PASSWORD} and deploy it at the user level
2. Sign in with managed user on a non-managed Chromebook
3. Wireless profile will deploy, but will fail to connect
What is the expected behavior?
The expected behavior is that either the policy will be filtered from deploying to a non-managed device because it cannot function or the password will be correctly passed so the connection will succeed.
What went wrong?
Currently, since the password is not passed, the Chromebook ends up hammering the network defined in the profile with invalid connection attempts because the password is not correct. This means the user has to manually connect to another SSID and they might get blacklisted from the network for too many invalid connection attempts.
Did this work before? No
Chrome version: 66.0.3359.43 Channel: beta
OS Version: 66.0.3359.43
Flash Version:
This issue is related to 386606, but is a new problem since 386606 has been implemented. The decision was made to not allow credentials to pass on a non-managed Chromebook and the result is that unmanaged systems now fail to connect completely because they have an incorrect password. Ideally, we should able to restrict this network from flowing to machines that are not managed by us. From a security standpoint, machines that we do not own should never get policies that we enforce on machines that we do own.
,
Apr 27 2018
David/May - I think maybe this is already covered by crbug.com/386606 , but not sure.
,
Apr 27 2018
This is definitely related to 386606, but 386606 as it was originally requested has been addressed. This is a new issue that stems from how 386606 was implemented. Ultimately, we need a setting to exclude policies on managed users from going to unmanaged devices or you need to fix it so that credentials can pass whether or not a device is managed. As it stands now, any unmanaged devices signing into a managed account will result in the problem shown above - credential spam against our authentication server. Thank you.
,
May 1 2018
We will fix this issue by applying this setting to user sessions regardless of the enrolled state of the device. defouwv@kmsd.edu, my understanding is that this would address your problem. Your ask was basically "support this on unenrolled devices or if you don't want to, then fail gracefully so that users are not confused by different behavior across machines". If I'm not reading it properly, please re-open. |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by rogerta@chromium.org
, Apr 26 2018Owner: atwilson@chromium.org
Status: Available (was: Unconfirmed)