performance darling service acccount #1802

Activity

1. ESLCH

   added

   questionFurther information is requestedFurther information is requested

   on Jul 28, 2026
2. erikdarlingdata commented on Jul 28, 2026

   

   erikdarlingdata

   on Jul 28, 2026

   Owner

   More actions

   The Darling service connects to your monitored SQL Servers as whatever Windows account the service runs under, for any server entry with "auth": "integrated" in darling.json. So "changing the service account" is a Windows-side change plus a SQL-side grant, with one file permission step in the middle that will bite you if you skip it.

   1. Stop the service, change the Log On account

   Services.msc > PerformanceMonitor Darling > Log On tab > This account > DOMAIN\your-svc-account. Doing it through Services.msc also grants the account the "Log on as a service" right automatically.

   Or from an elevated prompt (note the space after obj= and password=, sc requires it):

   sc config "PerformanceMonitor Darling" obj= "DOMAIN\svc-account" password= "ThePassword"
   

   With the sc route you have to grant "Log on as a service" yourself (secpol.msc or GPO), which is why Services.msc is the easier path. A gMSA works too: obj= "DOMAIN\gmsa-name$" password= "".

   2. Grant the AD account on each monitored instance

   USE master;
   CREATE LOGIN [DOMAIN\svc-account] FROM WINDOWS;
   GRANT VIEW SERVER STATE TO [DOMAIN\svc-account];
   GRANT ALTER ANY EVENT SESSION TO [DOMAIN\svc-account];
   
   /* Only if the instance hosts Availability Groups */
   GRANT VIEW ANY DEFINITION TO [DOMAIN\svc-account];
   
   /* Optional: SQL Agent job monitoring + failed-job alerts */
   USE msdb;
   CREATE USER [DOMAIN\svc-account] FOR LOGIN [DOMAIN\svc-account];
   ALTER ROLE SQLAgentReaderRole ADD MEMBER [DOMAIN\svc-account];

   3. The step people miss: re-grant the service's own files

   The service deliberately locks its files down to SYSTEM, Administrators, and the account it was running as. After you switch accounts, the new account is not on those ACLs and the service will fail to read its config or write its store. One-time fix from an elevated prompt, before starting the service:

   icacls "C:\ProgramData\PerformanceMonitorDarling" /grant "DOMAIN\svc-account:(OI)(CI)F"
   icacls "C:\PerformanceMonitorDarling\darling.json" /grant "DOMAIN\svc-account:F"
   

   Adjust the second path to wherever your darling.json sits next to the service exe. The first path covers the logs and, if you use the bundled managed Postgres, the store's data directory. On its next start the service re-asserts the tight ACL itself, now including the new account, so this is a one-time step.

   4. Start it and verify

   Start the service and watch C:\ProgramData\PerformanceMonitorDarling\logs for the per-server connect lines. One caveat: running --test-connection from your own console tests integrated auth as you, not as the service account, so the service log is the real proof.

   Two things you do not need to worry about: anything you encrypted with --encrypt-password (SQL auth passwords, SMTP) survives the account change, because those blobs are DPAPI machine-scope, not account-scope. And your collected data is untouched by any of this.
3. erikdarlingdata commented on Jul 28, 2026

   

   erikdarlingdata

   on Jul 28, 2026

   Owner

   More actions

   Closing as answered - the steps above are the complete recipe. If the account switch hits anything they do not cover, comment here and it can be reopened.
4. erikdarlingdata

   closed this as completedon Jul 28, 2026
5. ianwalkeruk

   added a commit that references this issue on Jul 31, 2026

   Darling: survive service accounts that are not the virtual account (e…

   ...

   4ef54e8
6. AAvella commented on Aug 7, 2026

   

   AAvella

   on Aug 7, 2026

   More actions

   Think I followed proper steps here but ran into an issue. Does the domain account need any other permissions on the machine the service is running on?

   • Installed Darling as a service (Using default data store, and connecting to 2 targets with Windows Auth)
   • Stopped the service
   • Changed service account (in the GUI) to a domain account
   • Regranted file-permissions to the service account
     PS C:\performancemonitordarling> icacls "C:\ProgramData\PerformanceMonitorDarling" /grant "MYDOMAIN\SVC-Darling:(OI)(CI)F"
     processed file: C:\ProgramData\PerformanceMonitorDarling
     Successfully processed 1 files; Failed processing 0 files
     PS C:\performancemonitordarling> icacls "C:\PerformanceMonitorDarling\darling.json" /grant "MYDOMAIN\SVC-Darling:F"
     processed file: C:\PerformanceMonitorDarling\darling.json
     Successfully processed 1 files; Failed processing 0 files
   • Started service
   • Opened Darling Viewer and get errors below:
     2026-08-07 15:35:25.225 [INFO ] [Lifetime] Application started. Hosting environment: Production; Content root path: C:\performancemonitordarling
     2026-08-07 15:35:25.895 [INFO ] [DarlingWorker] Loaded configuration from C:\performancemonitordarling\darling.json: 2 server(s)
     2026-08-07 15:35:28.423 [CRIT ] [DarlingWorker] Managed Postgres bootstrap failed: The managed Postgres credential file C:\ProgramData\PerformanceMonitorDarling\pg-credential.dpapi is not owned by SYSTEM, Administrators, or the service account — it may have been tampered with or pre-planted. Refusing to trust it. Investigate, then restore it from backup or re-initialize the data directory (destroys collected history).
7. erikdarlingdata commented on Aug 7, 2026

   

   erikdarlingdata

   on Aug 7, 2026

   Owner

   More actions

   You did everything the runbook says — the missing piece is that icacls /grant changes permissions but never ownership, and this particular check is an anti-tamper gate on the file's owner. The credential file is still owned by the previous service account (the virtual NT SERVICE\... identity from the original install), which is neither SYSTEM, Administrators, nor your new MYDOMAIN\SVC-Darling — so the service refuses to trust it rather than authenticate with a possibly-planted password. Your store and history are fine.

   From an elevated prompt, with the service stopped:

   # ownership to Administrators — stays trusted across any future account change
   takeown /f "C:\ProgramData\PerformanceMonitorDarling\pg-credential.dpapi" /a
   icacls "C:\ProgramData\PerformanceMonitorDarling\pg-credential.dpapi" /grant "MYDOMAIN\SVC-Darling:(F)"
   
   # the sibling credential files take the same treatment (idempotent if any don't exist)
   Get-ChildItem "C:\ProgramData\PerformanceMonitorDarling\pg-*.dpapi" | ForEach-Object {
       takeown /f $_.FullName /a
       icacls $_.FullName /grant "MYDOMAIN\SVC-Darling:(F)"
   }

   then start the service. To your broader question — the domain account needs: Log On as a Service (services.msc grants it automatically when you set the account there), the file grants you already made, and nothing else; all the DPAPI-encrypted secrets are machine-scope, so they survive the account change untouched.

   Two notes: newer builds replace that terse "tampered with or pre-planted" message with one that names the actual owner it found and prints this exact remediation — you'll see it if this ever recurs after upgrading. And once you're running, a later install-darling.ps1 upgrade preserves a custom Log On account and re-hardens files for it, so this is a one-time step, not a per-upgrade one.
8. dphugo

   added a commit that references this issue on Aug 19, 2026

   Refuse an install location the service account can never read (erikda…

   ...

   d7af697