Idle Timer from Local System Account?

[chaoticyeshua]

Hello,

I am curious if there is a way to detect the console user's idle time from the Local System account (i.e., as a service or scheduled task). I've attempted using _Timer_GetIdleTime and _WinAPI_GetIdleTime with not so good results. For example, _Timer_GetIdleTime returns a very high number when elevated to run as System using psexec and a low number when not. Essentially, I am attempting to develop a method of logging off idle sessions in computer labs utilizing the System account to detect whether the user is idle or not. Any advice would be appreciated.

Example returns:

Run as System - Idle time (ms): 358198875

Run by manually opening compiled exe - Idle time (ms): 5126

Thanks!

Edited December 5, 2017 by chaoticyeshua

[careca]

Timer that resets when mouse moves maybe?

[chaoticyeshua]

17 hours ago, careca said:

Timer that resets when mouse moves maybe?

Thanks for the suggestion. Is there a similar way to detect keystrokes just in case the user is using the keyboard but not the mouse? I understand this dangerously falls into a scenario where there might be keylogging involved, but this is not my intention. I currently have an Idle Logoff script that runs under the user's session each login, but since we started using Windows 10 we've run into a few issues. If they log out utilizing the start menu and have, for example, open Word documents, then the logout process hangs trying to inform them they need to save their documents. By the time that screen comes up, they've usually already left the computer. Unfortunately, it seems to get far enough along in the logout process that it closes my Idle Logoff script and so the computer just stays there logged in with their account.

Edited December 6, 2017 by chaoticyeshua

[orbs]

why from the local SYSTEM account? you can have a silent agent running in the background at logon for every user account, and that agent can even inform the user about a pending log-off, to allow the user  to abort the log-off (if user is still in front of the screen, watching a video or presentation or something). yes, a user can kill the agent; that's their problem if they have their session terminated as a planned maintenance or whatever reason you have to log them off.

[chaoticyeshua]

I ended up resolving this by applying the following registry keys in Group Policy:

HKEY_CURRENT_USER\Control Panel\Desktop

Value Type: REG_SZ

Value Name: AutoEndTasks

Value Data: 1

 

Value Type: REG_SZ

Value Name: HungAppTimeout

Value Data: (time in ms to wait before killing tasks)

[chaoticyeshua]

2 minutes ago, orbs said:

why from the local SYSTEM account? you can have a silent agent running in the background at logon for every user account, and that agent can even inform the user about a pending log-off, to allow the user  to abort the log-off (if user is still in front of the screen, watching a video or presentation or something). yes, a user can kill the agent; that's their problem if they have their session terminated as a planned maintenance or whatever reason you have to log them off.

That's basically what I'm already doing with my current script. However, as I said previously, the script closes when the user clicks sign out from the start menu but has open unsaved documents. It basically gets far enough along in the log out process to close the script, but didn't force quit the remaining applications. I resolved the issue by applying the above registry keys so it force closes hung tasks when the user manually logs off.

Edited December 6, 2017 by chaoticyeshua

[Earthshine]

 Glad you got it working 

[rudi]

Hello,

you can use qwinsta.exe to investigate session status and rwinsta.exe to kill idle sessions.

The line with ">" as first char is the currently used one (not to be killed)

Attached is a script I wrote for a pre backup job to terminate HUP TS Sessions. Comments and Text are in German, but the logic should be a start, at least.

 

Regards, Rudi.

 

Reset-RDP-Sessions.au3

[Earthshine]

He already got it working ....

Edited December 27, 2017 by Earthshine