EAP-TTLS password carrying over from device policy to user network policy; duplicate ssid's |
||||
Issue description
Version: r51
OS: ChromeOS
Description:
- Enterprise customer is configuring EAP-TTLS network policy one for user -and- one device; Both policies have the -same- SSID's.
- Device policy contains hardcoded username/password
- User policy contains ${LOGIN_ID}, and no password.
The default behavior with duplicate SSID's is if the user is logged in and receives both policies (user and device) containing a config for the same SSID and same security type, only the config from user policy should be visible/usable.
Customer is reporting that the user network is pre-filled with the password from the device network.
Video and images of network policy found at the link below:
https://drive.google.com/open?id=0B6fESMmJITTNeDM0VVJQbTItNzg
What steps will reproduce the problem?
1) configure EAP-TTLS network policy, one for user -and- one device.
2) setup both policies w/ the same SSID.
4) device policy w/ hardcoded username/password
5) user policy w/ ${LOGIN_ID}, and no password.
6) Log in to device and check network.
7) (User) device policy is pre-filled w/ password and does not auto connect.
What is the expected output?
No password in user network policy
What do you see instead?
Password pre-filled in (user) network policy
Video and images of network policy found at the link below:
https://drive.google.com/open?id=0B6fESMmJITTNeDM0VVJQbTItNzg
,
Jul 12 2016
If I understand the issue description correctly, the only reason why it's suspected that the password is carrying over is the asterisks shown in the passphrase field, is that correct? Then I'm wondering if it could be that the UI is a bit misleading here and shows the asterisks despite that the password is unset. Looking at the code in the WifiConfigView::InitFromProperties method, seems that it would display the fake password in case of EAP-TTLS method regardless of whether the password was actually set. But I may be missing something. Steven, could you please comment on this?
,
Jul 12 2016
That is likely correct, the UI is probably misleading here. We never send the password from Shill -> Chrome, and we don't necessarily know whether or not it is set in Shill. It's probably worth confirming that the user can not connect without providing the correct password. Assuming that is the case, this falls into the category of "minor UI improvements that we would like to make when we convert WifiConfigView to WebUI" (i.e. integrate with Settings UI).
,
Jul 12 2016
Just confirmed with the user, they are not able to connect without providing the correct password. That only happens with the SSID are the same.
He also said it would be interesting 2 things
1. If the password is wrong, pops up for the user to add the correct password
2. Have a variable like ${LOGIN_ID} to send the password
,
Jul 13 2016
Please follow Issue 386606 for #2. This is planned for upcoming milestones. #1 I believe already works today.
,
Jul 18 2016
,
Dec 7
Hello! This bug is receiving this notice because there has been no acknowledgment of its existence in quite a bit of time - If you are currently working on this bug, please provide an update. - If you are currently affected by this bug, please update with your current symptoms and relevant logs. If there has been no updates provided by EOD Wednesday, 12/12/18 (5pm EST), this bug will be archived and can be re-opened at any time deemed necessary. Thank you!
,
Dec 13
Due to lack of action this bug has been Archived. If work is still being done on this issue or you are still experiencing this issue please feel free to re-open with the appropriate information. |
||||
►
Sign in to add a comment |
||||
Comment 1 by sheriffbot@chromium.org
, Jul 8 2016