We help IT Professionals succeed at work.

Best Group or Permissions for Domain User to run Scheduled Task

Tessando
Tessando asked
on
14,982 Views
Last Modified: 2017-03-09
I need to run a Scheduled Task as a domain user. For the sake of explanation, let's just say: DOMAIN/Scheduled_Tasks is the user.

I've created the Scheduled Task in question (just a simple, local Powershell script) and when this user (DOMAIN/Scheduled_Tasks) is in the local Administrator group, the Task runs as expected.

When I remove the user out of the local Administrator Group, the task bombs with:

Task Scheduler failed to start "***" task for user "DOMAIN\scheduled_tasks". Additional Data: Error Value: 2147942667.

Open in new window


Using local security policy, I've added this user to:

Security Settings -> Local Settings -> User Rights Assignment -> Allow Log On Locally
Security Settings -> Local Settings -> User Rights Assignment -> Log On As A Batch Job
Security Settings -> Local Settings -> User Rights Assignment -> Log On As A Service

What are some options here to get DOMAIN/Scheduled_Tasks to run a Task without adding that user to the Administrator Group?


...
Comment
Watch Question

Patrick BogersDatacenter platform engineer Lindows
CERTIFIED EXPERT

Commented:
Hi

Does the schedule need elevated rights to run?
Login as that user and run the code in powershell, PS Will tell you what is wrong.

Cheers
TessandoIT Administrator

Author

Commented:
Thank you, Patrick. I logged in as DOMAIN/Scheduled_Tasks user and am able to run the Script itself, however the Scheduled Task fails with the same error code as I described.

Thanks for the suggestion.
CERTIFIED EXPERT
Distinguished Expert 2019

Commented:
You need to describe how you created the task. I assume you used GP preferences. It will be no problem to create a task to run only when that user is logged on (that is a task option - "run only when user is logged on". So is that user ever logged on, or is it a separate user that does not log on (if so: why use a separate user?)?
Shaun VermaakSenior Consultant
CERTIFIED EXPERT
Awarded 2017
Distinguished Expert 2019

Commented:
Can you post the Powershell?
TessandoIT Administrator

Author

Commented:
Yes, McKnife - I left out some important details:

  • Run whether user is logged in or not
  • Run with highest privileges
  • Configure for Windows Server 2016

Of course, I successfully enter in the password for DOMAIN/Scheduled_Tasks

When I created this, I was logged in as my own (Domain Administrative) account. And, like I mentioned before, this works when DOMAIN/Scheduled_Tasks is in the local administrative group.  

Thanks!
CERTIFIED EXPERT
Distinguished Expert 2019

Commented:
"run with highest privileges" -? Why would you need that and how should that work if the user is no admin?
TessandoIT Administrator

Author

Commented:
Per Shaun's suggestion, here's the Powershell script. It's just an example, I have many different .NET applications I need to setup using this DOMAIN/Scheduled_Tasks user so this is just a test:

Send-MailMessage -SMTPServer localhost -Port 587 -To me@domain.net -From server@domain.net -Subject "Paneer Test Mail" -Body "This is a test mail sent from SERVER at $((Get-Date).ToString())"

Open in new window


This script in all other contexts.

Thanks!
Patrick BogersDatacenter platform engineer Lindows
CERTIFIED EXPERT

Commented:
Hi again,

If the user can run the script but the task scheduler is not i get the feeling the job is not correct.
Did you define in the task where it should execute?
Shaun VermaakSenior Consultant
CERTIFIED EXPERT
Awarded 2017
Distinguished Expert 2019

Commented:
What do you have in command and argument?
David Johnson, CDSimple Geek from the '70s
CERTIFIED EXPERT
Distinguished Expert 2019

Commented:
remove Run with highest privileges if it is a standard user
TessandoIT Administrator

Author

Commented:
Here is the action:

Action to run the Powershell script
Many of the errors related to Error Value: 2147942667 have to do with quotes. I've seemed to isolate this to being permissions related. Once that DOMAIN/Scheduled_Tasks user is out of the local Administrator group, this doesn't work and gives an error.
Shaun VermaakSenior Consultant
CERTIFIED EXPERT
Awarded 2017
Distinguished Expert 2019

Commented:
Remove startup folder and move ps1
File to command with a -file. End result should be only command
CERTIFIED EXPERT
Distinguished Expert 2019

Commented:
Look, the case is clear already:

If the user has no additional privileges, the checkbox "run with highest privileges" is useless. But nevertheless, that is not the problem.
The problem rather seems to be that the "logon as batch job" privileges was set, but did not apply yet or was overridden by another (domain) GPO. Are you able to verify that? Can be done fast using rsop.msc
Patrick BogersDatacenter platform engineer Lindows
CERTIFIED EXPERT

Commented:
Hi

I would try several thing, create a folder e.g. C:\scripts and copy the ps1 file here.
Modify the job and try again.

Still not working i would change the argument to
-ExecutionPolicy Bypass -File C:\Users\blablabla\scheduled-task.ps1

And try again
TessandoIT Administrator

Author

Commented:
Per McKnife:

I've removed "run with highest privileges".

When I run the rsop.msc with a query for the user (DOMAIN/Scheduled_Tasks) it does show "Log on as Batch Job" as being undefined, so I think that you are correct that it didn't automatically propagate. Here's what I see:

scheduled_task-02.jpg
Is this fixable?

Thank you for all your great suggestions.
Tom CieslikIT Superintendent
CERTIFIED EXPERT
Distinguished Expert 2017

Commented:
Did you try add user to local POWER USERS group ?
TessandoIT Administrator

Author

Commented:
Hey Tom - Yes, I did add that user into the local Power Users group and got the same results. Thanks!
Tom CieslikIT Superintendent
CERTIFIED EXPERT
Distinguished Expert 2017

Commented:
When you open additional task properties you should see option to run task as a different user.
Just put domain admin as task owner

Did you try that ?
Capture.JPG
TessandoIT Administrator

Author

Commented:
Thank Tom. Yes, I do see that. And this particular Scheduled Task runs successfully as both a Domain Administrator and as a Local Administrator. This issue, and why I believe it's permissions related, is that my user of DOMAIN/Scheduled_Tasks was in the local administrator group it ran the Scheduled Task successfully but upon removing that user from the local group, the Scheduled Task fails.

Thanks for confirming that.
Tom CieslikIT Superintendent
CERTIFIED EXPERT
Distinguished Expert 2017

Commented:
I understand but why you preventing yourself from running task as different user ?
This will not compromise your security
CERTIFIED EXPERT
Distinguished Expert 2019
Commented:
This problem has been solved!
(Unlock this solution with a 7-day Free Trial)
UNLOCK SOLUTION
TessandoIT Administrator

Author

Commented:
Here's the properties of Log On As Batch Job, showing the domain user of Scheduled_Tasks:

scheduled_task-03.jpg
I did so both "gpupdate" and "gpresult", with the result being successful. In the res.html page that came up I don' t see a distinct area where "Log On As Batch Job" was changed. Here's where it showed successful:

scheduled_task-04.jpg
Thanks again.
CERTIFIED EXPERT
Distinguished Expert 2019

Commented:
Before further analysis: be so kind and answer the question of my first comment:
is it a separate user that does not log on (if so: why use a separate user)?
TessandoIT Administrator

Author

Commented:
Ah, sorry McKnife, I missed that one. Yes, this is a separate user that does not log on to the machine via RDP and such. This is a business requirement by DevOps.

It also occurred to me that you might be talking about doing the "gpupdate" as the user itself (DOMAIN/Scheduled_Tasks) so I went ahead and did that as well.

When I look at the results I can neither confirm or deny that anything changed for Log On As Batch Job, but the gpupdate was indeed successful.

Thanks!
CERTIFIED EXPERT
Distinguished Expert 2019

Commented:
Ok. Do me a favor and create another task (manually):
action: notepad
executor: your DOMAIN/Scheduled_Tasks
trigger: once: (one minute in the future from creation)
option "run with highest privileges" unchecked

Then wait that minute and afterwards look at task history - succeeded?
TessandoIT Administrator

Author

Commented:
Thank you, McKnife - It succeeded in that it started (and is currently running). In this case I constructed this while logged in as DOMAIN/Scheduled_tasks user. Does that make a difference?

scheduled_task-05.jpg
CERTIFIED EXPERT
Distinguished Expert 2019

Commented:
That does not make a diff, no.
Please substitute notepad for that pshell command, now.
TessandoIT Administrator

Author

Commented:
It failed almost immediately with the same results as before:

Task Scheduler failed to launch action "powershell.exe" in instance "{c240bc73-a583-4514-b71a-43d081369bd0}" of task "\testnotepad". Additional Data: Error Value: 2147942667.

Open in new window


Task Scheduler failed to start "\testnotepad" task for user "DOMAIN\scheduled_tasks". Additional Data: Error Value: 2147942667.

Open in new window


Would it make sense to re-add the Scheduled Task user to "Log On As Batch" locally or would that just muck things up?
CERTIFIED EXPERT
Distinguished Expert 2019

Commented:
Re-add? Why, the screenshot shows it's still there. You cannot add it twice and that's unnecessary.
So it's about the task action, after all.

It's quite simply a syntax error:
Instead of that sendmail... make it:
powershell.exe Send-MailMessage -SMTPServer localhost -Port 587 -To me@domain.net -From server@domain.net -Subject "Paneer Test Mail" -Body "This is a test mail sent from SERVER at $((Get-Date).ToString())"
TessandoIT Administrator

Author

Commented:
Okay, I replaced the Action with your script above.

I then re-ran the Scheduled Task and got the same error. However, from my Administrator login (via RDP) I got a different error this time, in the form of a pop-up inside windows:

scheduled_task-07.png
So, while it's equally as vague, it's something different but still aligning with Permission being the core issue.
CERTIFIED EXPERT
Distinguished Expert 2019

Commented:
You make this thing much bigger than it is. I can run the same task without errors with an executing account (non-admin) that has been  assigned "log on as batch job" - so you can definitely do the same.

(Anybody can do this: start task scheduler as admin, create a task with that action "powershell.exe send-mailmessage..." and a defined executor B that is also a weak user but has the privilege to logon as batch job. Start that task manually and it runs. Trigger it at some point in time and it runs)

To make progress, please logon as that scheduler user open an elevated command line (right click, run as administrator) and launch
whoami /all
and you'll see if that user really has the privilege "SeBatchLogonRight" which is needed.
TessandoIT Administrator

Author

Commented:
Thanks McKnife - I did that, logging into the machine as DOMAIN/Scheduled_Tasks and did 'whoami /all' from an elevated command prompt and do not see "Log On As Batch" listed. Here's what I get -> Logged in as DOMAIN/Scheduled_Tasks:

Microsoft Windows [Version 10.0.14393]
(c) 2016 Microsoft Corporation. All rights reserved.

C:\Windows\System32>whoami /all

USER INFORMATION
----------------

User Name                SID
======================== ============================================
********\scheduled_tasks S-1-5-21-515580095-2840579698-675601723-1108


GROUP INFORMATION
-----------------

Group Name                             Type             SID                                          Attributes         
====================================== ================ ============================================ ==================================================
Everyone                               Well-known group S-1-1-0                                      Mandatory group, Enabled by default, Enabled group
BUILTIN\Power Users                    Alias            S-1-5-32-547                                 Mandatory group, Enabled by default, Enabled group
BUILTIN\Remote Desktop Users           Alias            S-1-5-32-555                                 Mandatory group, Enabled by default, Enabled group
BUILTIN\Users                          Alias            S-1-5-32-545                                 Mandatory group, Enabled by default, Enabled group
NT AUTHORITY\REMOTE INTERACTIVE LOGON  Well-known group S-1-5-14                                     Mandatory group, Enabled by default, Enabled group
NT AUTHORITY\INTERACTIVE               Well-known group S-1-5-4                                      Mandatory group, Enabled by default, Enabled group
NT AUTHORITY\Authenticated Users       Well-known group S-1-5-11                                     Mandatory group, Enabled by default, Enabled group
NT AUTHORITY\This Organization         Well-known group S-1-5-15                                     Mandatory group, Enabled by default, Enabled group
LOCAL                                  Well-known group S-1-2-0                                      Mandatory group, Enabled by default, Enabled group
********\AMA_Reporting_Admin           Group            S-1-5-21-515580095-2840579698-675601723-1166 Mandatory group, Enabled by default, Enabled group
Mandatory Label\Medium Mandatory Level Label            S-1-16-8192                                                     


PRIVILEGES INFORMATION
----------------------

Privilege Name                Description                    State
============================= ============================== ========
SeChangeNotifyPrivilege       Bypass traverse checking       Enabled
SeIncreaseWorkingSetPrivilege Increase a process working set Disabled


USER CLAIMS INFORMATION
-----------------------

User claims unknown.

Kerberos support for Dynamic Access Control on this device has been disabled.

C:\Windows\System32>

Open in new window



So, I then created a new user (DOMAIN/Task_Scheduler), soup-to-nuts and re-created the Scheduled Task. I had it launch a few minutes into the future and I'm still getting the same error. Sorry, but this isn't working as expected for me. Could this be something different in Windows Server 2016?
CERTIFIED EXPERT
Distinguished Expert 2019

Commented:
Just work on giving him that privilege. No difference on 2016, at least not in theory.
Will reproduce this on 2016 as soon as I find the time.

Others, please reproduce this, too.
TessandoIT Administrator

Author

Commented:
Thanks McKnife for your quick response. When you say to give that user privilege are you referring to just putting that user into the Log On As Batch local security policy? Here's where I put it:

scheduled-tasks-3.png
Otherwise are there any other locations where this user needs to be (e.g. "Log On As Service", etc).

Thanks!
CERTIFIED EXPERT
Distinguished Expert 2019

Commented:
You did it right, no doubt. No idea why whoami does not list it. Confirm with an admin account that the privilege is there on an elevated command prompt in order to rule out that whoami is buggy.
CERTIFIED EXPERT
Distinguished Expert 2019
Commented:
This problem has been solved!
(Unlock this solution with a 7-day Free Trial)
UNLOCK SOLUTION
TessandoIT Administrator

Author

Commented:
Here's the results, with the user showing as in that Security Policy:

C:\Users\me\Desktop\AccessChk>accesschk.exe -q -a SeBatchLogonRight

Accesschk v6.10 - Reports effective permissions for securable objects
Copyright (C) 2006-2016 Mark Russinovich
Sysinternals - www.sysinternals.com

        BUILTIN\IIS_IUSRS
        BUILTIN\Performance Log Users
        BUILTIN\Backup Operators
        BUILTIN\Administrators
        DOMAIN\task_scheduler
        DOMAIN\scheduled_tasks
        SERVER\DPAPIAccount
        NT AUTHORITY\SYSTEM

C:\Users\me\Desktop\AccessChk>

Open in new window


The user that I'd like to use is DOMAIN\scheduled_tasks. Thanks!
CERTIFIED EXPERT
Distinguished Expert 2019

Commented:
Ok, fine, the user has the needed privilege. I have no idea what gpresult and rsop are doing wrong, but I could even reproduce this: entitle a user to that privilege using a GPO - those two don't list the priv entitlement in their results -  that has to be another bug.
Could you please export that task and upload the xml file? (Please note, your password will not be exposed that way).
TessandoIT Administrator

Author

Commented:
Thank you McKnife. Below is the export of the Scheduled Task:

<?xml version="1.0" encoding="UTF-16"?>
<Task version="1.4" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
  <RegistrationInfo>
    <Date>2017-03-02T15:12:07.7038771</Date>
    <Author>DOMAIN\me</Author>
    <Description>Test scheduled task</Description>
    <URI>\Amazon\Test Scheduled Task</URI>
  </RegistrationInfo>
  <Triggers>
    <TimeTrigger>
      <Repetition>
        <Interval>PT1H</Interval>
        <StopAtDurationEnd>false</StopAtDurationEnd>
      </Repetition>
      <StartBoundary>2017-03-02T15:05:11</StartBoundary>
      <Enabled>true</Enabled>
    </TimeTrigger>
  </Triggers>
  <Principals>
    <Principal id="Author">
      <UserId>S-1-5-21-515580095-2840579698-675601723-1108</UserId>
      <LogonType>Password</LogonType>
      <RunLevel>LeastPrivilege</RunLevel>
    </Principal>
  </Principals>
  <Settings>
    <MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
    <DisallowStartIfOnBatteries>true</DisallowStartIfOnBatteries>
    <StopIfGoingOnBatteries>true</StopIfGoingOnBatteries>
    <AllowHardTerminate>true</AllowHardTerminate>
    <StartWhenAvailable>false</StartWhenAvailable>
    <RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>
    <IdleSettings>
      <StopOnIdleEnd>true</StopOnIdleEnd>
      <RestartOnIdle>false</RestartOnIdle>
    </IdleSettings>
    <AllowStartOnDemand>true</AllowStartOnDemand>
    <Enabled>true</Enabled>
    <Hidden>false</Hidden>
    <RunOnlyIfIdle>false</RunOnlyIfIdle>
    <DisallowStartOnRemoteAppSession>false</DisallowStartOnRemoteAppSession>
    <UseUnifiedSchedulingEngine>true</UseUnifiedSchedulingEngine>
    <WakeToRun>false</WakeToRun>
    <ExecutionTimeLimit>PT72H</ExecutionTimeLimit>
    <Priority>7</Priority>
  </Settings>
  <Actions Context="Author">
    <Exec>
      <Command>Powershell.exe</Command>
      <Arguments>.\scheduled-task.ps1</Arguments>
      <WorkingDirectory>C:\Users\me\Desktop</WorkingDirectory>
    </Exec>
  </Actions>
</Task>

Open in new window


Thanks again!
Shaun VermaakSenior Consultant
CERTIFIED EXPERT
Awarded 2017
Distinguished Expert 2019

Commented:
Still recommend that you change this...
    <Exec>
      <Command>Powershell.exe</Command>
      <Arguments>.\scheduled-task.ps1</Arguments>
      <WorkingDirectory>C:\Users\me\Desktop</WorkingDirectory>
    </Exec>

Open in new window

to...
    <Exec>
      <Command>Powershell.exe -file "C:\Users\me\Desktop\scheduled-task.ps1"</Command>
      <Arguments></Arguments>
      <WorkingDirectory></WorkingDirectory>
    </Exec>

Open in new window

CERTIFIED EXPERT
Distinguished Expert 2019

Commented:
Let me guess: the path "C:\Users\me\Desktop" is not accessible by your taskuser. That would be the reason for your error code (if you make him admin, of course it is accessible).
It all works here, if I make that path accessible.
TessandoIT Administrator

Author

Commented:
Great guess, thanks McKnife. I changed the permission on the actual Powershell file for DOMAIN/Scheduled_Tasks from "Modify" to "Full Control" and unfortunately I got the same error. Thanks for the suggestion.
CERTIFIED EXPERT
Distinguished Expert 2019
Commented:
This problem has been solved!
(Unlock this solution with a 7-day Free Trial)
UNLOCK SOLUTION
TessandoIT Administrator

Author

Commented:
Thank you for your help and for hanging in there with me. I moved the Powershell script in question to the D: drive of the server in question and specifically assigned DOMAIN/Scheduled_Tasks "Modify" permissions. The script instantly ran successfully. Thanks again!