Log on as a batch job
Applies to
- Windows 11
- Windows 10
This article describes the recommended practices, location, values, policy management, and security considerations for the Log on as a batch job security policy setting.
Reference
This policy setting determines which accounts can sign in 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.
Constant: SeBatchLogonRight
Possible values
- User-defined list of accounts
- Default values
- Not Defined
Best practices
- Use discretion when assigning this right to specific users for security reasons. The default settings are sufficient in most cases.
Location
Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment
Default values
By default, this setting is for Administrators, Backup Operators, and Performance Log Users on domain controllers and on stand-alone servers.
The following table lists the actual and effective default policy values. Default values are also listed on the policy's property page.
| Server type or GPO | Default value |
|---|---|
| Default Domain Policy | Not defined |
| Default Domain Controller Policy | Administrators Backup Operators Performance Log Users |
| Stand-Alone Server Default Settings | Administrators Backup Operators Performance Log Users |
| Domain Controller Effective Default Settings | Administrators Backup Operators Performance Log Users |
| Member Server Effective Default Settings | Administrators Backup Operators Performance Log Users |
| Client Computer Effective Default Settings | Administrators |
Policy management
This section describes features, tools, and guidance to help you manage this policy.
A restart of the computer isn't required for this policy setting to be effective.
Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.
Group Policy
Task Scheduler automatically grants this right when a user schedules a task. To override this behavior, use the Deny log on as a batch job User Rights Assignment setting.
Group Policy settings are applied in the following order, which will overwrite settings on the local computer at the next Group Policy update:
- Local policy settings
- Site policy settings
- Domain policy settings
- OU policy settings
Security considerations
This section describes how an attacker might exploit a feature or its configuration. It describes how to apply the countermeasure and the possible negative consequences of countermeasure.
Vulnerability
The Log on as a batch job user right presents a low-risk vulnerability that allows non-administrators to perform administrator-like functions. If not assessed, understood, and restricted accordingly, attackers can easily exploit this potential attack vector to compromise systems, credentials, and data. For most organizations, the default settings are sufficient. Members of the local Administrators group have this right by default.
Countermeasure
Allow the computer to manage this user right automatically if you want to allow scheduled tasks to run for specific user accounts. If you don't want to use the Task Scheduler in this manner, configure the Log on as a batch job user right for only the Local Service account.
For IIS servers, configure this policy locally instead of through domain–based Group Policy settings so that you can ensure the local IUSR_<ComputerName> and IWAM_<ComputerName> accounts have this user right.
Potential impact
If you configure the Log on as a batch job setting by using domain-based Group Policy settings, the computer can't assign the user right to accounts that are used for scheduled jobs in the Task Scheduler. If you install optional components such as ASP.NET or IIS, you might need to assign this user right to other accounts that those components require. For example, IIS requires assignment of this user right to the IIS_WPG group and the IUSR_<ComputerName>, ASPNET, and IWAM_<ComputerName> accounts. If this user right isn't assigned to this group and these accounts, IIS can't run some COM objects that are necessary for proper functionality.