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:
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.
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:
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 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.