Issue metadata
Sign in to add a comment
|
FrE Enterprise re-enrollment screen is missing the "Managed by <domain>" text |
||||||||||||||||||||||
Issue descriptionChrome Version: M61.0.3163.120 stable cave OS: ChromeOS 9765.81.0 What steps will reproduce the problem? (1) Enroll a device in a OU with FrE or transfer the device to an OU with FrE. Reboot device. (2) Proceed through OOBE and when come to the Enterprise Enrollment screen, observe the Enterprise Enrollment dialog. What is the expected result? Under the "Enterprise Enrollment", there should be a "Managed by <domain>" text to indicate the device is designated to be forced enrollment in that domain. What happens instead? The "Managed by <domain>" text is missing. Same issue on M62.0.3202.50 9901.42.0 beta cave. No issue with M60.0.3112.118 9592.100.0 stable cave.
,
Oct 11 2017
+Ivan +Igor FYI It seems that the domain starts in InstallAttributes[1], goes through DeviceCloudPolicyInitializer::GetPrescribedEnrollmentConfig[2], gets transferred to the JS side in EnrollmentScreenHandler[3], then into gaiaParams in onBeforeShow(oobe_screen_oauth_enrollment.js)[4]. The lines doing the last mentioned step are: gaiaParams.enterpriseDomain = data.management_domain; gaiaParams.emailDomain = data.management_domain; Then it calls this.authenticator_.load(cr.login.Authenticator.AuthMode.DEFAULT, gaiaParams); authenticator_ is a cr.login.Authenticator defined in chrome/browser/resources/gaia_auth_host/authenticator.js. It seems to not support enterpriseDomain parameter anymore, as this got renamed to enterpriseEnrollmentDomain in https://chromium-review.googlesource.com/c/chromium/src/+/565574 which has been cherry-picked to M61. oobe_screen_oauth_enrollment.js is the only file still using the old name. We'll try to confirm that this is what is happening and run a CL ASAP to fix the parameter name there. [1] https://cs.chromium.org/chromium/src/chrome/browser/chromeos/settings/install_attributes.h?l=140&gs=cpp%253Achromeos%253A%253Aclass-InstallAttributes%253A%253Aregistration_domain_%2540chromium%252F..%252F..%252Fchrome%252Fbrowser%252Fchromeos%252Fsettings%252Finstall_attributes.h%257Cdef&gsn=registration_domain_&ct=xref_usages [2] https://cs.chromium.org/chromium/src/chrome/browser/chromeos/policy/device_cloud_policy_initializer.cc?rcl=21106965afc8e12bab1a1ad4646da1502dc4dcf5&l=179 [3] https://cs.chromium.org/chromium/src/chrome/browser/ui/webui/chromeos/login/enrollment_screen_handler.cc?rcl=21106965afc8e12bab1a1ad4646da1502dc4dcf5&l=683 [4] https://cs.chromium.org/chromium/src/chrome/browser/resources/chromeos/login/oobe_screen_oauth_enrollment.js?type=cs&q=attestationBased+file:.*%5C.js&sq=package:chromium&l=303
,
Oct 11 2017
CL up: https://chromium-review.googlesource.com/#/c/chromium/src/+/711837
,
Oct 11 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/8207e60c8cd0892312417f537db21a5e1aeaffcf commit 8207e60c8cd0892312417f537db21a5e1aeaffcf Author: Pavol Marko <pmarko@chromium.org> Date: Wed Oct 11 12:49:17 2017 Use correct field name for passing enrollment domain to Authenticator Enrollment domain was passed to cr.login.Authenticator in the wrong field, leading to the domain name not being displayed in forced re-enrollment usecases. In essence, this finishes a rename started in CL:565574. BUG= 773554 TEST=Manual: Verify that domain is displayed on forced re-enrollment. Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation Change-Id: I002d556c905bb3b3f93c28c7baf5de63778866e1 Reviewed-on: https://chromium-review.googlesource.com/711837 Reviewed-by: Maksim Ivanov <emaxx@chromium.org> Reviewed-by: Bernhard Bauer <bauerb@chromium.org> Reviewed-by: Ivan Ĺ andrk <isandrk@chromium.org> Commit-Queue: Pavol Marko <pmarko@chromium.org> Cr-Commit-Position: refs/heads/master@{#507960} [modify] https://crrev.com/8207e60c8cd0892312417f537db21a5e1aeaffcf/chrome/browser/resources/chromeos/login/oobe_screen_oauth_enrollment.js
,
Oct 11 2017
Thank you Pavol for fixing this! I think it may be too late to merge this to M61, but M62 is maybe a good candidate.
,
Oct 11 2017
Fixed on ToT (will reach M-63) with the above CL. I've done dev verification on 63.0.3238.0 with the CL patched in. I don't believe this should be a blocker for previous releases, as it's only a display issue and you can still see the domain after the @ sign on the screen.
,
Oct 11 2017
Pavol/Ivan, do you think it will be hard to write a regression browser test for this bug? I didn't manage to find any FRE test that involves going through the screen in question, but the EnrollmentScreenTest seems to contain similar non-FRE tests - probably it can be used as a starting point?
,
Oct 12 2017
It looks like it should be possible to trigger the enrollment screen in that mode and check webcontents to see if the domain is being displayed. Filed bug 774001 so I don't forget.
,
Jan 22 2018
,
Jan 23 2018
,
Feb 28 2018
Verified fixed. FRE Enterprise re-enrollment screen is showing the "Managed by <domain>" text (see attachment). Chrome OS: 10323.46.0 Chrome: 65.0.3325.107 Devices: Kevin, Blaze |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by krishna...@chromium.org
, Oct 11 2017Labels: -Pri-2 M-61 Pri-1