Using CarbonDLLs and sc config I am able to grant the user Logon As Service rights and also able to add the user as the Services' Log on as account.

Previously I was getting Logon Failure but after using carbon and powershell script I was able to remove that error by granting Logon as Service permission to the account.

But now when I start the service I get the following error:

A privilege that the service requires to start does not exist in the Service Account....

For Service Account I'm using a user account from AD which is also added as a Local Administrator on the server on which I am changing the services' log on as account.

For testing I was changing the Logon As Account of Themes service which by default runs under the Local System Account. I don't want to run it under Local System but under the Account Ive assigned


Members of the local group Administrators have many privileges, but definitely not all. One of those extra privileges is the one you already set: Logon as a service. You can find and manage all privileges in the Local Security Settings MMC snap-in (secpol.msc) under Security Settings > Local Policies > User Rights Assignment:

enter image description here

As you can see, not all (allowing) rights contain the Administrators group. If everything worked well, you will already see your domain user under Logon as a service. If not, add it now. This is the minimum requirement for a user account to run an executable1 as a service.

Running the Themes service of course also needs the Logon as a service right. But as you observed - for this service - it is not enough. This particular service also needs the Replace a process level token right. Btw., to learn more about a particular right, just open it and navigate to the Explain tab:

enter image description here

So, in conclusion, to run the Themes service under your domain user, add this account to the Logon as a service and Replace a process level token policies.

A recommendation: Please do not add a user to every allowing policy, to "make things work". This may impose serious security flaws.

As Windows services have to implement the Windows services API, they will contain a SERVICE_REQUIRED_PRIVILEGES_INFOA structure. This contains a list of all required privileges. You can use this C++ code to query this info. Alternatively, you can download the SystemExtensions module for PowerShell and use the Get-ServiceConfig cmdlet:

Get-ServiceConfig Themes | Select-Object -ExpandProperty Privileges



You can then use this documentation to translate these privileges into the policy names (same order as above):

  • Replace a process level token
  • Debug programs
  • Impersonate a client after authentication

1 Keep in mind that not all executables can be run as a service, as they have to implement the Windows services API at least.

  • Secondly by default Themes service runs under local system account and it's not added in Replace process level token but it's still able to run Themes service. So what's the catch there? Thanks – Omair Nabiel Jul 24 '20 at 11:43
  • "I cannot find where you found out that Themes service requires..." Read the last paragraph I added. "local system account and it's not added..." Local System is equivalent to the account SYSTEM with SID S-1-5-18. It is the system itself, it has all privileges. – Thomas Jul 24 '20 at 11:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.