While there were several headline-grabbing ransomware attacks during in 2017, another big threat started appearing at the same time that didn’t get the same coverage – illicit cryptomining.
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:
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?
...
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.
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?
...
Who is Participating?
Experts Exchange Solution brought to you by
Enjoy your complimentary solution view.
Get this solution by purchasing an Individual license!
Start your 7-day free trial.
I wear a lot of hats...
"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.
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.
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?)?
Yes, McKnife - I left out some important details:
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 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:
This script in all other contexts.
Thanks!
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())"
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?
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?
Here is the action:
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.
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.
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
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\schedul
And try again
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\schedul
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:
Is this fixable?
Thank you for all your great suggestions.
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:
Is this fixable?
Thank you for all your great suggestions.
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 ?
Just put domain admin as task owner
Did you try that ?
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.
Thanks for confirming that.
I understand but why you preventing yourself from running task as different user ?
This will not compromise your security
This will not compromise your security
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
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
gpresult /h %temp%\res.html /f & %temp%\res.html
Here's the properties of Log On As Batch Job, showing the domain user of Scheduled_Tasks:
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:
Thanks again.
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:
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!
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?
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?
It failed almost immediately with the same results as before:
Would it make sense to re-add the Scheduled Task user to "Log On As Batch" locally or would that just muck things up?
Task Scheduler failed to launch action "powershell.exe" in instance "{c240bc73-a583-4514-b71a-43d081369bd0}" of task "\testnotepad". Additional Data: Error Value: 2147942667.
Task Scheduler failed to start "\testnotepad" task for user "DOMAIN\scheduled_tasks". Additional Data: Error Value: 2147942667.
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())"
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:
So, while it's equally as vague, it's something different but still aligning with Permission being the core issue.
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:
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.
(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:
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?
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>
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.
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:
Otherwise are there any other locations where this user needs to be (e.g. "Log On As Service", etc).
Thanks!
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.
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:
Please download accesscheck from here and execute the following on an elevated command line:
accesschk.exe -q -a SeBatchLogonRight
Here's the results, with the user showing as in that Security Policy:
The user that I'd like to use is DOMAIN\scheduled_tasks. Thanks!
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>
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).
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:
Thanks again!
<?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>
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>
<Exec>
<Command>Powershell.exe -file "C:\Users\me\Desktop\scheduled-task.ps1"</Command>
<Arguments></Arguments>
<WorkingDirectory></WorkingDirectory>
</Exec>
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.
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.
Experts Exchange Solution brought to you by
Your issues matter to us.
Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.
Start your 7-day 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!
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Powershell
From novice to tech pro — start learning today.
Experts Exchange Solution brought to you by
Enjoy your complimentary solution view.
Get this solution by purchasing an Individual license!
Start your 7-day free trial.
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