New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 697369 link

Starred by 3 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 3
Type: Bug



Sign in to add a comment

Ephemeral Mode as User Setting in Group Policy

Project Member Reported by pastarmovj@chromium.org, Mar 1 2017

Issue description

I  work in an educational environment. We have roughly 1000 student Windows 7/10 machines in an Active Directory environment. We are running into security issues where students use a shared AD login ("Room100Lab") but sing into the Google Chrome browser using individual Google Accounts.
I tested the ephemeral mode as a computer policy and it works as expected. But I want students and/or faculty who log-in to Windows using their own individual accounts to work in the normal environment (not ephemeral mode). I want shared accounts to work in ephemeral mode. The same settings are available as a "User" policy rather than a "Computer" policy. I accompllish this by enabling loopback policies in AD, setting the ephemeral mode to "enabled" under the user settings, and permitting the "Apply Group Policy" security setting only for the shared user accounts.
This works partly. When the Chrome browser is closed and re-opened, the user who was previously logged into Chrome is still displayed in the title bar box. However, Google content is not available (Gmail, Drive, etc.). But another user can't sign-in without first going to settings and disconnecting the account being displayed.
Is there a way, applied as a user policy setting, to completely disconnect the account from Chrome when the browser is closed. Once again, this works fine when applied as a computer setting, but there's no way to specify who the policy should be applied to.

Thanks,  ...Kurt
 
Owner: blumberg@chromium.org
Matt to prioritize
Labels: -Pri-2 Pri-3
I've added this as a P3 on our list of priorities.  If we hear more reports of this we will consider bumping it up.  It sounds like one quick/easy work-around is to create role accounts for each machine. It is common in the EDU space that machines have a sticker 'PC-1' 'PC-2' with simple/shared passwords to log in to PCs (Especially in the K-5 space). While not ideal, it will resolve this issue and make it easier for admins to manage policy on a per-machine basis.
Project Member

Comment 3 by sheriffbot@chromium.org, Mar 6 2018

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Owner: georgesak@chromium.org
Status: Assigned (was: Untriaged)
This bug has an owner, thus, it's been triaged. Changing status to "assigned".
I would love to have this work as stated above in the OP. This would help in k5 schools where staff and students share PC's

Sign in to add a comment