Related to  crbug.com/548321 , but not sure if it's the same underlying cause

The domain name displayed there is sent down by the server, because the client is wiped in step 6.

Through my experimentation with this I've found that the "managed by" domain displayed is recorded on the device upon enrollment and is copied from the enrolling user's domain.

So let's say you have the domain example.com.  You also have sample.net, as well as subdomains sales.example.com and users.sample.net.  All of these domains are contained within one G Suite domain (let's say example.com is the primary).

user1@example.com enrolls a new Chromebook with his email.  The Chromebook will display "managed by example.com" until it is re-enrolled or reset (note: it does not have to be deprovisioned).

user2@sample.net gains possession of user1's device, performs Esc+Refresh+Power -> Ctrl+D -> Enter -> Space -> Enter to get the device back to the forced re-enrollment screen.  If user 2 re-enrolls the device with their email, the device will now display "managed by sample.net"  Neither user1 nor user2 is an admin, and user2 doesn't even need enrollment permissions via policy since it is a re-enrollment.  The "User" field of the device does not change in this process, it will continue to display "user1@example.com" unless an admin has changed it.

Now if user2 gets his domain changed to user2@users.sample.net, the device will not reflect this change in the "managed by" domain.  The same applies if user1 becomes user1@sales.example.com; the device's "managed by" field does not change, nor does the "User" field.  

The "managed by" also does not change when a device is moved across Organizational Units, but that's not really a surprise because there is not a policy that manages it.

Therefore it seems that the "managed by" domain is written to the local device upon enrollment or re-enrollment and not currently able to be changed by any enterprise policy.

I would very much like the ability to customize this field, since it would be useful in an EDU environment to know which school a device belonged to, for example.  Setting the field to say "Managed by Example Middle School" would be a great asset, but I think this is another request that's already been recorded and since lost in the abyss.

The server is sending display_domain. This issue is either obsolete or a client issue that was missed in the  crbug.com/548321  implementation. Assigning to the  crbug.com/548321  eng for analysis.

Server is sending display_domain only for policy responses.

However, in this case (FRE), we don't have any policy requests at early stages and device gets domain as |management_domain| field from DeviceStateRetrievalResponse: https://cs.chromium.org/chromium/src/components/policy/proto/device_management_backend.proto?l=1080&rcl=2cbab899749862da71732290935efdcbc97ecc19

Looks like the field is not updated on server side after domain is renamed and server still sends the old original domain name in response to DeviceStateRetrievalRequest.

So, it's a server issue - the server should already send the new domain name in DeviceStateRetrievalResponse - i.e.the same that server will want to send as |display_domain| in policy responses.
The issue can't be addressed on client side any other way as the device doesn't have any domain id - it only receives the first one from this response - and it's the wrong (old) one.

David, assigning to you to triage who'll handle this on server side. Feel free to file internal bug if it's easier for you to track.

Thanks for the detailed reply, makes sense. Raised b/77899022 to track the server change.

It should've already been fixed from ~Sep 2017 on server side.

If this is fixed from the server side, and fixed from the client side, do we need a new bug for a report on M63?

Verified fixed, after a primary domain change, FRE displays the new domain.

Tested the following:

Setup: enroll two devices to an OU with FRE  Have one of them on the user login screen and one of them mid-wipe.
- Verify that the device that was mid wipe can pick up with the new domain
- Verify that the device that was on the login screen can be wiped and force enrolled to the new domain

Chrome OS: 10718.22.0
Chrome: 68.0.3440.25