Google Admin>Devices > Chrome > Settings >Users & browsers > Idle settings aren't working?

[bjohnson]

Google Admin>Devices > Chrome > Settings >Users & browsers > Idle settings aren't working?

We have issues in our School with users not locking their Chromebooks and leaving them accessible. As this is privacy concern that needs enforcement, I was hoping I could set a "reasonable" time for idle> sleep/lock setting. I've tried multiple values in setting from 60 secs - 45min, and it never seems to work as described... If its less then the "hardware" Default it will function IE 60 secs 1 min ut anything >9 min seems to never work or at least never makes it to full length of time. Avg has been 8 min, but I have occasionally seen 15. It's almsot like soem default or hardware/manufacturer idle/power settings, when less than, take precedent over ChromeOS and Google Admin settings. Spent 2 hours online with Google support and didn't get anywhere except possible escalation... may here back but we use fundamentals so not expecting any rush. My issue is from a privacy concern enforced logouts on idle are kind of a big thing but getting logged out mid class for a teacher is a pain too. Anyone every found a good solution for Chromebooks?

[MAuger]

Just a thought , have you checked to see if there is any extension causing the unit to stay awake? Keep Awake bypasses that setting (We have disallowed the extension and others). 

[bjohnson]

Keep Awake defeats the prupose of the "idle" lock which is to prevent unattended access to a users account... After 6 hours I think I figure it out... Its the wording and menu layout, plus the fact that sleep doesn't work as expected.

The following didn't work... and I believe it is becaue of Sleep being the locking action and sleep can be in acted by others settings... IE the Screen Off is still set as system default even if not managed and screen off work like/with Sleep.

Action on lid close: Sleep

Lock screen on sleep or lid close: Lock Screen

AC idle action: Sleep

AC Idle Delay in Seconds = 2700

- Enter zero to never take the idle action. Leave empty for system default.

AC idle warning delay in Seconds = def

- The warning appears only if the idle action is logout or shutdown. Enter zero to never show an idle warning. Leave empty for system default.

AC screen dim delay in seconds = def

-Enter zero to never dim the screen. Leave empty for system default. Does not affect screen dim on lock screen.

AC screen off delay in seconds = def

-Enter zero to never turn off the screen. Leave empty for system default. Does not affect screen off on lock screen.

AC screen lock delay in seconds = def

-Enter zero to never turn off lock the screen on idle. Leave Empty fro system Default

The Following worked for what I needed though and as expected - 

Action on lid close: Sleep

Lock screen on sleep or lid close: Allow User to configure

AC idle action: Logout

AC Idle Delay in Seconds = 2700

- Enter zero to never take the idle action. Leave empty for system default.

AC idle warning delay in Seconds = 2400

- The warning appears only if the idle action is logout or shutdown. Enter zero to never show an idle warning. Leave empty for system default.

AC screen dim delay in seconds = 1800

-Enter zero to never dim the screen. Leave empty for system default. Does not affect screen dim on lock screen.

AC screen off delay in seconds = 2520

-Enter zero to never turn off the screen. Leave empty for system default. Does not affect screen off on lock screen.

AC screen lock delay in seconds = 2640

-Enter zero to never turn off lock the screen on idle. Leave Empty fro system Default

[Kim_Nilsson]

The idle action shouldn't have to be Logout, as that's disruptive, and the goal is security.

Lock is enough.

[bjohnson]

Agreed it shouldn't but the Sleep option locks all the other timers. It is not possible to enter any other timer other than Idle is sleep is the action. Unfortunatelt the sleep function is seemingly tripped by more than the idle action, (IE Lid, powersettings, hardware etc...) For whatever reason setting sleep as the idle actions never seems to function as expected (ie according to the timer) Average time has been 8 min when using sleep, and if I combine it with "lock" on sleep to privide security it becomes even more disruptive than Logout.... I guess the idle action timer coudl be set to 0 sot it never logs out and the other timers set to "lock" and "sleep" the device, I just haven't tested it. I just know the sleep + lock doesn't function as we need. There are a lot of forums out there saying similar things.

[Kim_Nilsson]

That sounds wrong.

Not all of it, of course, but the bit that "lock is more disruptive than log out".

Logging out you will lose everything that was active, and not saved, whereas Lock will only force you to enter your password, and everything is exactly as it was.

The rest is beyond what I have tested, as I have never ever wanted our users to be fully logged out on idle.

[bjohnson]

Perhaps I should add that these Chromebooks are connect to TVs + projectors fro instruction and that not all Teachers are interaction with them continuously throughout. For disruptive, I meant that Sleep + Lock (Lock screen on sleep or lid close) as the action since sleep occurs more often, for whatever reasons , users are getting "locked" every 10 min. Yes from an sys admin that seems acceptable and Safe but from an in front of class teaching it is fairly disruptive. "LogOut" seemed to be the only idle action that lets you set timers on the other actions but turns out it was just the "warning" timer; but does seem to be the only action that only triggers on the idle timer only. I can see what you mean for sleep being idle action, just not comibed with the above (Lock screen on sleep or lid close) setting set to "Lock." Down side of using Sleep as the idle action is that in all my tests it never seems to reach timers greater than 8 mins; meaning it still blanking the screen during instruction. Not even Google support could tell me why though... 45 min is a Class period and honestly if they leave alone them alone that long then logout isn't truly a bad thing. Everything is cloud saved so not a big risk in loosing much when being logged out. If sleep only trigged on the idle actions times, I could see this being more beneficial being done as you described and setting jus the Screen lock delay time and not the lid/sleep action to lock.

[DannyMc]

What about these settings:

AC Settings	Battery Settings
AC idle action = Sleep	Battery idle action = Sleep
AC idle delay in seconds = 900	Battery idle delay in seconds = 900
AC idle warning delay in seconds	Battery idle warning delay in seconds
AC screen dim delay in seconds = 600	Battery screen dim delay in seconds = 600
AC screen off delay in seconds = 900	Battery screen off delay in seconds = 900
AC screen lock delay in seconds = 900	Battery screen lock delay in seconds = 900

[bjohnson]

I've tested that... with Google Support on the phone too. It never reaches 15 min for sleep. Seemingly something else always triggers sleep first. Averaging around 8 mins. I confirmed each time in chrome://policy that the timers were correct before starting a stop watch and waiting. Seems silly but nearly every test I ran if Sleep is the idle action it wouldn't reach timers longer than 8  min. I'm not sure if its some kind of hardware thing or some kind of power save feature must trip sleep before Idle Action. whne combine that with Lock it makes it more disruptive then secure. Using Logout lets me set timers for more than one action, so as I mentioned above I guess maybe I could set idle action to zero so it never "logs out" but still set timers for Screen off and lock dim and warning aren't really required either I just used them as markers to check against the stop watch during my tests.

2 days so far and no additional complaints from when I first set it to sleep as the action.

[DannyMc]

The only other thing that caught me out when I was testing this was:

Apply at the Root OU if all other OUs are inheriting for this setting

Othwise if not, the setting must be applied at the correct OU and NOT at the Root OU

i.e. should be applied at Staff and Student OUs in order to cascade down

[mhermmsd]

I have this same issue with our devices.  We have chromboxes connected to TVs for teachers to display and I have played around these settings for sleep with no success.  Does not matter what we set it too, it always sleeps after about 8 minutes of non activity.  I thought I had remembered reading somewhere that Google does this as default for security reasons, but then why give us the settings.  I have not tried the logout settings but maybe will have to try that if that is what works and set it to logout after 2 hours.  For now we just use the Keep Awake extension.

[bjohnson]

I think if you went this route you may not need "Keep Awake" which is something of a security risk... So far our devcies no longer seem to go to sleep because the idel acction is no set as such... Setting the screen off timer to so close to the "logout"  means we get nearly a full 45mins before they do anything. I have had no complaints about sleep like I had before I even tried to secure it with locking on sleep.

[Kim_Nilsson]

I was JUST about to suggest Keep Awake! 😁

But, I actually do not see it as a major risk, as this keeps the device awake the entire time, meaning the teacher must actively log out or lock the device at the end of the class, or they will see that they are still logged in.

Secondly, it's an easier thing (for staff) to learn, to always log out at then end of the class, instead of you trying to automate locking of devices, in a way that does not interfere with the real work they are doing.

[bjohnson]

I feel Keep Awake,  just bypasses features designed to protect user account access. With The advent of SSO more prevalent it is way too easy to have a user logged in and walk away and have anyone, even students walk up and access just about anything without needing to know any passwords. There was loaner machine that they keep in the office to hand out as needed that I picked up at random and found a staff user still logged in, no lock, and still open to a student's medical information... If that had been handed out to a student it would have been a HIPAA violation. I believe this to also be a part of the NIST framework risk assessment points, under account access protection. Sleep+ lock has been a sysadmin standard for a long time especially in Windows environments. While it should be the staff's  responsibility it is often scape goated as human error but when it comes to data privacy not having protections against human error is I think a bad thing for a sysadmin. "LogOut" is probably not the greatest option, but Google Admin doesn't let you use "lock" as an idle action by itself, and by setting the idle action to Logout instead of Sleep the devices are not needing the "Keep Awake" ext. because they are not going to sleep as often.  If the Sleep as Idle action worked as timed, without other actions also causing sleep then yes; combined sleep and lid close action being Lock, I would agree Sleep+ Lock is better and Staff can be responsible for logging out.

[Kim_Nilsson]

Of course. If you can't train your humans to do their job properly, it becomes a technical issue.

Your solution follows some simple rules, which humans should cope with, but since they don't, they will have to suffer the consequences, which is better than a data leakage. Agreed.