The script user needs all the rights necessary to run the commands you are using - so it's not as simple as "it needs x,y,z" etc. It also needs a high enough admin level (obviously "1" is not going to cut it). For example, all machines are level 1 so if you have a script which only works with machines, a level 2 scriptuser may be sufficient.
It certainly does not need level 32, all rights though, but that certainly removes the problem of "permission denied".
The best thing to do is to test the commands you want to use with the .exe version of the API, and of course, to have proper error handling for permission issues.
Thanks for the update. So If I have all the machines at admin level 1, support team at 10, admin at 32 and scriptuser at 31. Would that satisfy the security hierarchy. Are there any security implications with Scriptuser having 31 - admin level?. Some users have local admin previliges to laptop.
it means the scriptuser account will be able to modify any user account?
As I said above though, without analyzing what you are using the scriptuser for, who can tell?
We predominently use scripts for password reset (for SSO), few scripts for creating machine groups, user groups, provision users (from a flat file - exported AD users), disable support ids.
Give regular users lower security levels. Then just use one notch higher for your scripting account.
But pay attention to permission sets for various tasks. Again, you just need to enable some permissions, only those that are neccessary for job to be done.
Run scripts on secured systems, or encrypt/compile your scripts to hide credentials.
Thanks Simon & Peter.