Windows GDMA as non-admin user

Overview

As of the Windows GDMA 2.6.1 release, it is possible for a site to run the GDMA service as a non-administrative user. Many customers would prefer this, as a means of limiting the overall security profile of this service. This page describes the procedure.

1.0 Windows GDMA Installer Options

The Windows GDMA installer now supports two new command-line options, mirroring what has been available in earlier releases for the UNIX-like platforms. These options can be used during an unattended-mode install on this platform:

An explicit username will need to be specified in a

format. And if this string contains spaces and you are supplying it on the command line, it will need to be double-quoted, as shown.

Equivalent data may be entered during a UI install, in the same screen where you enter the Target Server name, as the "GDMA username" and "GDMA user password" fields. This username and password will be used to set the Windows service run-as account for the GDMA service.

That sounds simple, but there are complications. Additional steps need to be taken, some of which are automated, and some of which cannot be automated because they depend on the specifics of the customer situation. We explain the situation below.

2.0 Account Types

There are multiple types of accounts that might be used as a service run-as account, different rules as to how the new options are to be set in the different cases, and possibly some follow-on adjustments to make after GDMA is installed. The rest of this document provides that information. Our expectation is that most customers wanting to use a non-admin run-as account will settle on using a virtual account, as it is the simplest approach.

As a general rule, whatever account you use must already exist before you run the GDMA installer. The special system accounts are all considered to already exist on your system, regardless of whether they show up in various lists of users. Also, a virtual account is considered to already exist; it will be automatically created when it is used to create a service that references it. So the rule about needing to deal with account creation explicitly just applies to ordinary user accounts and to managed service accounts.

2.1 Special system accounts

The special system accounts run with various sorts of elevated privileges, so if you're looking to prevent running as an administrator, you probably want to avoid using these accounts. We mention them here for completeness.

There are three special system accounts that may be used to run a service:

.\LocalSystem
NT AUTHORITY\LocalService
NT AUTHORITY\NetworkService

For all of these accounts, no password information should be passed to the GDMA installer.

The LocalSystem account is the account used if no user name is passed to the GDMA installer, so you don't need to name it explicitly. It is the historical administrative account that has been used automatically by the installation of earlier releases of Windows GDMA.

The privileges assigned to these accounts are listed on these pages, though we have not looked in detail in MSDN to find out if these are the most up-to-date pages describing these accounts:

• https://msdn.microsoft.com/en-us/library/windows/desktop/ms684190(v=vs.85).aspx
• https://msdn.microsoft.com/en-us/library/windows/desktop/ms684188(v=vs.85).aspx
• https://msdn.microsoft.com/en-us/library/windows/desktop/ms684272(v=vs.85).aspx

2.2 Ordinary user account

You may choose to use an arbitrary ordinary user account for the service run-as account. In this case, you must pass the account's password to the GDMA installer, so it can be passed to Windows when the GDMA service is created.

2.3 Managed service account

As of Windows 2008 R2, Microsoft provides support for managed service accounts, and you can use one as the GDMA service run-as account. In more recent Windows releases, there is also an extension called a "group managed service account". These types of accounts provide a moderate administrative burden; see the Microsoft documentation for more information.

For this type of account, you must not provide any password information to the GDMA installer. Windows GDMA 2.6.2 or later is required to allow this.

2.4 Virtual account

As of Windows 2008 R2, Microsoft provides support for a virtual account as a service run-as account. This provides a low administrative burden, since the system does most of the work of establishing and maintaining the account. All you have to do is to mention the account name to the GDMA installer.

A virtual account has a fixed name, comprised of a special domain name and the name of the service that will use this virtual account. For GDMA, this is:

NT SERVICE\GDMA

You can specify the virtual account name either on the GDMA installer command line, quoted because the name contains whitespace:

--gdma_username "NT SERVICE\GDMA"

or in an equivalent directive in an options file, or as the value of the "GDMA username" field in a UI install. In all of these modes of installation, when using a virtual account, you must not provide any password information to the GDMA installer.

3.0 Assigning Additional Rights

3.1 Service Logon Rights

Some types of user accounts may need additional setup after the GDMA installer has run, in order for the GDMA service to be able to run. When that is the case, you should not have the GDMA installer try to immediately start the service. In a UI-based install, answer "No" to the question "Do you want to start the GDMA service after the installation?". For a scripted install, you will want to use this option:

--gdma_service_start no

(There may be other reasons to do this as well, such as pausing to allow modification of the gdma_auto.conf file to adjust options such as Enable_Auto_Setup or Enable_Local_Logging before GDMA is started the first time, depending on your local needs.)

When running GDMA as a non-admin user, the Windows SeServiceLogonRight right (sometimes seen as "Log on as a service") must be assigned to the user if it is not already so assigned. GroundWork has demurred from making this change automatically from within the GDMA installer, partly because Microsoft has not provided a simple, portable means to make this assignment from the command line, and partly because different customer sites will have different policies and customs as to the administration of such rights. Consult the Microsoft documentation for your system to find out how to set this right for a user.

• Hint #1: The relevant tools might be secpol.msc, or gpedit.msc, or secedit.exe (although that seems to be a sharp-edged knife), or the old unsupported NTRights.exe program. GroundWork is not responsible for any of these tools, but an Internet search for them might be one way into the Microsoft documentation.

• Hint #2: On some systems, this trail might be of use, if you are content to make adjustments via the UI:
  Start > Administrative Tools > Services > Continue > (right-click GDMA) > Properties > Log On > This account

For an overview of security considerations with respect to the SeServiceLogonRight right, see: https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/log-on-as-a-service

Once you have made all the local changes you need, you can start the GDMA service via the usual mechanism on the Windows platform:

net start gdma

3.2 Windows Service QueryStat Access Rights

For GDMA to monitor the up/down status of a Windows service, it needs the service QueryStat access right. Some services in Windows have (or have been restricted to have) no QueryStat access rights for non-administrative users, even those in the "Performance Monitor Users" group (which a non-admin GDMA service run-as user is automatically added to). In such cases, if you wish to monitor those Windows services from GDMA, you will need to add these access rights yourself. GroundWork recommends using a group for this (such as the Performance Monitor Users group), but it's also possible to restrict the right to use QueryStat to an individual account.

Please see https://support.microsoft.com/en-us/help/914392/best-practices-and-guidance-for-writers-of-service-discretionary-acces and other Microsoft documentation for a discussion of the details involved.

One technical hint you may find useful is to list the rights and permissions on the service you want to monitor:

sc sdshow ServiceName

where ServiceName is the service to be monitored. That will give you some cryptic output like:

C:\Windows\system32>sc sdshow "ServiceName"
D:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CC
LCSWLOCRRC;;;IU)(A;;RPWPDTRC;;;S-1-5-21-1229299991-688789999-1801679999-1059999)
S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)

As an aside, it's hard to understand exactly what user is being referred to with a Security Identifier (SID) like "S-1-5-21-1229299991-688789999-1801679999-1059999" instead of a user name. Here are a couple of commands that may help in that regard; adjust as needed for your situation.

wmic useraccount where name='%username%' get sid
wmic useraccount where sid='S-1-5-21-1229299991-688789999-1801679999-1059999' get name

Looking at the sc sdshow output with some knowledge of Microsoft rights assignments, you can see that user "S-1-5-21-1229299991-688789999-1801679999-1059999" has these rights to access this service:

RP = Start
WP = Stop
DT = Pause
RC = Remote Control

It does NOT include LC, or QueryStat. So if this user is not a member of one of the other user groups mentioned in the D: section of the security descriptor that has the LC access right (in this example, SY = "Local System"; BA = "Built-in (Local) Administrators"; IU = "Interactive Logon User"), it will not be able to monitor the service. You will need to add that user to a group that has such a right on the service, or explicitly grant that user that right to that service. How you do so (Policy, secedit, etc) is up to you, and we would demur from advising you, as this is different for every Windows administration setup. We do think that using a group for this purpose is generally easier, and the Performance Monitor Users group is the obvious candidate, but this is a matter of local administrative policy.

4.0 Other System Adjustments

There are some other system changes made by the GDMA installer to support a non-admin service run-as user. These are automated, so there is nothing you need to do about them, but we record them here so you have a complete understanding of how installation of GDMA affects your system.

4.1 The "Performance Monitor Users" group

A number of the plugins that GroundWork provides with Windows GDMA attempt to access certain system counters to find the data they need. But at least some of those counters are not ordinarily permitted to be seen by ordinary users. To get around that, when we believe the run-as account is not one of the standard accounts that Windows assumes should automatically have such access, the GDMA installer will locally add the user to the "Performance Monitor Users" group. This addition of the user to the group is not automatically reversed when GDMA is uninstalled.

4.2 File permissions

Certain files within the installed GDMA software must be read and written during normal operation of the GDMA service. In general, the GDMA distribution is installed while running as an administrator, so write access is only provided to administrators. When provided with an explicit service run-as account, the GDMA installer therefore must and will provide write access to the relevant files and directories to that run-as account. Nothing outside the GDMA distribution itself is touched in this regard.

Some of the GDMA config files on the client contain a bit of sensitive information, which should not be accessible to arbitrary users on the system. Therefore, regardless of whether or not an admin account or a non-admin account is used as the service run-as account, starting with the Windows GDMA 2.6.1 release, world-read permissions are being suppressed for those config files.

5.0 Operational Considerations

The one aspect of this feature that is not fleshed out is how the administrator will execute a diagnostic run of the GDMA poller or spooler if that becomes necessary. The expectation is that it will be much less necessary now that we can safely and permanently enable logging. That is possible because as of GDMA 2.6.1, the GDMA daemons now have log rotation built in and operating automatically. So generally speaking, all the data we need for diagnostic purposes should be in the log files if the customer enables logging (which for now remains off by default as we ship the GDMA release). If that is done, the need for interactive running of the daemons should be greatly reduced. Nonetheless, there may come a time when some strange circumstance causes the system to not even be able to run well enough to start up and log what is happening.

The issue now is that some non-admin accounts will have no ability to support an interactive login. That means that any diagnostic runs would either need to be run as an administrator, or you would need to start a command window running as the GDMA service run-as user and execute the diagnostic run within that window. If you run as an administrator, such runs might create files that would not be writable by the intended service run-as user, and later on GDMA might fail because of that. GroundWork does not currently have a cleanup script that will delete any files that may have been written to while the GDMA service was being run as an admin user, so you should first attempt to use the special command window:

runas /user:"MyDomain\MyUser" cmd

A problem with trying to do that is that you will need to know the password for that run-as account. And that can be difficult to deal with for a managed service account or a virtual account, wherein the system manages the password automatically and you're not likely to know what it is.

The best approach is to anticipate this sort of thing, and when GDMA is installed, use the

--gdma_service_start no

option or take care when answering the equivalent UI question at that time, as described above in the section on service logon rights. Then before the service is first started, edit the

groundwork\gdma\config\gdma_auto.conf

file and turn on logging:

Enable_Local_Logging = "on"

Once you have made all the local changes you need, you can start the GDMA service via the usual mechanism on the Windows platform:

net start gdma

There is also a companion issue regarding the new client-side

groundwork\gdma\bin\discover

tool, which can be used to interactively run a pass of Auto-Setup discovery on the client in case the situation is so bad that the GDMA poller is not reporting back to the server enough information to diagnose problems with the discovery instructions. There may be similar problems with what account to use for such diagnostic runs, if GDMA is installed as a non-admin service run-as user. As above, try using a command window running as the GDMA service run-as user.