Issue metadata
Sign in to add a comment
|
Enterprise user does not connect with configured authentication. |
||||||||||||||||||||||
Issue descriptionChrome Version: <From about:version: Google Chrome 68.0.3433.0> Chrome OS Version: <From about:version: Platform 10068.0.0> Chrome OS Platform: <Coral> Network info: <WiFi- Enterprise> Please specify Cr-* of the system to which this bug/feature applies (add the label below). Steps To Reproduce: (1) Connect to an 802.1x network on the login screen with EAP-PEAP. Also, make sure we have the same network SSID configured for the enterprise user with different EAP security credentials (EAP-TLS in my case). (2) Log in as an enterprise user. Expected Result: The network should disconnect and try to connect using the EAP-TLS security configured for the enterprise user. Actual Result: The device does not disconnect and shows incorrect network information on the chrome://settings network info page. How frequently does this problem reproduce? (Always, sometimes, hard to reproduce?) Always. What is the impact to the user, and is there a workaround? If so, what is it? Please provide any additional information below. Attach a screen shot or log if possible. 2018-05-18T02:57:19.257093-07:00 INFO shill[1521]: [INFO:supplicant_eap_state_handler.cc(35)] EAP: accepted method PEAP 2018-05-18T12:05:46.510387-07:00 INFO shill[1521]: [INFO:supplicant_eap_state_handler.cc(35)] EAP: accepted method PEAP 2018-05-18T12:19:23.237482-07:00 INFO shill[1521]: [INFO:supplicant_eap_state_handler.cc(35)] EAP: accepted method PEAP FEEDBACK REPORT https://listnr.corp.google.com/report/85453728100 LOCAL LOGS: Attached. Configured policy for the enterprise user { "GUID": "{b83beb2b-495a-4b44-86ff-97b6018a99a7}", "Name": "EAP-TLS- Enterprise-Temporary (Other being used for dynamic WEP)", "ProxySettings": { "Type": "Direct" }, "Type": "WiFi", "WiFi": { "AutoConnect": false, "EAP": { "ClientCertPattern": { "EnrollmentURI": [ "http://www.radius.com/certs/download.php" ], "Issuer": { "CommonName": "radius-ca", "Organization": "Google", "OrganizationalUnit": "ChromeOS" }, "Subject": { "CommonName": "radius-client", "Organization": "Google", "OrganizationalUnit": "ChromeOS" } }, "ClientCertType": "Pattern", "Identity": "CrOS", "Outer": "EAP-TLS", "Recommended": [ "AnonymousIdentity", "Identity", "Password" ], "SaveCredentials": true, "ServerCARef": "{ec4cb0aa-25a4-4e7b-9e6f-b71def059de0}", "UseSystemCAs": true }, "HiddenSSID": false, "SSID": "CrOS_WPA2_LinksysE3000N_5GHz", "Security": "WPA-EAP" } Will check and update if R67 and R66 see this issue. For graphics-related bugs, please copy/paste the contents of the about:GPU page at the end of this report.
,
May 18 2018
I wouldn't expect the device to automatically reconnect to the same network just because the configuration has changed. >>IIUC, After login, the enterprise user should connect with authentication configured by the administrator. The other major issue is the device connect with PEAP authentication, but the OS UI shows EAP-TLS as the authentication protocol.Also, this happens if there are no known networks it can switch too. +bartfab
,
May 19 2018
This is reproducible on R67-10575.40.0 and R66-10452.96.0
,
May 23 2018
,
Sep 13
This is reproducible on Eve M69-10895.56.0
,
Sep 13
pmarko@ - Could this be related to issue 787602 ?
,
Sep 14
Re Comment #6: No, that should be unrelated (also because this repros back to M-66). This looks superficially similar to bug 873775 - Alex, could you take a look if it is indeed similar when you have a minute as I'm effectively OOO? Thanks!
,
Sep 14
Yes, this looks very similar ("Identity" from policy is only recommended and CrOS therefore uses the value entered on the login screen instead).
I already filed a DMServer bug on buganzzer (https://buganizer.corp.google.com/issues/115610576), which should also fix this bug report here.
,
Sep 14
,
Dec 6
I can replicate this issue on M72 Sona. The issue always happens after adding a new enterprise user other times it is not always reproducible. Re-opening this issue. https://listnr.corp.google.com/report/85830555370
,
Dec 11
@aashutoshk What policy did you use to verify this? Did you also have the recommended fields (especially the "Identity" field)? "Recommended": [ "AnonymousIdentity", "Identity", "Password" ] If so, please try again without the "Identity" field in the "Recommended" list (this was fixed server-side).
,
Dec 14
,
Dec 14
What policy did you use to verify this? Did you also have the recommended fields (especially the "Identity" field)? "Recommended": [ "AnonymousIdentity", "Identity", "Password" ] >> Yes, I have this fields in the policy. If so, please try again without the "Identity" field in the "Recommended" list (this was fixed server-side). >> How do I remove the field? I don't see any options (Recommended or Identity) in the admin console UI
,
Dec 17
already discussed this with aashutoshk@ on a different channel, but documenting it here if somebody has similar problems: With bug 873775 we changed the behavior for EAP policies. So far, all policies would have username/password as 'recommended' (i.e. users could override the policy values with their own). With that bugfix we changed the behavior to enforce any username/password value sif they are present and only set those values to 'recommended' if you leave those fieldds empty. For existing network configuration policies to trigger the new behavior, you need to save them (click 'save' button without any changes) again in your admin console. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by steve...@chromium.org
, May 18 2018Labels: -Pri-1 Pri-2