This is all stemmed from an initial requirement in that I want a sql job to run a windows scheduled task. To do this I had to setup xp_cmdshell on SQL server, I don’t want to go into the pros/cons of xp_cmdshell , but to try to reduce risk I setup xp_cmdshell to use a proxy account, which is a reduced level windows user.
However in doing this I discovered that the user could not run the scheduled tasks. This in the end turned out to be that the scheduled tasks are only visible to the user that created them or a user with same permissions or higher. So the existing tasks having been created by an administrator were not accessible to this lower user.
After trying many thing to get this working I settled on this solution. This may or may not be the correct way but it works for me.
So I logged into windows using the lower user, then created a basic task in task scheduler. This task did nothing except fire up cmd.
Once this task had been created, I then logged in as an administrator and modified the task to fully do what I wanted. Including the option run as another user (which you cannot set using the low end user).
So in essence once the initial task is setup by the user it appears that you can use an admin account to change the options that cannot be changed with the low level user.
In addition if you don’t set the run as another user option you will have to ensure that the non admin account has appropriate access to the objects it will try and access.
With this done, you will find that the task can now be executed by the low level user, and hence the xp_cmdshell procedure can be run within a reduced security user and run the scheduled task I desired.
In addition it must be noted that any higher level user (administrator) can see and run all scheduled tasks including the low level user generated tasks.
Now if I can just figure out how to assign rights to allow non admin users to manage scheduled tasks, that would be great…
Actually I did the same as you, before reading this your blog post but the result was that the task didn't even run manually from both admin and non admin accounts.
ReplyDeleteI finally realized that the user set in "run as another user" option, if used to gain high privileges for the task, must be a LOCAL machine administrator account; it DOESN'T WORK if the administrator account is a DOMAIN one (not local).
Hope this helps.
Alex
I found that if you create a sub folder and grant hte group or user permissions they can add, mosify or run those tasks with out messing with any you setup as an adminthe actual folder is a bit trickybut on a windows 2008R2 its :
ReplyDeleteC:\Windows\System32\Tasks
Regards
JMc