Customer logs - 
https://drive.google.com/open?id=1w1K7d4yot36vGoqmihtiEpcgeSoyGmyb
But we were able to repro this on our devices, so could provide any necessary info

Assign to Drew to take a look.

So, sounds like we aren't switching to the device-configured network automatically post-enrollment. I can't tell whether they have a policy that would force them to switch to the policy-configured network, though.

vkhabarov, can you also attach exported policy JSON file so we can see the network policies being pushed?

https://drive.google.com/open?id=1t3mMi4AaaAvEjOgHqTDnHi1-MA9cKtmC - policy JSON
https://drive.google.com/open?id=1FvAJBUhghuqijK6O49dBu_U67HU7vXTo - screenshot showing device policy with network setting for the same network

One more note - if "save credentials" is not selected for pre-enrollment network, then after enrollment this connection credentials are lost - it still shows pre-enrollment user, but password needs to be entered again. This happens immediately as device receives policies. 

We are having a large number of reports of this issue.  A few observations from our testing on ChromeOS v67:

* If we use an open or PSK network for enrollment, we do not have any problems.  The policy correctly applies the 802.1X credentials.
* When we use an 802.1X network for enrollment, the Wi-Fi drops mid-enrollment, however the Chromebook still shows that the enrollment was successful.  After this, the credentials are stuck.
* There is anecdotal reports of the Wi-Fi being "unstable" in this scenario, where the connection will drop for no reason mid-session.
* There appears to be no way to remove or alter the (incorrect) PEAP/TTLS credentials once they are set, without powerwashing.
* Altering the Wi-Fi policy makes no difference to the username and password, however the policy does update from PEAP->TTLS when that field is changed.

Happy to provide more information that could assist with this issue.

Thanks a lot for the report.
I'll see if I can repro this locally.
One thing that seems slightly strange is that the Password field is marked as "Recommended" in the example policy shown in Comment #4.
If I understand the merging logic[1][2] correctly, if there is:
- a user-configured password already set in the shared shill profile (i.e. set on the sign-in screen)
- a recommended password in device policy

the recommended password does not automatically apply.
However, it should be possible to set a new password.

Steven, do you know what could have changed behavior here in M-66?

It sounds like *either*

a) The user policy is not getting pushed applied correctly.

Or

b) Shill is not switching to the user policy configuration.

I couldn't say off the top of my head what changes may have landed in the 65-66 timeframe that might have caused this, but it could be a lot of things.

A feedback report here would be very helpful; that would allow us to determine whether or not both configurations exist.

Note: Shill doesn't (shouldn't) merge configurations from different profiles; Shill should use the configuration from the "topmost" (i.e. user) profile.

Note that this is about device policy.
IIUC the steps are:
- manually configure PEAP network on unenrolled sign-in screen
- enroll for enterprise management
- now existing device policy has configuration for the PEAP network.
Basically, the bug report is saying that we don't respect the device policy
PEAP network  credentials(1) and can't change the manually configured PEAP
credentials anymore(2).

(1) I would understand this not happening automatically when those are
Recommended
(2) OTOH, if the credentials are Recommended, it should be possible to
reconfigure them manually




stevenjb via monorail <monorail+v2.3638709369@chromium.org> schrieb am Fr.,
7. Sep. 2018, 02:16:

Ah, I see, I think. Yeah, I'm not sure what the expected behavior even is here, but even if the values are Recommended, I would probably expect the device policy to override any existing configuration the first time it is applied. It's possible that some re-factoring introduced a subtle change that modified the previous behavior. It will probably be easier to debug the code that applies the policy than it will be to bisect the regression since it occurred in the 65-66 release.

I don't see any mention of not being able to enter credentials manually (i.e. by opening the configuration dialog)? That would be a separate UI bug.

AFAIK, if the user specified identity & password and the policy only recommends it, then the user specified values should be used.
I haven't tested it yet, but if you specify identity & password in the policy without "recommended", it should probably use those.

However, for recommended values the user should still be able to change the values in the UI. I suspect this is related to  crbug.com/877424 . Apparently, the UI to configure networks is enabled even for policy configured networks, but the changes from the UI are not applied to shill.
For a policy configured network without "recommended" this is obviously what we want, even though we should probably also hide/disable the UI in that case.
For our case with "recommended" we will have to find out, why the changes aren't applied correctly.

I will do some investigation on these two issues.

poromov@ just pointed out to me, that we don't have any information about "Recommended" in the docs (go/onc).
@stevenjb: is this even fully supported and just missing in the docs or was support for it removed in the past?

I just reproed it with a normal PSK wifi:
-policy configuration: UI available, but changes aren't applied
-recommended policy configuration: UI available and changes are applied

I will try to repro it with a PEAP network

I don't believe that the policy metadata (i.e. "managed" ONC) was ever documented outside of the code. It is however part of the cpanel integration and should be fully supported.

Could you clarify what you mean by 'UI available, but changes aren't applied'? Scanning the code, it looks like we may not have implemented policy enforcement in the new configure UI, which is a separate (but significant) bug.

>>> Could you clarify what you mean by 'UI available, but changes aren't applied'?
Steps to reproduce:
1) configure Wifi device policy (no recommended values)
2) correct passphrase is set in shill (/var/cache/shill/default.profile)
3) open UI and configure network by setting a new passphrase
4) correct passphrase is still set in shill (/var/cache/shill/default.profile)
So the UI changes in 3) are correctfully not applied.

If the policy sets the passphrase as recommended, step 4) will show the updated passphrase from the UI (at least for PSK networks). So the UI changes are correctfully applied in that case.
I still have to repro this for PEAP networks and figure out, why it's not working there. Apart from that, this bug report is indeed working as intended, since the policy values are only recommended.


For  crbug.com/877424  we will probably load the network as ManagedProperty and then disable/enable the input fields based on the UserEditable/DeviceEditable values. So non-recommended values can't be edited anymore. If no field is marked as recommended, then we should probably disable the configure UI entirely.

So I finally managed to setup a Wifi network using PEAP/MSCHAPv2 and I'm running chrome 71.0.3551.0. Here are my findings trying to reproduce this behavior.

### From Yaps with recommended
1) Set up device policy with user "test1" and "Identitiy" & "Password" as recommended
2) Before enrollment log into wifi using "test2"
3) After enrollment & policy fetch, the wifi connection is disconnected and asks for a password when re-connecting. Username "test2" is pre-filled in the UI, but you can use either usernames+passwords and both work fine.
-> working as intended? (@stevenjb: is the disconnect correct in this case or should we stay connected with "test2" in this case?)

### From Yaps without recommended
1) Set up device policy with user "test1" without recommended values
2) Before enrollment log into wifi using "test2"
3) After enrollment & policy fetch, the wifi connection is switched to using "test1" and can't be changed using the UI
-> working as intended (apart from UI bug:  crbug.com/877424 )

### From DMServer
I also tried a wifi device policy directly from DMServer, which indeed also has identitiy & password as recommended fields. So it is basically the same as "FromYaps with recommended". I guess this is the culprit here and those fields should be enforced and not only recommended if set. I will file a DMServer bug.




To alex.duckworth@ed.act.edu.au from #c6:
Since the policy values from the DMServer are only recommended, they won't override the existing values, even when the policy changes. (see above)
However, users should still be able to change the credentials manually using the UI. Please clarify what you mean with "the credentials are stuck".

The PEAP credentials used to enrol the device cannot be removed.  They can’t be forgotten nor overridden with a policy.  It should be noted that when the PEAP credentials were added pre-enrolment, the option box to store the credentials wasn’t even ticked, yet it still “remembers” these credentials.

DMServer bug: https://buganizer.corp.google.com/issues/115610576

# Re: "with reconnect":
I don't know why the disconnect occurred. I would need to look at the logs in chrome://network or a feedback report to determine whether Chrome or Shill triggered the disconnect.

I can help with that (see https://drive.google.com/open?id=1lsqzaiGNpHLsJfADGzLczgkjB7Qg2Yux)

"max" is the username entered before/during enrollment and "bob" is the username from the policy:
{
  "Type": "UnencryptedConfiguration",
  "GlobalNetworkConfiguration": {},
  "NetworkConfigurations": [
    {
      "GUID": "{485e6176-dd34-6b6d-asdsad}",
      "Name": "hendrich_PEAP_test",
      "Type": "WiFi",
      "WiFi": {
        "SSID": "hendrich_PEAP_test",
        "Security": "WPA-EAP",
        "AutoConnect": true,
        "EAP": {
          "Identity": "bob",
          "Inner": "MSCHAPv2",
          "Outer": "PEAP",
          "Password": "hello",
          "SaveCredentials": true,
          "UseSystemCAs": false,
          "Recommended": ["Identity", "Password"]
        }
      }
    }
  ]
}

After enrollment, the network is disconnected. Clicking on the network opens up the UI (see download.png), but the password for "max" is not stored, even though the "SaveCredentials" was enabled before/during enrollment.

Thanks for looking into it!

Issue 844598 has been merged into this issue.

Is the password not stored, or is the UI just not indicating that it is not stored? We may need to do something similar to what we did for  issue 875983  (in which case we may want to build that behavior into network-password-input which is used for both *.PSK and *.Password).

@stevenjb:
It is stored (/var/cache/shill/default.profile has the identity & password values entered before enrollment), but the password input field is blank.
I just also tested it with a WPA-PSK network and there we have exactly the same problem (password field is blank). Those values are simply not filled when retrieving an ONC networkProperties object from the networkingPrivateApi
So +1 to the idea of doing something similar as 875983 for network-password-input.
We have some more Nooglers joining the team in the next few months and this sounds like a good first bug. Or do you think this more time critical?

This primarily affects enterprise users, so I would talk to atwilson@ or the enterprise PM (do we have an enterprise PM these days?) WRT priority. I would certainly love to have more people working on the Network Config UI, and this one should be pretty straightforward... :)

 Issue 863958  has been merged into this issue.

Can I just put this problem into context from a customer's perspective?

* New Chromebook is received.
* Admin user connects to the Wi-Fi with their credentials on the Chromebook and enrolls it for the first time.
* Wi-Fi credentials never get replaced by the policy.
* Admin user's password expires, user changes their password.
* All the Chromebooks the admin user has enrolled will no longer automatically connect to the Wi-Fi.

As more and more Chromebooks gets enrolled and as time goes on, this problem is just going to get bigger and bigger for us.

+Marcus Koehler (enterprise PM?)

Re Comment #28:
Alex, is it correct that this scenario can not happen with a server-side fix, sending the fields as mandatory instead of recommended?

(I still think we should fix the "Recommended" behavior here anyway)

Please find the observations from the Enterprise Test Team. I was able to repro this, however with some questions.

1. In CPanel I have configured the device-level PEAP network for user "test1" (incorrect username/password).
2. During enrollment I used the same PEAP network with correct username/password (manually entered).
3. The network was disconnected during enrollment, however enrollment was successful (exactly like in c#6).
4. I connected this network manually again and was able to login.
5. The network policy was applied to device:

{
      "GUID": "{463ae4b2-174e-4191-84b5-9b65521ce871}",
      "Name": "test1",
      "ProxySettings": {
         "Type": "Direct"
      },
      "Type": "WiFi",
      "WiFi": {
         "AutoConnect": true,
         "EAP": {
            "AnonymousIdentity": "PEAP",
            "Identity": "test1",
            "Inner": "MSCHAPv2",
            "Outer": "PEAP",
            "Password": "********",
            "Recommended": [ "AnonymousIdentity", "Identity", "Password" ],
            "SaveCredentials": true,
            "UseSystemCAs": false
         },
         "HiddenSSID": false,
         "SSID": "CrOS_WPA2_LinksysE3000N_5GHz",
         "Security": "WPA-EAP"
      }
   }, 

6. But in network settings I can see correct username which was provided manually.

Looks like the policy sets username/password as recommended and when user manually changes them, they stay the same even after enrollment (policy push). Also the network settings UI allows to edit username/password.

Chrome OS: 11021.22.0
Chrome: 70.0.3538.27
Device: Snappy

Re Comment #31:
I am unable to find a way to set Recommended/Mandatory settings under Device management > Networks > Wi-Fi > <A policy>

Can anyone point me to where I can change this? I'm assuming I'm missing something obvious, but I haven't found it clicking around or on support.google.com

@comment #31: Yes, if the server enforces these values (=no recommended), then the device will use the policy provided values and they can't be changed via UI (UI still visible though = separate bug  crbug.com/877424 ). I verified it using yaps.

@comment #32: Yes, if the value is recommended, then it should be possible to edit these values using the UI and those changed values should also be used. To decide which value to use, we have following order:
-enforced user policy
-enforced device policy
-user settings
-device/shared settings
-recommended user policy
-recommended device policy
(see logic: https://cs.chromium.org/chromium/src/chromeos/network/onc/onc_merger.cc?rcl=2ba8941506f93f635af10ba5a0fd54f8f38c5ad8&l=290, user_editable = !HasUserPolicy() || IsRecommendedUserPolicy())

@comment #33: You can't. The policy values Device management > Networks > Wi-Fi are set as recommended.

FYI an update from the buganizr thread (https://buganizer.corp.google.com/issues/115610576): Turns out "recommended" values are indeed correct here since the primary use case is for users to manually change these settings with their own credentials.
Nonetheless, we asked the server-side team to implement non-recommended (i.e. enforced) credentials (as requested in this bug here) as a separate use case. This will probably take some time (see buganizr thread for more infos).

The UI bug is almost finished and should land soon.

Greetings, do we have updates for this issue? 

Somebody from the server-side is looking into it. I don't have any more details, it may take a while.
The fix for the UI bug ( crbug.com/877424 ) has landed by now, so at least the UI should be a bit clearer.

Server-side fix is planned to go live on Wednesday midnight (PST).

Leaving the username & password field empty will mark these values as being "recommended" (i.e. user can override them with their own values). If username and/or password are filled in, the values will be enforced (i.e. user cannot override them).
For existing policy values, admins will have to go to the admin console, edit the network and click "Save" to trigger a policy update.

Did this proceed as planned?  Has anyone tested and confirmed?  Because it has not solved the original issue at all for us.

I can confirm that I also have the same behavior as before, I'll check back with the server-side guys.

Same here - it's not working.  We edited the policy and saved to trigger the update and there was no change.

Hi Team, could we get an update on this? Was the fix implemented as planned? We have different users reporting the issue persists.

Just did an investigation here. The fix is still in the testing cycle on the server side and therefore NOT yet rolled out. 

Let me follow up with an update on the status on Nov, 19th.

FYI: Server-side fix is up and running now.
You need to hit *save* on your network configuration again to trigger an update for the new behavior.