Account Secutiry problem when launched from Automaiton Point

[PeterJ]

We are running Automation Point on NT 4.0 and are using REXX for the program logic and workflow.

The REXX is setup to call an executable (TEXT.EXE) which will then start/stop a service on another server on our network. If I run the TEST.EXE from a desktop command prompt on the Automation Point workstation, it runs fine. If I allow Automation Point to execute TEST.EXE, it uses the system account instead of the current logged-on account and the executable fails because the system account has no access/security privileges anywhere else on the rest of the network.

I have a workaround but it is less than elegant. For now, in the script I do a NET USE to the destination server and include the /USER parameter to specify the account with which I want to connect. Now that I have a valid connection to the server with the proper privileges established, Automation Point can call TEST.EXE and it works fine. When I am done I use NET USE /D to terminate the connection.

What I want is for the command session provided within Automation Point to have the same user environment as the workstation's desktop. Alternately, how can I get Automation Point to use the current userid as it's default instead of using the system account?

 

[PeterJ]

I have so far found 2 possible workarounds - although neither is perfect. We are running Automation Point 3.4 for NT and things may be slightly different under 3.5.

First, we are currently starting Automation Point with the Autostart service. This service uses a "system account" to start the application. If you change this and specify a particluar user account (with all the proper privileges) everything functions properly. The downfall to this is that you can not locally administer Automation Point as there is no longer a GUI on the desktop. - CA confirmed this.

The second option is not to use the autostart and instead put Automation Point into the startup folder. This does require a logon to actually take place and then Automation Point starts with all the privileges of the current logged on user. The downfall here is that this requires a logon before it starts.

I am not pleased with any of these solutions and will continue to persue it with CA. Interestingly, in speaking with a CA support rep in Pittsburgh, he indicated that they had a similar issue at their own location and had to find a workaround. Seems to me that if you know you have an issue, wouldn't you fix it for everyone and not just with a "workaround"?