Let's say you have an active directory domain, and you want to have a service account run a certain windows service on multiple machines on the domain. The service account needs to be the same account on all the servers because it needs certain (file access) permissions across all the servers.

The minimum permission you need for this user to be able to run a service is "Log on as a service" permission - in fact, as soon as you go to the Services panel and try to set up a service with a domain user (regardless of what rights they already have, I believe) they automatically get assigned the "Log on as a service" permission.

What I'm trying to to understand is what other rights / permissions this automatically implies;

I'm finding that a service running under a domain account with "Log On As a Service" rights and no other (intentional, at least) rights, is still able to read files on the local file system. Does this mean that I've got a permission inheritance somewhere that I don't know about, or does that mean that "Log on As a Service" also grants some file access or other rights on the server?

I guess another way to ask the question - is there a utility that can tell you, for a given object/user/account, exactly what rights it has and why/where from?

  • 1
    domain users is in your local users thus it gains perms from that – tony roth Jun 23 '10 at 18:55
  • that is absolutely correct, thanks! (I've now figured that out from looking in procexp as suggested below) – Tao Jun 23 '10 at 19:10
  • @tony roth, a follow-up if I may (not enough for a new question): with that setup is there any way for domain users to gain access to the filesystem that isn't "Log On Locally"/"As a Service"/"As a Batch Job", or of course an explicit share? I'm a little freaked out by this, feels like any domain user potentially has filesystem access but I'm not sure whether those are the only possible entry points. – Tao Jun 23 '10 at 19:25
  • @tao yes they can gain access if you have a share permissions set up incorrectly. If there are no shares then being in domain user won't grant them access to resources on the server. From the sounds of it I don't think your service needs to login with a domain account. If I can have more details about what your doing I can give you a better way to do things. – tony roth Jun 23 '10 at 22:11
  • OK, fair enough, thanks; The reason we're using a domain account is that multiple servers need to be able to access each others' filesystems - we really don't want to be adding a list of the other servers' machine users to each of the servers, that becomes a maintenance nightmare (and poor security anyway, when you end up assigning them all the same password) – Tao Jun 23 '10 at 22:39

There are different logon types. Specifying a given account or group as having "Logon as a Service" rights permits that account or grup to logon with that particular logon type. "Logon as a Service" doesn't grant any additional rights to the account other than the ability to logon with the "LOGON32_LOGON_SERVICE" type.

Group memberships, such as membership in the "Users" group, drives the ability to read files from the filesystem. Using the "WHOAMI /ALL" command while logged-on as the service user can show you all the group memberships and privileges granted to a given user account (including SeLogonServiceLogonRight-- the privlege behind the "Logon as a Service" right). The SysInternals "Process Explorer" tool can do this for running processes (by enumerating their security token).

As far as auditing filesystem access goes, you're going to have to write something or find a third-party tool to enumerate all the files and directories you want to test. There's no central "clearinghouse" for filesystem ACLs. They're strewn about all over the filesystem. If you want to know "which files / folders xxx user has access to" you'll have to test all the files and folders to see.


The SysInternals tool 'procexp' will give you this. Run the tool, hunt for the process started by the service, right-click on it and go to properties. On the 'Security' tab it will give you a list of authorities held by that process, as well as telling you who it is logged in as. This should help you chase down the access environment for the service process.

  • Awesome, I had no idea that procexp could do that - thanks for the great tip! I would have liked to accept this as the answer but @Evan Anderson's answer below had more :) – Tao Jun 23 '10 at 19:08

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.