How to allow non-admin to run scheduled tasks remotely?

Server OS: Server 2003 R2
Client OS: XP Pro SP2

I am trying to allow a non-admin user to run a scheduled task on a
remote server. According to the Help text, the user must be a member
of the local Administrators group, the local Backup Operators group,
the domain Server Operators group, or “have been delegated the
appropriate authority, on the local computer”. I would prefer not to
add the user to one of the three groups I mentioned. I have given the
user Read+Execute on the target task. I also gave the user Read (and
even Full Control) to the C:\windows\tasks folder on the server using
CACLS, still no dice. When the user brings up the server via UNC, they
don’t see Scheduled Tasks. I tried running schtasks /query /s serverA,
but the user gets an Access is denied message. I confirmed that the
user can view the scheduled tasks folder when they are a member of the
Backup Operators group, but when they double-click on it, it doesn’t
list the scheduled tasks.

How can I go about delegating the proper authority? Is there a group
policy setting in Server 2003 that will allow a user to run a
scheduled task remotely (i.e. \\server, double-click on scheduled
tasks, right-click the task and select Run)? I already tried providing
the user with Log on as a batch job, but that had no impact.
Thanks,
pimy

In Windows Help:
To run a scheduled task immediately
1. Open Task Scheduler.
2. Right-click the task that you want to run, and then click Run.
Notes
• To perform this procedure, you must be a member of the
Administrators, Backup Operators, or Server Operators group, or have
been delegated the appropriate authority, on the local computer. As a
security best practice, consider using Run as to perform this
procedure.
• To open Task Scheduler, click Start, point to Settings, click
Control Panel, and then double-click Scheduled Tasks.
• You can also run a scheduled task immediately by selecting a
task in
the details pane, and then clicking Run on the File menu

"pimy" <pimy103@gmail.com> wrote in message
news:ffd93b7d-cb85-4ac0-9ede-de94b2855c67@z6g2000pre.googlegroups.com...
Server OS: Server 2003 R2
Client OS: XP Pro SP2

I am trying to allow a non-admin user to run a scheduled task on a
remote server. According to the Help text, the user must be a member
of the local Administrators group, the local Backup Operators group,
the domain Server Operators group, or “have been delegated the
appropriate authority, on the local computer”. I would prefer not to
add the user to one of the three groups I mentioned. I have given the
user Read+Execute on the target task. I also gave the user Read (and
even Full Control) to the C:\windows\tasks folder on the server using
CACLS, still no dice. When the user brings up the server via UNC, they
don’t see Scheduled Tasks. I tried running schtasks /query /s serverA,
but the user gets an Access is denied message. I confirmed that the
user can view the scheduled tasks folder when they are a member of the
Backup Operators group, but when they double-click on it, it doesn’t
list the scheduled tasks.

How can I go about delegating the proper authority? Is there a group
policy setting in Server 2003 that will allow a user to run a
scheduled task remotely (i.e. \\server, double-click on scheduled
tasks, right-click the task and select Run)? I already tried providing
the user with Log on as a batch job, but that had no impact.
Thanks,
pimy

In Windows Help:
To run a scheduled task immediately
1. Open Task Scheduler.
2. Right-click the task that you want to run, and then click Run.
Notes
• To perform this procedure, you must be a member of the
Administrators, Backup Operators, or Server Operators group, or have
been delegated the appropriate authority, on the local computer. As a
security best practice, consider using Run as to perform this
procedure.
• To open Task Scheduler, click Start, point to Settings, click
Control Panel, and then double-click Scheduled Tasks.
• You can also run a scheduled task immediately by selecting a
task in
the details pane, and then clicking Run on the File menu


====

If you were to give a non-admin the unrestricted ability to run tasks on a
server, I believe he would be able to make himself an admin. At the very
least he would be able to create his own tasks/scripts/programs to run -
surely not what you want a non-admin to be doing...

If you just want the user to be able to cause an already existing task to
run at a time of his choosing, then perhaps your best bet would be to create
a task that the user could interact with for that purpose. How best to do
that might depend on the nature of the task(s) involved, but it could be as
simple as having a task running every 5 minutes and quitting if a certain
file does not exist (in a folder to which the user alone has RWC access). If
it finds that the file does exist, it would delete it and then perform the
work that you wanted the user to trigger.

If that is too simplistice, this rudimentary interface could be made much
more sophisticated to handle all kinds of situations. But, again, it depends
on the specific needs you have.

/Al

>
> ====
>
> If you were to give a non-admin the unrestricted ability to run tasks on a
> server, I believe he would be able to make himself an admin. At the very
> least he would be able to create his own tasks/scripts/programs to run -
> surely not what you want a non-admin to be doing...
>
> If you just want the user to be able to cause an already existing task to
> run at a time of his choosing, then perhaps your best bet would be to create
> a task that the user could interact with for that purpose. How best to do
> that might depend on the nature of the task(s) involved, but it could be as
> simple as having a task running every 5 minutes and quitting if a certain
> file does not exist (in a folder to which the user alone has RWC access). If
> it finds that the file does exist, it would delete it and then perform the
> work that you wanted the user to trigger.
>
> If that is too simplistice, this rudimentary interface could be made much
> more sophisticated to handle all kinds of situations. But, again, it depends
> on the specific needs you have.
>
> /Al

Hi and thank you for the response. Yes, the intent is to limit the
user's permission to running an existing scheduled task. This
particular task is used to reset the inheritance flag for a given set
of folders. This forces the propagation of existing permissions down
onto newly created files. New files aren't inheriting by default
because of a bug with third-party software. The users will require
periodic access to those files. Thus I was hoping to let them steer
when the permissions should be updated because they are best suited to
know when access will be required. As of right now I'm just running
the task on a fixed schedule (every hour). Still, my question remains,
how can I go about delegating the "proper authority", without making
them a member of the Administrators, Backup Operators, or Server
Operators groups?

Thanks,
pimy

"pimy" <pimy103@gmail.com> wrote in message
news:0f0660c5-ad83-4e0b-8a5b-907cb3427bc3@x35g2000hsb.googlegroups.com...
> >
>> ====
>>
>> If you were to give a non-admin the unrestricted ability to run tasks on
>> a
>> server, I believe he would be able to make himself an admin. At the very
>> least he would be able to create his own tasks/scripts/programs to run -
>> surely not what you want a non-admin to be doing...
>>
>> If you just want the user to be able to cause an already existing task to
>> run at a time of his choosing, then perhaps your best bet would be to
>> create
>> a task that the user could interact with for that purpose. How best to do
>> that might depend on the nature of the task(s) involved, but it could be
>> as
>> simple as having a task running every 5 minutes and quitting if a certain
>> file does not exist (in a folder to which the user alone has RWC access).
>> If
>> it finds that the file does exist, it would delete it and then perform
>> the
>> work that you wanted the user to trigger.
>>
>> If that is too simplistice, this rudimentary interface could be made much
>> more sophisticated to handle all kinds of situations. But, again, it
>> depends
>> on the specific needs you have.
>>
>> /Al
>
> Hi and thank you for the response. Yes, the intent is to limit the
> user's permission to running an existing scheduled task. This
> particular task is used to reset the inheritance flag for a given set
> of folders. This forces the propagation of existing permissions down
> onto newly created files. New files aren't inheriting by default
> because of a bug with third-party software. The users will require
> periodic access to those files. Thus I was hoping to let them steer
> when the permissions should be updated because they are best suited to
> know when access will be required. As of right now I'm just running
> the task on a fixed schedule (every hour). Still, my question remains,
> how can I go about delegating the "proper authority", without making
> them a member of the Administrators, Backup Operators, or Server
> Operators groups?

I do not know how you can delegate the authority to run a scheduled task,
while restricting the individual's ability to create his own tasks. This is
why I suggested in my last two paragraphs a different approach...

Basically, you have a job running frequently and with which the user(s) in
question communicate through, for example, file semaphores. All they will
need is read/write access somewhere where the file semaphores are stored.

But let me ask you this: do your users have the privileges themselves
required to reset the inheritance flag? If so, then just have them run a
read-only copy of the script directly.

/Al

> I do not know how you can delegate the authority to run a scheduled task,
> while restricting the individual's ability to create his own tasks. This is
> why I suggested in my last two paragraphs a different approach...
>
> Basically, you have a job running frequently and with which the user(s) in
> question communicate through, for example, file semaphores. All they will
> need is read/write access somewhere where the file semaphores are stored.
>
> But let me ask you this: do your users have the privileges themselves
> required to reset the inheritance flag? If so, then just have them run a
> read-only copy of the script directly.
>
> /Al

File semaphores is a great idea. No, the users do not have the
privileges themselves required to reset the inheritance flag.
Ultimately I was hoping to find a way to delegate the privilege of
running tasks, while restricting the ability to create new tasks.
Thank you nonetheless, your words have been helpful.

pimy

pimy,

Please let me know how you solved the executing a scheduled task with
non-admin id. Please let me know what are the privilages required to run to
allow non-admin to run scheduled tasks remotely?




"pimy" wrote:

> > I do not know how you can delegate the authority to run a scheduled task,
> > while restricting the individual's ability to create his own tasks. This is
> > why I suggested in my last two paragraphs a different approach...
> >
> > Basically, you have a job running frequently and with which the user(s) in
> > question communicate through, for example, file semaphores. All they will
> > need is read/write access somewhere where the file semaphores are stored.
> >
> > But let me ask you this: do your users have the privileges themselves
> > required to reset the inheritance flag? If so, then just have them run a
> > read-only copy of the script directly.
> >
> > /Al
>
> File semaphores is a great idea. No, the users do not have the
> privileges themselves required to reset the inheritance flag.
> Ultimately I was hoping to find a way to delegate the privilege of
> running tasks, while restricting the ability to create new tasks.
> Thank you nonetheless, your words have been helpful.
>
> pimy
>