Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

A Windows Scheduled Task runs as serviceAccount@domain.tld on a 2008R2 server. The server's local disk has some files that Joe Blow should not see. Joe Blow knows the serviceAccount password. As far as I know, serviceAccount has no server privileges beyond Log on as a batch job, and local Users group membership via Domain Users. Could Joe read those files?

If so, I should probably create another service account to run the task. But I'd prefer to avoid that clutter, if 'Log on as a batch job' does not expose the files.

The question title may be misleading; I'm asking if I've done due diligence restricting unauthorized access in this particular case. I'm not asking for help reading files... although I am asking if and how files might be read.

I was relieved to get Access Denied attempting to use Enter-PSsession as serviceAccount to create a remote session. But I haven't tested much further.

The server is a VMware virtual machine, but I'm asking here about guest-level as opposed to hypervisor-level security.

edit I tried scheduling a Task on a second server, where serviceAccount is in the local Administrators group. (That membership was not my decision, and i'm aware it's bad practice.) The Task runs test.cmd with contents:

dir \\firstServer\c$\ > C:\temp\out.txt 2>&1

Ran the task as serviceAccount and "Task Scheduler successfully finished" with out.txt contents, 'Access is denied.' - good. As a kind of control test, ran the task as otherAdmin with rights to both servers, and out.txt contained the directory listing from firstServer.

So maybe I should have asked: should I create a new service account for which Joe Blow does not have the password? Or is that unnecessary?

More about this convoluted scenario here.

share|improve this question
If the account is a member of Domain Users and is in the Local users group then he could access anything on that server that the Local users group could access (SMB shares, printers, etc.) – TheCleaner Mar 29 '13 at 19:02
@TheCleaner - No folders are Shared, and I'm not concerned about printer access unless you think it would help Joe read a file on the local drive. – noam Mar 29 '13 at 21:47

Joe can read those files if he creates a batch job, sets it to log in as that user, and has that batch job read that data and somehow get it out to him. Or, if he manipulates the existing batch job to somehow read that data.

share|improve this answer
Fair enough... see edit. – noam Mar 29 '13 at 21:45
Assuming Joe's efforts to read the restricted data will be less than heroic, do you agree with Kasius's conclusion in the comments? Or have we missed something? – noam Apr 2 '13 at 17:06

I assume that Joe Blow is not an administrator and thus cannot create Scheduled Tasks. If this is the case, set the NTFS permissions on the file to only allow "Administrators" and the "BATCH" built-in group to read the file. "BATCH" includes users who are currently logged in via batch mode. Batch mode is only for scheduled tasks. You can't login via batch mode just by creating a .BAT file, so this should work for your purposes. The file will only be readable by admins and accounts logged in via scheduled task.

share|improve this answer
Thanks. Joe does not have local Administrators group privileges on firstServer. The Scheduled Task is a Powershell script and actually runs fine without the BATCH group in the security context. – noam Apr 1 '13 at 15:39
I'm afraid this answer begs the question: could Joe somehow log "in via scheduled task" and read the data? Or has he been effectively restricted? – noam Apr 1 '13 at 21:36
As long as the Administrators group and BATCH group are the ONLY groups listed in the NTFS permissions, and the user is not an Administrator, he will be effectively restricted. A user cannot create a scheduled task, and I am fairly certain there is no mechanism by which a user can initiate a batch mode login. There's no interface for it, programmatic or otherwise. Another process on the machine has to initiate a batch login for somebody. – Kasius Apr 2 '13 at 16:18

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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