Link to home
Start Free TrialLog in
Avatar of Tessando
TessandoFlag for United States of America

asked on

Best Group or Permissions for Domain User to run Scheduled Task

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?


...
Avatar of Patrick Bogers
Patrick Bogers
Flag of Netherlands image

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
Avatar of Tessando

ASKER

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.
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?)?
Can you post the Powershell?
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!
"run with highest privileges" -? Why would you need that and how should that work if the user is no admin?
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!
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?
What do you have in command and argument?
remove Run with highest privileges if it is a standard user
Here is the action:

User generated image
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.
Remove startup folder and move ps1
File to command with a -file. End result should be only command
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
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
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:

User generated image
Is this fixable?

Thank you for all your great suggestions.
Did you try add user to local POWER USERS group ?
Hey Tom - Yes, I did add that user into the local Power Users group and got the same results. Thanks!
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 ?
User generated image
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.
I understand but why you preventing yourself from running task as different user ?
This will not compromise your security
SOLUTION
Avatar of McKnife
McKnife
Flag of Germany image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Here's the properties of Log On As Batch Job, showing the domain user of Scheduled_Tasks:

User generated image
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:

User generated image
Thanks again.
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)?
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!
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?
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?

User generated image
That does not make a diff, no.
Please substitute notepad for that pshell command, now.
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?
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())"
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:

User generated image
So, while it's equally as vague, it's something different but still aligning with Permission being the core issue.
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.
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?
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.
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:

User generated image
Otherwise are there any other locations where this user needs to be (e.g. "Log On As Service", etc).

Thanks!
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.
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
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!
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).
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!
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

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.
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.
ASKER CERTIFIED SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
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!