This is happening both on the Acer (peppy) and Dell (candy) Chromebooks.  It began late spring 2016, but I cannot remember exact version.  I usually see it after an update as students rarely reboot otherwise, but I have seen it happen randomly with no updates.

I have commented on this in other issues that seemed related, but as it is continuing I though it deserves its own issue.

I have confirmed for a majority of issues that there have been no password changes via the google apps admin console.  Changing the password does seem to reliably reproduce the issue, however.

Does a manual password change (e.g. go to account on other device and change password) also result in the same issue? Chrome OS should be agnostic to this, but want to get it out of the way before digging further.

Yes, it happens with manual password changes from another device.  Tested:

-powerwashed a Chromebook
-logged in with a test account
-waited for apps to sync
-shut down Chromebook
-changed password manually from another computer
-powered on Chromebook
-logged in using old password
-received sign-in error notification
-signed out
-attempted to sign in with new password, didn't work
-signed in with old password, was immediately signed back out
-signed in with new password, was prompted to enter old password to unlock data
-immediately signed out
-now have orange exclamation point next to username
-can sign on with new password, but am immediately signed back out

+Albert +Zach in case this was brought by a change in the OOBE feature.

I raised priority since this seems pretty drastic. Krishna, can your team reproduce?

The orange exclamation mark indicates bad token. It could happen when chrome either crashed or exited before it could validate user's token. The black screen could be a symptom of that.

I am unable to repro the problem on trunk with password change. :(

greigm@: 
Is it possible to get logs on the device where the problem happens? You can login as guest, open chrome://net-internals, select "ChromeOS" on the left side, and there should be a "Store Debug Logs" button show up. Use it to collect logs on the device and attach it here.

Thanks for looking into this.  Here are the logs.

Deleted: debug-logs_20170201-100338.tgz 476 KB

debug-logs_20170201-100338.tgz 476 KB Download

Thanks for the log.

This log line explains what has happened:

[19733:19733:0127/153029:ERROR:user_cloud_policy_manager_chromeos.cc(419)] Policy fetch failed for adam@students.gabrielrichard.org - aborting profile initialization

This line means that chrome fails to fetch user policy during profile init. It is a critical error and current impl exits user session when it happens. [1]

It also appears that the network is somehow flaky. There are many network errors in the log.

e.g. the following ones happens just before user policy fetch failure:
[19733:19845:0127/153028:ERROR:ssl_client_socket_impl.cc(1146)] handshake failed; returned -1, SSL error code 1, net_error -101
[19733:19733:0127/153029:ERROR:device_event_log_impl.cc(140)] [15:30:29.768] Network: network_state_handler.cc:599 DefaultNetworkPropertyUpdated: Gabriel Richard.Error = "out-of-range"
[19733:19733:0127/153029:ERROR:device_event_log_impl.cc(140)] [15:30:29.768] Network: network_state_handler.cc:900 Default network in unexpected state: Gabriel Richard (/service/0)State: failure
[19733:19733:0127/153029:ERROR:device_event_log_impl.cc(140)] [15:30:29.775] Network: network_state_handler.cc:599 NetworkPropertyUpdated: Gabriel Richard.Error = "Unknown"

It looks like the device uses one flaky wifi on the login screen. And just after login, the device attempts to change wifi (maybe the user has a preferred wifi). The wifi change is either flaky or taking too long, which causes the user policy fetch failure.

While we need to understand the network problems, we should probably fix the UX here. Instead of exitting without any UI, it might be better to show some UI to retry the user policy fetch.

[1]: https://cs.chromium.org/chromium/src/chrome/browser/chromeos/policy/user_cloud_policy_manager_chromeos.cc?rcl=f2b188baeb2938427bf58b6ff6b61840f325055b&l=448

+tnagel

greigm@: Could you confirm which ChromeOS version you are using? And whether active directory account is used?

Based on Chrome version 55 / "began last spring" we can pretty much rule out Chromad as a cause.  (Also I'm not sure whether RBS is justified, given that the problem seems to have been around for a while.)

Adding atwilson and emaxx who've been working on profile initialization recently.

Yes, there is still no error handling implemented when Chrome decides that a fresh fetch of the admin policy is required: [1]
This was introduced abort a year ago (see commit [2], which went into 50.0.2661.0), which corresponds to the estimation written in comment 1.
AFAIU, that change is necessary to disallow bypassing admin policy under some circumstances (like network errors).

Drew, should we file a separate bug to track adding of error handling into the code?

Also I agree with comment 12 in that this shouldn't probably be a release blocker, as the issue, as reported, was there for several major releases already. Therefore removing RBS - please add it back if you think the argument here is wrong.

[1] https://cs.chromium.org/chromium/src/chrome/browser/chromeos/policy/user_cloud_policy_manager_chromeos.cc?l=442
[2] http://crrev.com/041151c642ee1ce37e41cd6365b2f2fa456bb4bc

xiy@   currently 55.0.2883.105  platform 8872.76.0

Our AD passwords are synced to the Google accounts.  As tested earlier, a manual password reset triggered the issue.

All of our users authenticate to our WiFi via 802.1x/PEAP.  The connection is setup via Google Apps and applied per user.  No connection is available pre-login.

To setup users the first time, we open a temporary PSK network, have the users sign in, and after the policies sync and the managed network is added, they enter their password for the connection.

A few Chromebooks (including the one I sent logs from) have a set of 'dummy' WiFi credentials saved that will be active until the user logs in.  Most of the devices experiencing this issue do not have the dummy credentials set; they have no connection until the user is logged in.

I agree this should not block a release at this point.

OK, got it. Yeah, this is due to my decision in http://crrev.com/041151c642ee1ce37e41cd6365b2f2fa456bb4bc to use the "force online signin" flag as a proxy for "the profile was never fully initialized". Once you are forced to do an online signin, you must do a policy fetch as well, and if we can't reach DMServer, we shut down the profile because we don't know if we can trust the cached policy.

I'm guessing there's some problem where we try to fetch policy simultaneously with switching wifi networks which causes the policy fetch to fail. I believe we have retry code down in device_management_service so I would have figured that the retry should have allowed the policy fetch to succeed (https://cs.chromium.org/chromium/src/components/policy/core/common/cloud/device_management_service.cc?q=device_management_service.cc+package:%5Echromium$&dr&l=406) - in theory, we should retry after 10 secs, 20 secs, and 40 secs which should be more than enough time to setup the wifi network, *if* the network config is valid.

But fundamentally, if you have user policy that configures an invalid network, you'll get this behavior after a password change, which is pretty bad. A better solution would be to actually track when a user profile is fully initialized in a persistent flag (meaning that we've completed a policy fetch request and finished storing any policy for the profile) instead of relying on the oauth token state (https://cs.chromium.org/chromium/src/chrome/browser/chromeos/policy/user_policy_manager_factory_chromeos.cc?l=207). That's a better solution than shenanigans with network retries that may just never succeed if the network config is bad. This would also help solve some other issues we had where the browser crashes and restarts and we don't know whether to trust the cached policy or not.

I think one of us on the enterprise team should own this - I'm traveling tomorrow, but Maksim and I can discuss the appropriate fix when I'm back in the office on Friday.

@16: I agree that keeping the persistent flag sounds like a good way to go. Also this should resolve remaining issues around restart-after-crash, which are tracked in bug 676624.

The retry logic does not work properly. In the log, login finished at 15:30:29 and we bail almost immediately.

[19733:19733:0127/153029:VERBOSE1:cryptohome_authenticator.cc(613)] Login success
[19733:19733:0127/153029:VERBOSE1:login_performer.cc(82)] LoginSuccess hash: d69490c642c1d2c41897115f42010cd9b02903c5
[19733:19733:0127/153029:VERBOSE1:user_session_manager.cc(483)] Starting user session.

greigm@: The orange exclamation mark means the oauth2 token of the user is bad. The user would have to go through an online login to restore the token. For those device with no 'dummy' wifi, would they able to see the online login UI (the box with blue header)? Or they show a network error UI with a dinosaur, asking user to config a network? 

It's possible that the type of error (no network available?) is one we don't think is retryable.

In any case, the retry logic is a red herring - even if the retry logic worked perfectly, we'd still be broken in the case that the user policy defines an inaccessible network, and the user changes his password.

Dropping priority to P1, since it's not a regression, does not introduce a security hole, and there's a workaround.

@18

I have tried connecting back to the WiFi before retrying login. (by this point the certificate for 802.1x is installed).  The online login UI does come up and successfully logs in, but immediately logs back out again.  This makes sense, as the WiFi will drop as soon as the login succeeds and switch to the user credentials saved in the user's profile.

I have not tried activating a PSK network to try recovering the chromebooks.  I will attempt this next time one comes down, but I suspect it will switch to the user's preferred WiFi upon login and will have the same result of immediately logging back out.  Actually, I'm almost sure--I did have one student say the orange triangle happened over Christmas vacation at home on a PSK network.  

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d5a7eabf41ff530632d5cd18b7136b52bbdc5f20

commit d5a7eabf41ff530632d5cd18b7136b52bbdc5f20
Author: atwilson <atwilson@chromium.org>
Date: Thu Mar 09 13:18:39 2017

Track whether a given user session has completed initialization

Start tracking user session initialization in local state and use
that flag to determine whether to force a policy load instead of relying
on the oauth token status. This is important because forcing a policy load
when it's not strictly required can lock users out of their accounts.

This flag is not persisted across restarts of ephemeral sessions (including crash-induced restarts) so policy code will force a policy reload after a crash (identical to previous ephemeral behavior, so no behavior change from this CL)

BUG= 684031 

Review-Url: https://codereview.chromium.org/2711113003
Cr-Commit-Position: refs/heads/master@{#455727}

[modify] https://crrev.com/d5a7eabf41ff530632d5cd18b7136b52bbdc5f20/chrome/browser/chromeos/login/screens/user_selection_screen.cc
[modify] https://crrev.com/d5a7eabf41ff530632d5cd18b7136b52bbdc5f20/chrome/browser/chromeos/login/users/fake_chrome_user_manager.cc
[modify] https://crrev.com/d5a7eabf41ff530632d5cd18b7136b52bbdc5f20/chrome/browser/chromeos/login/users/fake_chrome_user_manager.h
[modify] https://crrev.com/d5a7eabf41ff530632d5cd18b7136b52bbdc5f20/chrome/browser/chromeos/login/users/user_manager_unittest.cc
[modify] https://crrev.com/d5a7eabf41ff530632d5cd18b7136b52bbdc5f20/chrome/browser/chromeos/policy/user_policy_manager_factory_chromeos.cc
[modify] https://crrev.com/d5a7eabf41ff530632d5cd18b7136b52bbdc5f20/chrome/browser/profiles/profile_browsertest.cc
[modify] https://crrev.com/d5a7eabf41ff530632d5cd18b7136b52bbdc5f20/chrome/browser/profiles/profile_impl.cc
[modify] https://crrev.com/d5a7eabf41ff530632d5cd18b7136b52bbdc5f20/components/user_manager/fake_user_manager.cc
[modify] https://crrev.com/d5a7eabf41ff530632d5cd18b7136b52bbdc5f20/components/user_manager/fake_user_manager.h
[modify] https://crrev.com/d5a7eabf41ff530632d5cd18b7136b52bbdc5f20/components/user_manager/known_user.cc
[modify] https://crrev.com/d5a7eabf41ff530632d5cd18b7136b52bbdc5f20/components/user_manager/known_user.h
[modify] https://crrev.com/d5a7eabf41ff530632d5cd18b7136b52bbdc5f20/components/user_manager/user.h
[modify] https://crrev.com/d5a7eabf41ff530632d5cd18b7136b52bbdc5f20/components/user_manager/user_manager.h
[modify] https://crrev.com/d5a7eabf41ff530632d5cd18b7136b52bbdc5f20/components/user_manager/user_manager_base.cc
[modify] https://crrev.com/d5a7eabf41ff530632d5cd18b7136b52bbdc5f20/components/user_manager/user_manager_base.h
[modify] https://crrev.com/d5a7eabf41ff530632d5cd18b7136b52bbdc5f20/components/user_manager/user_unittest.cc

Thank you for looking into my issue and developing a fix.  If I followed it correctly, it won't roll out until this summer with Chrome 59.  Is there any chance of this being merged into a sooner release?

Drew, shall we merge this to M-57?

I think it's probably a bit invasive for M-57 at this point, but def worth merging to M-58.

Your change meets the bar and is auto-approved for M58. Please go ahead and merge the CL to branch 3029 manually. Please contact milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop)

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

This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

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

Clearing randomly added cc list by sheriffbot. sorry for the spam. thanks.

This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

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

This issue hasn't been updated in the last 6 weeks, so removing its merge approval label. Please re-request a merge if needed.

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

Did this make it into one of the stable 57 releases?  My issues all ceased before 58 was released; I haven't had an orange triangle in weeks.

Issue has now occurred for me since updating to version Version 71.0.3578.94 (Official Build) (64-bit). Never had the problem before but now no amount of signing out and signing back in will resolve.

omg, this is doing the same thing to me since yesterday/updating.  PLEASE HELP!!!

This is a very old bug. Please file a new one with chrome version. Then file a feedback after repro mentioning the new bug number.

hey, i fixed it not too long after reading this thread; glad it was here! -- when i saw the stuff about the "flaky" wi-fi hopping in & out & during the policy fetching & not letting the "full" sign-in happen, i thought about the fact that this was the first time i had completely restarted since adding the NordVPN extension, & how that would be connecting & resolving right as the browser was getting going. i had restarted several times before this; no luck. i turned off NordVPN extension (which was set to auto-connect) & restarted... IT WORKED!! no *powerwash*!!  -- i think the add same user trick sounded good, but didn;t need it. just posting this here in case anyone else having the same issue... i guess if the NordVPN extension were set to NOT auto-connect, it would have the same result/ not produce a policy fetch problem during sign-in.

yvonne111: Are you signing in with a managed account (example, a school or work account) or just a regular gmail account when this happens?

Does it happen only on the very first time you sign in on a device? Or on all subsequent signins?

atwilson: I had the exact same issue and got here. After Yvonne's suggestion I uninstalled the NordVPN extension and shutdown, then on a restart it worked fine and the "sign-in details" error disappeared.

Version 71.0.3578.98 (Official Build) (64-bit)

Regular gmail account to sign in. This started happening after the last update, and persisted through a powerwash.

This happens to me at EVERY BOOT. I am logging in with a gmail address, with 2FA (Security Key) enabled.

When I turn on the Chromebook, I get the red triangle under my name, and have to use the web sign-in flow, including the security key.  Chrome then logs me in, but within one minute displays a notification

>>
Sign-in errror
Chrome OS could not sync your date because your
account sign-in details are out of date.

SIGN OUT
>>>


If I click the sign-out button, or sign out, or shutdown the chromebook, the same error returns at the next startup.

hi there! ((: using a regular sign-in. i had restarted numerous times; the only thing that worked for me was turning off the AUTO-CONNECT for the chrome NordVPN extension: that was it;s not trying to auto-connect while simultaneously doing the sign-in/start-up policy fetching phase. 

We here at a School District are having this issue with the Orange triangle and with the Error that says the user needs to Sign in again. We have removed user and Power Washed the units that we are using to try and resolve. I can't imagine that there is no way to resolve this. Especially with the time frame, this has been going on. any suggestions or ideas to try and resolve would be appreciated! 

Deleted: Screenshot_20190117-094006_Gallery.jpg 704 KB

	Screenshot_20190117-094006_Gallery.jpg 704 KB View Download

Deleted: Screenshot_20190115-145925_Gallery.jpg 860 KB

	Screenshot_20190115-145925_Gallery.jpg 860 KB View Download

Chrome OS could not sync your data because your account sign-in details are out of date; Problem happens randomly on my chromebook. I have two (2)  Accounts general gmail accounts; NOTE only one account has this issue need help to resolve!