The Wrapper can be used to control a Windows Service with various actions, such as START, STOP, RESUME, QUERY, etc.
By default, these actions require Administrator privileges, and a User Account Control approval may be prompted on their execution.
Since version 3.5.42, the Professional Edition of the Wrapper makes it possible to grant permissions on Windows Services. It is possible to configure as many permissions as needed, each of them allowing a user or a group to execute a list of actions on a specific service.
There are a number of cases where it can be useful to change the permissions of a service:
By granting the permissions to a specific user, the actions can be executed without the User Account Control approval popup. This offers a faster way for normal users to execute commands, but also allows scripts or automated tasks to be executed without requiring the intervention of the user.
You may want to only authorize a given list of actions to a user. This can be achieved by making sure it doesn't belong to any group that has permissions on the service, and specifically granting the desired actions to this user.
You can also grant permissions to a group, and thus have a single and fixed configuration that targets any user belonging to the group.
If you have a service running under a non-admin account that needs to control another service, you will need to grant permissions to this account for the desired operations to be executed on the target service.
The permissions are either set when installing a service, or when updating an installed service. For the second, the service must be in a stopped state.
Sets the account or the group to which access rights will be granted for the targeted service.
Valid formats are:
It is also possible to set the property with 'CURRENT_USER' in order to specify the current user on the machine where the permission will be set.
This can be useful when deploying the same configuration to several machines set up with different user names.
If the account doesn't exist, by default the Wrapper will show an error and stop before setting any permission.
However, if a non-existent account is listed in the wrapper.ntservice.permissions.optional_accounts, the permission will just be skipped.
You may configure as many permissions as you want by incrementing the <n> component of the property name (counting up from "1").
By default, the numbering should be in sequence without gaps.
property can optionally be set to allow gaps in the sequence.
If you have several permissions targeting the same service and the same account, the permissions will be merged using the bitwise OR operator.
This means that, for example, if permission #1 grants START, and permission #2 grants STOP, the resulting permission and will grant both START and STOP.
This can be used when an include file needs to extend a permission with additional access rights.
For safety, the Wrapper doesn't allow to change the permissions of the Administrators group. This could indeed lead to a blocked situation where it is no longer possible to stop/uninstall the service or even reset its permissions.
Sets a list of comma-separated actions that a permission grants to a user or a group on a Windows Service.
There is no default value. This property, along with wrapper.ntservice.permissions.<n>.account, must be both set for a permission to be valid. However, you might define it to an empty value or to 'NONE' to remove all permissions for a certain user or group.
The following access rights can be listed:
Allows to query the status of the service.
Allows to query the permissions of the service.
Use this permission together with UPDATE_CONFIG when updating a service.
Allows to update the configuration of the service.
Allows to update permissions of the service.
Allows to start the service.
Allows to stop the service.
Allows to pause/continue the service.
Allows to interrogate the service.
This permission should be used together with CONTROL_CODE when sending control code to interrogate a service.
Allows to send User-Defined Control Commands to the service.
If a value that is not listed above is found, it will be skipped and a warning will be printed.
Even when permissions are set during the installation of a service, they are actually set after the service is created.
Therefore, there are no permissions to install a service, as its installed status is a prerequisite for setting permissions.
Specifies the name of the service to which the permission should apply.
This property is optional. When it is not specified, the default value will be the name of the current service (the value of wrapper.name).
A service must exist for the permission to be valid. If the value doesn't match any names of the installed services, by default the Wrapper will show an error and stop before setting any permission.
However, if an non-existent service is listed in wrapper.ntservice.permissions.optional_services, the permission will just be skipped.
Optional permissions (for portability)
Allows to list optional accounts when setting permissions of a Windows Service. If a permission is set with an account present in this list, and this account doesn't exist on the machine where the Wrapper is executed, the permission will be skipped instead of causing a FATAL error.
Listing optional accounts can be useful when deploying a single configuration file to several machines set up with different accounts. The permissions for which the accounts don't exist will be ignored, leaving the possibility for other permissions to be set normally.
Allows to list optional services when setting permissions of a Windows Service. If a permission is set with a service present in this list, and this service doesn't exist on the machine where the Wrapper is executed, the permission will be skipped instead of causing a FATAL error.
Listing optional services can be useful when deploying a single configuration file to several machines where different services are installed. The permissions for which the services don't exist will be ignored, leaving the possibility for other permissions to be set normally.
Controls the log level at which debug output are printed when checking permissions.
A permission for an operation that the Wrapper performs on a service is actually composed of several basic access rights provided by the Windows security model.
Before executing an operation, the Wrapper will check whether the current user has the permission for it, and thus check that any of the basic access rights are granted.
While doing this, a message will be printed to show the status (granted or not) of each access right.
This property allows to control the log level of these messages.
The default value is DEBUG.
Permission check for testwrapper - QUERY_PERMISSIONS (SERVICE_QUERY_STATUS=TRUE, READ_CONTROL=TRUE) -> OK
On the above example, you can see that QUERY_PERMISSIONS is actually composed of SERVICE_QUERY_STATUS and READ_CONTROL. Both base access rights are TRUE, which results in QUERY_PERMISSIONS being granted to the current user.
Query the permissions of a Windows Service
It is possible to query the permissions of a service with the following command:
Query the permissions of the current service:
PS C:\wrapper\bin> .\wrapper.exe -qp ../conf/wrapper.conf
wrapperm | Current user: mypc\myuser
wrapperm | Is member of: NT AUTHORITY\INTERACTIVE
wrapperm | Permissions for the testwrapper service:
wrapperm | mypc\myuser:
wrapperm | START, STOP, PAUSE_RESUME
wrapperm | NT AUTHORITY\SYSTEM:
wrapperm | QUERY_STATUS, QUERY_PERMISSIONS, START, STOP, PAUSE_RESUME, INTERROGATE, CONTROL_CODE
wrapperm | NT AUTHORITY\INTERACTIVE:
wrapperm | QUERY_STATUS, QUERY_PERMISSIONS, INTERROGATE, CONTROL_CODE
wrapperm | NT AUTHORITY\SERVICE:
wrapperm | QUERY_STATUS, QUERY_PERMISSIONS, INTERROGATE, CONTROL_CODE
In the output of the above example, you can see that myuser if a member of NT AUTHORITY\INTERACTIVE and thus inherits its permissions. In addition, START, STOP, PAUSE_RESUME are specifically granted to the user.
You might also want to query the permissions of another service by using '-qp=serviceName'. In this case, the configuration file is not required, but if it is missing, the output will only go to the console without the possibility to control the log format.
Query the permissions of a service using its name: