I tried this on 53.0.2785.103 (Pixel 2 with google.com enrollment and wolf without enrollment) and on 54.0.2840.24 too (wolf), and it logged me in instantly in all cases. (Freshly created dasher domain without any chrome management settings.)

I could reproduce this with 52.0.2743.116, but that version doesn't contain my previous fix ( crbug.com/639822 ).

I just reproduced again using 54.0.2840.24 (Pixel 2).

It's definitely getting a 10-second timeout doing a policy fetch at the start (see logs below). What I don't understand is why it's taking us so long to fail to load policy given that there *should* be no network connectivity (no network interfaces to send packets on, so failures should be immediate). Can you try starting ARC in your session between steps 2 and 3? Maybe ARC has something to do with it since it's the only thing I see starting up at the beginning of user session initialization.

[4460:4460:0919/162733:VERBOSE1:arc_net_host_impl.cc(642)] ArcBridgeService does not support DeviceListChanged.
[4460:4460:0919/162733:WARNING:merge_session_throttling_utils.cc(138)] Loading content for a profile without session restore?
[4460:4460:0919/162733:WARNING:user_cloud_policy_store_chromeos.cc(153)] Failed to load legacy policy cache: 1
[4460:4460:0919/162743:WARNING:user_cloud_policy_manager_chromeos.cc(403)] Timed out while waiting for the policy fetch. The session will start with the cached policy.


BootTime.Login: 10.86
0.00 +0.0000 LoginStarted
0.00 +0.0001 AuthStarted
0.00 +0.0002 CryptohomeMount-Start
0.60 +0.6031 CryptohomeMount-End
0.60 +0.0002 BootTime.Authenticate
0.60 +0.0013 StartSession-Start
0.61 +0.0001 StartSession-End
0.61 +0.0000 UserLoggedIn-Start
0.62 +0.0130 UserLoggedIn-End
10.73 +10.1163 UserProfileGotten
10.75 +0.0174 TPMOwn-Start
10.78 +0.0289 TPMOwn-End
10.81 +0.0249 TabLoad-Start: 
10.81 +0.0035 TabLoad-Start: 
10.82 +0.0144 BrowserLaunched
10.85 +0.0235 TabLoad-Start: 
10.86 +0.0153 LoginDone

I also see this:

[12002:12002:0919/164322:ERROR:policy_oauth2_token_fetcher.cc(239)] Unrecoverable error or retry count max reached.

Looking at policy_oauth2_token_fetcher.cc, I don't think it's even possible for it to fail in less than 9 seconds. Can you look at your test account and see why we aren't trying to call policy_oauth2_token_fetcher.cc on it in your case?

OK, so Chrome management was on by default on a freshly created dasher domain. After disabling it manually, I can also reproduce the problem.

Alex, this would be an interesting starter bug for you to learn about how the policy stack is initialized on Chrome OS during signin.

I've just tried to repro this with freshly registered dasher account: no luck, both offline and online logins happen in ~3 secs. Also tried with device management enabled/disabled.