Regression : Enable SAML SSO for Chrome devices by default
Reported by
arnaud.h...@test.airliquide.com,
Jun 24 2016
|
|||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; CrOS armv7l 8172.56.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36 Platform: Platform 8172.56.0 (Official Build) stable-channel nyan_blaze Steps to reproduce the problem: 1. At the first logon, create add a new user 2. Type your corporate email account only 3. SSO IdP login page prompts to enter Windows credentials 4. Type again your corporate email account only 5. Sign-in failed page What is the expected behavior? SAML SSO login should not be triggered since not enabled into cPanel (cf. Take users to SAML SSO IdP login page device policy) What went wrong? Appears sign-in error page and all new Chrome devices users cannot log in on any devices. Did this work before? N/A Chrome version: 51.0.2704.103 Channel: stable OS Version: 8172.56.0 Flash Version: Shockwave Flash 22.0 r0 Please advise when this kind of policy is pushed on the console furthermore one related policy is disabled into cPanel. By default, this policy at the user level should be disabled.
,
Jun 24 2016
,
Jun 24 2016
Is it correct that you use the following configuration? 1. device policy "Redirect users to SAML SSO IdP" = "Default. Take users to the default Google login page" 2. user policy "SAML-based Single Sign-On for Chrome Devices" = "Disable SAML-based Single Sign-On for Chrome Devices"
,
Jun 24 2016
1. YES 2. NO (since it has been enabled by default that's why error appears) ..But after switched to Disabled it works like before.
,
Jun 27 2016
We've received 2 enterprise customers reporting this issue, confirmed reproducible locally using several test accounts as well.
,
Jun 27 2016
Bin, PTAL - have we changed the behavior of this dropdown recently?
,
Jun 28 2016
,
Jun 28 2016
Just to summarize our findings here, taking into account that all cases below require that the domain have the the Chrome policy "SAML-based SSO for Chrome Devices" enabled and has been reproduced on M49, 50, 51 and 53. Also we've noted that crbug.com/622945 seems related to this. 1. If the domain has SSO settings configured in the Admin console, but disables the setting under security to actually use SSO, it will still redirect on login 2. If user signing into a Chrome device is a super admin, they still get redirected 3. If the domain has a network mask in place where SSO should be ignored, the mask is disregarded and SSO redirection takes place 4. If SAML SSO is enabled for Chrome devices, but the "Sign-in page URL" is invalid or blank, redirection takes place, and returns a 500 error
,
Jun 29 2016
I'm agree with those cases but at the end the only issue was having this chrome policy enabled by default. On our side, SSO has been enabled from the beginning for Windows users but not for Chrome devices where we have still issues (look like the fourth point you mentioned). That's why, all new Chromebook users were impacted not only admin one.
,
Jul 12 2016
This issue should be fixed by now. Fix is on server side, so affected users do not need to update Chrome or change channels. b/29990720
,
Jul 13 2016
Trapti to verify.
,
Jul 26 2016
@Kaishenc Could you please check default values of this settings in CPanel?
,
Jul 26 2016
,
Jul 26 2016
After creating a new test domain and enabling SSO for the domain, the following is the result. Device settings page: - CPanel:Signle sign-on idP redirection - > Default. Take users to the default Google login - Policy on device: loginAuthenticationBehavior -> not set User settings page: - CPanel: Single Sign-on - > Disable SAML-based Single Sign-on for chrome devices - Policy on device: SAMLofflineSigninTimeLimit -> not set
,
Jul 27 2016
Based on comment#14 default values looks correct. Verified in Candy M ChromeOS Chrome ARC Type Channel 51 8172.62.0 51.0.2704.106 2778284 release stable |
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by pbond@chromium.org
, Jun 24 2016