TeamSite Groups - iwgroup - Remove/Add issue

TS 6.7.2 Service Pack 2
Windows
TeamSite Groups

We are using the following command from perl script in a work flow :

1) iwgroup remove-users GRPNM USR1 USR2 USR3 ... USR10

Initially it worked fine, but now it is writing the error in the log as
Error : ERROR:00013: Permission denied

2)Same with addition :

iwgroup add-users GRPNM USR1 USR2 USR3 ... USR10 USR11
ERROR:00013: Permission denied

When we use same command from command line then these are working fine.
Here we are deleting all current users and adding them all by including new users.

Can you please advice the other possibilities? Thanks in advance.

Find more posts tagged with

Comments

sheikh1

You might need look at owner of workflow task who is executing the script. By default the value would bd $IW_USER which takes the same user as who initiated the workflow job.

As a last option you can also change the owner of the task to 'root' user.

Srinivasa Talla

$result1 = `$delTSGroupUsersCmd $redirect`;

do we get the user issue(owner/root) when we execute like above command? I guess the system will run the above command as root user. If not, in this particular command, how can mention the root user?

sheikh1

$result1 = `$delTSGroupUsersCmd $redirect`;

do we get the user issue(owner/root) when we execute like above command? I guess the system will run the above command as root user. If not, in this particular command, how can mention the root user?

The script in which you have the above statement $result1 = `$delTSGroupUsersCmd $redirect`; will be run by default as the same user who initiates the job unless you change it to something. YOu can change the owner of the task from the task properties in WFM client. I'm guessing you are using ane external task to run your perl script.

Srinivasa Talla

Yes, it is external task/script. It was working before. But not sure what happened after that.

Adam Stoller

Yes, it is external task/script. It was working before. But not sure what happened after that.

What happened is that it probably worked before because the users who were running the job (or who owned the task) had sufficient rights to perform that action - and now they don't -- they were probably members of the Administrators, or Local Administrators group on the TeamSite server, and someone in IT decided to "clean things up" such that they no longer are members of those groups on the server.

You might be able to hard-code the owner of the task to either "SYSTEM" or "Administrator" (assuming the account hasn't been renamed, if it has, use that name instead).

Srinivasa Talla

For the external tasks to be executed as SYSTEM in TeamSite 6.7, you need to set the following in the [authentication] section of the iw.cfg file:

[authentication]

impersonate_without_password=false

If we add this line, will that effect any other permissions?

Actually we are using this add group script in assignment workflow. Can we give any special permission to the assigner to make it work without doing changes to iw.cfg?

sheikh1

For the external tasks to be executed as SYSTEM in TeamSite 6.7, you need to set the following in the [authentication] section of the iw.cfg file:

[authentication]

impersonate_without_password=false

If we add this line, will that effect any other permissions?

Actually we are using this add group script in assignment workflow. Can we give any special permission to the assigner to make it work without doing changes to iw.cfg?

As I see that you are on windows I'm quite not sure about it. I have seen a similar thread of using impersonating setting for windows, you can give a try, restart teamsite after your changes to iw.cfg and beware of any negatives which come out of this change.