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?
Best Answer
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.