WFM: Java copy files through UNC path

Environment

Find more posts tagged with

Comments

Why not FTP it over?

Or you could look into the "runas" command.

Google "runas batch file with password" and you will find an Experts Exchange link that has some good details on how to use the runas command with a password.

Adam Stoller

Why not FTP it over?

Well - let's see:

Any other ideas?

Migrateduser

As far as security is concerned, you can grant access to specific IP addresses in the FTP server in IIS. Is this the most secure, maybe not, but then username and password is not needed if you enter ip addresses.

ISCBorisB

[QUOTE=ghoti]Well - let's see:

Perhaps you can use JAAS' (starting with 1.4 this Package has been integrated with JRE) doAs Method(s).I do not know though if JAAS will allow SYSTEM to authenticate "Subject" with the Task Owner Credentials

Migrateduser

You could run your java app as a Windows service. Run the service under an account that has network access to your target server and pass your parameters to that application.

Another solution that I implemented years ago, but have since gone away from is to copy the files to another location on your TeamSite server. I then created a virtual directory in IIS on the web server that pointed to the location on the TeamSite server (you could point to your staging area on iw-mount instead if you don't perform the redundant copying). This worked great on our pre-prod servers for many years. I now use opendeploy and have abandoned this method. By the sounds our your example this won't work well in your environment, but I thought it could help others.

Migrateduser

Is there some [relatively easy?] way to "force" the process (at least this part if not the entire process) to be owned by the task owner? (again, this is a URLExternalTask, not a CGITask - and it's written in Java, not Perl)

Does your taskowner currently have permission to the target location? If not, then trying to run your code as the taskowner won't help much and you'll have to run as a user who does. I would be surprised if your taskowners were also given permission to your target server. But, since I don't know what your entire setup look like and if you're sending to a staging or production server I just have to guess.

Adam Stoller

Does your taskowner currently have permission to the target location? If not, then trying to run your code as the taskowner won't help much and you'll have to run as a user who does. I would be surprised if your taskowners were also given permission to your target server. But, since I don't know what your entire setup look like and if you're sending to a staging or production server I just have to guess.

Yes - the task owner does have access to the directories and files (via Windows Explorer, I can navigate to \\TGTSRV\folder and rename a file in that directory)

Adam Stoller

Perhaps you can use JAAS' (starting with 1.4 this Package has been integrated with JRE) doAs Method(s).
I do not know though if JAAS will allow SYSTEM to authenticate "Subject" with the Task Owner Credentials

I just took a [very] quick look at some of the JAAS stuff on the web, and it sounds like I would still have to deal with explicit authentication (userid + password) in order to use it - so that's pretty much a non-starter for me.

I would really like to minimize the amount of coding overhead needed to perform what otherwise is a simple file copy operation.

What strikes me as odd is that apparently this used to work on their old (6.5) server using a Perl script with Win32API::File->CopyFile() and as near as I can tell they were using UNC paths then. So I'm confused why it won't work in Java (I'm assuming it worked on their old system in Perl - I wasn't involved with that implementation - I just know that they want to move away from WFT+Perl and towards WFM+Java)

ISCBorisB

...it sounds like I would still have to deal with explicit authentication...

Please note that in Windows 'Administrator' and 'SYSTEM' are sort of super-users, they are both mapped to euid 0.
You just *might* be able to get away with userid only (and you already have it). That said, I never tried. As to
minimizing coding - it's Java, what can I say...

Migrateduser

Probably not highly recommended, but you could run the TeamSite service under a named account instead of the Local System account. It has to be an account that has access to the other server. I don't know what other issues you may encounter by doing the above, but's if it works it's the easiest solution. It's similar to the process for placing the backing store on another server.

Here are some documents describing some of what needs to be done (in version 6.x) in order to make it work properly.

https://customers.autonomy.com/support/secure/docs/FAQ/Interwoven/49040.html

https://customers.autonomy.com/support/secure/docs/FAQ/Interwoven/2072.html

Adam Stoller

Probably not highly recommended, but you could run the TeamSite service under a named account instead of the Local System account. It has to be an account that has access to the other server. I don't know what other issues you may encounter by doing the above, but's if it works it's the easiest solution. It's similar to the process for placing the backing store on another server.

Here are some documents describing some of what needs to be done (in version 6.x) in order to make it work properly.

https://customers.autonomy.com/support/secure/docs/FAQ/Interwoven/49040.html

https://customers.autonomy.com/support/secure/docs/FAQ/Interwoven/2072.html

Adam Stoller

Please note that in Windows 'Administrator' and 'SYSTEM' are sort of super-users, they are both mapped to euid 0.
You just *might* be able to get away with userid only (and you already have it). That said, I never tried. As to
minimizing coding - it's Java, what can I say...

Hmm - well I'm trying to verify that the perl code worked on their old dev system - because I just tried a very simple WFT running a very simple externaltask script using the Win32API::File module - with hard-coded source / target files - and it failed for "Access Denied" too.

Migrateduser

Win32API::File never worked for me either when trying to copy out to a UNC path.

You're running the TeamSite service under a named account that has access to the other server and it isn't working? Seems like it should work. However, I can't say that I have ever tried it, wanted to, but never did.

Is the account you're using in the service an Administrator account or an account that they set up just for this service? If it's an account set up for this service, then maybe they cut down the permissions too far. See if they'll let you run it as an Administrator account, just for testing purposes. Preferably an Active Directory Administrator account.

Adam Stoller

[QUOTE=ghoti]Environment

mart2001

Does your copyFile java program work from the command line, and not through the TeamSite workflow? You can test that out by adding a main method to your class and just call the required methods passing the argument necessary.

Adam Stoller

Does your copyFile java program work from the command line, and not through the TeamSite workflow? You can test that out by adding a main method to your class and just call the required methods passing the argument necessary.

I believe I tested this yesterday and was unable to get it to work - however I shall probably try testing that again today.

What has me concerned / curious is that it works from the workflow if I copy the file via a UNC path to their PROD target server, but not if I use a UNC path to their DEV target server - and I believe the permissions on the folders are now essentially the same ("Everyone" FULL).

UPDATE[indent]If I run the code manually - as me - then it works for both PROD and DEV target servers.
If I run the code through the workflow - as SYSTEM - then it works for PROD and fails for DEV target servers.[/indent]

Migrateduser

Are all the DEV and PROD servers running Windows 2003 SP3?

Are they all part of the same domain or active directory and using the same group policies?

I also find it hard to believe that it's really using the System account during the successful copying to PROD. There is just no way that you can use the System account and get network access. Not possible. It must be using another account.

On the PROD server, what user displays as the owner of the successfully copied file?

Migrateduser

I figured out how you can do it. I tested it and it works.

In your security and sharing options on the destination computer you need to add the name of the source "computer". Not a user account. This way it will trust the computer and the system account. If you are unable to see the computer make sure you click the "Object Types" button and select "Computers" in the security area.

You need to add the TeamSite computer to the share on your DEV boxes.

This is all assuming that they are all on the same domain.

Adam Stoller

I figured out how you can do it. I tested it and it works.

In your security and sharing options on the destination computer you need to add the name of the source "computer". Not a user account. This way it will trust the computer and the system account. If you are unable to see the computer make sure you click the "Object Types" button and select "Computers" in the security area.

You need to add the TeamSite computer to the share on your DEV boxes.

This is all assuming that they are all on the same domain.

I've passed this suggestion along - and now have to wait to see if the proper folks can do this.

Yes, the servers are all in the same domain - though the TS DEV server is brand new (VM instance) and I'd be surprised if the PROD target server actually has it listed [explicitly] - but it is possible that some setup like this was not performed on the DEV target server. Time will tell...

Adam Stoller

I'm closing this thread now as my problem has been resolved.

In this particular case it turns out that the server name I was using in the UNC path was an "alias" and not the actual server's name.

When we switched to using the actual server's name - the original code worked just fine.

Why it worked with the alias for the PROD server and not the alias for the DEV server is a mystery - but not one that I'm particularly concerned about.

Thanks for the thoughts / suggestions anyway