Allow the user to log on as a service. Blocking the start of sessions

In previous articles on local security policies, you learned about how account policies and audit policies work. With the knowledge you have acquired, you can significantly secure your users' credentials and track unauthorized access attempts. It is worth considering that users do not have a sufficient security knowledge base, and even a regular user may have enough privileges to damage their system and even computers on your intranet. Local security policies for assigning user rights help to avoid such problems, which, in fact, will be discussed in this article. With the help of user rights assignment policies, you can determine which users or user groups will be granted different rights and privileges. With these policies, you don't have to worry about users doing things they shouldn't. 44 security policies are available for assigning rights, the application of which will be discussed later.

User Rights Assignment Policies

As mentioned above, there are 44 security policies for assigning user rights. Next, you will be able to familiarize yourself with eighteen security policies that are responsible for assigning various rights to users or groups in your organization.

Archiving files and directories. With this policy, you can specify users or groups intended to perform operations Reserve copy files, directories, registry keys and other objects that are subject to archiving. This policy grants access to the following permissions:

Browse Folders/Execute Files
Folder Contents/Data Reading
Reading Attributes
Reading Extended Attributes
Read permissions

"Administrators" and "Archive Operators", and on domain controllers - "Archive Operators" and "Server Operators".

Lock pages in memory. Using this security policy, you can specify specific users or groups that are allowed to use processes to save data to physical memory to prevent data from being flushed to virtual memory on disk.

Restoring files and directories. This policy allows you to specify users and groups that can restore files and directories, bypassing locks on files, directories, registry keys, and other objects located in archived versions of files.

On workstations and servers, these privileges are granted to groups "Administrators" and "Archive Operators", and on domain controllers - "Archive Operators" and "Server Operators".

Login as a batch job. When you create a job using the Task Scheduler, the operating system logs the user into the system as a batch logon user. This policy allows a group or a specific user to log in using this method.

By default, on both workstations and domain controllers, these privileges are granted to groups "Administrators" and "Archive Operators".

Sign in as a service. Some system services log on to the operating system under different accounts. For example, service Windows Audio running under an account "Local Service", service "Telephony" uses an account "Network Service". This security policy determines which service accounts can register a process as a service.

By default, on both workstations and servers, neither group has permission to do so.

Performing Volume Maintenance Tasks. Using this policy, you can specify users or groups whose members can perform volume maintenance operations. Users with these privileges have the right to read and modify the requested data after opening additional files, they can also browse disks and add files to memory occupied by other data.

By default, only administrators of workstations and domain controllers have such rights.

Adding workstations to a domain. This policy is responsible for allowing users or groups to add computers to Active domain Directory. A user with these privileges can add up to ten computers to the domain.

By default, all authenticated users on domain controllers can add up to ten computers.

Accessing the credential manager on behalf of a trusted caller. A credential manager is a component that is designed to store credentials, such as usernames and passwords, used to log on to websites or other computers on a network. This policy is used by Credential Manager during backup and restore and is not recommended for users.

By default, on both workstations and servers, neither group has permission to do so.

Accessing a computer from the network. This security policy is responsible for allowing specified users or groups to connect to a computer over a network.

On workstations and servers, these privileges are granted to groups "Administrators" and "Archive Operators", "Users" and "Everything". On domain controllers - "Administrators", "Verified Users", "Enterprise Domain Controllers" and "Everything".

System shutdown. Using this policy setting, you can list the users who are authorized to use the command "Shutdown" after a successful login.

On workstations and servers, these privileges are granted to groups "Administrators", "Archive Operators" and "Users"(only on workstations), and on domain controllers - "Administrators", "Archive Operators", "Server Operators" and "Print Operators".

Loading and unloading device drivers. Using the current policy, you can specify which users will be granted permissions to dynamically load and unload device drivers in kernel mode, and this policy does not apply to PnP devices.

On workstations and servers, these privileges are granted to groups "Administrators", and on domain controllers - "Administrators" and "Print Operators".

Replacing the Process Level Marker. By using this security policy, you can restrict users or groups from using the CreateProcessAsUser API to allow one service to start another function, process, or service. It is worth paying attention to the fact that such an application as "Task Scheduler" uses these privileges for its work.

By default, both on workstations and on domain controllers, these privileges are granted to accounts "Network Service" and "Local Service".

Prevent login through Remote Desktop Service. With this security policy, you can restrict users or groups from logging on as a Remote Desktop client.

By default, on both workstations and servers, everyone is allowed to log in as a remote desktop client.

Deny local login. This policy prevents individual users or groups from logging on to the system.

By default, all users are allowed to log in.

Change the label of objects. With this rights assignment policy, you can allow specified users or groups to change the integrity marks of other users' objects, such as files, registry keys, or processes.

By default, no one is allowed to change object labels.

Changing the manufacturer's environment settings. Using this security policy, you can specify which users or groups will be able to read hardware environment variables. Hardware environment variables are settings stored in non-volatile memory on non-x86 computers.

On workstations and domain controllers, by default these privileges are granted to groups "Administrators".

Changing the system time. This policy is responsible for changing the system time. By granting this right to users or groups, in addition to allowing changes to the date and time of the internal clock, you will allow them to change the corresponding time of monitored events in the snap-in. Event Viewer.

On workstations and servers, these privileges are granted to groups "Administrators" and "Local Service", and on domain controllers - "Administrators", "Server Operators" and "Local Service".

Changing the time zone. With the current security policy, you can specify users or groups that are allowed to change their computer's time zone to display local time, which is the sum of the computer's system time and the time zone offset.

On workstations and domain controllers, by default, these privileges are granted to groups "Administrators" and "Users".

Apply policies assign user rights

In this example, I'll show you how you can assign rights to one of your organization's groups on a domain controller. Do the following:

Conclusion

In this article, we continued to study security policies, namely, we learned about the policies for assigning user rights. With the help of user rights assignment policies, you can determine which users or user groups will be granted different rights and privileges. 18 out of 44 security policies are described in detail. The example in the article also showed you how you can apply these policies in your organization. In the next article, you will learn about the policies that control event logs.

When creating a task in the windows scheduler and trying to run it, an error pops up. This task requires that the specified user account has rights to log on as a batch task. The fact is that the account on behalf of which I am trying to run does not have enough rights.

This security setting allows a user to log on using the batch processing tool.

For example, if a user initiates a job using the Task Scheduler, the Scheduler ensures that the user is logged on as a batch user, not as an interactive user.

Note

In operating rooms Windows systems 2000 Server, Windows 2000 Professional, Windows XP Professional. and families Windows Server The 2003 Task Scheduler automatically grants this right as a requirement.

You can solve this problem either in local or in group policy by setting the desired parameter and giving the right user rights along the way Account on behalf of which the task is to be executed, in "Local Security Policy\Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment" the "Log on as a batch task" right must be selected (In the foreign language interface, it will be in "Local policy \Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\" will highlight "Log on as a batch job").

By default, Administrators and Backup Operators have rights in this group, do not forget to add them here in the group policy, otherwise you will overwrite their rights.

I won’t describe anything in detail here, and I don’t do network administration, it’s better for a master of his craft, a system administrator, to do this.

2. Block the start of sessions

We launch the 1C:Enterprise server administration console, open the properties information base and set the checkbox for the property Session start blocking enabled. Please note that as soon as you apply this property, the start of any sessions will be blocked, therefore, in order to perform the next step, the configurator must be launched before applying the property.

3. Making a backup

Here, as your soul tells you. In my opinion, the simplest and reliable way creation backup- this is an unloading of the infobase through the configurator.

4. Set local security policies

Open the "Local Security Policy" console (in command line type secpol.msc). Go to the section Local Policies -> User Rights Assignment and add the domain user to the policies (see Figure 1):

Login as a batch job(Log on as batch job) - ensures the functioning of the Task Scheduler without the need for the user to personally log into the computer under his account;
Sign in as a service(Log on as service) - allows you to run on behalf of the user any process as a service.

Additionally, if required, the user can be added to policies:

Accessing a computer from the network(Access this computer from the network) - the user has the right to connect to the computer from the network;
Local logon y (Allow log on locally) - the user has the right to start an interactive session on the computer;
Allow login through Remote Desktop Service(Allow log on through Remote Desktop Services) - the user has the right to log in remote computer through a Remote Desktop Services connection.

5. Add a domain user to groups

Open the "Computer Management" console, go to the section Utilities -> Local Users -> Users and look at which groups the local user belongs to, on behalf of which the 1C:Enterprise Server Agent service works (usually this is the user USR1CV8) (see Figure 2).
We add the domain user to the same groups.

6. Run the agent on behalf of the domain user

Open the "Services" console, find the "Server Agent 1C: Enterprise" service in the list and open its properties. On the tab Are common stop the service, on the tab Login instead of local user specify the domain name (see Figure 3).
Go back to the tab Are common and start the service. If everything is configured correctly, the service starts without problems.

You can say that the 2nd and 3rd points are redundant, but it is better to overdo it than to underdo it. The instruction is valid not only for a domain user, but also for a local one.