Documentation

Service Account

This page is also in the Groundskeeper wiki: https://github.com/rsjsoftwareltd/groundskeeper/wiki/Service-Account

Groundskeeper runs as a Windows service on your server. By default that service runs as Local System -- which is fine for the cloud connectors. On the network, Local System acts as the server's own computer account, which has no administrator rights on your other machines. So it can't do the agentless WMI/CIM reads (Windows servers/clients, Active Directory, AD Account Health, and the other LAN connectors) that need a proper domain account.

To use those connectors, run the Groundskeeper service as a domain account. This page covers the account to create (a dedicated, low-privilege one), and how to set it from the dashboard so Groundskeeper reapplies it for you across upgrades.

The quick version: create a dedicated Domain User called svc-groundskeeper, then set it on the General Settings > About screen and click Apply now. Groundskeeper stores it encrypted and re-sets it after each upgrade, so the account doesn't silently revert to Local System. An ordinary Domain User is enough for every AD-read connector; if you also use the agentless WMI connectors (Windows Servers, Windows Clients, Endpoint Reports), the account additionally needs admin rights on the machines it monitors -- two ways to grant that, see Step 3.

How much privilege does it need? (an honest answer) #

Groundskeeper is read-only by design -- it never writes to Active Directory, never resets accounts, never changes anything on the systems it monitors. Every AD connector works as an ordinary Domain User.

The agentless WMI connectors are the exception: Windows only lets an account query another machine over WMI/DCOM if that account has admin rights on the target machine. So the practical choice is about where the account gets admin, not whether:

• Recommended -- local admin on monitored machines, via one Group Policy. Create a group (e.g. GK-Monitoring), put the service account in it, and add the group to the local Administrators group of your monitored servers/workstations via GPO (Restricted Groups). About five minutes, once -- and the account still cannot touch Active Directory, Group Policy, or your domain controllers. If the credential is ever exposed, the blast radius is the monitored machines, not the domain.
• Quicker -- add the account to Domain Admins. One click, and it works. Be aware of what it means: the account's password is stored (encrypted) on the Groundskeeper server, and Domain Admins membership makes that one credential full control of your entire domain if that server is ever compromised. A penetration test, cyber-insurance questionnaire, or Cyber Essentials assessment may flag a domain-admin service account. If your risk appetite accepts that for the convenience, it is your call to make -- this page just makes sure you make it with eyes open.

An earlier version of this page claimed WMI monitoring needed only scoped per-namespace grants, "not local admin". That is technically achievable and practically not deployable -- there is no native Group Policy mechanism for WMI namespace permissions, so following the recipe meant custom startup scripts nobody realistically runs. The advice above replaces it with the two options schools actually use.

Step 1 -- create the service account #

On a domain controller (or anywhere with AD Users & Computers / RSAT):

1. Create a new domain user -- suggested name svc-groundskeeper.
2. Give it a long random password, and set Password never expires (a service account whose password lapses will stop the service starting). A group Managed Service Account (gMSA) is a stronger alternative if your estate supports one.
3. Leave it as an ordinary member of Domain Users -- add it to no other groups. That is enough for all the Active Directory read connectors.

That's the whole account for AD monitoring. The next two steps only matter for specific connectors.

Step 2 -- grant "Log on as a service" + set the account #

You can do this from the dashboard -- Groundskeeper will grant the required rights and set the account on its own service for you.

1. Open General Settings > About.
2. In the Service Account section, enter the username in DOMAIN\svc-groundskeeper form and the account password.
3. Click Save account to store it (encrypted on this machine), then Apply now to set it on the Groundskeeper service.
4. Restart the Groundskeeper service for the change to take effect. The About screen then shows the service running as svc-groundskeeper instead of Local System. Check service health confirms the service came back up correctly.

Apply now does several things in one click, so you don't need to touch Local Security Policy, file permissions, or sc config by hand:

• Grants the account the "Log on as a service" right (a service will not start under an account that lacks it).
• Grants the account read access to the TLS private key, so the app can still serve HTTPS once it's running under the account instead of Local System.
• Grants the account Modify on the ProgramData data directory (C:\ProgramData\RSJ Software\Groundskeeper\Server), so it can write config, the database, and logs.
• Grants the account service-level start/stop control, which the Restart Service button on this same screen relies on (see below).
• Grants the account Remote Desktop Services "Query Information" rights, so it can see other users' RDP/console sessions via quser -- needed for the Ollama automatic-install feature (Settings > AI) to find a live admin session to install into. A plain domain user can otherwise only see its own session, not anyone else's. If you set the account up on an older version, click Apply now once more to pick up this grant.
• Points the Groundskeeper service at the account.

Before changing anything, Apply now asks Windows to check the password. If Windows refuses it (wrong password, expired, account disabled or locked out), nothing is changed and the reason is shown.

GPO gotcha. If a Group Policy in your domain already defines the "Log on as a service" User Rights Assignment, that GPO's list is what actually applies -- and it overwrites any local grant Apply now makes the next time gpupdate runs, silently reverting the service to failing on startup. In a GPO-managed estate, add the service account (or a security group it belongs to) to that GPO's own "Log on as a service" assignment instead of relying on the local grant alone.

Doing it manually instead? If you'd rather set it outside Groundskeeper, grant "Log on as a service" via Group Policy (Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment > Log on as a service) or secedit, then set the account on the service (services.msc > Groundskeeper > Log On tab). The catch this page solves is that a manual account reverts to Local System on the next upgrade -- see below.

Restarting the service from the dashboard #

The Restart Service button (About screen) works via a short-lived Scheduled Task, which Windows only allows an account with local Administrator rights to create -- this is a Windows Task Scheduler requirement, separate from the service account's own privileges above. If the session clicking the button isn't a local admin (a plain domain user session, for example), the button shows a clear message explaining this rather than failing silently; use services.msc to restart the service manually in that case.

Step 3 -- admin rights on monitored machines (WMI connectors) #

Only needed if you use the agentless Windows server/client connectors (as opposed to deploying the RSJ Agent to those machines, which needs none of this). Without this step, the Windows Servers Test connection button -- and the connector itself -- reports "Access is denied" for every server (once the firewall lets WMI through; before that it says "The RPC server is unavailable"): Windows requires the calling account to have admin rights on the target machine before it will answer remote WMI/DCOM queries.

Two ways to grant it -- quick vs secure, pick one:

Option A (recommended) -- local admin on monitored machines, one GPO #

1. In AD Users & Computers, create a security group, e.g. GK-Monitoring, and add svc-groundskeeper to it.
2. Create (or edit) a GPO linked to the OU(s) containing your monitored servers/workstations: Computer Configuration > Policies > Windows Settings > Security Settings > Restricted Groups -- add GK-Monitoring, and under "This group is a member of", add Administrators.
3. Wait for Group Policy to refresh on the targets (or run gpupdate on a couple), then click Test connection on the Windows Servers connector -- it should report the sampled servers reachable.

The account gets admin on the machines it monitors and nothing else -- it still cannot touch AD, Group Policy, or your domain controllers.

Option B (quicker) -- Domain Admins #

Add svc-groundskeeper to Domain Admins. One click, no GPO, works immediately -- with the trade-off described in "How much privilege does it need?" above: that one stored credential becomes full control of your domain, which a security audit or Cyber Essentials assessment may flag.

See Firewall and Network for the matching firewall rules (TCP 135 + the dynamic RPC range) and the full agentless-WMI checklist. If you deploy the RSJ Agent to endpoints instead, skip this step entirely -- the agent reports in over outbound HTTPS and needs no domain account of its own (it runs as Local System per endpoint).

Why Groundskeeper manages the account (upgrades) #

The Groundskeeper installer stops, removes and re-registers the Windows service on every upgrade. That re-registration always creates the service as Local System -- so a service account you set by hand would silently revert to Local System after each update, and your AD/WMI connectors would quietly stop returning data until you noticed and set it again.

To avoid that, Groundskeeper stores the account you set (username + password, password encrypted at rest with Windows DPAPI) and reapplies it. Setting the account through the About screen -- rather than by hand in services.msc -- is what lets it survive upgrades.

After an upgrade, Groundskeeper puts the account back and restarts the service once by itself. Two starts in a row after an upgrade are normal, and the dashboard may be slow for the first minute.

Security note. The stored password is encrypted with machine-scoped DPAPI: it can only be decrypted on this server. That protects it against theft of the config file off the box. It is, by necessity, reversible by anything already running with admin/SYSTEM rights on the server (Groundskeeper itself has to be able to read it to reapply it) -- which is exactly why the account should be low-privilege: a decrypted credential then grants only ordinary domain-user access, not domain compromise.

If the account's password changes #

Set the account's password to never expire (Step 1). If it is changed in Active Directory anyway, Windows can no longer start the service: it fails with error 1069 ("logon failure") at the next restart, and the dashboard is simply unreachable -- Groundskeeper is not running, so it cannot tell you. To fix it:

1. In services.msc, open Groundskeeper > Log On, enter the new password (or choose Local System for now), and start the service.
2. Open General Settings > About, enter the new password in the Service Account section and click Apply now.

If the stored password stops working while Groundskeeper is still running (for example at an upgrade), it stays on its current account rather than breaking, and the feed shows "The service account's password no longer works". Enter the new password and click Apply now; the problem clears once it works.

Stop managing the account #

To hand the service back to manual management, open General Settings > About and click Stop managing in the Service Account section. Groundskeeper forgets the stored account and no longer reapplies it. The service keeps running under its current account until it is next restarted or upgraded.

What the About screen tells you #

See also: Connectors for which connectors need a domain account, and Firewall and Network for the WMI/DCOM firewall and permission checklist.

Last updated: 2026-10-17 (v0.192.4)