Unexpected behavior for "Restict which users are allowed to sign in to Google Chrome" GPO
Reported by
briped...@gmail.com,
Aug 23 2017
|
|||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Safari/537.36 Steps to reproduce the problem: This might be somewhat the same as 471268, where I've commented. But as that one has status WontFix I assumed that no one is actually going to see that comment. 1. Enable the "Restrict which users are allowed to sign in to Google Chrome" GPO, and restrict it to a very limited set, such as "^$" or "verySpecific@mailaddress.com". 2. Apply policies on computer, very in about://policy that the GPO is applied. 3. Sign in to Chrome (or attempt to). What is the expected behavior? The expected behavior when restricting to nothing "^$" is that the option to sign in (the button) is removed. The expected behavior when restricting to limited set "verySpecific@mailaddress.com" is to get the blocked message on the screen after entering an e-mail address which isn't allowed. What went wrong? Instead of stopping the login process after having entered the e-mail address, the login process continues to ask for the users password and even to ask for the users 2-factor information. Did this work before? No Chrome version: 60.0.3112.90 Channel: stable OS Version: 10.0 Flash Version: Going through the entire login process, and only giving the "blocked" message after having gone through the entire login process, is counter-intuitive and is wasting time, not to mention potentially transmitting sensitive login credentials to Google services (or whatever MitM attack that could potentially exist in-between?), because as it is an integrated login process, the user will trust it more and think it's part of the organisation login process. This gives unnecessary support calls to the helpdesk as to why it fails or to please unlock their account (users don't read the message, they just see "blocked" or "locked" or "failed")
,
Aug 25 2017
Able to reproduce this issue on Skytap environment with Win2K12 as server and Win7 as client with chrome #60.0.3112.90 Precondition: 1. Enable restrict sign in pattern with one gmail address Steps followed: 1. In the client machine, launch chrome and click on browser sign in 2. Try to signin with different gmail address Observations: Even though we entered different gmail address other than policy, it has asked for a password and after entering the password it displayed a error "Can't sign in---" Attaching the screencast for reference. briped.dk@ Could you look into it and let us know any steps i have missed while reproducing the issue. Thank You...
,
Aug 25 2017
From the looks of it, you haven't missed any steps. Only comment to your steps is that the you should try enabled 2-factor for the test account (the one that isn't allowed). This shows the issue even more clearly; i.e. that the entire login process is completed and the account is actually being authenticated (only way to validate 2-factor), before access is actually denied.
,
Aug 28 2017
Hi guys, im not 100% sure that i got the same problem, maybe i should create new issue. If yes please tell me. Its my post from here: https://groups.google.com/a/chromium.org/forum/#!topic/chromium-discuss/Bls9SQmeRck "Hi, i got a question. Im trying to use admx template to allow only certain addresses sign in to chrome in my domain. I got in Computer Configuration > Administrative Templates > Google > Google Chrome policy as Enabled (Disable Synchronization of data with Google) and Restrict which users are allowed to sign in to Google Chrome - i got this pattern here oneuse...@gmail.com|seconduserlogin@gmail.com. I got domain users logging to profiles with radius so my admin user goes to other vlan that my normal user. And on admin profile i can sign in only for this two accounts enabled with *Restrict which users are allowed to sign in to Google Chrome - i got this pattern here oneuse...@gmail.com|seconduserlogin@gmail.com.) and it WORKS FINE. On normal user profile i can sign in with all accounts. How can i debug it and know why it happens?" In chrome://policy value of the RestrictSigninToPattern is OK for all accounts. Im not 100% sure that admin privileges makes the difference. i should get on user profile information that i can not login but it let me sign in to other account.
,
Aug 28 2017
,
Aug 28 2017
This is a known issue (go through the entire process before actually failing). For now, we don't have an immediate solution. +rogerta +zmin
,
Aug 29 2017
So, can You please confirm that value userlogin1[at]gmail.com|userlogin2[at]gmail.com should let sign in only for this 2 users, other addresses should get login failed? Where exactly is the problem - is it admin and non admin account? Can i temporary do anything to block all users with signing in? Or maybe i can let only 3-4 adresses to be used in other way?
,
Aug 29 2017
@Comment 7: Not sure who you're directing your questions at, or how it's related to this issue. The GPO in question let's you restrict who's allowed to login. The issue here is that it goes through the entire authentication process before actually informing the user that the login used is blocked from logging in, by the system administrator (GPO administrator). Your questions is essentially answered here: https://www.chromium.org/administrators/policy-list-3#RestrictSigninToPattern The following is a shorther regex to achieve the same as your example: ^userlogin(1|2)@gmail\.com$ Whether it's an admin or non-admin account has no relevance to the issue. Restrict by typing a regex that can never be matched by a valid e-mail and you're essentially blocking all users from signing in, but they still go through the entire authentication process before being informed that their login is blocked. That is the issue handled here. The following will match nothing, ie. no one can login: ^$
,
Sep 13 2017
--Chrome Identity automated triaging-- This bug is Untriaged and has gone for two weeks without any activity, so it is being moved to Available. Please see https://goo.gl/78kbny for more details. Please remove the Services>SignIn or UI>Browser>Profiles components if this bug isn't related to Chrome Identity. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Sep 21 2017
This is more of an Enterprise issue than a Sign-in issue, per-se. Removing our component so you stop getting nagged by our sheriffbot.
,
Nov 5
|
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by ligim...@chromium.org
, Aug 23 2017Labels: Needs-Triage-M60