Assigning to Mihai to take a look

pastarmovj@ / ewald@: This bug is really cryptic and I do not know where to start in order to reproduce it (I do not know how to " joining the machine to a windows domain"). Do you guys have any information on how I can test this?

pastarmovj@: Is this bug something that the enterprise team should own?

I'm not 100% sure either - Julian, can you help answer? I assume that means that the machine is added to some enterprise fleet of Windows machines with a certain policy/configuration.

To Mihai's point, we may need some help from the enterprise team to help debug this. Is there anyone else we should loop in from the enterprise team?

We have some test environments but in order to reproduce I guess we will need more feedback. Technically any Windows box in the company is also AD joined so it's not that alone. I will ask the user to start responding here instead of on the forum and then ask about the active policies in place.

Julian: I am reassigning this bug to you based on comment #4. Once we have more info from the user and a repro case that we can work on, we'll re-evaluate if this bug should be taken by the sign-in team.

Chrome signin internals before reboot
Chrome policy after reboot
Chrome signin internals after reboot

Deleted: chromesignininternalsbefore.png 86.8 KB

	chromesignininternalsbefore.png 86.8 KB View Download

Deleted: chromepolicyafter.png 79.3 KB

	chromepolicyafter.png 79.3 KB View Download

Deleted: chromesigninginternalsafter.png 52.7 KB

	chromesigninginternalsafter.png 52.7 KB View Download

Sorry, somehow the Policy before screenshot was deleted.

Deleted: chromepolicybefore.png 66.7 KB

	chromepolicybefore.png 66.7 KB View Download

Mihai, does these screenshots give you some idea about what the problem could be?

paul.tietjens@mesd.us: Thank you for sharing the screenshots.

Here is how I read the chrome://signin-internals screenshots:

1. Before reboot, Chrome is signed in with one account that is signed in with a valid token (we see a bunch of successful requests to get access tokens).

2. After reboot, SigninManager still knows that there is a signed in account. However, the TokenService is in authentication error and there was no successful or failure request to get an access token. I think this pretty much means there was a problem when loading the accounts:
2.a. There was no error when loading the tokens (in the screenshot there is  "TokenService status: Load credentials finished with success"). This means that there was not encrypt / decrypt error when loading the tokens.
2.b. There is no failure or success for an access token request (basically there was no request). This means that the account was marked in auth error from the moment it was loaded. Note that
2.c. This means that the token service loaded an empty list of tokens from the DB and then entered an auth error state as it did not find any tokens for the authenticated account (see line https://cs.chromium.org/chromium/src/chrome/browser/signin/mutable_profile_oauth2_token_service_delegate.cc?rcl=56ee973ff5693c1a1801decb3cfa97ab3d6b56b3&l=359 )

paul.tietjens@mesd.us: Could you check if there are any tokens stored in your profile? To do that:
* Go to the profile folder in C:\Users\<username>\AppData\Local\Google\Chrome\User Data\Default (if this is the default profile).
* Use sqlite3 to list the contents of the file "Web Data" (this is an sqlite DB).
* Select all from the "token_service" table: "select * from token_service". You should have one entry like "AccountId-<account_id>|<encrypted_data>"
Do you see any entry like this in the DB after restarting the machine?

I must be doing something wrong, because the token_service table is empty before and after a reboot, whether signed in or not.

How many profiles do you have in Chrome?

One.

Running Proccess Monitor I can verify that this is the Web Data file opened by Chrome when launched.

Deleted: webdatafilemon.png 129 KB

	webdatafilemon.png 129 KB View Download

There is data, but not in this table.

Deleted: emptywebdatatokens.png 65.7 KB

	emptywebdatatokens.png 65.7 KB View Download

Let's do another test - create a new profile and sign in to that one. Here are the steps to do that:
1. Tap on the avatar icon in the upper right corner.
2. Select Manager People.
3. Select "ADD A PERSON"
4. Leave the name Person 1.
5. In the new profile, sign in to Chrome.
6. Close Chrome and check the token service table in C:\Users\<username>\AppData\Local\Google\Chrome\User Data\Profile 1

Do you see any rows in that table?

No, no change.

Strange. This means that the tokens never get stored for your profile. Was your secondary profile a normal one (or did it also have some special enterprise policy)?

It is important to make sure that you are checking the right profile folder. May I ask you to open all files with names "Web Data" in "Default" and "Profile <n>" folders under "C:\Users\<username>\AppData\Local\Google\Chrome\User Data"?

That certainly matches the symptoms.

No policy that I'm aware of. It is a Samba 3 domain, incapable of serving policies to Windows 10.

HKEYLM\Software\Policies contains no Chrome folder. I don't see any strange errors in Process Monitor when filtering for the "Web Data" file...

I understand it is important. I have done as you asked. The table is empty in each Web Data file.

Logging in as a local (non-Domain) account works, and there is a single row in token_service, even when setting user-dir to a folder also used by a domain account.

One thing I remember to ask (and I am sorry if I may have asked this already). The "User Data" folder is a local folder on disk right? Not a network redirected location?

It's on a local disk.

CC+ Roger (maybe he can help)

paul.tietjens@mesd.us: Thank you so much for answering our questions. From your answers, it looks like the problem cames from the fact that in the profile with cloud policy enabled, the tokens are not saved to disk (the file in <profile_directory>/"Web Data" is empty). Just for the sake of completeness, could you try to use a different local folder for your profile when signing in with a domain account?

pastarmovj@: I do not know what the cause for this may be. I am not aware of anything in the sign-in code that would block writing token data to the profile directory and this is the first time I came across something like this. Is this something that you could repro (otherwise, I do not see how I can help)? 

I have tried --user-data-dir on different folders. That doesn't seem to make a difference.

Paul, 
any chance you can arrange for msarda or me to log in to an affected machine and debug this issue on premise? If so you can mail any of us with instructions and we can see what we can find there.

That can be arranged, but it will be some time while I deal with other duties.

I have sent details for a remote connection to sample machine.

TL;DR; In a nutshell you have to set a value ProtectionPolicy to 1 (DWORD type) under HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\Protect\Providers\df9d8cd0-1501-11d1-8c7a-00c04fc297eb

Technical details: 

I nailed down the problem to one particular Windows API function which is used to store sensitive data on disk that is failing for this Windows account and therefore Chrome fails to store any sensitive data to disk (including these credentials, cookies, passwords etc.).

From my research this can be a cause of misconfiguration/bug of your samba store and some threads suggest the solution is to set one registry value to allow windows to store the needed type of data locally.

https://social.technet.microsoft.com/Forums/windows/en-US/47faab6b-d717-4068-bee4-c694811e0066/credential-manager-problems-error-0x80090345?forum=w8itpronetworking

https://support.microsoft.com/en-us/help/3000850/november-2014-update-rollup-for-windows-rt-8-1--windows-8-1--and-windo