user rights assignment scheduled task

• Stack Overflow for Teams Where developers & technologists share private knowledge with coworkers
• Advertising & Talent Reach devs & technologists worldwide about your product, service or employer brand
• OverflowAI GenAI features for Teams
• OverflowAPI Train & fine-tune LLMs
• Labs The future of collective knowledge sharing
• About the company Visit the blog

Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Get early access and see previews of new features.

Powershell: Set a Scheduled Task to run when user isn't logged in

I have been using the Powershell Scheduled Task Cmdlets to create a scheduled task on our servers.

How do I elect to 'Run whether a user is logged in or not using this API?

I've created action , trigger , principal and settings objects, and passed them to Register-ScheduledTask , as below:

When I create a scheduled task like this, it defaults to 'Run only when the user is logged on.

This question shows how to do so using COM objects, and this one using schtasks.exe, but how do I do it using the *-ScheduledTask* cmdlets?

• scheduled-tasks
• powershell-3.0
• windows-server-2012

8 Answers 8

I'm not a fan of embedding my credentials into a script (which a few other example here do) and additionally, you generally can't do this from something like Packer or some other system/configuration automation or in a cloud provider with an pseudo-randomly generated password. Plus, generally, I feel hardcoding your credentials into a script or command or task is "bad practice" and can then easily leak.

There is a better way to do this which I want to recognize that Aeyoun mentioned in a comment in this thread but didn't go into details about which is to properly set the principal to run as the system user. I dove into and resolved this, and this is how I schedule the task as the SYSTEM user that runs automatically and in the background and doesn't depend on a user being logged in or not.

This below set of commands is what I've used in a handful of places where I've had to schedule in the background a critical task that needed administrator access. Hope it helps you!

• 1 I just discovered this. Your answer definitely works the best here! –  Christopher Cass Commented Mar 27, 2018 at 18:02
• @MarjanKalanaki There's a lot of genuinely bad answers on the net... but there are gems here and there, glad I could be one for some of you! :) I know I sure needed this answer. –  Farley Commented Jun 14, 2018 at 22:00
• Useful for many, but not if you do not fully trust the task you're running. I just want to say that. Managed Service Accounts may be a better way in that case, but I'm currently struggling with getting that to work. –  Macke Commented Feb 26, 2020 at 9:23
• @Macke You should just be able to use the above example, but change UserID to the following... -UserId 'MyNTDomain\MyServiceAcctName' should be all there is to it man –  Farley Commented Feb 27, 2020 at 9:46
• 2 I've set the LogonType as ServiceAccount but that task still shows up as it will run only if user is logged on –  Cícero Neves Commented Aug 4, 2021 at 13:58

You need to remove $principal and register the task with a user and password:

• 1 That does exactly what I need. Thanks. –  Peter Commented Dec 20, 2012 at 22:16
• 2 In all fairness, this was a decent answer at the time the question was asked. However, it's not standing the test of time. A much better option is the answer below which doesn't require embedded credentials. With more and more automation today (Chef, terraform, etc.), getting credentials is a lot of unnecessary work. –  iisystems Commented Apr 24, 2020 at 14:16
• 4 addition: you may prompt the user for a password if you're installing these tasks while logged in $user = $env:userdomain\$env:USERNAME then $credentials = Get-Credential -Credential $username then $password = $credentials.GetNetworkCredential().Password . then you can safely (?) pass the password to the rest of the script without it showing up anywhere. –  anon Commented Jun 24, 2020 at 1:38
• For Local Accounts it fails when you set the User as ".\<UserName>" but "<UserName> works –  Steffen Bauer Commented Jul 30, 2021 at 9:52
• 1 This answer may have happened to work correctly for the OP, but only perhaps because they may have created a task through the GUI, checking the Run whether the user is logged in or not box, and the GUI automatically assigned the right to the user. Then, and only then , would the above code "work correctly". But from a pure scripting solution, this answer will not work by itself. Again, see my answer for the whole story. –  fourpastmidnight Commented May 4, 2022 at 15:19

Primer on Creating Scheduled Tasks via PowerShell

I, too, was trying to create a scheduled task on Windows Server 2019 using PowerShell. None of the answers worked. It seems like all the answers really have bits and pieces of the correct solution, but none had the full solution. While some of the answers may have worked for some people, it was really all luck based on their existing system, security settings, and other factors, I'm sure. There's a lot that I learned on my journey to creating a really simple scheduled task via PowerShell to collect some application telemetry.

So I've completely revised my original answer and will now take you step-by-step through what it takes, in nearly all circumstances, to create a Scheduled Task, especially on a server. If only it were as simple as cron .

Assigning Logon as a batch job for users running unattended tasks

When most people want to create a scheduled task, especially for server/application maintenance, or just to run something on a periodic basis, the first stop is the Windows Task Scheduler. A nice GUI is provided (well, it could be nicer/modernized, but hey, at least it's a GUI) where you can specify all the details necessary to get you going. The problem is, you can't automate the GUI. And as I found out, the GUI is doing things behind the scenes that Microsoft isn't exactly forthright in telling you how it's doing it (or how it's not doing it, for that matter). And that can lead to a lot of issues—including the task just not running or even the user account under which the task runs becoming locked.

In Microsoft's documentation on the Logon as a batch job ( SeBatchLogonRight ) under the Group Policy heading , Microsoft states that, "Task Scheduler automatically grants this right when a user schedules a task." Well, this statement is not always true.

When you create a scheduled task using the Task Scheduler GUI, yes, if the scheduled task is configured to Run whether the user is logged on or not and the user does not have the Logon as a batch job right, then the Task Scheduler will assign that right to the user (unless that default is changed—see the referenced link above).

However, when creating a scheduled task using the PowerShell ScheduledTask module's cmdlets, this automatic user rights assignment DOES NOT occur. So you must do this manually. The GUI way to do this is to use the Local Security Policy MMC (Microsoft Management Console). Of course, the GUI is out in an automation scenario, so your friend here will be secedit.exe . (For myself, I wrote PowerShell wrappers around secedit.exe .)

So, let's assume we have a scheduled task that will collect telemetry for an application running on your server, which will then send that telemetry to your telemetry gathering service, such as New Relic or Data Dog, for example. The task will run under the user account CONTOSO\AppTelemetry . Given we'll be creating the scheduled task via PowerShell in an automated fashion during blue/green deployments, we need to assign this user the Logon as a batch job user right.

Using secedit to assign user rights

The steps are quite simple here:

• Export the existing server's security policy to a security policy template (optionally, only containing the sections you care about)
• Create a new security policy template
• Add the security identifier (SID) of the user under which the scheduled task will run to the corresponding user right in the new security policy template
• Import the security policy template containing the security policy changes to a new database
• Configure the system's security policy to incorporate the changes in the security policy database created in step 4.

Let's go through the code that will make this happen.

Export the existing server's security policy to a security policy template

You can do this from CMD or from PowerShell (Desktop edition or Core, it doesn't matter). All examples will be in PowerShell unless noted otherwise.

The above command exports the system's security policy, but only the section that contains information on User Rights assignments. If you need to add additional settings, such as registry keys, this can also be done via security policy. Read the Microsoft documentation on secedit.exe or Security Policies, in general.

Create a new security policy template and add our scheduled task user's SID to the SeBatchLogonRight value

Now we need to make a new security policy template that contains the delta of what we want to be the new security policy vs. what is the current security policy. I recommend that the new security policy template contain as little information as possible—only those settings which need to be changed.

One would think that all you need to do is specify that the SeBatchLogonRight must include the SID for the user, and that would be it. But if you thought that, you'd be wrong. The SeBatchLogonRight has some users assigned to it by default (see the above-referenced link to the Microsoft docs). If we were to just assign our user's SID to this right in the new policy template, it would effectively replace the existing value in the system's security policy, not update it. So since we're making an additive change, we need to add this user right to our template with the existing value from the system security policy that we exported above, and then add our user SID to the list.

By default, the SeBatchLogonRight has these SIDs assigned to it:

These are some "well-known" SIDs for some standard Windows security groups whose users should have this right. Let's assume the SID for CONTOSO\AppTelemetry is S-1-5-21-0000000000-1111111111-2222222222-3333 . But wait—how do you get that?

(Why didn't I simply use Get-ADUser to get the SID for a user account? Two reasons. First, it's not as straightforward to get a user account name from a SID using Get-ADUser . It can be done, but the code above is clearer. Secondly, and most importantly , not all users will have Get-ADUser installed on their machines. My previous laptop had the Windows Remote Server Administration Tools (RSAT) installed, so I had Get-ADUser available. Without RSAT installed or installing the Active Directory PowerShell module, Get-ADUser is not available. The cmdlets above work without a dependency on anything except Windows and the .NET framework, which, if you're trying to get a user account SID and using PowerShell to do so, by definition, you most likely have the two prerequisites.)

Then you can simply run:

Now that we have our SID, we can create a security policy template (note, there are better ways to do this—I created PowerShell cmdlets that let me programmatically interact with these INF files, but I'm just going to use here documents). Note that in the security policy you exported, all SIDs are prefixed with an * , and that multiple values are comma-delimited:

Import the new security policy template to a new security policy database

The heading says it all:

Configure the system security policy with the changes contained in the new security policy database

Once again, the heading says it all:

And that's all there is to add a user to the Logon as a batch job right from the CLI.

Create a Scheduled Task via PowerShell

Now that the user has the right to run the scheduled task whether or not they are logged in, we need to create a scheduled task that will run whether or not the user is logged in. You will see many links to many Q&A answers that say you need this or that LogonType (notably, S4U or ServiceAccount ) or run it with the highest privileges, etc. Don't listen to any of that. It's (mostly) wrong . This section will outline the minimum necessary steps to achieve creating a scheduled task that runs whether the user is logged on or not.

Create the Scheduled Task Action

First up is creating the task action. Scheduled tasks are made up of a few parts:

• Principal(s)
• Registration

The names are fairly self-explanatory. We'll be creating a scheduled task action that executes a program. (There are other action types. See the documentation on Task Actions .)

The important thing to know about Exec actions is that the Task Scheduler service will spawn an instance of cmd.exe to run the provided program. This means that if you need to specify arguments to the program, you need to ensure you follow the difficult quoting rules for CMD commands. (Depending on your arguments, these quoting rules can require a lot of testing to ensure the command will run as expected. In even my simple case, I got it wrong, and the task seemed to run correctly—a 0 exit code—but did nothing at all!) See cmd.exe /? for all the gory details. Also, you can find a lot of info through a web search.

Let's create the task action:

Again, be careful of quoting rules (i.e. if your file path has spaces in it, or, in the case you pass a bit of PowerShell script to the -Command parameter as opposed to using -File as I did here). There are a few things to point out here:

• I could've used pwsh.exe instead to run PowerShell Core
• -NoLogo avoids printing the "banner" that appears when you start PowerShell. It can make redirected output to log files nicer if you do such a thing.
• -ExecutionPolicy Bypass specifies that this script will bypass any current execution policy on the system. The default execution policy is Restricted , which disallows any script from running unless a full path is specified, and disallows any scripts which came from remote sources. This switch basically ensures that the script will be run. It may not always be necessary, but if you trust the script you're scheduling, this shouldn't hurt either.
• -NoProfile is used to not load the user's PowerShell profile (it's a similar concept to a user's bash profile on Linux OSes). However, there can also be global profile scripts. Unless you know you need profile scripts to run when PowerShell starts, it doesn't hurt to add this switch, and most likely will prevent errors.
• -NonInteractive is a very important switch. Basically, this prevents Powershell from prompting for user input (e.g. for cmdlets that require confirmation or user input). This also means if your script does require confirmation/user input, it won't work non-interactively (i.e. when the user is not logged on).
• -File tells PowerShell to execute the specified file. You could also use -Command instead and pass in some "stringified" PowerShell code.

Create the Scheduled Task Principal

This is the most important step for properly creating a scheduled task that will run whether the user is logged in or not. In fact, this step is REQUIRED to configure a scheduled task to Run whether the user is logged on or not .

Let's go over these settings in a bit more detail.

This is a free-form text field, so much as I can tell. The Task Scheduler GUI always uses the term 'Author', but generally, you can use whatever you want here. The caveat though, is that a scheduled task can contain many different actions (up to 32). And Actions also have a "context" associated with them. The task scheduler automatically assigns the context to 'Author' (for simple, single-action tasks). The documentation seems to indicate that you can provide more than one principal to a scheduled task, and the Id of the principal, in correlation with an action's context, will determine under which principal an action will execute. For our single-action task, we'll just go with 'Author'.

-UserId or -GroupId

A task can run under a user account or any user belonging to a specified Group. Be aware that when using a group, only when a user of the group is logged on will the scheduled task run. That's because using a group ID, you cannot specify a password for the task.

In 99% of the cases, you're going to want to use -UserId as I did above. It doesn't need to be a fully qualified user Id. Note that we don't store the password with the principal. That comes later.

This is probably one of the most misunderstood parameters of this cmdlet. The documentation on LogonType is pretty good. Too bad the PowerShell help for New-ScheduledTaskPrincipal doesn't link to it (I put in feedback about that).

Basically, you'll probably never need to be concerned with the S4U logon type. It may be relevant in some scenarios (which is why it exists), but for almost everything, you'll want to do, it probably won't be.

You'll only use the ServiceAccount logon type if the scheduled task will run under the NT AUTHORITY\LOCALSYSTEM ( LocalSystem ), NT AUTHORITY\SYSTEM ( System ), or NT AUTHORITY\NETWORK ( NetworkService ) user accounts, for example. Since our task is not running under a system account, this is not the value we want.

As you might be able to guess, Interactive means the task will be run under the context of a logged-on user. This can be useful when the task needs to start a GUI application, or the task action is Message Box to display a dialog on the system. Obviously, this is not useful in our case. There's also the InteractiveOrPassword type which combines this logon type, with the one we want, Password . And so I won't discuss it further.

And now, of course, the Password logon type, which is the one we want. This says that a password will be stored with the scheduled task, which will be used to logon the user (as a batch job) so the task can run whether the user is logged on or not. Yes, this is the value that results in setting the Run whether the user is logged on or not checkbox in the Task Scheduler UI.

Think of this option as specifying whether or not the task needs to run with elevated privileges. When you run a command, such as installing some software, the User Access Control (UAC) kicks in and displays a dialog asking if you want to allow the program to make changes to your computer. You probably click Yes half the time without even reading it. Setting this parameter to Highest is like clicking Yes to the UAC dialog (or just starting the process with elevated privileges, i.e. Run as Administrator ). This is a bad thing, unless you know you need it. You should always start with Limited , and if you find the scheduled task won't run under those privileges, then elevate. So that's what I've done. I'm starting with the principle of least privilege and using Limited run level.

Creating the Scheduled Task trigger

You can have one or more triggers to trigger a scheduled task. There are different trigger types. See the documentation for these different types. I'm just going to do a very simple one:

I just want a task that will run once, starting 5 minutes from now, and then run subsequently every 5 minutes after that.

Task Settings Set

If I needed to customize some other task settings, I could do so by using New-ScheduledTaskSettingsSet . I'm fine with the defaults, so I'll skip this. But the Task Scheduler documentation details it all, and really, the settings are quite self-explanatory for the most part (except the RunOnlyIfNetworkIsAvailable , but it's not overly difficult to understand).

Create the Scheduled Task

Now you might think this is where we create the task and we'll get to see it in Task Scheduler. Wrong. But we will be creating a Scheduled Task object. You MUST do this step or your task will not be registered correctly—most importantly, it will not be set up to Run whether the user is logged in or not .

All that's happening here is we're creating a scheduled task instance. But it has not been added to the list of tasks in the task scheduler. That's known as registration , and we'll be doing that next. If you just type $Task in your shell after executing the above command, you'll notice that the task name and path will be blank. You can't even specify it as part of calling New-ScheduledTask . Again, that, oddly enough, happens during registration. So let's talk about the second-most important part : registration .

Registering the Scheduled Task

It is true that I could simply:

But this would result in a task that runs interactively ( Run only when the user is logged on ). And this is not what we want. This is why we created the task principal above, and a task instance containing the task principal.

So let's register our task:

So as you can see, yes, you MUST supply a password. There are various ways to do this safely and securely in an automated fashion—but alas, not so easy for demonstration purposes. (I recently came across this blog post: How to use the Secret Modules which outlines yet another tool in your PowerShell secrets management arsenal.) The important part here is the user and password provided to Register-ScheduledTask . The specified user MUST be the same user as specified in the principal we created. And obviously, the password for that user must be correct. IF you use a different user to register the scheduled task, the task principal will be updated to run the task using the user account specified when registering the task . (That's documented here .)

And that's all there is to scheduling a task to run whether the user is logged on or not using PowerShell. But there's one more topic to discuss before I finish: updating a scheduled task.

Updating a Scheduled Task

Believe it or not, this is not as straightforward as it should be. The syntax for Set-ScheduledTask is not documented correctly. Let's pretend that I need wo write a file somewhere as part of this scheduled task, but the code that writes the file doesn't use an absolute path. Therefore, I need to set a working directory and forgot to do so. Let's fix the action and update the task.

This is the way to do it properly. There are different ways you can use Set-ScheduledTask , but I found that other ways of doing it can lock the user account or just plain not work (i.e. give you an error). It's not to say those other ways are wrong, but just for this particular kind of change, this is what worked for me every time :

Again, it's important to use the same user and password used when registering the task. If you use a different username/password, then the task principal WILL ALSO be updated. That's probably not what you want.

That's pretty much all there is to working with Scheduled Tasks in Powershell.

Use schtasks for debugging help

One way to help yourself when you're having trouble creating scheduled tasks via PowerShell is to create a similar scheduled task on your local computer via the GUI. Then you can use the schtasks command to query for the scheduled task you created via the GUI and compare it with the scheduled task you created via PowerShell. To use schtasks , for example:

You can also get a scheduled task's XML representation via PowerShell using Export-ScheduledTask . You can find documentation for all of the PowerShell Scheduled Task cmdlets here . The documentation is OK. Some of it is misleading; most of it is incomplete (i.e. it assumes you have knowledge about the Task Scheduler apart from the PowerShell cmdlets themselves). Documentation on the Task Scheduler, its COM interfaces, XML schema, etc., can be found here .

I hope this helps someone because it took me a long time to figure this all out. Mainly, a lot of, "Why isn't this task doing anything even when it says it's successful?" Or "Why does the account keep getting locked out?" (Wrong logon type, password, or user rights assignment, or all 3!)

• 5 This is an excellent answer. Thanks for all the details. –  gerard Commented Apr 13, 2022 at 10:09
• 4 Thanks for the feedback. I'm glad you found it useful! –  fourpastmidnight Commented Apr 13, 2022 at 19:20
• 1 This answer should have more upvotes –  ArwynFr Commented May 1, 2023 at 11:08
• 1 Thank you. I'm glad you found it useful! –  fourpastmidnight Commented May 1, 2023 at 20:22
• 1 Yeah, so that may depend on any security requirements (a/k/a Group Policies) your organization has applied to your infrastructure. But, I'm glad this worked for you! And it's good to know that, depending on your organization, you may need to use elevated credentials to setup a task. –  fourpastmidnight Commented Jul 21, 2023 at 20:11

The “Run whether user is logged in or not” option in the Task Scheduler GUI is equivalent to New-ScheduledTaskPrincipal -LogonType S4U .

• when this is set the user cannot interact with local user files –  C.Unbay Commented Feb 19, 2020 at 23:12
• Yes, this answer is incorrect. See my primer above. The GUI does some "magic" Local Security Policy changes that don't occur when creating the tasks via PowerShell, such that, without the LSP changes, the task won't work as expected, no matter what settings you end up using. –  fourpastmidnight Commented Nov 30, 2022 at 21:29

Once you have the task set up in the gui, run this

• 1 Holy... that was the only solution that worked here as the local user has a blank password. Thanks! –  tar Commented Nov 25, 2021 at 19:31

also control Run level check:

Specifies the required privilege level to run tasks that are associated with the principal.

e.g.: "Highest" or "Limited"

I had a similar challenge when trying to create a scheduled task on Powershell to copy files to a mapped drive.

Here's how I solved it :

First, I had to use the UNC path to specify the path of the mapped drive:

Next, I set up the scheduled job with the commands below:

Note : The $Principal to allow the task to run whether the user is logged in or not is very essential for a scheduled job that is to sync to a mapped drive.

That's all.

I hope this helps

Not sure about what's going on in Windows but I don't like not finding a solution, had this problem and solved it by making the user running it SYSTEM (change username -> Advanced -> Find -> Select SYSTEM).

It will automatically force the task scheduled to be "Run when user is not logged on" you can run PS scripts thereafter.

Tested working on Windows 11 Pro.

[Use fully qualified paths]

• Please don't. Running under SYSTEM is highly discouraged , as that is a very privileged account . Of course it works under SYSTEM, that's practically running as Administrator (or potentially even slightly higher privileges)! Please see my answer for correctly setting up a scheduled task via PowerShell. To anyone else reading this answer, DON'T DO IT! THIS IS EXTREMELY INSECURE! –  fourpastmidnight Commented Jul 3 at 15:29

Your Answer

Reminder: Answers generated by artificial intelligence tools are not allowed on Stack Overflow. Learn more

Sign up or log in

Post as a guest.

Required, but never shown

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy .

Not the answer you're looking for? Browse other questions tagged powershell scheduled-tasks powershell-3.0 windows-server-2012 or ask your own question .

• Featured on Meta
• We spent a sprint addressing your requests — here’s how it went
• Upcoming initiatives on Stack Overflow and across the Stack Exchange network...
• What makes a homepage useful for logged-in users
• The [lib] tag is being burninated

Hot Network Questions

• Who is the woman who speaks when the Ravagers stop the Benatar?
• How do we define addition?
• Can you be charged with breaking and entering if the door was open, and the owner of the property is deceased?
• firefox returns odd results for file:/// or file:///tmp
• Changing equation into elliptic curve
• Can a country refuse to deliver a person accused of attempted murder?
• It was the second, but we were told it was the fifth
• What does "that" in "No one ever meant that, Drax" refer to?
• Can the differential be unitless while the variable have an unit in integration?
• What is the difference, if any, between "en bas de casse" and "en minuscules"?
• Was I wrongfully denied boarding for a flight where the airliner lands to a gate that doesn't directly connect to the international part the airport?
• Tour de France General Classification time
• Attaching foam to the bottom of a PCB
• Debsecan showing deprecated linux-libc-dev
• What is the reason for using decibels to measure sound?
• Are there dedicated research facilities in the USA?
• Star alliance lounge at Luxembourg?
• When selling a machine with proprietary software that links against an LGPLv3 library, do I need to give the customer root access?
• Everything has a tiny nuclear reactor in it. How much of a concern are illegal nuclear bombs?
• Apex Batch QueryLocator : SOQL statements cannot query aggregate relationships more than 1 level away from the root entity object
• Did Joe Biden refer to himself as a black woman?
• Why does black have a higher win rate here?
• Setting Stack Pointer on Bare Metal Rust
• 'adb help' for 'root' says "restart adbd with root permissions", but 'adb root' says "adbd cannot run as root in production builds"

SOLVED: This Task Requires That The User Account Specified Has Log On As Batch Job Rights

Published by ian matthews on june 20, 2019.

How to assign a user “Batch Job Rights” Locally

On the local server use Local Security Policy manager:

• Click START and type secpol.msc then press Enter
• Expand Security Settings > Local Policies > User Rights Assignment node
• Double click Log on as a batch job
• Click the Add User or Group button and add your service account user
• Have a nice day, you are done

If you find the ADD button greyed out it is likely because that policy is controlled by a Group Policy:

How to assign a user “Batch Job Rights” via GPO

• Click START and type Group Policy then click on Group Policy Management
• Either edit the existing GPO that contains existing USER RIGHTS ASSIGNMENT (likely Default Domain Policy) or right click and CREATE AND EDIT a new policy
• Expand Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment node

Anonymous · February 19, 2023 at 2:14 am

This artile on research skills has been extremely helpful to me. Thank you.

Julio Rolandi · June 24, 2022 at 4:46 am

Straight to the point!Thank you very much!!

pandin · June 28, 2020 at 9:21 pm

Thank so much, it solved my problem

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Related Posts

SOLVED: What Is An AI PC, In Simple Terms?

If desktop computers and laptops have been performing artificial intelligence tasks for the last few years, what’s this new category of computer called an “AI PC” all about? While it is certainly true that you Read more…

SOLVED: Where Domain Member Server is Getting Time & Other W32tm FAQ’s

If you’ve worked on a domain, you know how important it is to have all of your servers and clients running at exactly the same time. When they get out of sync things get ugly. Read more…

SOLVED: What Is Modern Setup Host?

Modern Setup Host, also known as SetupHost.exe, is a core component of the Windows Operating System. It’s a system process which prepares your computer for updates and facilitates the system setup when you upgrade your Read more…

All things IT

User Rights Assignment Definitions

This is a list of all the User Rights Assignments available on a Windows network along with a brief description and default values. The definitions are taken from the Microsoft documentation .

Access Credential Manager as a trusted caller The Access Credential Manager as a trusted caller policy setting is used by Credential Manager during backup and restore. No accounts should have this privilege because it is assigned only to the Winlogon service. Do not modify this policy setting from the default.

Access this computer from the network The Access this computer from the network policy setting determines which users can connect to the device from the network. This capability is required by a number of network protocols, including Server Message Block (SMB)-based protocols, NetBIOS, Common Internet File System (CIFS), and Component Object Model Plus (COM+). On desktop devices or member servers, grant this right only to users and administrators. On domain controllers, grant this right only to authenticated users, enterprise domain controllers, and administrators. This setting includes the Everyone group to ensure backward compatibility. Upon Windows upgrade, after you have verified that all users and groups are correctly migrated, you should remove the Everyone group and use the Authenticated Users group instead.

Act as part of the operating system The Act as part of the operating system policy setting determines whether a process can assume the identity of any user and thereby gain access to the resources that the user is authorized to access. Typically, only low-level authentication services require this user right. Do not assign this right to any user accounts. Only assign this user right to trusted users. If a service requires this user right, configure the service to log on by using the local System account, which inherently includes this user right. Do not create a separate account and assign this user right to it.

Add workstations to domain This policy setting determines which users can add a device to a specific domain. For it to take effect, it must be assigned so that it applies to at least one domain controller. A user who is assigned this user right can add up to ten workstations to the domain. Configure this setting so that only authorized members of the IT team are allowed to add devices to the domain. By default, this setting allows access for Authenticated Users on domain controllers, and it is not defined on stand-alone servers.

Adjust memory quotas for a process This privilege determines who can change the maximum memory that can be consumed by a process. This privilege is useful for system tuning on a group or user basis. Restrict the Adjust memory quotas for a process user right to only users who require the ability to adjust memory quotas to perform their jobs. If this user right is necessary for a user account, it can be assigned to a local machine account instead of to a domain account. By default, members of the Administrators, Local Service, and Network Service groups have this right.

Allow log on locally This policy setting determines which users can start an interactive session on the device. Users must have this user right to log on over a Remote Desktop Services session that is running on a Windows-based member device or domain controller. By default, the members of the following groups have this right on domain controllers: Account Operators, Administrators, Backup Operators, Print Operators, Server Operators.

Allow log on through Terminal Services This policy setting determines which users or groups can access the logon screen of a remote device through a Remote Desktop Services connection.

Back up files and directories This user right determines which users can bypass file and directory, registry, and other persistent object permissions for the purposes of backing up the system. This user right is effective only when an application attempts access through the NTFS backup application programming interface (API) Default on domain controllers: Administrators, Backup Operators, Server Operators Default on Workstations and Server: Administrators, Backup Operators

Bypass traverse checking This policy setting determines which users (or a process that acts on behalf of the user’s account) have permission to navigate an object path in the NTFS file system or in the registry without being checked for the Traverse Folder special access permission. This user right does not allow the user to list the contents of a folder. It only allows the user to traverse folders to access permitted files or subfolders.

Change the system time This policy setting determines which users can adjust the time on the device’s internal clock.

Change the time zone This policy setting determines which users can adjust the time zone that is used by the device for displaying the local time, which includes the device’s system time plus the time zone offset.

Create a pagefile This policy setting determines which users can create and change the size of a page file. By default, members of the Administrators group have this right.

Create a token object This policy setting determines which accounts a process can use to create a token, and which accounts it can then use to gain access to local resources. This user right is used internally by the operating system. Unless it is necessary, do not assign this user right to a user, group, or process other than Local System.

Create global objects This policy setting determines which users can create global objects that are available to all sessions. Users can still create objects that are specific to their own session if they do not have this user right. A global object is an object that is created to be used by any number of processes or threads, even those not started within the user’s session. Remote Desktop Services uses global objects in its processes to facilitate connections and access. By default, members of the Administrators group have this right, as do Local Service and Network Service accounts on the supported versions of Windows. Service is included for backwards compatibility with earlier versions of Windows.

Create permanent shared objects This user right determines which accounts can be used by processes to create a directory object by using the object manager. Directory objects include Active Directory objects, files and folders, printers, registry keys, processes, and threads. Users who have this capability can create permanent shared objects, including devices, semaphores, and mutexes. By default, LocalSystem is the only account that has this right. Do not assign this right to any users.

Create symbolic links This user right determines if users can create a symbolic link from the device they are logged on to. A symbolic link is a file-system object that points to another file-system object. By default, members of the Administrators group have this right.

Debug programs This policy setting determines which users can attach to or open any process, even those they do not own. Developers who are debugging their own applications do not need to be assigned this user right. Developers who are debugging new system components need this user right. This user right provides access to sensitive and critical operating-system components. By default, members of the Administrators group have this right.

Deny access to this computer from the network This security setting determines which users are prevented from accessing a device over the network. By default, this setting is Guest on domain controllers and on stand-alone servers.

Deny log on as a batch job This policy setting determines which accounts are prevented from logging on by using a batch-queue tool to schedule and start jobs automatically in the future. The ability to log on by using a batch-queue tool is needed for any account that is used to start scheduled jobs by means of the Task Scheduler. Deny log on as a batch job prevents administrators or operators from using their personal accounts to schedule tasks.

Deny log on as a service This policy setting determines which users are prevented from logging on to the service applications on a device. A service is an application type that runs in the system background without a user interface. It provides core operating system features, such as web serving, event logging, file serving, printing, cryptography, and error reporting.

Deny log on locally This policy setting determines which users are prevented from logging on directly at the device’s console.

Deny log on through Remote Desktop Services This policy setting determines which users are prevented from logging on to the device through a Remote Desktop connection through Remote Desktop Services.

Enable computer and user accounts to be trusted for delegation This policy setting determines which users can set the Trusted for Delegation setting on a user or computer object. Security account delegation provides the ability to connect to multiple servers, and each server change retains the authentication credentials of the original client. Delegation of authentication is a capability that client and server applications use when they have multiple tiers. It allows a public-facing service to use client credentials to authenticate to an application or database service. For this configuration to be possible, the client and the server must run under accounts that are trusted for delegation. Limit this assignment as it poses a security risk. There is no reason to assign this user right to anyone on member servers and workstations that belong to a domain because it has no meaning in those contexts. It is only relevant on domain controllers and stand-alone devices.

Force shutdown from a remote system This security setting determines which users are allowed to shut down a device from a remote location on the network.

Generate security audits This policy setting determines which accounts can be used by a process to generate audit records in the security event log. The Local Security Authority Subsystem Service (LSASS) writes events to the log. You can use the information in the security event log to trace unauthorized device access. By default, this setting is Local Service and Network Service on domain controllers and stand-alone servers.

Impersonate a client after authentication This policy setting determines which programs are allowed to impersonate a user or another specified account and act on behalf of the user. Impersonation is the ability of a thread to run in a security context that is different from the context of the process that owns the thread. By default, this setting is Administrators, Local Service, Network Service, and Service on domain controllers and stand-alone servers.

Increase a process working set This policy setting determines which users can increase or decrease the size of the working set of a process. The working set of a process is the set of memory pages currently visible to the process in physical RAM. By default, standard users have this right.

Increase scheduling priority This policy setting determines which user accounts can increase the base priority class of a process. This user right is not required by administrative tools that are supplied with the operating system, but it might be required by software development tools.

Load and unload device drivers This user right is not required if a signed driver for the new hardware already exists in the driver.cab file on the device. Because device driver software runs as if it is a part of the operating system with unrestricted access to the entire computer, it is critical that only known and authorized device drivers be permitted. By default this setting is Administrators and Print Operators on domain controllers and Administrators on stand-alone servers.

Lock pages in memory This policy setting determines which accounts can use a process to keep data in physical memory, which prevents the computer from paging the data to virtual memory on a disk. Enabling this policy setting for a specific account (a user account or a process account for an application) prevents paging of the data. Thereby, the amount of memory that Windows can reclaim under pressure is limited. This could lead to performance degradation.

Log on as a batch job This policy setting determines which accounts can log on by using a batch-queue tool such as the Task Scheduler service. When you use the Add Scheduled Task Wizard to schedule a task to run under a particular user name and password, that user is automatically assigned the Log on as a batch job user right. When the scheduled time arrives, the Task Scheduler service logs on the user as a batch job instead of as an interactive user, and the task runs in the user’s security context. By default, this setting is for Administrators, Backup Operators, and Performance Log Users on domain controllers and on stand-alone servers.

Log on as a service This policy setting determines which service accounts can register a process as a service. By default this setting is Network Service on domain controllers and Network Service on stand-alone servers.

Manage auditing and security log This policy setting determines which users can specify object access audit options for individual resources such as files, Active Directory objects, and registry keys. These objects specify their system access control lists (SACL). A user who is assigned this user right can also view and clear the Security log in Event Viewer. By default this setting is Administrators on domain controllers and on stand-alone servers.

Modify an object label This privilege determines which user accounts can modify the integrity label of objects, such as files, registry keys, or processes owned by other users. By default this setting is Not defined on domain controllers and on stand-alone servers. Do not give any group this user right.

Modify firmware environment values This security setting determines who can modify firmware environment values. Firmware environment values are settings that are stored in the nonvolatile RAM of non-x86-based computers. The effect of the setting depends on the processor. On x86-based computers, the only firmware environment value that can be modified by assigning this user right is the Last Known Good Configuration setting, which should only be modified by the system. By default this setting is Administrators on domain controllers and on stand-alone servers.

Perform volume maintenance tasks This policy setting determines which users can perform volume or disk management tasks, such as defragmenting an existing volume, creating or removing volumes, and running the Disk Cleanup tool. By default this setting is Administrators on domain controllers and on stand-alone servers.

Profile single process This policy setting determines which users can view a sample performance of an application process. Typically, you do not need this user right to use the performance reporting tools included in the operating system. However, you do need this user right if the system’s monitor components are configured to collect data through Windows Management Instrumentation (WMI). This right should not be granted to individual users. It should be granted only for trusted applications that monitor other programs.

Profile system performance This security setting determines which users can use Windows performance monitoring tools to monitor the performance of system processes. By default this setting is Administrators on domain controllers and on stand-alone servers.

Remove computer from docking station This security setting determines whether a user can undock a portable device from its docking station without logging on.

Replace a process level token This policy setting determines which parent processes can replace the access token that is associated with a child process. Specifically, the Replace a process level token setting determines which user accounts can call the CreateProcessAsUser() application programming interface (API) so that one service can start another. By default this setting is Network Service and Local Service on domain controllers and on stand-alone servers.

Restore files and directories This security setting determines which users can bypass file, directory, registry, and other persistent object permissions when they restore backed up files and directories, and it determines which users can set valid security principals as the owner of an object. Users with this user right can overwrite registry settings, hide data, and gain ownership of system objects, so only assign this user right to trusted users. By default, this right is granted to the Administrators, Backup Operators, and Server Operators groups on domain controllers, and to the Administrators and Backup Operators groups on stand-alone servers.

Shut down the system This security setting determines if a user who is logged on locally to a device can shut down Windows. By default this setting is Administrators, Backup Operators, Server Operators, and Print Operators on domain controllers, and Administrators and Backup Operators on stand-alone servers.

Synchronize directory service data This policy setting determines which users and groups have authority to synchronize all directory service data, regardless of the protection for objects and properties. This privilege is required to use LDAP directory synchronization (dirsync) services. Domain controllers have this user right inherently because the synchronization process runs in the context of the System account on domain controllers. Ensure that no accounts are assigned the Synchronize directory service data user right. Only domain controllers need this privilege, which they inherently have.

Take ownership of files or other objects This policy setting determines which users can take ownership of any securable object in the device, including Active Directory objects, NTFS files and folders, printers, registry keys, services, processes, and threads. By default, the owner is the person who or the process which created the object. Owners can always change permissions to objects, even when they are denied all access to the object.

Stack Exchange Network

Stack Exchange network consists of 183 Q&A communities including Stack Overflow , the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

What local group should user belong to be able to run windows task as that user

When I assign user to a task, I get warning message "This task requires that the user account specified has Log on as batch job rights", but then I can click ok and it keeps this user assigned for that task.

What local group other than Administrators can I assign that user to be able to avoid that warning message and run tasks as that user.

• permissions
• windows-server-2008
• scheduled-tasks

I seem to remember that Task Scheduler assigns the "Batch logon" privilege to users automatically... But you can assign it manually (to both users and groups) via secpol.msc → User Rights Assignment → Log on as batch job .

• Thank you, removed user from admin group and added to that right and it does not give me that warning anymore. It was not in that list, so system did not add it automatically. –  alpav Commented Oct 5, 2012 at 16:49

You must log in to answer this question.

Not the answer you're looking for browse other questions tagged windows permissions windows-server-2008 scheduled-tasks tasks ..

• Featured on Meta
• We spent a sprint addressing your requests — here’s how it went
• Upcoming initiatives on Stack Overflow and across the Stack Exchange network...

Hot Network Questions

• Can we *really* do algebraic operations involving roots on C?
• Debsecan showing deprecated linux-libc-dev
• If eigenvalues of two matrices are equal then the matrices are equal?
• Air magic only used to decrease humidity and improve living conditions?
• Splitting Scalar into Holomorphic and Anti-Holomorphic Parts
• Why is there not a test for diagonalizability of a matrix
• Is the text of a LLM determined by a random seed?
• Rolling median of all K-length ranges
• Can player build dungeons in D&D? I thought that was just a job for the DM
• Can I convert 50 amp electric oven circuit to subpanel, and power oven plus water heater, plus maybe a car charger?
• Who is the woman who speaks when the Ravagers stop the Benatar?
• Did Joe Biden refer to himself as a black woman?
• What does "that" in "No one ever meant that, Drax" refer to?
• Would this telescope be capable to detect Middle Ages Civilization?
• Why are responses to an attack in a cycling race immediate?
• Transferring at JFK: How is passport checked if flights arrive at/depart from adjacent gates?
• Challenge the appointment of the prime minister
• How to photograph the lettering on a bronze plaque?
• Apex Batch QueryLocator : SOQL statements cannot query aggregate relationships more than 1 level away from the root entity object
• What spells can I cast while swallowed?
• Can you be charged with breaking and entering if the door was open, and the owner of the property is deceased?
• Plastic plugs used to fasten cover over radiator
• firefox returns odd results for file:/// or file:///tmp
• Can the differential be unitless while the variable have an unit in integration?

Task scheduler need be accessed by non admin users on Windows server 2016.

I have a requirement to enable non admin users to access Task scheduler on Windows 2016. View and execute the tasks configured by domain administrator.

I have given permissions for the required users on C:\Windows\System32\Tasks folder and files under it.

I have also included the users in secpol.msc under Security Settings – Local Policies – User Rights Assignment node → Log on as a batch job parameter.

Still when that non admin user logs in to rdp of the server, user can not view any tasks under task scheduler.

Note: this procedure was working fine when we used Windows 2008 R2.

The first thing…users should never be given access to servers. The RDP is for remote admin…

There is a difference between users and administrators.

The workaround is to add the domain user into that servers local administrators group…then that although is only a domain user but is an administrator of the server.

Yes, Few days ago, I did added few domain users in local administrators group to achieve this functionality, as there was no other solution coming in my mind.

But, this is not the way I was looking for. Any more ideas?

Hi, try this post: https://www.mysysadmintips.com/windows/clients/576-allow-to-view-and-run-scheduled-tasks-without-admin-rights

It works in 2008 r2 and may be in 2012 r2 as well but not in 2016.

Related Topics

• IT Administration Forum
• PowerShell Forum
• Community Forum
• PowerShell Group
• Earning as 4sysops member
• Member Ranks
• Member Leaderboard – This Month
• Member Leaderboard – This Year
• Member Leaderboard – All-time
• Author Leaderboard – 30 Days
• Author Leaderboard – 365 Days
• Cloud Computing
• Write for 4sysops
• User rights assignment in Windows Server 2016

4sysops - The online community for SysAdmins and DevOps

Built-in local security principals and groups

Center for internet security, local policies/user rights assignment.

• Recent Posts

• What is Microsoft Dev Home? - Wed, Jul 3 2024
• New in Microsoft PowerToys: Advanced Paste and additional enhancements - Thu, Jun 13 2024
• KeePassXC: A free cross-platform password manager for Windows, macOS and Linux - Wed, Jun 5 2024

Security policy settings are sets of rules that control various aspects of protection. They include account policies, local policies, user rights assignment, the Windows firewall, software restrictions, and so on. There are several ways to configure security policy settings. The most common are:

• Group policy objects (GPO) – Used in Active Directory domains to configure and regularly reapply security settings to multiple computers.
• Local security policy (secpol.msc) – Used to configure a single (local) computer. Note that this is a one-time action. If another administrator changes these settings, you will need to manually change them back to the required state.

As most organizations use an Active Directory domain, it is preferred to apply security settings via group policies. You should have at least three security baselines created and linked in your domain, based on the following machine types:

• Domain Controllers (DC)
• Member Servers (MS)
• User Workstations

Configuring user rights assignment via Goup Policy

If you have multiple versions of operating systems (OS) running on these machines, you should create separate baselines for each OS version, as some settings might not be available. This also enables stricter configuration for older systems, as they are usually less secure.

It is a best practice to configure security policies using only built-in local security principals and groups, and add needed members to these entities. This gives you much better visibility and flexibility, as GPO provides more options to manage local group members, than to manage security policy members. For example, it's not possible to add a group whose name is generated using system variables (e.g., LAB\LocalAdmins_%COMPUTERNAME%) to a security policy; however, the group can be added to the Administrators group itself.

Security policies do not support generated group names

• Administrators – Members of this group have full, unrestricted access to the computer. Even if you remove some privileges from the Administrators group, a skilled administrator can still bypass those settings and gain control of the system. Only add highly trusted people to this group.
• Authenticated Users – A special security principal that applies to any session that was authenticated using some account, such as a local or domain account.
• Local account and member of Administrators group – A pseudogroup available since Windows Server 2012 R2. It applies to any local account in the Administrators group and is used to mitigate pass-the-hash attacks (lateral movement).
• Remote Desktop Users – Members of this group can access the computer via Remote Desktop services (RDP).
• Guests – By default, this group has no permissions. I don't think there is any need to use the Guest account and group today.

The Center for Internet Security (CIS) is a well-known non-profit organization that focuses on cybersecurity. To improve your knowledge of cybersecurity, you can access their free materials:

• CIS Controls – A set of 20 basic and advanced cybersecurity actions (controls). Using these, you can stop the most common attacks.
• CIS Benchmarks – Guidelines with specific configuration steps and detailed explanations. CIS Benchmarks are available for various products such as Windows Server, SQL Server, Apple iOS, and many more.

Both can be downloaded in exchange for your email address. There's no need to worry—there will be no further email, unless you choose to receive them.

Many companies and institutions create their security baselines based on CIS. I recommend you read CIS Controls. It really helped me to understand the importance of various security actions and settings.

CIS Benchmarks example

User rights assignments are settings applied to the local device. They allow users to perform various system tasks, such as local logon, remote logon, accessing the server from network, shutting down the server, and so on. In this section, I will explain the most important settings and how they should be configured.

For each setting, the following format is used:

Name of the setting: Recommended value, or values

Access Credential Manager as a trusted caller: No one (empty value)

Access to the Credential Manager is granted during Winlogon only to the user who is logging on. Saved user credentials might be compromised if someone else has this privilege.

Access this computer from the network: Administrators, Authenticated Users

Required for users to connect to the computer and its resources, such as an SMB share, shared printers, COM+, etc. If you remove this user right on the DC, no one will be able to log on to the domain.

Note : On DCs, you should also add the “ENTERPRISE DOMAIN CONTROLLERS“ group.

Allow log on locally: Administrators

The default configuration includes the Users group, which allows a standard user to log on to the server console. Limit this privilege only to administrators.

Allow log on through Remote Desktop Services: Administrators, Remote Desktop Users

It's common practice that some applications are used via RDP sessions by standard users. This privilege is also frequently required for remote assistance offered by an organization's helpdesk. If a server is running Remote Desktop Services with the Connection Broker role, the Authenticated Users group must also be added to this privilege.

Note: On the DC, it is recommended to allow only administrators to connect via RDP.

Back up files and directories: Administrators

This is a sensitive privilege that allows a user to bypass NTFS permissions (only via an NTFS API interface, such as NTBACKUP). A malicious user could backup and restore data on a different computer, thereby gaining access to it.

Deny access to this computer from the network/Deny log on through Terminal Services: Local account and member of Administrators group, Guests

The default value is only Guests. You should add the second group to prevent pass-the-hash attacks, so if a local elevated user is compromised, it cannot be used to elevate privileges on any other network resource, or access it via RDP.

Force shutdown from a remote system/Shut down the system: Administrators

Only administrators should be able to shut down any server, to prevent denial-of-service (DoS) attacks.

Manage auditing and security log: Administrators

This is a sensitive privilege, as anyone with these rights can erase important evidence of unauthorized activity.

Note: If you are running MS Exchange, the “Exchange Servers” group must be added to DCs.

Restore files and directories: Administrators

Attackers with this privilege can overwrite data, or even executable files used by legitimate administrators, with versions that include malicious code.

Take ownership of files or other objects: Administrators

User having this privilege can take control (ownership) of any object, such as a file or folder, and expose sensitive data.

Deny log on as a batch job/Deny log on as a service/Deny log on locally: Guests

To increase security, you should include the Guests group in these three settings.

Debug programs/Profile single process/Profile system performance: Administrators

This setting allows a user to attach a debugger to a system or process, thereby accessing critical, sensitive data. It can be used by attackers to collect information about running critical processes, or which users are logged on.

Change the system time: Administrators, Local Service

Changes in system time might lead to DoS issues, such as unavailability to authenticate to the domain. The Local Service role is required for the Windows Time service, VMware Tools service, and others to synchronize system time with the DC or ESXi host.

Create a token object: No one (empty value)

Users with the ability to create or modify access tokens can elevate any currently logged on account, including their own.

Impersonate a client after authentication: Administrators, Local Service, Network Service, Service

An attacker with this privilege can create a service, trick a client into connecting to that service, and then impersonate that account.

Note: For servers running Internet Information Services (IIS), the "IIS_IUSRS" account must also be added.

Load and unload device drivers: Administrators

Malicious code can be installed that pretends to be a device driver. Administrators should only install drivers with a valid signature.

I hope this article helped you to understand why it is important to define a security baseline for your systems. Many of the settings are already configured properly following server deployment; however, if they are not controlled by a GPO, they can be manipulated by malicious users. Be careful to whom you grant administrator permissions.

IT Administration News

• Declare your AIndependence: block AI bots, scrapers and crawlers with a single click
• Amazon is working on a ChatGPT competitor called Metis
• Apple M5 Chip’s Dual-Use Design Will Power Future Macs and AI Servers – MacRumors
• Cloudflare offers 1-click block against web-scraping AI bots – The Register
• Microsoft CEO of AI: Online content is ‘freeware’ for models The Register

Read All IT Administration News

Join our IT community and read articles without ads!

Do you want to write for 4sysops? We are looking for new authors.

• Windows Server security features and best practices
• Security options in Windows Server 2016: Accounts and UAC
• Security options in Windows Server 2016: Network security

List groups in Linux

Install Let’s Encrypt certificates on Windows with Certbot and export as PFX

Create and remove group in Linux, add user, switch primary group

Audit and disable NTLMv1

Enable FIDO passkey authentication for IAM users in AWS

Enable Microsoft Entra ID passkey authentication

KeePassXC: A free cross-platform password manager for Windows, macOS and Linux

Configuring external authentication methods in Microsoft 365 with Microsoft Entra ID

Integrate Microsoft Graph activity logs for Microsoft 365 with Azure Monitor

Disable Basic Authentication for SMTP AUTH in Exchange Online

Rotate BitLocker recovery passwords, delete used keys from Active Directory

Delegate permission to unlock Active Directory accounts

Partition Windows drive in WinPE using PowerShell

Allow end users to execute code on the Windows logon screen with administrator privileges

New mitigations for CVE-2023-24932 (BlackLotus) in the April update, not yet enabled by default

Combining password policies for Active Directory and Entra ID (Azure AD)

Create, use, and manage Windows Passkeys

Improve Windows performance with Microsoft PC Manager

Encrypt and decrypt with Ansible Vault

Critical alert: SSH and XZ vulnerability (CVE-2024-3094) – Testing and remediation

Created a domain account to use as a service account and then tried to run powershell cmdlets against the active RDS management server.

Gave that account local admin access on the broker servers and then was able to get further.

Got the error “Access is denied” when trying to run the invoke-RDUserLogoff(with correct hostserver and unifiedsessionID values) to log off a session using that account.

Need to know what permissions should be granted to the account to provide ability to run this command and where like on the broker or the session host.

I can’t run the RD cmdlets on the RD broker to remove a user session without local administrator privileges on the broker and session host.

I need to know what user permissions are necessary to run these cmdlets as giving local admin is not desired.

Sir we are having user1 in server1. We want to collect logs of server1 from server2 using credentials of user1. Surprisingly even after entering the credentials of user1 in event viewer it is taking loggedin credentials of the user logged into server2.

Leave a reply Click here to cancel the reply

Please enclose code in pre tags: <pre></pre>

Your email address will not be published. Required fields are marked *

Notify me of followup comments via e-mail. You can also subscribe without commenting.

Receive new post notifications

Subscribe to Newsletter

Follow 4sysops.

Please ask IT administration questions in the forums . Any other messages are welcome.

Log in with your credentials

or      Create an account

Forgot your details?

Create account.

Stack Exchange Network

Stack Exchange network consists of 183 Q&A communities including Stack Overflow , the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Permissions for Scheduled Tasks on a Domain Controller

I'm trying to run a Scheduled Task on a 2008 R2 Domain Controller and all was well until I set it into the production environment. I'm running the task as a Domain User that's defined in the "Log on as a batch job" setting. For giggles I also added the account to "Allow log on locally" after the former failed.

When I'm prompted for the password after setting up the task I receive the error: "An error has occurred for the task ########. Error message: The following error was reported: Logon failure: the user has not been granted the requested logon type at this computer.."

I'm thinking that because this a DC that maybe it needs something else?

• windows-server-2008-r2
• domain-controller
• scheduled-task
• user-permissions

2 Answers 2

"Log on as batch job" should be all the account needs to run a simple task on the DC. How did you give the account that permission? In a vanilla 2008 R2 AD, that privilege is configured in the Default Domain Controllers Policy GPO to include:

• BUILTIN\Performance Log Users
• BUILTIN\Backup Operators
• BUILTIN\Administrators

In order to add a user or group to that list, you'd either have to edit that policy or create a new policy to override that setting. Since editing MS default policies is a bad idea, you should create a new policy with the setting overridden. Make sure you include the default groups listed above as well as the user you're trying to give access to. This particular setting gets overwritten (rather than merged) if there are multiple policies trying to configure it.

Did you check if the account has the "Allow log on locally" right in the Domain Controller? This is done in the Domain Controller Security Policy:

GroupPolicyObjectName [DomainControllerName] Policy/Computer Configuration/Windows Settings/Security Settings/Local Policies/User Rights Assignment

As stated in: http://technet.microsoft.com/en-us/library/cc785165%28WS.10%29.aspx

EDIT: there is a "Logon as service" privilege for the user.

• I did try that out and it didn't work. Ultimately, I don't want this account to be allowed to log on locally though. I only want it to run the scheduled task. –  ceskib Commented Feb 8, 2012 at 18:43

You must log in to answer this question.

Not the answer you're looking for browse other questions tagged windows-server-2008-r2 domain-controller scheduled-task user-permissions ..

• Featured on Meta
• Upcoming initiatives on Stack Overflow and across the Stack Exchange network...
• We spent a sprint addressing your requests — here’s how it went

Hot Network Questions

• Attaching foam to the bottom of a PCB
• How does a country without exit immigration check know you have overstayed?
• Is it possible for some p-values to be impossible? (because statistic generated by parametric bootstrap is mostly the same value.)
• What is the difference, if any, between "en bas de casse" and "en minuscules"?
• Why was this a draw? What move I supposed to play to win?
• How often should I replace my tires on my mountain bike?
• Debsecan showing deprecated linux-libc-dev
• Could mathematical truths have been otherwise?
• Decorate equations with arrows using TikZ
• What does "that" in "No one ever meant that, Drax" refer to?
• Would this telescope be capable to detect Middle Ages Civilization?
• If I Trace "Pickup", will I pickup?
• Question about NMAP HTTP Verb Tampering
• Challenge the appointment of the prime minister
• Any alternative to lockdown browser?
• Can player build dungeons in D&D? I thought that was just a job for the DM
• Why did the main wire to my apartment burn before the breaker tripped?
• Air magic only used to decrease humidity and improve living conditions?
• How to pin to the Task Bar the Device Manager on Windows 11?
• pdfgrep How to locate the pages that contain multiple strings and print the page numbers?
• Splitting Scalar into Holomorphic and Anti-Holomorphic Parts
• Is "necesse est tibi esse placidus" valid classical Latin?
• Why are responses to an attack in a cycling race immediate?
• Who is the woman who speaks when the Ravagers stop the Benatar?

Get the Reddit app

A community about Microsoft Active Directory and related topics. If it relates to AD or LDAP in general we are interested. Posts about specific products should be short and sweet and not just glorified ads.

Schedule task permissions to non admin user

Hello, All I have two questions.

Is it possible to give permissions to a non admin user to be able to create & execute scheduled tasks on all computers in the (Active Directory) Domain ?

As I read in this post ( https://serverfault.com/questions/256196/windows-scheduled-task-what-are-the-minimum-user-rights-needed-for-the-task ) I need to give the user only SeBatchLogonRight rights, Is that correct ?

And is it the same thing to give to a user SeBatchLogonRight or to put him into Backup Operators ?

Thank you in advanced for the help

This browser is no longer supported.

Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.

User Rights Assignment

Applies To: Windows Vista, Windows Server 2008, Windows 7, Windows 8.1, Windows Server 2008 R2, Windows Server 2012 R2, Windows Server 2012, Windows 8

This reference topic for the IT professional provides an overview and links to information about the User Rights Assignment security policy settings user rights that are available in the Windows operating system.

User rights govern the methods by which a user can log on to a system. User rights are applied at the local computer level, and they allow users to perform tasks on a computer or in a domain. User rights include logon rights and permissions. Logon rights control who is authorized to log on to a computer and how they can log on. User rights permissions control access to computer and domain resources, and they can override permissions that have been set on specific objects. User rights are managed in Group Policy under the User Rights Assignment item.

Each user right has a constant name and a Group Policy name associated with it. The constant names are used when referring to the user right in log events. You can configure the user rights assignment settings in the following location within the Group Policy Management Console (GPMC) under Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment , or on the local computer by using the Local Group Policy Editor (gpedit.msc).

For information about setting security policies, see How to Configure Security Policy Settings .

The following table links to each security policy setting and provides the constant name for each. Setting descriptions contain reference information, best practices for configuring the policy setting, default values, differences between operating system versions, and considerations for policy management and security.

Additional resources