FastBack Encrypted Replication using FTPS

[mccleld]

Hi Guys,

I wanted to share for posterity my understanding/experience of the FastBack DR Replication mechanism so and encryption lest anyone else be caught out.

o - By default, the FastBack DR mechanism uses FTP to send its data to the FastBack DR Hub.

o - FastBack uses FTP over SSL (aka FTPS, not to be confused with SFTP) when the 'Encryption' check box is selected in the DR Parameters section of the DR Configuration tab in the FastBack Server's General Configuration window.

The FTP Server component of IIS 6.0 that is shipped with Windows 2003 does *not* support FTPS (FTP over SSL). However, 3rd party FTP Server tools *do* provide FTP over SSL capabilities, as well as IIS 7.0 and 7.5 version shipped with Windows 2008 and Windows 2008 R2.

The error that I'm seeing (which has prompted this) is where DR fails once Encryption is checked and the FTP Server (IIS on Win2K3) doesn't support FTPS - the "c:\Documents and Settings\All Users\Application Data\Tivoli\TSM\FastBack\dr\FAST_BACK_DR_PH1_040.sf" file reveals AFS::FTP CONNECTION ERROR: address:'x.x.x.x', port:21, user:'x', err='Unable to establish security context for this session' - there is nothing further in the FastBack Server Log itself other than the undescriptive 'DR Policy ... failed'.

I found this to be remarkably unclear in the FastBack Deployment Redbook, the suggestion being that the Windows FTP Server would support encrypted replication. The FastBack Installation and User Guide does make general statements that the FTP Server must support encryption, but doesn't anywhere mention FTPS (instead using its longer name FTP over SSL).

_________________
David McClelland
London, UK

 

[mccleld]

I wanted to share my experiences of configuring the FastBack Server for FTPS DR encryption to the remote DR Hub Server - it's pretty straightforward but not explicitly documented in any of the IBM literature I've seen. Hopefully it may help others in the future.

I wanted to achieve this using Windows' native tools rather than any third party FTP Server software. For this I needed to use Windows 2008 as the FastBack DR Hub, as the version of IIS that ships with Windows 2003 doesn't support FTPS. I configured the DR Hub's default IIS 7.0 install with the Microsoft FTP 7.5 service as described here: http://learn.iis.net/page.aspx/304/using-ftp-over-ssl/ << NB, this is actually the official MS IIS site. This talks you through downloading the additional code and creating a self-signed server certificate which is subsequently bound to the FTP site for FastBack DR. I created the FTP site itself in collaboration with the steps in the IBM FastBack Redbook (http://www.redbooks.ibm.com/abstracts/sg247685.html) - these are for IIS 6 in Windows 2003, but it's trivial to figure out the differences.

To unit test the process, initially I turned off the SSL requirement from the IIS Server and simply performed an FTP login from the remote machine (i.e., the FastBack Server) - this proved that the appropriate network was in place, firewall ports were opened and that the FTP Server itself was properly configured. Re-enabling the SSL certificate requirement, I configured the FastBack Server DR tab in exactly the same manner as without the SSL but simply clicked the 'Encryption' check box, clicked Apply and then ran a 'Test Now' which almost immediately (suspiciously!) returned a success. I had expected that I'd need to supply some certificate details to the FastBack Server, but none were prompted for. I then selected Run Now and waited until DR had completed. Verification that data comms had indeed been encrypted was via the FTP Server logs on the DR Hub:

2010-09-13 13:16:46 172.26.105.7 - 172.26.105.8 21 ControlChannelOpened - - 0 0 bc83bbcb-fc13-438c-afdb-0ea6f101cf97 -
2010-09-13 13:16:46 172.26.105.7 - 172.26.105.8 21 AUTH TLS 234 0 0 bc83bbcb-fc13-438c-afdb-0ea6f101cf97 -
2010-09-13 13:16:46 172.26.105.7 - 172.26.105.8 21 USER fastbackdruser 331 0 0 bc83bbcb-fc13-438c-afdb-0ea6f101cf97 -

The message 234 (AUTH TLS) is the key here, apparently confirming that the comms have been encrypted. And finally, of course, I tested with a restore of the DR-ed data in the DR location.

Hope that helps - if anyone has tried this and achieved it in a different way, spots a flaw in the above or had any problems with the process, don't hesitate to post.

_____________
David Mc
London, UK