How to identify which user triggered task?

Question

I would like to have a Scheduled Task that runs as SYSTEM but is triggered by a user action and is on a delay. That part doesn't seem so hard.

The hard part is that I want the (PoSh) script that runs to be able to identify which user triggered the task. How might I go about doing that?

Because it is on a delay, the action may no longer be in play. Since the task delays are random (with a max delay), I don't have a specific time.

Answer 1

Scheduled Task that runs as SYSTEM but is triggered by a user action and is on a delay.

Since you are using a random delay and it seems to be troublesome per timing, you should just use an explicit delay per each trigger event. Each trigger has its own setting for the delay this way.

Try the attached XML export from a job I setup on a system on my side changed up a bit to obscure real script and process names.

You can import it and then look over all the setup and configuration to see what all settings were set, make adjustments, etc.

Task Scheduler Job - XML Export

<?xml version="1.0" encoding="UTF-16"?>
<Task version="1.2" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
  <RegistrationInfo>
    <Date>2019-12-10T13:30:30.3849335</Date>
    <Author>Administrator</Author>
    <URI>\Kill Daemon</URI>
  </RegistrationInfo>
  <Principals>
    <Principal id="Author">
      <UserId>S-1-5-18</UserId>
      <RunLevel>HighestAvailable</RunLevel>
    </Principal>
  </Principals>
  <Settings>
    <DisallowStartIfOnBatteries>true</DisallowStartIfOnBatteries>
    <StopIfGoingOnBatteries>true</StopIfGoingOnBatteries>
    <MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
    <IdleSettings>
      <StopOnIdleEnd>true</StopOnIdleEnd>
      <RestartOnIdle>false</RestartOnIdle>
    </IdleSettings>
  </Settings>
  <Triggers>
    <LogonTrigger>
      <Delay>PT10S</Delay>
    </LogonTrigger>
    <SessionStateChangeTrigger>
      <Delay>PT10S</Delay>
      <StateChange>RemoteConnect</StateChange>
    </SessionStateChangeTrigger>
    <SessionStateChangeTrigger>
      <Delay>PT10S</Delay>
      <StateChange>ConsoleConnect</StateChange>
    </SessionStateChangeTrigger>
  </Triggers>
  <Actions Context="Author">
    <Exec>
      <Command>Powershell</Command>
      <Arguments>-ExecutionPolicy Bypass -File "C:\process\killit.ps1"</Arguments>
      <WorkingDirectory>C:\process</WorkingDirectory>
    </Exec>
  </Actions>
</Task>

I want the (PoSh) script that runs to be able to identify which user triggered the task

Because the trigger of the task is an event and not a user clicking on a script to execute a scheduled task, the PoSH script that executes cannot tell what user it was that logged on per the event that executes it.

This means doing simple logging and using $env:username will not give you the username that logged on causing the event.

How to identify which user triggered task?

You'd likely have to capture data from Event Viewer security logs at the time of execution to get the user account detail that logged on generating the event which triggers the Task Scheduler job, and incorporate that into the PoSH logic to save a log, etc.

You might be able to run the quser command and record the active session username and log it per PoSH logic that way too.

quser example output

C:\Users\ClownMan>quser
 USERNAME              SESSIONNAME        ID  STATE   IDLE TIME  LOGON TIME
>ClownMan              console             1  Active      none   4/14/2021 7:46 AM

Additional PowerShell

(quser)[1].Split("").Where({$_.Trim() -ne ""})[0] -join " " -replace ">";
(quser)[1].Split("").Where({$_.Trim() -ne ""})[3];
(quser)[1].Split("").Where({$_.Trim() -ne ""})[5..7] -join " ";

Example Output

Note: With these values you could get the name of the user account that is active and then calculate with PowerShell to ensure the date and time is greater than one hour and only if it is to run the script per the hour delay condition.

ClownMan
Active
4/14/2021 7:46 AM

Additional Resources

• Task Scheduler
• How to See Who Logged Into a Computer (and When)