views:

5202

answers:

4

Hi all,

Does anyone know what would be the minimum rights I would need to grant to a domain user account in order to run a windows service as that user?

For simplicity, assume that the service does nothing over and above starting, stopping, and writing to the "Application" event log - i.e. no network access, no custom event logs etc.

I know I could use the built in Service and NetworkService accounts, but its possible that I may not be able to use these due to network policies in place.

Thanks,

Paul

+2  A: 

I do know that the account needs to have "Log on as a Service" privileges. Other than that, I'm not sure. A quick reference to Log on as a Service can be found here, and there is a lot of information of specific privileges here.

Chris Marasti-Georg
+10  A: 

Two ways:

  1. Edit the properties of the service and set the Log On user. The appropriate right will be automatically assigned.

  2. Set it manually: Go to Administrative Tools -> Local Security Policy -> Local Policies -> User Rights Assignment. Edit the item "Log on as a service" and add your domain user there.

spoulson
Fantastic - so "Log on as service" is all that is needed for a basic service (plus any rights specific to the logic in the service, e.g. to access network resources). For some reason i'd imagined a huge tangle of rights would be necessary. Thanks
Paul Nearney
A: 

Thanks for the links, Chris. I've often wondered about the specific effects of privileges like "BypassTraverseChecking" but never bothered to look them up.

I was having interesting problems getting a service to run and discovered that it didn't have access to it's files after the initial installation had been done by the administrator. I was thinking it needed something in addition to Logon As A Service until I found the file issue.

1) Disabled simple file sharing. 2) Temporarily made my service account an administrator. 3) Used the service account to take ownership of the files. 4) Remove service account from the administrators group. 5) Reboot.

During Take Ownership, it was necessary to disable inheritance of permissions from the parent directories and apply permissions recursively down the tree.

Wasn't able to find a "give ownership" option to avoid making the service account an administrator temporarily, though.

Anyway, thought I'd post this in case anyone else was going down the same road I was looking for security policy issues when it was really just filesystem rights.

T.Rob
BTW, it shouldn't need to own the files, it should only need read and execute permissions for the files.
X-Cubed
The files in question include the run-time data as well as the static build-time files. The static files can be read/execute but the run-time files need to be updated, new files and directories created, files deleted, etc. It's possible to figure out on a per-directory basis exactly what's needed but it could change across a release or even a fix pack and be devliishly hard to diagnose. So you are correct that less then full ownership is required but from a serviceability standpoint I'd still recommend taking ownership.
T.Rob
A: 

Thanks Rob, it's still helpful!

Alex

related questions