We wish to solve the business problem of how to schedule automated password updates, on a remote FTP server (note: z/OS) over which we have no administrative control, before the password expires. For example, once each month, update user JDoe's password, both locally and on remote FTP server ftp.abc.com.

Our business process necessitates transferring files, using protocol FTPS, to/from a remote FTP server (note: z/OS). A separate organization administers this remote FTP server, providing our team with a user account but no server-level administrative control. FTP server policy automatically expires user account passwords, after a period of time. When this happens, FTP server staff require the person tied to the named account to call their FTP server help desk, to verify their identity. Upon successful verification, FTP server help desk staff reset the password, requiring the user to choose a new password upon the next login. The FTP server allows users to reset their password via the command-line, by setting password to string "oldpw/newpw/newpw"; subsequently, users login with only "newpw".

FTP server administrators will not set an FTP user password to never expire.

Years ago, a now-retired team member created an in-house app to perform this task, using FTPS functionality provided by ComponentPro "FTP/SSL Client Component for .NET". Per resource constraints, we'd prefer a solution we don't have to maintain in-house. Note: if possible; if in-house represents the way to go, so be it.

How can we do this better?



Each FTP server implementation decides if/how to invoke access controls, per File Transfer Protocol (FTP) technical specification RFC 959:

   access controls
      Access controls define users' access privileges to the use of a
      system, and to the files in that system.  Access controls are
      necessary to prevent unauthorized or accidental use of files.
      It is the prerogative of a server-FTP process to invoke access

Since password policy represents a form of access control, and RFC 959 specifies no password reset mechanism, it seems reasonable to conclude each FTP server implementation decides if/how to support FTP client-initiated password resets.

In practice, this represents what we see:

Some servers, such as Titan FTP server, support SITE PSWD command:

SITE PSWD "<old_password>" "<new_password>"

Other servers, such as WS_FTP Server, support CPWD command:

CPWD <new_password> Yet another

variant is:

SITE CPWD <new_password>


IBM z/OS FTP server extends File Transfer Protocol (FTP) command "PASS", to grant FTP users the ability to initiate the password change, via the FTP client.

Specifically, enter "oldpass/newpass/newpass", in FTP client field "password" (substitute the actual old and new passwords, for "oldpass" and "newpass", respectively, preserving the forward-slash delimiters). Upon successful login, this triggers the FTP server to subsequently change the FTP user password, on the remote server. Subsequent logins require the FTP user to provide only the new password. Additional constraints exist; please refer to the IBM FTP command "PASS" documentation for full details.


Automation depends on both the FTP server password reset mechanism and an FTP client which lends itself to automation.

We currently use Ipswitch WS_FTP Professional Client v12:

ONERROR GOTO end1 ;(Goes to the end1 label and ends the script) 
TRACE SCREEN ;(sends a trace of the script to the screen - you can modify this line to point to a trace files so that any errors can be viewed after the script is run) 
LOG SCREEN ;(sends the log file to the screen you can modify this line to point to a trace files so that any errors can be viewed after the script is run)
USER test ;(username command) 
PASS oldpw/newpw/newpw ;(password command) 
CONNECT 21 ;(connects to the remote site) 
CLOSE ;(closes the connection) 
LABEL end1

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.