Secure File Transfer The Secure File Transfer service offering may be used to securely exchange files over the Internet with external non-IBM users such as customers, suppliers, and business partners. The Secure File Transfer service may also be used to exchange files only between IBM users within the IBM Intranet. Secure File Transfer is a replacement offering for the legacy Private FTP service. The Secure File Transfer service acts as a file "dropbox." Users of the service may "upload" files to Secure File Transfer for subsequent "download" by other users. Two instances of the Secure File Transfer service are available: one in Boulder, Colorado, and the other in Dublin (Mulhuddart), Ireland. Clients may choose to use the Boulder instance, the Dublin instance, or both as appropriate for their business needs. Each site has its own separate instance of the service; there is no data sharing or common external user authentication between the service instances. Note: The Secure File Transfer service will not be recovered at a disaster recovery site in the event of extended unavailability of the service. If your business needs cannot tolerate extended unavailability of the Secure File Transfer service, you will need to utilize the service at both sites as appropriate for your application. For example, for an outgoing Internet transfer application, you may wish to have your directory and external user access ID provisioned at both sites, uploading your outbound data to both the Boulder and Dublin site instances. Your external users would then have the ability to download from either the Boulder site or the Dublin site. Secure File Transfer must not be used for the following without prior review and approval by the service business owner: files that contain Personal Information (Secure File Transfer may never be used for Sensitive Personal Information) files that are subject to government export regulations Usage of this service must be consistent with IBM Business Conduct Guidelines. Managers of the users of this service must ensure that use of this service is not in conflict with any other duties their employees may have. The following topics are discussed in more detail below. Overview Directory owner and end-user responsibilities Sites and hostnames Secure file transfer protocols Getting started Using Secure File Transfer with FTP or FTPS Using Secure File Transfer via web browser Using Secure File Transfer with SFTP Using Secure File Transfer with SCP IBM Confidential information Managing passwords for external users FTP subcommands Reports and transfer logs Frequently Asked Questions (FAQ) Contacts Related links Overview There are two ways to use the Secure File Transfer service. Secure File Transfer may be used to exchange files with external, non-IBM users over the Internet. External users must use a secure network protocol to transfer files (i.e. HTTP over SSL, FTP over TLS, or the SSH-based SFTP or SCP applications). Secure File Transfer may be used to transfer files between IBM users within the IBM Intranet only. Internet secure file exchange The Secure File Transfer service may be used for secure file exchange over the Internet. The Secure File Transfer environment resides across two servers. One server resides in the DMZ (yellow zone) making it accessible from the Internet by external users. The other server resides within the IBM Intranet (blue zone) for access by IBM users. Internet file transfer requests are securely proxied from the DMZ server, through a firewall, to the data server within the IBM Intranet. Secure File Transfer files are never stored outside the firewall; files are only stored inside the firewall on the IBM Intranet server. External users must access the Secure File Transfer service from the Internet using a secure file transfer protocol. Secure File Transfer supports the following secure protocols: Secure HTTP over SSL/TLS (HTTPS) using a web browser Secure FTP over TLS (FTPS) using FTP client software that supports the FTPS protocol Secure Shell (SSH) based file transfer using the SFTP or SCP applications. External users are provided with an ID and password to access the service. These IDs are requested, owned, and managed by an IBM owner. External users are "jailed" into their assigned directory and may only access files and subdirectories contained within that directory. External users may be provided with either read-write access (download and upload) or read-only access (download only) to their assigned directory. IBM internal users access Secure File Transfer from the IBM Intranet using their IBM Intranet Password (IIP) IDs and password. IBM users may use a web browser or FTP client software to access the service. The use of secure TLS FTP client software may also be used by IBM users on the IBM Intranet, but is not required. IBM BlueGroups membership is used to control IBM user access to Secure File Transfer directories. IBM users may only access files in directories that they are authorized to access. Both a read-write (download and upload) access control group and a read-only (download only) access control group may be assigned to a directory. IBM Intranet-only internal file exchange The Secure File Transfer Service may also be used for IBM Intranet-only file exchange. Files stored in IBM Intranet-only areas are not accessible from the Internet. Internal IBM users use their IBM Intranet Password (IIP) IDs and passwords to access the service. IBM BlueGroups membership is used to control access to Secure File Transfer directories. IBM users may only access files in directories that they are authorized to access. Both a read-write (download and upload) access control group and a read-only (download only) access control group may be assigned to a directory. IBM users may use file transfer client software or a web browser to access the service. IBM users may optionally use secure file transfer protocols such as FTP over TLS, but these are not required to be used within the IBM Intranet. Directory owner and user responsibilities Secure File Transfer directory owners and end users have the following responsibilities. Directory owner responsibilities Directory owners are responsible for the appropriate classification and the associated protection and labeling of their data. See Classification and control of IBM information (Corporate Instruction LEG 116) and all other applicable corporate directives. Owners of directories that contain IBM Confidential information are required to revalidate the business need for access to their directories on at least an annual basis, and to retain evidence that the revalidation has been conducted. Directory owners are responsible to ensure that the users of their directories understand their responsibilities for use of the service. End-user responsibilities IBM users must never store or transmit files that are subject to government export regulations using Secure File Transfer without review and approval by the service business owner. See the IBM Export Regulations Office site for more information. IBM users must never store or transmit files over the Internet that contain Business Personal Information or Personally Identifiable Information without review and approval by the service business owner. The service may never be used for Sensitive Personal Information under any circumstances. See Internet privacy - personal information collected on-line (Corporate Instruction LEG 117) for further information. IBM users are responsible to ensure that files obtained from the Internet are virus free and that infected files are handled appropriately. See IT Security Standards (ITSS - Chapters 2 and 3) for more information. IBM users using Secure File Transfer for IBM Confidential information must store that information only in directories designated for IBM Confidential data. Specifically, /w3/ibmconf directories must be used for exchange within the IBM Intranet-only. /www/ibmconf directories must be used for for IBM Confidential information exchange over the Internet. IBM owners of external, non-IBM IDs must manage those IDs and passwords on behalf of their external users. IBM users must comply with all applicable provisions of IT Security Standards (ITSS - Chapters 2 and 3). IBM users must use Secure File Transfer for management approved purposes only. Managers of IBM users must ensure that use of this service is not in conflict with any other duties they may have. The Secure File Transfer service supports asynchronous file exchange activities. It is not intended for real time exchange of data. The service can support periodic checking by users for the existence of new files, but appropriate use of such polling activity is essential to permit effective sharing of the service resources. Users that need to poll the service for new content should do so no more frequently than once every 10 minutes. Abusive use of the service may result in revocation of access. Sites and hostnames The Secure File Transfer service is available at two sites: one in Boulder, Colorado, and the other in Dublin (Mulhuddart), Ireland. The recommended hostnames for these instances are as follows: Site User Recommended Hostname Boulder Internal IBM user w3-transfer.boulder.ibm.com External non-IBM user transfer.boulder.ibm.com Dublin Internal IBM user w3-transfer.mul.ie.ibm.com External non-IBM user transfer.mul.ie.ibm.com Note that the Boulder instance of the Secure File Transfer service shares infrastructure with the Testcase Data Exchange service. Hostnames associated with the Testcase Data Exchange service (e.g., testcase.boulder.ibm.com) are therefore also usable but are not recommended for the Secure File Transfer service. Secure file transfer protocols External non-IBM users must use secure file transfer protocols to access the Secure File Transfer service from the Internet. Non-secure FTP cannot be used over the Internet since it transmits authentication information in cleartext. Secure FTP over TLS (FTPS) FTPS is also known as "FTP using TLS". This is an extension to the FTP protocol to support secure file transfer using Transport Layer Security (TLS) technology. The Internet Engineering Task Force (IETF) RFC 4217 Securing FTP with TLS standard was originally proposed in 1996. The FTPS standard has been driven by IBM Corporation through the IETF standards process. Many software vendors (including IBM) and Open Source Software projects support the FTPS protocol. It is important to note that some external users may experience difficulties using the FTPS protocol through their network infrastructures. External users connect to IBM through a variety of firewalls, routers, and ISPs that may perform Network Address Translation (NAT) and stateful inspection of FTP traffic flows. External users may experience problems connecting to or using the server due to the way some network equipment handles FTPS flows. These issues are described in the draft IETF RFC entitled FTP/TLS Friendly Firewalls. If necessary, external users should contact their local network support and network providers to determine how to best support FTPS within their environments. An FTP software client that supports the TLS protocol must be used. Numerous FTPS software clients are available. IBM provides FTPS support on several platforms, such as z/OS 1.2.0 and later, OS/400 V5R2 and later, and WebSphere Host On-Demand. Many popular third-party FTP software vendors provide FTPS support as well. An Internet search engine may be used to search on "FTP+client+TLS" to identify third party or Open Source Software alternatives. The server supports the use of "explicit" mode FTPS on control port 21. Use of "implicit" mode FTPS over port 990 is not supported; implicit FTPS has been deprecated from the FTPS standard. The FTP server is configured to support FTP over TLS using either "active" or "passive" FTP modes. Since active mode FTP may be disabled by network routers or firewalls by default, customers may have better success using passive FTP mode. The server uses ports 65024 through 65535 for passive FTP data connections. Encryption of both the FTP control and data channels is required, however, the FTP server also supports the use of the Clear Command Channel (CCC) FTP command. Use of the CCC command causes the FTP control connection to be sent in clear text after secure authentication has occurred. Note: due to firewall restrictions, "active" mode FTPS connections to the server require use of the CCC command. See IETF RFC 2228 FTP Security Extensions for further information on the CCC command. The server also supports the use of the EPSV ALL FTP command as defined in IETF RFC 2428 FTP Extensions for IPv6 and NATs. If supported by the FTP client, this may provide some benefit to customers using Network Address Translation (NAT) devices that also have support for it. The FTP server supports use of TLS version 1.2. The server accepts the AUTH TLS commands from the FTP client. Note: the use of FTP over SSL has been deprecated since 5/1/2015 to remediate the POODLE (Padding Oracle On Downgraded Legacy Encryption) vulnerability The server's SSL certificate is signed by the DigiCert Global Root CA. If this CA is not in the list of trusted CAs for your secure FTP client, the root certificate may be obtained directly from https://www.digicert.com/kb/digicert-root-certificates.htm. Some client software will validate that the hostname of the server being accessed is the same as the name specified in the server certificate. Only the preferred hostnames, and not all legacy hostname aliases, are provided in the server certificate. The SecureTransport software from Axway Corporation (formerly Tumbleweed Corporation) is used to provide this service. Axway also provides SecureClient software specifically for use with their server. External users who may be unable to get FTPS to function in their environments may consider the use of this software which supports the use of the HTTPS protocol. Although there are no current plans in this regard, IBM reserves the right to replace the server software at some future date, at which time this vendor-proprietary client software would become inoperable. Secure HTTP over SSL/TLS (HTTPS) HTTP over SSL/TLS (HTTPS) is the secure version of the HTTP protocol used on the World Wide Web. HTTPS uses the Secure Sockets Layer (SSL) or Transport Layer Security (TLS) protocols to encrypt the session data. The Secure File Transfer server supports file upload and downloads from a web browser using HTTPS. Secure Shell (SSH) based file transfer (SFTP/SCP) The Secure Shell or SSH network protocol supports secure communication between two systems. Two file transfer applications are available for use with SSH. SFTP allows for file transfer operations similar to that provided by native FTP software. SCP allows for file copy operations. Getting started Process Summary: 1. Create IBM BlueGroups - This is used to control internal IBM access to your directory. 2. Create a billing account SDF Registration site 3. Create a new Secure File Transfer directory request - This will be the accounts directory on the Secure File Transfer Server. 4. Create a new Non-IBM Secure File Transfer ID request - Non-IBM external clients will need to be provided with an ID. 5. AccessHub - This tool is used to manage external ID's. Create Billing Account and Obtaining a new directory Create a billing account at the SDF Registration site Before you can use the Secure File Transfer service, If you don't already have one, you will first need to create a billing account at the SDF Registration site. This account will be used for ongoing file transfer charges. You will need a valid division code to complete this account creation process. There are no setup charges. Cost is based purely on data transfer. Further information is available on the Internet Services Pricing page. Once you have a billing account, you may submit a New Secure File Transfer directory request. the preferred name for the new directory. Please request directories whose name is descriptive of the activity/project. the site for the directory (Boulder, Dublin, or both). No automatic replication of data occurs between the two FTP sites. Request the directory on both FTP sites only if needed. whether this is an Internet (www) or IBM Intranet-only directory (w3). the name of the existing IBM BlueGroups group that will be used to grant read and write (download and upload) access to the directory. Only IBM users that are members of this group will have access to your directory. You can add IBM members to this group at this time or later. The BG group just needs to exist before your new directory can be created. optionally, the name of an existing IBM BlueGroups group that will only allow read-only (download only) accesses to the directory. New directory requests are forwarded to the Secure File Transfer administrator for fulfillment. You may begin using your new directory immediately once you receive notification that it has been created. Obtaining new external IDs for non-IBM users IBM users use their IBM Intranet Password ID and password to access Secure File Transfer, however, external non-IBM users must be provided with their own Secure File Transfer IDs. External user's IDs are requested by the directory owner at the SDF Registration site by submitting a new Non-IBM Secure File Transfer ID request. The following will need to be provided: the site of the directory (Boulder, Dublin, or both) the name of the directory that will be the home directory for the external user. The external user will be "jailed" into this directory and will only be able to access the files and sub-directories within this directory. In some circumstances, you may want external users to share the same home directory; in other cases, you may want external users to have different home directories and be isolated from each other the preferred name for the new external ID. Take care not to request non-IBM IDs with common/reserved names. whether the external user should have read-write access (download and upload) or read-only access (download only) to the specified directory New external ID requests are forwarded to the Secure File Transfer administrator for provisioning. You will receive e-mail notification from the service administrator when the ID has been created and is ready for use. You may then provide the ID and password to the external user. These external ID's are managed by the internal IBM directory owner using AccessHub Using Secure File Transfer with FTP or FTPS Use by internal IBM users To access the Secure File Transfer service, IBM users initiate an FTP session to the w3-transfer.boulder.ibm.com or w3-transfer.mul.ie.ibm.com servers and login using their IBM Intranet Password ID and password. Once logged in, IBM users should change their working directory to one of the following top directories: Top Directory Environment IBM Confidential Permitted? Comment /www/prot Internet No /w3/prot IBM Intranet-only No /www/ibmconf Internet Yes Use /toibm and /fromibm subdirectories for incoming and outgoing data exchange, respectively /w3/ibmconf IBM Intranet-only Yes Secure File Transfer service directories are located within subdirectories of these directories. Access to the subdirectories is controlled via membership in an IBM BlueGroups group. IBM users will only be able to access directories where they've been granted access by the directory's group owner. Here is an example using a line mode FTP client to perform an upload using an IBM Intranet Password ID from the IBM Intranet. Command/Response Description C:\> ftp w3-transfer.boulder.ibm.com The IBM user enters the ftp command to invoke the FTP client and begin an FTP session with the server. Connected to testcase-blue.boulder.ibm.com 220 testcase-blue secure FTP server ready. The IBM user receives verification that the session has been established and that the FTP server is ready. User (testcase-blue.boulder.ibm.com:(none)): yourid@us.ibm.com The IBM user is prompted for their user name. They should enter their IBM Intranet Password ID. 331 Password required for yourid@us.ibm.com. The FTP server responds a password is required to login. Password: yourpw At the password prompt, the IBM user should enter the current password for their IBM Intranet Password ID. 230 Virtual user yourid@us.ibm.com logged in. The FTP server responds that the login was successful. ftp> cd www/prot/mydir The IBM user should then change to their Secure File Transfer directory 250 CWD command successful The FTP server responds that the change (working) directory command was successful. ftp> binary 200 Type set to I. ftp> put 2cust.txt The IBM user may upload a file by using the put FTP subcommand. In this example, a file called 2cust.txt is uploaded. Depending on the requirements, the file may be uploaded in binary format by first specifying the binary subcommand. 200 PORT command successful. 150 Opening binary mode connection for 2cust.txt 226 Transfer complete. The FTP server responds that the connection has started and also responds when the upload is complete. File transfer times will vary depending on network speed and file size. ftp> quit The IBM user may then terminate the FTP session using the quit subcommand. Use by external non-IBM users External non-IBM users must initiate an FTP over TLS session to the transfer.boulder.ibm.com or transfer.mul.ie.ibm.com servers. Note that a secure FTP session must be used. Non-secure FTP cannot be used to access Secure File Transfer from the Internet. External users will use the ID and password obtained and provided to them by the IBM directory owner. External users are only able to access their assigned Secure File Transfer directory. External users cannot access files outside of their directory. Here is an example using a line mode secure FTP client to perform a download using an external ID from the Internet. An FTPS client is required. Command/Response Description C:\> ftptls transfer.boulder.ibm.com The external user invokes an TLS capable FTP client to begin a secure FTP session with the server. Connected to testcase-yellow.boulder.ibm.com 220 testcase-yellow secure FTP server ready. 234 TLSv1 235 PBSZ=0 200 PROT command successful The external user receives verification that the session has been established and that the FTP server is ready and that a TLS session is being established. User (testcase-yellow.boulder.ibm.com:(none)): custid The external user is then prompted for your user name. They should enter the ID provided them by the directory owner. 331 Password required for custid. The FTP server responds a password is required to login. Password: custpw At the password prompt, the external user should enter the password provided them by the directory owner. 230 Virtual user custid logged in. The FTP server responds that the login was successful. ftp> binary 200 Type set to I. ftp> get 2cust.txt The external user may download a file by using the put FTP subcommand. In this example, you are uploading a file called 2cust.txt. Depending on your requirements, the user may want to download the file in binary format by first specifying the binary subcommand. 200 PORT command successful. 150 Opening binary mode connection for 2cust.txt 226 Transfer complete. The FTP server responds that the connection has started and also responds when the download is complete. File transfer times will vary depending on network speed and file size. ftp> quit You may then terminate the FTP session using the quit subcommand Using Secure File Transfer via web browser Both IBM users and customers may use a web browser to perform file transfers using the secure HTTP over SSL/TLS protocol (HTTPS) per the following table: User Site URL Authentication Internal IBM user Boulder https://w3-transfer.boulder.ibm.com/ IBM Intranet Password (IIP) ID and password Dublin https://w3-transfer.mul.ie.ibm.com/ External non-IBM user Boulder https://transfer.boulder.ibm.com/ ID and password provided by directory owner Dublin https://transfer.mul.ie.ibm.com/ Once logged in, you may use your web browser to navigate through the directory structure and download, upload or delete files per your defined access permissions. Both FTPS and HTTP provide access to the same files and directories. Note that it is not possible to rename files or create subdirectories via the HTTP web interface. Note: Some web browsers have limitations on the sizes of files that may be transmitted. Using Secure File Transfer with SFTP (SSH-based FTP) Use by internal IBM users Similar to Using Secure File Transfer with FTP, IBM users initiate an SFTP session to the w3-transfer.boulder.ibm.com or w3-transfer.mul.ie.ibm.com servers. Note: not all host names and aliases that may be associated with the Secure File Transfer service support use of SFTP; this w3-transfer.* names should be used for SFTP. IBM users login using their IBM Intranet Password ID and password. Here is an example using a line mode SFTP client to perform an upload using an IBM Intranet Password ID from the IBM Intranet. Command/Response Description C:\> sftp yourid@us.ibm.com@w3-transfer.boulder.ibm.com The IBM user enters the sftp command to invoke the SFTP client and begin an SSH-based FTP session with the server. Connecting to w3-transfer.boulder.ibm.com... Password authentication The SFTP client software connects to the SFTP server. The server responds that password authentication is required. Password: yourpw At the password prompt, the IBM user should enter the current password for their IBM Intranet Password ID. sftp> cd www/prot/mydir The IBM user should then change to their Secure File Transfer directory sftp> put 2cust.txt The IBM user may upload a file by using the put SFTP subcommand. In this example, a file called 2cust.txt is uploaded. Uploading 2cust.txt to /www/prot/mydir/2cust.txt The SFTP server responds that the file transfer has started. File transfer times will vary depending on network speed and file size. sftp> quit The IBM user may then terminate the SFTP session using the quit subcommand. Use by external non-IBM users Similar to Using Secure File Transfer with FTP, external users initiate an SFTP session to the transfer.boulder.ibm.com or transfer.mul.ie.ibm.com servers. External users will use the ID and password obtained and provided to them by the IBM directory owner. Here is an example using a line mode SFTP client to perform a download using an external ID from the Internet. Command/Response Description C:\> sftp custid@transfer.boulder.ibm.com The external user enters the sftp command to invoke the SFTP client and begin an SSH-based FTP session with the server. The external user should specify the ID provided by the directory owner. Connecting to transfer.boulder.ibm.com... Password authentication The SFTP client software connects to the SFTP server. The server responds that password authentication is required. Password: custpw At the password prompt, the external user should enter the password provided them by the directory owner. sftp> get 2cust.txt The external user may download a file by using the get SFTP subcommand. In this example, a file called 2cust.txt is downloaded. Fetching 2cust.txt to 2cust.txt The SFTP server responds that the file transfer has started. File transfer times will vary depending on network speed and file size. sftp> quit The external user may then terminate the SFTP session using the quit subcommand. Using Secure File Transfer with SCP (SSH-based file copy) Use by internal IBM users Similar to Using Secure File Transfer with FTP, IBM users perform an SCP to the w3-transfer.boulder.ibm.com or w3-transfer.mul.ie.ibm.com servers. Note: not all host names and aliases that may be associated with the Secure File Transfer service support use of SCP; these w3-transfer.* names should be used for SCP. IBM users authenticate using their IBM Intranet Password ID and password. Here is an example using a line mode SCP client to perform an upload using an IBM Intranet Password ID from the IBM Intranet. > scp 2cust.txt yourid@us.ibm.com@w3-transfer.boulder.ibm.com:www/prot/mydir Password Authentication: Password: yourpw 2cust.txt > The 2cust.txt file is uploaded to the www/prot/mydir directory on the w3-transfer.boulder.ibm.com server. Use by external non-IBM users Similar to Using Secure File Transfer with FTP, external users perform an SCP to the transfer.boulder.ibm.com or transfer.mul.ie.ibm.com servers. External users will use the ID and password obtained and provided to them by the IBM directory owner. Here is an example using a line mode SCP client to perform a download using an external ID from the Internet. > scp custid@transfer.boulder.ibm.com:2cust.txt 2cust.txt Password Authentication: Password: custpw 2cust.txt > The 2cust.txt file is downloaded from the external user's directory on the transfer.boulder.ibm.com server. IBM Confidential information Secure File Transfer may be used for exchange of IBM Confidential information. At the time a new directory is requested, the requester must specify whether or not it will be used for IBM Confidential information. IBM Confidential information may only be stored in directories designated for that purpose (/w3/ibmconf and /www/ibmconf). Secure File Transfer directory owners are responsible for the appropriate classification and the associated protection and labeling of their data. See Classification and control of IBM information (Corporate Instruction LEG 116) and all other applicable corporate directives. Owners of directories that contain IBM Confidential information are required to perform annual revalidation of the users that have access to their directory. Managing passwords for non-IBM users ID passwords for external users must adhere to IBM password security policies as defined in IT Security Standard. This means that external user passwords will expire every 90 days. IDs with expired passwords cannot log in to Secure File Transfer. When a password is changed, IBM policy does not allow it to be changed again for 7 days. Additionally, external IDs with more than 5 failed login attempts will be locked and ID not to be reused until after at least 8 iterations. IBM owners must manage the external IDs and passwords associated with Secure File Transfer directories. External IDs are managed using the AccessHub. AccessHub is only available from the IBM Intranet. Changing or resetting an external ID password Perform the following to change or reset an external ID password. From the AccessHub Home Page, click the 'Change Password for Self' tile. (Do NOT use the Change Password link in the left menu, it is defective.) Click on cart icon (ADD ALL TO CART) to view all your accounts. Click on 'Checkout' button. You will not be able to change the password for any IDs with a non-expiring password. Select the account(s) for which you want to change password, click on 'Change Password' button at TOP of accounts list/table. To select all, click on the box beside 'Associated Accounts'. There will be two options to change password: Suggested Password or Type New Password. Choose anyone. i) For 'Suggested Password', click on 'Autogenerate Password' button to use machine generated password. ii) For 'Type New Password', enter password manually and follow the password rules provided on page, see below. Click 'Use Password'. Click on Next button. 'Your request has been submitted!' gets displayed on the request submission page. You will receive a confirmation email when the password change request completes successfully. The AccessHub password policy for AIX and Linux is: Minimum length 15 characters. Maximum length 20 characters. Must have 1 lower case character. Must have 1 number. Upper case characters are allowed but not required. Special characters are allowed but not required. Unlocking an external ID Perform the following to unlock an external ID that has been locked due to excessive failed login attempts. From the AccessHub Home Page, click the 'Change Password for Self' tile. Under ACTIONS column, click on cart icon (ADD TO CART) for all respective server/endpoint(s) on which your account(s) are locked and you want to unlock them (either testcase-blue.cpc.limited-use.ibm.com or dhempsts01.mul.ie.ibm.com as appropriate). Click on 'Checkout' button. Click on 'Unlock Account' button adjacent to the locked account(s) which you want to unlock. Click on Next button. 'Your request has been submitted!' gets displayed on the request submission page. After few minutes try to login to endpoint/server with unlocked account. Deleting an external ID Please note that AccessHub will not allow you to delete an ID. Users can only disable an ID and AccessHub will automatically delete the account after 92 days. Once an ID is deleted on the server, another account of the same name CANNOT be created on the server. Perform the following to delete an external ID that is no longer required. From the AccessHub Home Page, click "Manage My Existing Access" tile. Perform a search to locate the account to be Enabled or Disabled either based on ID name or based on server/endpoint. Select the account to be Enabled or Disabled by clicking Modify button next to it. For Enable Account flow, select Inactive Account For Disable Account flow, select Active Account Select Account Action as Enable to enable an Inactive account; or select Disable to disable an Active account. Click "Review & Submit" button. Verify the request details on the Request Review page, provide Business Justification and accept the obligation statement by clicking the checkbox. This will enable the Submit button. Click Submit to submit the request. Request Confirmation page displays request id and the "Request History" button can be used to navigate to Request History page. FTP subcommands Here are some common FTP subcommands: open Initiates a session between your FTP client and the FTP server cd Changes your current directory on the FTP server dir Lists all files and subdirectories in your current directory on the FTP server ls Lists retrievable files only in your current directory on the FTP server pwd Displays the name of the current directory on the FTP server get Retrieves a file (download) from the FTP server to your FTP client (local) put Stores a file (upload) from your FTP client (local) to the FTP server mget Performs multiple file downloads with a single command mput Performs multiple file uploads with a single command prompt Sets interactive prompting to either "on" for verification prior to each transfer or "off" to disable verification ascii Performs file transfers in ASCII mode binary Performs file transfers in binary mode delete Deletes a file on the FTP server mkdir Creates a directory on the FTP server rmdir Deletes a directory on the FTP server quit Terminates the FTP session To display all the available FTP subcommands, you may be able to enter help or ? from your FTP client. Reports and transfer logs ISC Software makes standard monthly file transfer reports available. Recent reports (e.g., the current and prior year) are available at http://submit.boulder.ibm.com/cgi-bin/logr/dirlist/dirlist.cgi?. Older reports (e.g., older than prior year) are available at http://dhempdel06.mul.ie.ibm.com/cgi-bin/logr/dirlist/dirlist.cgi?. Daily server transfer log data is similarly available at these sites. Reports and log files are available per the following table. Age Site Environment Host Name Report Files Log Files Recent Boulder IBM Intranet w3-transfer.boulder.ibm.com (testcase-blue.boulder.ibm.com) ftpstats/testcase-blue/all (to 06/2022) ftpstats/testcase-blue.cpc/all (starting 07/2022) stranlogs/testcase-blue (to 06/22/2022) stranlogs/testcase-blue.cpc (starting 03/04/2022) Internet transfer.boulder.ibm.com (testcase-yellow.boulder.ibm.com) ftpstats/testcase-yellow/all stranlogs/testcase-yellow (to 06/21/2022) stranlogs/testcase-yellow.cpc (starting 05/13/2022) Internet and IBM Intranet combined w3-transfer.boulder.ibm.com transfer.boulder.ibm.com (testcase.boulder.ibm.com) ftpstats/testcase/all use log files above Dublin IBM Intranet w3-transfer.mul.ie.ibm.com ftpstats/dhempsts01/all stranlogs/dhempsts01 (to 10/31/2023) stranlogs/dhempsts01.dub (starting 09/13/2023) Internet transfer.mul.ie.ibm.com ftpstats/dhempste01/all stranlogs/dhempste01 (to 10/31/2023) stranlogs/dhempste01.dub (starting 16/07/2023) Older Boulder IBM Intranet w3-transfer.boulder.ibm.com (testcase-blue.boulder.ibm.com) ftpstats/testcase-blue/all stranlogs/testcase-blue Internet transfer.boulder.ibm.com (testcase-yellow.boulder.ibm.com) ftpstats/testcase-yellow/all stranlogs/testcase-yellow Internet and IBM Intranet combined w3-transfer.boulder.ibm.com transfer.boulder.ibm.com (testcase.boulder.ibm.com) ftpstats/testcase/all use log files above Dublin IBM Intranet w3-transfer.mul.ie.ibm.com ftpstats/dhempsts01/all stranlogs/dhempsts01 Internet transfer.mul.ie.ibm.com ftpstats/dhempste01/all stranlogs/dhempste01 The log file format is a variation of the Washington University FTP Server xferlog format. The "direction" field may contain the following values: o download successful p download error q download aborted i upload successful j upload error k upload aborted Frequently Asked Questions (FAQ) Q1: What is FTPS? A1: FTP over TLS is commonly known as "FTPS". This is an extension to the FTP protocol to support secure file transfer using Transport Layer Security (TLS). These extensions provide for the encryption of the FTP session authentication and data transfer. The Securing FTP with TLS standard (RFC 4217) was originally proposed in 1996 and has gone through a number of revisions. This standard is being driven by IBM Corporation through the IETF standards process. Many software vendors and Open Source Software projects support the secure FTP over TLS protocol. Note: The use of FTP over SSL has been deprecated since 05/01/2015 to remediate the POODLE(Padding Oracle On Downgraded Legacy Encryption) vulnerability. Q2: What FTP software clients support SSL or TLS (FTPS)? A2: There are numerous FTP software clients available that support FTP over TLS. IBM provides TLS support for FTP on several platforms (e.g. z/OS 1.2.0 and later, OS/400 V5R2 and later, WebSphere Host On-Demand). Many popular third-party FTP software vendors provide this support. Use an Internet search engine to search for "FTP+client+TLS" to identify third party or open source alternatives. Note that the Microsoft Windows FTP client does not support FTPS. Additionally, web browsers such as Internet Explorer or Firefox also do not support FTPS. Q3: What version of TLS is supported? A3: TLS Version 1.2 is supported by the FTP server. The server supports the use of the AUTH TLS commands by the FTPS client. Q4: Why do external users need to use secure FTP over the Internet to access the Secure File Transfer service? A4: IBM IT Security Standard requires that passwords not be transmitted in clear text form over the Internet. Use of the non-secure FTP protocol does not comply with this standard. The Secure File Transfer service is only accessible from the Internet using the FTP over TLS protocol. FTP over /TLS is not required at this time on the IBM Intranet, however it may be used if desired. Q5: What do I need to use TLS FTP? A5: An FTP software client that supports TLS must be used for a secure FTP connection. Depending on your FTP client software, TLS generally needs to be enabled via a configuration option or command switch. As with non-secure FTP, port 21 should be used for the control connection. Q6: My external user is having issues with using FTPS through their corporate firewall. What can they do? A6: The Secure File Transfer service is configured to support FTP over TLS using either Active or Passive FTP modes. However, since Active mode FTP may be disabled by network routers or firewalls by default, customers may have better success using Passive FTP mode. The Secure File Transfer server uses ports 65024 through 65535 for Passive FTP data connections. Many Internet firewalls perform inspection of TCP/IP network packets on the FTP control connection. The firewall is not able to inspect the control connection when it is encrypted. Depending upon the specific firewall used and it's configuration, the firewall may disallow the session. See FTP/TLS Friendly Firewalls for more information. The Secure File Transfer service supports the Clear Command Channel (CCC) FTP command. Use of the CCC command causes the FTP control connection to be sent in clear text after secure authentication has occurred. Internet users with firewall issues may experience benefit when using an FTP software client that also supports CCC. See FTP Security Extensions (RFC 2228) for further information. Q7: When using TLS FTP, must I encrypt both the FTP control and data channels? A7: Yes. Although the FTP over TLS RFC allows for optional encryption of the data channel, encryption of both channels is required by the Secure File Transfer service for security reasons. Q8: What Certificate Authority has signed the secure FTP server SSL certificate? A8: The server's SSL certificate has been signed by the DigiCert Global Root CA root certificate. If this root certificate is not in the list of trusted CAs for your secure FTP client, you may obtain it from https://www.digicert.com/kb/digicert-root-certificates.htm. Q9: What cipher suites are supported by the secure FTP server? A9: It depends on which protocol is being used. The FTP server supports the following cipher suites when using FTPS and/or HTTPS: Hexcode Cipher Suite Name (OpenSSL) KeyExch. Encryption Bits Cipher Suite Name (IANA/RFC) xc030 ECDHE-RSA-AES256-GCM-SHA384 ECDH 521 AESGCM 256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 xc028 ECDHE-RSA-AES256-SHA384 ECDH 521 AES 256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 xc02f ECDHE-RSA-AES128-GCM-SHA256 ECDH 521 AESGCM 128 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 xc027 ECDHE-RSA-AES128-SHA256 ECDH 521 AES 128 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 x9f DHE-RSA-AES256-GCM-SHA384 DH 2048 AESGCM 256 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 x6b DHE-RSA-AES256-SHA256 DH 2048 AES 256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 x9e DHE-RSA-AES128-GCM-SHA256 DH 2048 AESGCM 128 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 x67 DHE-RSA-AES128-SHA256 DH 2048 AES 128 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 x3d AES256-SHA256 RSA AES 256 TLS_RSA_WITH_AES_256_CBC_SHA256 x9c AES128-GCM-SHA256 RSA AESGCM 128 TLS_RSA_WITH_AES_128_GCM_SHA256 x9d AES256-GCM-SHA384 RSA AESGCM 256 TLS_RSA_WITH_AES_256_GCM_SHA384 x3c AES128-SHA256 RSA AES 128 TLS_RSA_WITH_AES_128_CBC_SHA256 x2f AES128-SHA RSA AES 128 TLS_RSA_WITH_AES_128_CBC_SHA x35 AES256-SHA RSA AES 256 TLS_RSA_WITH_AES_256_CBC_SHA As for SFTP (or anything related to SSH such as SCP) previously Secure File Transfer supported the following cipher suites on its SSH implementation: AES256-CBC, AES192-CBC, AES128-CBC, 3DES-CBC, AES128-CTR, AES192-CTR and AES256-CTR. However, due to security concerns, the CBC family of encryption hashing algorithms has been deprecated recently and thus the only remaining supported cipher suites are AES128-CTR, AES192-CTR and AES256-CTR. External customers that reach testcase from the Internet using SFTP/SCP will be presented with the following RSA fingerprint: SHA256:hsPI1gW5845xXusI7b1qugRNsizTkez40iv+lKcUN84 Internal customers that reach testcase from the Intranet using SFTP/SCP will be presented with the following RSA fingerprint: SHA256:hsPI1gW5845xXusI7b1qugRNsizTkez40iv+lKcUN84 Q10: How can I use FTPS from Java? A10: The custom Java Secure FTP over TLS library (jFTPS) developed by former IBM employee Brent Davis is still available on the IBM Rational Asset Manager (iRAM)) on the IBM Intranet should you wish to use it. iRAM itself apparently has been deprecated in favor of the new PC/Mac@IBM portals so the link provided no longer points to a page but to a Box@IBM link where you can download the class files and, presumably, some documentation with it. That said, please note that this code is pretty much unmaintained at this point and offered 'as-is' as a courtesy and therefore we will not support it, officially or otherwise. However, third-party Java FTPS libraries are also available. You can, for example, use the FTPSClient class from the Apache Commons Net library which is recommended since it is open source, better supported and you can find broad documentation about it on the internet. Q11: Does Secure File Transfer support access via HTTP or HTTPS? A11: Non-secure HTTP requests will be automatically redirected to HTTPS prior to login (e.g., http://transfer.boulder.ibm.com will be redirected to https://transfer.boulder.ibm.com). Q12: What operations may I perform when using HTTP access from my web browser? A12: When using HTTP access from your web browser, you may download, upload or delete files according to your access permissions. It is not possible to create or delete subdirectories via the web interface. Q13: Does Secure File Transfer support Public-Key Authentication for the Secure Shell (SSH) based SFTP or SCP applications? A13: No. SSH Public-Key Authentication is not available for use with SFTP or SCP file transfers. Password authentication must be used. Q14: What is IIP? A14: IIP is an abbreviation for IBM Intranet Password. Your IBM intranet password is used by many IBM internal applications such as Sametime Connect or the protected pages on the You and IBM w3 site. Q15: How do I FTP login using my IBM Intranet Password (IIP) and password? A15: IBM users must access the Secure File Transfer service from within the IBM Intranet. After you FTP to the w3-transfer.boulder.ibm.com or w3-transfer.mul.ie.ibm.com servers, enter your IIP ID at the FTP username prompt. When prompted for your password, enter your IIP password. > ftp w3-transfer.boulder.ibm.com Connected to testcase-blue.boulder.ibm.com. 220 testcase-blue secure FTP server ready. Name (testcase-blue.boulder.ibm.com): jdoe@us.ibm.com 331 Password required for jdoe@us.ibm.com. Password: jdoe's-IIP-password 230 User jdoe@us.ibm.com logged in Q16: How do I change or reset the password for my IBM Intranet Password (IIP) ID? A16: You may change or reset the password for your IBM Intranet Password ID at http://w3.ibm.com/password. This site is used to create and maintain the single ID and password that you use for many IBM internal Web applications. Q17: Is it possible to obtain an IBM Intranet Password ID for an application which needs to use Secure File Transfer from an automated process? A17: You need to obtain a special type of IIP ID called a "functional ID" as follows: Obtain a Lotus Notes ID. In the US, access the IBM US ID request database and create a new request selecting a generic or function ID. Consider specifying someone who will have access authority to the notes mail file for this ID (in case any is received). Have your manager (or have your manager allow you as a delegate) create DRMS record at https://w3.ibm.com/tools/drms/ using the information received from the Lotus Notes ID creation. Have your manager update the Corporate Directory, via the BluePages GUI, and update your employee's Node with the above Host node name, and the Userid with the above Notes Short Name. Change the assigned serial number of the Lotus Notes ID from your serial number to the one generated by the DRMS request. In the US, this can be accomplished by using the IBM US ID request database. Request an Internet password for your functional ID. It will be sent to the Lotus Notes mail for the functional ID. More detailed information on the functional IIP ID request process is available in KnowledgeWeb at https://knowledgecommunity.raleigh.ibm.com/KnowledgeWeb/protect/command.wss/doUTSubmissionDisplay?icID=948&ukc_system=WKC (you may need to register for KnowledgeWeb access to view this page). Q18: I use FTP from z/VM. When I try to FTP to Secure File Transfer with my IBM Intranet Password ID, I am unable to authenticate. Why? A18: By default, the z/VM Control Program recognizes the '@' symbol as the "character delete" character. Your IIP ID contains the '@' character. You should modify your session using the command CP TERM CHARDEL OFF which will disable '@' as the character delete character. Q19: I am using Internet Explorer to access Secure File Transfer specifying a URL like ftp://myiip@us.ibm.com@w3-transfer.boulder.ibm.com but it doesn't work. What can I do? A19: Internet Explorer is unable to parse the URL as it contains two '@' symbols (due to the '@' symbol present in your IBM Intranet Password ID). A suggested technique is to first access Secure File Transfer using the anonymous FTP URL of ftp://w3-transfer.boulder.ibm.com. When Internet Explorer displays the directory page, either (1) right click and select 'Logon as...' or (2) select File -> 'Login as...'. When the "Log On As" dialog box is displayed, enter your IIP username and password. Other web browsers, such as Firefox, Mozilla and Opera, seem to handle IBM Intranet Password IDs correctly when specified in FTP URLs. Q20: How is IBM BlueGroups being used by Secure File Transfer? A20: Each Secure File Transfer directory has an IBM BlueGroups group assigned that will control access to that directory and all subdirectories. You must be a member of that IBM BlueGroups group, or a member of a subgroup of that group, to access a directory and its contents. Each IBM BlueGroups group has an owner. An IBM BlueGroups group may also have one or more administrators assigned. IBM BlueGroups group owners and administrators are responsible for adding and removing users for their groups. If you find you can't access a Secure File Transfer directory, you must contact the directory's group owner or administrators to have yourself authorized for access. Secure File Transfer allows directories to be protected by groups that allow read-write access (download and upload) or read-only access (download only). Q21: Who manages the access to Secure File Transfer directories? A21: Only an IBM BlueGroups group owner or designated administrator may add members a group that control IBM user access to Secure File Transfer directories. The Secure File Transfer administrator cannot grant or revoke access. Q22: How do I assume ownership of an IBM BlueGroups group from a previous owner who is no longer employed by IBM? A22: The new owner's manager, as listed in IBM BluePages, should send e-mail to Enterprise Directory/Southbury/IBM listing the name of the IBM BlueGroups group to transfer along with their approval for the ownership change. Q23: Are there any characters that cannot be used in file and directory names? A23: File and directory names must consist of uppercase letters (A-Z), lowercase letters (a-z), numbers (0-9), hyphen ( - ), underscore (_), period (.), comma (,) the dollar sign ($) and the 'at' sign (@). File and directory names cannot contain any other characters. Additional file and directory names cannot begin with a hyphen ( - ), period (.) or comma (,). Attempting to upload a file or create a directory containing invalid characters will result in a 553: Permission Denied error. Q24: Are files and directories case-sensitive? A24: Yes. Files and directories are stored in a Unix (AIX) filesystem and are therefore case-sensitive. Make sure that you specify the correct uppercase and lowercase characters when uploading and downloading files or working with directories. Q25: Is there any limit on the size of an uploaded file? A25: There are no hard limits on individual file sizes, however uploaded files are subject to the available free space in the Secure File Transfer file systems. Please coordinate with the Secure File Transfer administrator if you have a requirement for large file transfers. Q26: I'm an IBM user and have used my IBM Intranet Password ID and password to login to Secure File Transfer, but am receiving a 553: Permission Denied error when attempting to access a directory or upload a file. What might be causing this? A26: Permission denied errors for IBM users are likely the result of: attempting to upload a file into a directory that you are not authorized to access or have insufficient access (i.e. read-only). In this case, you should contact the directory's IBM BlueGroups group owner and request access. attempting to upload a file that has invalid characters (special characters, spaces, etc.) in the file name. Q27: My external user is receiving a 553: Permission Denied errors when attempting to access a directory or upload a file. What might be causing this? A27: Permission denied errors for external users are likely the result of: attempting to upload a file into a read-only directory. attempting to upload a file that has invalid characters (special characters, spaces, etc.) in the file name. Q28: How can I upload or download multiple files at once? A28: Multiple files may be uploaded using the mput FTP subcommand. Multiple files may be downloaded using the mget FTP subcommand. You may use the prompt subcommand to disable or enable verification prompting prior to each transfer. Q29: May I use a Graphical User Interface (GUI) FTP client? A29: Yes. Any compliant FTP client should function with the FTP server, however support is generally not provided for FTP client configuration problems. Q30: I am working from home and am connected to the IBM internal network via AT&T Net Client. When I try to access testcase.boulder.ibm.com, it doesn't allow me to login. Why? A30: You are likely experiencing a known issue with Domain Name Service (DNS) hostname resolution with AT&T Net Client and Microsoft Windows. It is recommended that you not use the testcase.boulder.ibm.com hostname to access the Secure File Transfer service. Use the w3-transfer.boulder.ibm.com hostname instead. Q31: Does the FTP server support resumable file uploads? A31: FTP clients that support resumable transfers by using either the APPE FTP subcommand or a combination of the REST and STOR FTP subcommands are supported. Q32: How can I validate that a file was uploaded or downloaded correctly? A32: The Secure File Transfer server supports the XCRC subcommand. The XCRC subcommand is used by some intelligent FTP clients to perform file integrity checking. The XCRC subcommand returns a CRC32 checksum value for the target file. The FTP client may use the XCRC command to request the server's XCRC value for a file, and then compare it with the value computed for the local file to confirm that the file transferred correctly. The XCRC subcommand is available for use by all users (both anonymous and authenticated). Note: The XCRC subcommand currently returns incorrect results for file sizes greater than 2GB. A workaround for this is to specify a byte range of "0 0" (e.g., xcrc big.file 0 0). Q33: I received a "421 Timeout (600 seconds): closing control connection. Connection closed by remote host" message. What is happening? Is there anything that can be done? A33: The FTP server will timeout inactive sessions after 600 seconds (10 minutes). Some FTP clients support a "keep alive" feature that will send innocuous FTP commands to the server to prevent the timeout from occurring. If your FTP client supports this feature, enable it and set it to a value of less than 10 minutes. Q34: Is it possible to directly link to a file stored in the Secure File Transfer service from a web page? A34: There is unfortunately no way to directly link to Secure File Transfer files from a web page. Use of the HTTPS protocol first requires users to login to the https://transfer.boulder.ibm.com or https://transfer.mul.ie.ibm.com sites. Additionally, web browsers do not support use of the FTPS protocol. In any event, placing IDs and passwords in URLs such that they are visible is strongly discouraged and likely a violation of IBM security policies. Q35: Internet Explorer upload throughput is very slow compared to other web browsers like Firefox. Is there anything that can be done? A35: Internet Explorer uses the default Winsock Send buffer size of 8KB which may be too small and limit upload throughput. See Microsoft Knowledge Base article #329781 for further information. Q36: I have an unattended process that needs to check the service periodically for new uploaded content. How often may I do this? A36: Polling for new content should not occur more frequently than once every 10 minutes. There should be at least 10 minutes between sessions (or repetitive list operations within a single session). Abusive use of the service may result in revocation of access. A37: Can a Functional ID be the owner of non-IBM IDs? Q36: Yes. A few notes: Non-IBM user IDs can be transferred from a End User to a BluePage Functional Person only. Non-IBM user IDs cannot be transferred between End Users. System Accounts are owned by a BluePage Functional Person. Contacts To obtain a new Secure File Transfer directory or IDs for external users, please complete and submit request forms at the SDF Registration web site. See Internet Services Help Desk Support for information on Help Desk support. Contact the Secure File Transfer administrator at sftadmin@us.ibm.com for Secure File Transfer administration support. Related links See Service Availability for the service availability schedule and related information. See Internet Services Pricing for current pricing information. BACK TO TOP Last updated: Jun 17, 2025 at 12:55 pm