[English]A German blog reader noticed that the local security policies for locking a user account during inactivity seem to stop working on Windows 10 and Windows Server 2016 and 2019. I'm going to put it up for discussion here, maybe the community can contribute to the clarification.
What exactly is it about?
Windows has local security policies to lock user accounts after a certain period of inactivity, so that the user has to log on again. Blog reader Heiko A. has now noticed that exactly this is probably not working under Windows 10 and Windows Server 2016/2019 anymore. In a first mail he wrote me last week:
Inactivity limit not working (security policy)
I have recently noticed that the inactivity limit that can be set under the local security guidelines no longer seems to apply. I noticed this with Windows Server 2016 and 2019 as well as Windows 10 Pro, Education and Enterprise. The goal is to automatically lock the computer after a certain time window (inactivity). Even the "dynamic lock", which can be activated under Windows 10 when the OS detects an absence, does not work on some of our customers' PCs. Do you know something about this?
Of course I didn't know anything about it, so I asked him for more details and decided to post it here in our blog for discussion.
Heiko, who works in the health sector of the IT industry, answered my question how he became aware of the issue. He wanted to set an automatic computer lock on Windows Server 2016 Standard via the local security policy. A customer had noticed that the automatic lock had stopped working since the 'last Windows update'.
- Heiko then tried the security policy with 10, 30 and 60 seconds timeout, but nothing worked.
- He then checked the advanced settings in the power options, but the fields were empty, so unused.
Since he couldn't find an update that could possibly cause this problem, he tried the same with another customer running Windows Server 2019 Standard, but without success. The computers used by the customer have Windows 10 Pro. However, the inactivity limits set by security policies do not apply there either.
His employer uses Windows 10 Enterprise. There, the local security policy does not take effect at the individual workstation or as a rolled out group policy by the internal IT. The internal IT staff was amazed and follows Heiko's advice that the security policy does not apply.
Here you can find the settings
Heiko writes that he had Windows 10 Education in front of him at an academy. In the local security policies (secpol.msc -> Local Policies ) go to the branch:
Security Options -> "Interactive Login: Inactivity limit of the computer
and set the policy. Heiko has set the guideline at 60 seconds. He then waited two minutes, but despite inactivity, the system did not lock automatically. Afterwards Heiko added in another mail his observations to a "dynamic lock". At his workplace he paired Windows 10 Enterprise with his Samsung Galaxy S10e via Bluetooth. For testing purposes he put the smartphone in another room, but the computer was not locked despite inactivity. The same happened with a mouse and keyboard, which are also paired via Bluetooth. The dynamic lock doesn't work here either.
Heiko wrote: "In my further research I have not yet found any clues". My question: Does anyone know the problem? Was something missed here?
Some more notes
Addendum: I submitted this blog post in advance to Group Policy Guru and ex-MVP colleague Mark Heitbrink. Mark did this test on Sunday and gave me the following feedback.
Inactivity 120 seconds works for me here. Always. Otherwise it stands at 10 minutes on me and my system locks up. Dynamic lockout also kicks in. Takes longer than the first tests I did when it was introduced in 1709.
I can't recreate it on my hardware. My client is not domainjoined. I try it again in a VM … Without Bluetooth, but I can try the inactivity
Domainjoined tuts also. 120 seconds arrive via gpo and are also applied. System locks up
Mark Heitbrink draws the following conclusion: Let me say spontaneously – third-party software, service, task etc. prevents them from doing so. Or a conflicting policy, but I don't know of any except screen savers. And there it is rather confusing, with different times …
Cookies helps to fund this blog: Cookie settings