Did this only happen on initial sign-in with the new version, or does this consistently happen on subsequent sign-in attempts as well?

I can see this in the ui.log:
[984:984:1030/084037.079189:ERROR:device_event_log_impl.cc(159)] [08:40:37.079] Network: network_connection_handler.cc:100 Connect Failure: certificate-required: /service/14
[984:984:1030/084037.079249:ERROR:device_event_log_impl.cc(159)] [08:40:37.079] Network: network_connect.cc:194 Connect Failed: certificate-required For: {3db9b36f-111e-46e1-8f75-86aca4db815f}

Was a client certificate matching the user-policy configured pattern present?

Thanks!

(5) and (7) were combined in the past (before 69) and we split them up since a new managed network should be preferred over an unmanaged network that previously connected. But I guess if both networks are managed, it does make sense to ignore/skip (7). I'll fix that.

@pmarko: I'm not sure if (8) would rank the EAP higher than the PSK network, you probably have more insights to this. Relevant code parts are [1] & [2].

[1] https://cs.corp.google.com/chromeos_public/src/platform2/shill/service.cc?rcl=fa74f7233ead4fcf35761071ae440cd279745aac&l=1090
[2] https://cs.corp.google.com/chromeos_public/src/platform2/shill/service.cc?rcl=fa74f7233ead4fcf35761071ae440cd279745aac&l=1011

I did think we had logic to prefer EAP > PSK (that's how I thought our internal EAP networks auto-connects when you sign in with a corporate Chrome OS device), but I can't find code for this atm. Maybe we preferred user policy networks over device policy networks instead?

Steven would know for sure.

Ok, thanks. And yes, user policy > device policy would be the next ranking criteria (9) after security_level (8).

So I do think chrome should try to auto connect if a matching client certificate was available. That's why I was trying to rule out a missing client certificate in Comment #3. 

We prefer "more secure" networks in Shill, and I thought anything with a cert was considered more secure than PSK, but I could be wrong. +kirtika@

User profile configurations override device configurations, but beyond that I didn't think we preferred user networks over device networks, policy or otherwise, but I am not certain. This is also handled in Shill.

Shill will auto connect to a network that is "configured", so if Chrome successfully provides the certificate info (and does not set the AutoConnect property to false), Shill should auto connect to the network.

Issue 902887 has been merged into this issue.

@hendrich: any update on this issue? Please let us know if there is additional info needed. Thanks.

CL is in review and will hopefully land soon.

 Issue 906661  has been merged into this issue.

sorry for answering only now, but I was waiting for order possible bugs to be fixed.
About #3 
It happens just after the first login.
the customer has pushed an user policy that will generate the certificate using the extension "Certificate Enrollment for Chrome OS".
"
1) What we have experienced so far is that the device connects to the "WIFI_EXTERNAL" Network on startup, as it is meant to, once logged in however, we are no longer automatically prompted with the Enrollment Web Page for the more Secure Network "INTERNAL_WIFI" Network. 
2) We have also noticed that even though the enrollment process completes successfully, it does not automatically switch over to the "INTERNAL_WIFI" Network,  we have to click on it again from the list of available networks and then the Chrome book will connect to it. 
3) Additionally if we sign out/restart and then sign back in as the previous user (that has already successfully enrolled onto "INTERNAL_WIFI" Network on that Chrome Book), the Chrome Book no longer automatically connects back on to "INTERNAL_WIFI" like it previously use to. Again we must locate it from the list of available networks and select it.
"
the last issue is the most troublesome for the customer.

new debug logs: https://drive.google.com/open?id=1UpFENKBAsoG5QTUdjBPomphcvvaj8hUG
policies:
json: https://drive.google.com/open?id=1SnTGT4JD4UrO1j_vLQg1J6QqviZBCMcF
pdf: https://drive.google.com/open?id=1jRUDC4c3rZ-oEm4WHBZNeBl0Qidd-AF7

extract of the network policy
device: https://drive.google.com/open?id=1KIUzkL582YZ0lAMuKvV6wnPUCmi50fAT
user: https://drive.google.com/open?id=1xhhmdkr89q6Hck-fXRSENEjG_Ngd-aB8

FYI: the CL with a fix was approved and will land soon (hopefully before M72 branch point). I will probably also ask for merge approval to M71.

@marcore: I was able to reproduce (1) and (2) and both should be fixed once the CL lands. However, I was not able to reproduce (3), after I manually connected to the policy provided network once, it would always auto-connect to that network again after restart. I'll take another look.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform2/+/e24da9c63554a9d3641b8206cf22feb25e3853a9

commit e24da9c63554a9d3641b8206cf22feb25e3853a9
Author: Alexander Hendrich <hendrich@chromium.org>
Date: Tue Nov 27 19:23:14 2018

shill: Deprioritize |has_ever_connected| in network sorting

This CL moves the 'has ever connected' criteria just above the 'signal
strength' and below the 'profile' criteria. This way a never before
connected network from user policy/setting will be preferred over a
previously connected network from device policy/setting.

BUG= chromium:904837 
TEST=shill unit test ServiceTest.Compare

Change-Id: I3178959913b684256035425d038eaf551287e38c
Reviewed-on: https://chromium-review.googlesource.com/1346509
Commit-Ready: Alexander Hendrich <hendrich@chromium.org>
Tested-by: Alexander Hendrich <hendrich@chromium.org>
Reviewed-by: Steven Bennetts <stevenjb@chromium.org>
Reviewed-by: Ben Chan <benchan@chromium.org>
Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org>

[modify] https://crrev.com/e24da9c63554a9d3641b8206cf22feb25e3853a9/shill/service.cc
[modify] https://crrev.com/e24da9c63554a9d3641b8206cf22feb25e3853a9/shill/service_test.cc

Requesting merge approval for CL in comment #19 to M71. This should be a very low risk merge and fixes a regression from M69.

This bug requires manual review: We are only 5 days from stable.
Please contact the milestone owner if you have questions.
Owners: benmason@(Android), kariahda@(iOS), kbleicher@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I'm not inclined to approve such a late P2 M71 merge, esp since it's not a regression.  Can you provide details otherwise, along with testing rsults?  #17 appears to show more outstanding issues.

Ok, I just thought that this should be a low risk merge and due to the multiple reports we received, I gave it a try. But skipping M71 and having it in M72 will suffice as well then I guess, especially since it's a P2 regression from M69. Thank you nonetheless.

@test team (to verify this fix):

1) Setup two different network policies (user & device policy)
2) Enroll device
3) Verify: Device should connect to device policy network
4) Sign-in with managed user
5) Verify: Device should automatically switch to user policy network (especially after the initial sign-in)

The fix landed in M72. Behavior for M69-71 was for step (5) that the device would stay on the device policy network and would only auto-connect to the user policy network after the user manually connected to that network once before. I was not able to reproduce (3) from comment #15 (i.e. user policy network would *never* auto-connect, even after manually connecting to it before).
Thanks!

Hello team, I would like to confirm based on #24 if we can test the fix on Beta M72? Thank you.

I was able to repro this in M71 (11151.54.0, 71.0.3578.87) and verify in M72 (11316.9.0, 72.0.3626.9) follow the steps from c#24.

Thanks for verifying!

Just to document the new network sorting order (since it was unclear in multiple other instances):
1) connectable (configured network > unconfigured network)
2) dependency
3) technology (ethernet > wifi)
4) priority
5) managed (managed network (policy) > unmanaged network (user config))
6) auto_connect
7) security_level (PSK > open network)
8) profile (user setting > device setting)
9) has_ever_connected
10) signal strength
11) (serial number)

Hi Alexander, 

Thank you a lot for looking at this.

Do we have a more formal document about the wifi behavior to answer to our numerous enterprise/EDU customer questions? 

Not yet.
AFAIK https://support.google.com/chrome/a/answer/2634553?hl=en is about to be updated soon, but I'm not sure yet how much change will happen there.
I'm happy to answer any questions if you have any.

Hello team, 

The commit from comment #19, still gives the following result https://storage.googleapis.com/chromium-find-releases-static/e24.html#e24da9c63554a9d3641b8206cf22feb25e3853a9 when checked in https://omahaproxy.appspot.com/, which normally means that the fix is not live yet.

However, as per #26 it was verified in 72.0.3626.9 and since then 72.0.3626.15 was published on Dev and 73.0.3640.0 on Canary. 

The customer that we have also gives mixed results. They were first testing Canary and the issue persisted and then reported that it's resolved, no clear still which is the exact build they were testing on.

My question is, if the fix for the issue is live and if yes, in which versions?

Thanks.

"Included in" says:
-release-R72-11316.B
-stabilize-11306.B

So the change is live in ChromeOS 11307.0.0 (Chrome 72.0.3623.3) and later (currently in canary, dev, beta, but not yet stable). See https://crosland.corp.google.com/log/11302.0.0..11303.0.0 for reference.

Yes, I'd like to see an enterprise help article that shows how we prioritize so we can set expected behavior with customers. It doesn't need to be as detailed as #28 buy should cover major areas such as device vs. user, security (open<psk<TLS).

Is that the plan for https://support.google.com/chrome/a/answer/2634553?hl=en and if so is there a bug tracking the work we can follow and comment on?

If not allanrobert@ let's get a doc bug filed.

@jay I've already opened b/120120619 for modifying that page.
we are working on it.

Removing the view restriction since this network sorting order will soon be included in public docs anyways. I don't see anything else here that could be confidential.