Some organizations will not allow direct connections from the outside world through their firewall to their CrushFTP server. In these cases, you can run a CrushFTP server in the DMZ which handles connections, and it then makes requests on behalf of the user to the internal server. This prevents users having direct access to the internal server, and can off-load encryption on the DMZ server. You can also use the ReverseSocket plugin in this scenario to have the internal server always make outgoing connections to the DMZ server so that no incoming firewall access needs to be allowed. The internal server doesn't have to be a CrushFTP server either. You could use this type of method to provide secure protocols over another server such as the IIS FTP daemon, or other existing legacy servers. [Guide]
CrushFTP has an included plugin called CrushLDAPGroup. This plugin allows you to configure an LDAP server to handle authentication of CrushFTP users. You can then have the plugin operate in three different authentication modes.
The plugin can also limit access to users who are found in a list of specified roles, and are part of the search base location. As with all plugins, you can create multiple LDAP configurations, and they will be searched in order until a plugin configuration matches the user. This allows you to configure a primary LDAP and backup LDAP configuration. You can also enter two URLs on one plugin, separating each of the full URLs with a comma.
The CrushFTP user manager allows you to configure PGP encryption / decryption settings on any folder item a user has access to. This configuration can operate in dual mode, both removing encryption, and adding encryption on a single incoming, or outgoing file transfer. The ideal scenario for this might be applying a specific encryption key on files being delivered to the HR folder. When a user uploads to that folder, you could have your own global company private key stripping the encryption off the file the user is sending that they encrypted using your company's public key. Then at the same time the files are being encrypted with the HR departments public key. No one can then access those files unless they have the private key. HR employees downloading the files would use their own PGP software to remove the encryption on the files. This ensures that no one else could have viewed or tampered with the file in any way. So users are sending data to your company encrypted using your public key, and you are stripping that and writing the data to specific folders using another departments key.
You can configure an always on CrushTunnel configuration that can be running on a cloud server. This can be a Linux VM running in Amazon's cloud, or a Virtual Private Server with DigitalOcean, etc. Below is an example command to start up the tunnel, allowing you to them have a static IP that will have all data tunneled through it. An ideal scenario for this is for users who have geographically diverse users. You could have an European CrushTUnnel running that has the DNS name eruope.domain.com, and a us one that has us.domain.com while you are running your server in Australia. Users in the US would access your server with the appropriate domain name, and they would be directed through the CrushTunnel. Any uploads or downloads they do would now run at full bandwidth speed.
java -cp CrushTunnel.jar com.crushftp.tunnel2.Tunnel2 protocol=https host=crushftp.com port=443 username=demo password=demo
At launch, CrushTunnel will get the tunnel for the specified account, and listen for connections on the port configured in the tunnel. It will remain running indefinitely processing connections.
If you don't have a lot of bandwidth, or machines you can leave always running, it might make sense to run CrushFTP in a VM hosted somewhere else. I've provided a guide stepping through the details of configuring a headless Linux server to run CrushFTP and managing it. [Guide]
The CrushTask plugin allows for very straight forward operations (moving uploaded files to another folder) and very complex operations. Here are a couple possible scenarios that could be of benefit.
Enterprise users have the option of scheduling jobs to run at specified intervals. A good use for this could be running a CrushTask sequence of items. Have CrushTask use a UsersList task item to go through a list of usernames. Then have it call the PopImap task item and use the user's email address, and their configured IMAP settings to connect to the IMAP server to find messages matching the configuration. This could be messages that have a certain subject, or attachments with a certain name or size. These files can then be saved off, and added to the user's virtual file system. As an added bonus you could then have the next task item send a notification email to the user confirming the arrival of these newly found files.