This issue appears to affect dev-channel (M57) but not canary (M58), for me.

Looking at chrome://policy, I see that my Chromebox (dev-channel) has the corp device policy listed under Status, but no "user" policy listed.

My Canary and Beta channel devices show both Device and User policies under Status, and both devices show only the "primary" sign-in account on the lock-screen.

Albert, has something change in M57 around the lock or login areas?

OK, I just signed-out and back in again, and I now have user policies for @google, and lock screen is behaving as expected.

When I signed in to ChromeOS this morning I found that e.g. my GMail tab wanted me to sign-in again, which seemed strange; the lack of user policy was in the same session, so perhaps that's related?

Add UI>Browser>Profiles for more exposure.
Component owners, please help triage this bug. Thanks! 

Based on the observation in #5, this seems to have been an enterprise policies bug; the sign-in screen was actually WAI, given that the two accounts temporarily appeared to have no policies set.

steel@ can someone on your team investigate

This should fall into Jake's queue.

wez@: Did you collect logs or similar? Did you see an error notification during sign-in complaining that sign-in credentials were bad, like in  issue 682695 ?

Re #11: I don't recall seeing any, but network association is super slow on this device, so it's plausible.

However, the device had been signed-in over the weekend, and when I came back some sites were showing sign-in dialogs, so presumably some token actually *had* expired - it was the subsequent login that was missing the policies, though.

FWIW I shared logs with jdufault@ offline.

I didn't see anything suspicious in the logs. I'm not sure how we could have pulled device policy but failed to pull user policy. Looking at [1] it seems like we block until we have policy.

+atwilson@, xiyuan@ if they have any thoughts on how we could have device policy but not user policy.

1: https://cs.chromium.org/chromium/src/chrome/browser/chromeos/policy/user_policy_manager_factory_chromeos.cc?l=207

It shouldn't be possible to get in to a managed user session without downloading policy, due to this logic: https://cs.chromium.org/chromium/src/chrome/browser/chromeos/policy/user_cloud_policy_manager_chromeos.cc?l=448. The only way this is possible is if DMServer returns a MANAGEMENT_NOT_SUPPORTED error when registering for user policy.

I'm happy to take a look at the logs if someone can reshare with me or add to the bug (since this bug already has restricted visibility).

Was this the first time you signed in to the corp account (was there no corp account on the device until you did the signin)?

Re #17: Shared the logs with you; I'm not sure which exact log is from that session, so there are several logs from around that time.

This was not the first sign-in on the device, no. However, I had removed the corp account and re-added it, to diagnose another issue - I don't recall if this was the first sign-in after re-adding or not, though.

Handing off to atwilson@ so someone more familiar with policy can take a deeper look. Feel free to reassign to me if this is an issue with non-policy related sign-in flow.

During one of the runs, RemoteCommandsInvalidator never seems to have run. Cryptohome also reports that it did an offline-only login, but in another log file RemoteCommandsInvalidator ran but cryptohome still reported it did an offline-only login. Testing offline login locally worked as expected w.r.t. user policy. I'm not familiar with RemoteCommandsInvalidator so this may or may not indicate an issue. I would expect that it is not an issue though, since if we fail to invalidate we should still have the policy data available.

  > [628:628:0206/102920.927974:VERBOSE1:cryptohome_authenticator.cc(730)] Resolved state to: 12
  // OFFLINE_LOGIN = 12,      // Login succeeded offline.


The following also stood out, but I think it is expected output and does not indicate a problem.

  [628:628:0206/102851.137793:VERBOSE1:auto_enrollment_controller.cc(231)] Device already owned, skipping auto-enrollment check.
  [628:628:0206/102851.137824:VERBOSE1:auto_enrollment_controller.cc(283)] New auto-enrollment state: 5

  5 -> // Check completed successfully, enrollment not applicable.
       AUTO_ENROLLMENT_STATE_NO_ENROLLMENT,

I looked through the logs and didn't see any kind of policy errors.

The entries for auto_enrollment_controller.cc are expected. RemoteCommandsInvalidator is not related to delivery of policy to the device so that seems to be a red herring.

emaxx, tnagel - I've shared the logs with you. Do you see anything odd there?

I take it back - I don't have permissions to reshare. Wez, any reason not to just attach the logs to this bug?

Maksim/Thiemo - any insights? If not, then maybe next step is to see if we can figure out repro steps.

I haven't found any hints in the logs.

This is a stable blocker for M57. Does this still repro on M57 Beta?

Removing RBS since we can't repro.

removing RBS again. For some reason the sheriffbot brought it back.

atwilson: Uh oh! This issue still open and hasn't been updated in the last 14 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

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

At this point, without repro steps I think we need to (unfortunately) WontFix this as no-repro. Any objections?

atwilson: Uh oh! This issue still open and hasn't been updated in the last 14 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

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

OK, marking wontfix - feel free to reopen if we find a repro.