This looks like WAI, cause the owner key is now invalid. @lawrence could you please comment.

Noted that long after the rename of domain, despite a number of user sessions with new domain, during a forced re-enrollment, the old domain is shown again instead of the new domain name.

Attached screenshot. The old domain name is cdm-rename1.jaylee.us and the new domain name is renamed-cdm1.jaylee.us.

Deleted: IMG_20170530_184806.jpg 6.1 MB

	IMG_20170530_184806.jpg 6.1 MB View Download

I didn't know a "rename domain" feature exists.

Is it this?
https://support.google.com/a/answer/7009324

If yes, it looks like "Chrome device management" is one of the "currently not supported" cases here:
https://support.google.com/a/answer/6301932?hl=en

Or is this a test case you do regularly and this was a regression?

Sorry pmarko@ I had wrongly assigned this to you. It's a test for us to find out any issues would occur with migration of domain name.

I believe that:

1) This has more to do with the USER rename than the domain rename and can be simulated without domain rename by renaming a user and removing the alias they are given that is their old email.

2) This is expected behavior. If a user is logged in while their account is renamed and the alias is removed, the user session is invalidated.

3) If user logs out and logs back in as their new email address they should get a new profile and policy should sync properly.

I suppose we could solve this by doing the user policy sync based on unique user ID rather than email address but that would be a pretty major change and we don't hear of very much concern from customers that policy sync breaks for logged in user when they are renamed.

Assigning to lawrencelui@ to determine if this is WAI or not for domain rename work.

After speaking with krishanrgv@, since the local login is cached, item (3) in comment #6 does not trigger during login. The only way to currently work around it is to remove the user locally and re-add, as indicated in the original message. 

I think given the current design it is WAI, so in the short term we can warn customers of the consequences. However, I will file an FR to handle this more gracefully. Ideally the user could see a GAIA prompt similar to when they change their password. I'll file an FR for that.

For Comment #2, that sounds like a separate bug which I can file

Filed  crbug.com/728361  for comment #2

"Some of the user policies under the enrolled OU is no longer in effect"

jingwee@ can you list some examples?

OK, spoke more with krishnargv, and there are a couple of important findings:

1. After taking the repro steps, user policies stopped syncing altogether, which can have security implications (stale policies). It wasn't a matter of some policies working, and some not.

2. We suspected this might be related to username change. However, simply renaming the user did not produce the same bug. It seems like the client is reacting differently when the rename is due to a domain change. 

I don't think this is WAI; I think it is a bug with a workaround of deleting the user, which is a blocker for domain rename on CDM domains.

Drew who would be the best person to take a look?

If you change the domain of a user, future policy fetches for those users will fail - this is WAI, as we require that the user email + domain remain consistent (it is part of the protections we've built to guard against policy injection, so you can't inject policy from user A into user B's session).

If you rename the user, you need to delete the user account. Please see comment #36 here: https://b.corp.google.com/issues/24007965#comment36 where Jay confirms that renaming users is out of scope for this feature - has this changed?:

"regarding Andrew's comments in #29, we are not concerned with dasher user rename here. We are concerned with the change of primary domain for the dasher customer. While user rename may (or may not happen) as part of customer's steps to change primary domain, user rename is NOT something new to dasher, it's been around for at least as long as managed Chrome OS has.

Expected behavior here is that once user's primary email address is changed, Chrome OS login will see it as a new profile. I've not seen any concerns from customers regarding user rename."

So I don't think this issue should be viewed as a blocker.

If we want user policy fetches to continue to work on these obsolete domains, then DMServer needs to continue to send down the original email address for that user as the username field.

I am somewhat confused about why about://policy is complaining about an invalid DMToken. jingwee@ can you add logs from the client?

Zhanlu, any thoughts about invalid DMToken? Are you able to pair up the client ID from the about:policy screenshot with your server logs to see if you see anything odd there?

atwilson@ all the logs I gathered from the client was already attached in the original post.  Are you looking for particular logs absent from the archive file?

Krishna and I both did further testing on this and got same result for 1 and 2 by changing username portion of email and not the domain portion.

1) simply renaming a user does not break user policy sync because the user's old email address is kept as an alias and this is apparently sufficient to map back to the correct user.

2) If the alias is deleted, user policy sync breaks with the "invalid device management token" error. User needs to log out and login with correct new email address though this may be non-obvious, especially in cases where user photos are shown on login page (and email address is only visible when clicking triangle).

3) Since user rename predates Chrome OS itself, this is not a new issue but it may be something customers are more likely to run into with primary domain change scenarios.

I do not consider this a blocker to primary domain change but it's something we should include in admin documentation as a problem they may face.

Ultimately, if we want to tackle this issue, we should look at syncing user policy based on user ID, not email address since user ID is consistent for life of the Google account and email address is not. One other shorter-term solution might be to force removal of the profile on logout if we've been getting the user profile sync error as described above. Not sure on feasibility of this but it would allow a straightforward way of cleaning up the dead profiles in fairly short order.

Chrome OS started on the long path of migrating from e-mail addresses to obfuscated GAIA IDs a while ago. But a lot of places still rely on e-mails and in some places, we do not have the mapping from e-mail to GAIA ID.

If Jay doesn't think this is a blocker, then it's fine with me (just might cause some occasional headaches for support). Having users log in with a fresh profile is probably still easier than wiping/enrolling every device for many customers.

A couple of things:

- Is there a tracking bug or list of efforts to move from email to GAIA ID? This might just be a dupe of that IMO
- I am thinking that switching to ephemeral mode, then cleaning up devices that don't sync for a period of time manually might be the best recommendations for admins once we unblock primary/secondary domain switch. Reasoning is, admins are likely expecting a transition period anyway if they are swapping domains. Are there any concerns with this solution?

Re #18:

* The tracking bug is crbug.com/462823 though as you can see, there is not much happening there anymore.
* Using ephemeral mode to clear out orphaned profiles SGTM.

Alex, what's the status of the email->id transition?

We met, and it sounds like the tentative target is M63

+components/signin owners:

+rogerta@
+msarda@
+droger@

There are several ways to fix this issue, but the easiest one seems to enable migration for all OSes: https://cs.chromium.org/chromium/src/components/signin/core/browser/account_tracker_service.cc?l=259

Are there any known issues, or we can just flip the bit?
My simple check shows that it works.

CC+ Xiyuan.

Chrome desktop and mobile have migrate and are using the Gaia user id as the identifier. This means that they are safe for user changing their email.

Xiyuan: Are there any plans to migrate ChromeOS to use the Gaia user id as identifier? If not, what are the blockers for this migration? 

cros is the only remaining platform that has not moved to gaiaids as primary account identifier for everything.  It will be super cool to see it working there too!

Alex: you say "simple check shows that it works", but I still see a few TODOs and commented out code here:

https://cs.chromium.org/chromium/src/components/signin/core/account_id/account_id.cc

When I was reviewing the CLs for crbug.com/462823, we agreed these things had to be fixed before migration could be enabled.  Have things changed since then?  When will these TODOs and commented out code be addressed?  Are there other source files that also need attention?

+rkc

Re #23: I think the plan (as in issue 462823) is still there But I have not followed closely on the current status. alemate@ knows the most on this front. FWICT, the crypthome part is done but there are still chrome parts that depend on e-mails and need migration code.

I'll look into the code and check it.

As I mentioned in Comment #14, we use the user's email address as a key identifier during policy verification. There are currently no plans to migrate this to Gaia ID, although it's likely not a ton of work. I'm tracking that work at  crbug.com/780792 

I see  crbug.com/780792  is marked as fixed (woohoo!). Should we consider this issue to be resolved too?

I am going to take a look at it soon.

While  crbug.com/780792  is fixed on client side, required server side change is not yet submitted

Verified in M68.0.3440.25 10718.22.0 dev kevin,reks,coral that user policies fetch works without issue even when the old username was still shown in policies page and continued to work fine after replacing the old username with new username by adding the new user at sign-in.