|
|
![]() |
|
|
|
|
||
|
When Good Batch FTP Users Go Bad Hey, Joe: I set up a Windows batch FTP script to automatically transfer files from my iSeries box to a Windows desktop. I set up this transfer to occur every Friday evening. This week, the batch transfer stopped working because the remote OS/400 FTP server rejected the FTP user profile and password in the script. The strange thing is that the OS/400 FTP user profile is still enabled on the server. Any ideas what's happening here? -- Al To get an idea of what's going on, let's examine the following sample Windows batch FTP script from a recent article on batch FTP, "FTP Basics: Batch Processing," by Shannon O'Donnell, and I will use that example to explain what's happening. open YourIPAddress AS400UserID AS400Password get /QSYS.LIB/QGPL.LIB/QRPGLESRC.FILE/PROOF.MBR C:\Proof.txt quit
Like many client/server programs, this script opens an FTP session, passes in a valid OS/400 user profile and password, and then transfers the file to a Windows directory. More than likely, your problem is that your AS/400 FTP user password was automatically expired because it passed the expiration time interval set up in the Password expiration interval system value (QPWDEXPITV). When the batch FTP runs and attempts to sign on with this user, OS/400 won't allow it because it considers the password expired and the FTP session fails. Many shops set QPWDEXPITV to a fairly low time value--such as 30 days--which complicates matters in this case, because the password is used weekly for unattended processing, and it's fairly awkward to change your script every month. One answer is to override the QPWDEXPITV value for this user by changing the user profile's individual password expiration interval to never expire. You do this by using the Change User Profile (CHGUSRPRF) command to set the Password Expiration Interval (PWDEXPITV) parameter to *NOMAX, as shown here: CHGUSRPRF USRPRF(ftp_user_name) PWDEXPITV(*NOMAX) Setting PWDEXPITV to *NOMAX tells OS/400 to ignore QPWDEXPITV processing for this particular user and let the password stay active even if it should be expired according to the system. And once you make this change, I suspect your batch FTP transfer will start working again. The unfortunate thing about this solution, and most client/server solutions, is that you're forced to leave an active OS/400 user profile and password sitting around in a script on another server, where it may be discovered by hackers. There's no getting around the necessity for embedding passwords in these types of programs. However, you can set the following OS/400 user profile parameters for your FTP user to minimize damage if someone discovers the password and tries to sign on as that user.
Similar to setting the PWDEXPITV parameter to *NOMAX, prompt the CHGUSRPRF command to change these values for your user. In addition, be sure the FTP user has no authority to any OS/400 or IFS object other than what is needed for its batch FTP transfer. This will protect your other OS/400 objects. Client/server situations are problematic because of potential password exposure issues. However, if you lock down your FTP user profiles, you can limit the potential for abuse and make the situation somewhat (but not perfectly) safe. I hope this helps. -- Joe
|
Editors
Contact the Editors |
|
Last Updated: 10/02/02 Copyright © 1996-2008 Guild Companies, Inc. All Rights Reserved. |