windows – Running programs from an admin without admin rights


There are many accounts grouped into the usersgroup with regular user rights. They need to run programs that require Administrator rights, but it is not advisable to assign them to the Administrators group.
How to make it so that they can run programs as administrator without administrator rights?
Programs like runas, AdmiLink, etc. are not suitable, because they allow you to run programs as an administrator without rights under a specific account, and I need it for a group of accounts, since there are a lot of accounts.


I understand that necroposting, but it hurts too wonderful a puzzle (put the emphasis wherever you want%)).

By referring to a large group of accounts, we can assume that we are talking about domain users.

In principle, in cases where a domain user needs administrator rights for a certain working set of programs, it is easiest to place him in the "Local Administrators" group of a particular workstation. Thus, the user can only harm his own computer and is almost (!) Unable to harm the domain as a whole.

If this option does not fit in any way, then you need to carefully study why the programs require elevated privileges, perhaps this does not require full administrative rights, but only specific ones, then you can choose a more suitable group of highly specialized administrators.

Most often, the requirement for elevated privileges is associated with writing to disk in system-protected folders, such as Program Files or the root of the system disk. This usually applies to old programs. In this case, you can configure the rights of the folder in which the program is installed so that ordinary users can write to it.

If elevation is associated with writing to the system registry branch or calling system functions that require elevated privileges, for which there are no pre-configured highly specialized groups, then it cannot be solved so easily, and there are not so many options.

A bad option is to create a BAT file in which to register the launch as a local administrator. The bad thing about it is that the BAT file is just plain text and you tell the user the credentials of the local administrator yourself. At the same time, it is easier and safer to issue local administrator rights explicitly. they can be taken away at the right time.

A bad and difficult way is to write a launcher for each program that will launch the program in a separate process on behalf of the desired user. The problem is that the launcher must in some way receive the data of the required account to start the process, otherwise this generally does not differ much from the BAT file in terms of reliability and security, but it is several orders of magnitude more difficult to implement.

Inconvenient option 1 – using the system task scheduler, you can launch the specified programs automatically, for example, when a user logs in. Yes, in the scheduler it will be necessary to indicate on whose behalf the program should be launched, but this data is not stored in clear text and it will be much more difficult to get it (if at all possible, since the scheduler works with system rights and therefore only needs a user descriptor , and his username and password were unnecessary for him, but this is only a theory, I did not dig deeply). The disadvantages of this approach are that the configuration must be done on specific workstations individually, and if the user closes the program, he will not be able to restart it, for this he will need to log out and log in again. In addition, if my memory serves me, the system scheduler does not know how to distinguish which user is logged in.

Inconvenient option 2 is to use logon scripts in Group Policy. On the one hand, everything is great, we just silently launch the program when the user logs in with a regular BAT file and do not disclose information about its contents (in any case, you need to have some qualifications to get it, and if the user has the necessary qualifications, it’s easier for him to give him a local administrator) … On the other hand, we have some of the disadvantages of Inconvenient option 1 and the need to place user accounts in one OU in Active Directory, in order to apply group policy only to these users.

Scroll to Top