Best Group or Permissions for Domain User to run Scheduled Task

Tessando
Tessando used Ask the Experts™
on
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

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Patrick BogersDatacenter platform engineer Lindows

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.
Distinguished Expert 2018

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?)?
Python 3 Fundamentals

This course will teach participants about installing and configuring Python, syntax, importing, statements, types, strings, booleans, files, lists, tuples, comprehensions, functions, and classes.

Shaun VermaakTechnical Specialist
Awarded 2017
Distinguished Expert 2018

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!
Distinguished Expert 2018

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

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 VermaakTechnical Specialist
Awarded 2017
Distinguished Expert 2018

Commented:
What do you have in command and argument?
Top Expert 2016

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 VermaakTechnical Specialist
Awarded 2017
Distinguished Expert 2018

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

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

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 Engineer
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 Engineer
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 Engineer
Distinguished Expert 2017

Commented:
I understand but why you preventing yourself from running task as different user ?
This will not compromise your security
Distinguished Expert 2018
Commented:
Power users are deprecated since 10 years. No effect whatsoever.
Running tasks as administrator cannot be compromised unless you choose a task action (=script) in a user writable location.

Tessandro, please open secpol.msc again and verify if that policy (logon as batch job) is set.
If so, open an elevated command prompt (right click cmd.exe, select "run as administrator") and launch
gpupdate

Open in new window

Afterwards, on the same command prompt, launch
gpresult /h %temp%\res.html /f & %temp%\res.html

Open in new window

and look at the output - did it apply?
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.
Distinguished Expert 2018

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!
Distinguished Expert 2018

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
Distinguished Expert 2018

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?
Distinguished Expert 2018

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.
Distinguished Expert 2018

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?
Distinguished Expert 2018

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!
Distinguished Expert 2018

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.
Distinguished Expert 2018
Commented:
Ok, it looks as though whoami /all is a little buggy after all. It doesn't list all privileges but only some.
Please download accesscheck from here and execute the following on an elevated command line:
accesschk.exe -q -a SeBatchLogonRight

Open in new window

That will list all users and groups that have this privilege.
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!
Distinguished Expert 2018

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 VermaakTechnical Specialist
Awarded 2017
Distinguished Expert 2018

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

Distinguished Expert 2018

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.
Distinguished Expert 2018
Commented:
On the file alone won't do. Move it to another folder that is accessible by all.
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!

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial