Being a Windows System Administrator: "Interactive logon: Machine inactivity limit" policy gets triggered by disabled screensaver's timeout

This is just a quick post about how Microsoft managed to keep me busy for a couple hours on what should have been a simple 5-minute job.

After months and years I have finally managed to get the higher-ups to agree on implementing the "Interactive logon: Machine inactivity limit" local security policy after I proved to them that we have a number of users who do not lock their machines even over night or even the weekend.

Previously all we did was enable the power saving option for the monitor but let the user disable that if they had any kind of issue with it or "simply do not like it".

Anyway, I finally got the green light and enabled the policy with a 1200 seconds timeout on inactivity. And that is were most of my workday suddenly got a lot busier than I had it expected to be.

I did test the policy on a few systems and they all locked themself properly after the 20 minutes (1200 seconds) specified in the policy. So I rolled the policy out to all our 5000 clients. Fast-forward about 90 minutes and a number of tickets kept rolling in.

They all read similarly: "Computer is locking after 1 minute", "PC locks itself after 3 minutes", ...

So the relation between the tickets and the policy was obvious. But why would a computer lock itself after 1 minute or 3 minutes when the policy clearly says 20 minutes? "secpol.msc" showed that the correct value had been applied. Power saving settings had the monitor timeout on either "Never", our default of 20 minutes or even higher values. So this was not the cause of this issue either.

While talking to one user she mentioned that until now she had been able to get rid of her screensaver by simply moving the mouse. But now she had to actually enter her password to unlock the machine. And indeed her screensaver timeout was set to just 1 minute.

After talking with a couple more affected users and checking their screensaver settings a pattern emerged. They all had relatively low screensaver timeouts set - between 1 and 5 minutes. However, some of them actually did not have a screensaver selected but instead had it set to "(None)" with the timeout field greyed out.

After some testing on my own machines it quickly became clear that the "Interactive logon: Machine inactivity limit" policy was doing something weird ...

The documentation on the policy clearly states the following:

"If the Interactive logon: Machine inactivity limit security policy setting is configured, the device locks not only when inactive time exceeds the inactivity limit, but also when the screensaver activates or when the display turns off because of power settings."

So yes, the screensaver turning on and Windows requiring the user to enter their password is by design and actually quite sensible.

What the documentation kind of neglects to mention though is the fact that it still "respects" the screensaver timeout period even though the screensaver had been disabled - set to "(None)".

So if a user had previously configured a screensaver and later decided that they did no longer want to use a screensaver Windows would now suddenly lock the machine after a much shorter period than the 20 minutes configured in the new policy because there was still the stray screensaver timeout stored in the user's registry.

Great. A couple thousand potential tickets. Good start into the week. Not.

The fix itself is quite easy though. Simply change the screensaver timeout to something that still lets the user work but does not exceed the number of minutes specified in the policy. (Windows will silently not accept any number entered into the screensaver timeout field greater than the policy value and will silently reduce it to that number). For people with "(None)" selected for their screensaver, simply select any other screensaver, change the timeout to "20" or whatever other value, then change the screensaver back to "(None)".

After figuring this out and fixing the issue for the users we already had tickets for I dug into the registry and found the relevant registry keys to be the following:

[HKEY_CURRENT_USER\Control Panel\Desktop]
"ScreenSaveTimeOut"="300"
"SCRNSAVE.EXE"="C:\\WINDOWS\\system32\\ssText3d.scr"

The "ScreenSaveTimeOut" key clearly specifies the timeout until the screensaver turns on while the "SCRNSAVE.EXE" key specifies the selected screensaver. If "(None)" is selected the "SCRNSAVE.EXE" key gets deleted, but the "ScreenSaveTimeOut" key sticks around - and causes the issue described above.

To fix this issue on a bigger and more automated scale I decided to whip up a little temporary policy with item level targeting to fix "broken" entries.

The XML below is a copy of the "Registry.xml" file directly from the policy. Basically what it does is the following:

If a screensaver is configured ("SCRNSAVE.EXE" key exists) and the value of "ScreenSaveTimeOut" exceeds "1200" (20 Minutes) then reduce the value of "ScreenSaveTimeOut" to 1200
If no screensaver is configured ("SCRNSAVE.EXE" key does not exist) then delete the "ScreenSaveTimeOut" key

After a restart of the machine (at least a logoff is required) the user's screensaver setting should no longer interfere with the "Interactive logon: Machine inactivity limit" policy and everyone should be happy again.

Especially me since I can go back to dealing with more important and entertaining stuff.

<?xml version="1.0" encoding="UTF-8"?>
<RegistrySettings clsid="{A3CCFC41-DFDB-43a5-8D26-0FE8B954DA51}">
  <Registry clsid="{9CD4B2F4-923D-47f5-A062-E897DD1DAD50}" name="ScreenSaveTimeOut" status="ScreenSaveTimeOut" image="7" changed="2022-05-31 11:57:03" uid="{BFD218A2-6EDC-4750-8D42-BA912310DC8B}" bypassErrors="1">
  <Properties action="U" displayDecimal="0" default="0" hive="HKEY_CURRENT_USER" key="Control Panel\Desktop" name="ScreenSaveTimeOut" type="REG_SZ" value="1200" />
  <Filters>
  <FilterRegistry bool="AND" not="0" type="VALUEEXISTS" hive="HKEY_CURRENT_USER" key="Control Panel\Desktop" valueName="SCRNSAVE.EXE" valueType="REG_SZ" valueData="" min="0.0.0.0" max="0.0.0.0" gte="1" lte="0" />
  <FilterRegistry bool="AND" not="0" type="MATCHVALUE" subtype="VERSION" hive="HKEY_CURRENT_USER" key="Control Panel\Desktop" valueName="ScreenSaveTimeOut" valueType="REG_SZ" valueData="1200" min="1200.0.0.0" max="65535.0.0.0" gte="0" lte="0" />
  </Filters>
  </Registry>
  <Registry clsid="{9CD4B2F4-923D-47f5-A062-E897DD1DAD50}" name="ScreenSaveTimeOut" status="ScreenSaveTimeOut" image="8" changed="2022-05-31 11:49:11" uid="{040654C3-576D-4625-B8D7-6395789A932F}" bypassErrors="1">

[1] https://www.reddit.com/r/SysAdminBlogs/comments/v1wrdm/interactive_logon_machine_inactivity_limit_policy/?

[2] https://twitter.com/BeingSysAdmin/status/1531722110154027009

Being a Windows System Administrator

2022-05-31

"Interactive logon: Machine inactivity limit" policy gets triggered by disabled screensaver's timeout

No comments:

Post a Comment