When the SafeHouse Setup program is run in GUI mode, the Create Volume wizard is launched automatically at the tail end of the installation process and users are walked through the simple steps to create their first volumes. This is a straight-forward procedure which really doesn't need any further explanation.
However, when preparing for silent or automated deployments, things get a little trickier, which is why we've put together this detailed discussion of some of the issues you'll face in this regard, along with potential solutions which we know can be successfully implemented with relatively little effort.
The ultimate goal is to craft a deployment scenario in which after all is done and said, Windows is restarted and SafeHouse is fully operational from that point forward. This includes having users' first volumes created and ready to go, as well as users knowing the password to their first volume.
And finally, let's add in the factor of when and how do your users learn about SafeHouse, such that when you start asking them about passwords or whatever else, that they'll at least have some clue about what's going on.
Good question, eh? Possible choices include:
Launching the standard SafeHouse Create Volume wizard in GUI mode and letting the wizard do all the work.
Creating some kind of script or Visual Basic program which prompts for the password, and then running the Create Volume wizard in silent mode to finish creating the volume in the background.
Silently running the Create Volume wizard using a fixed password, and then somehow instructing users to change the password using the SafeHouse Change Password dialog.
Fortunately, you don't need to look far for solutions to this problem. The harder issue will be choosing which solution is right for your organization.
Described below are a number of solutions which we know have been successfully executed by our customers along with some of the pros and cons of each. In reading through some of these, hopefully you'll begin to form some thoughts about which approaches might work best in your environment.
In this scenario, the customer was readying hundreds of new PCs to be rolled out to employees. The preferred method of software installation was to prepare a single gold master hard drive containing a fresh copy of Windows along with all their new software, and then replicate this master hard drive for each of the newly-purchased machines.
The following steps were taken to implement this deployment scenario:
A custom SafeHouse installer was created which included a .BRAND file in order to support resetting passwords.
The customized installer was run on the master PC in GUI mode, which allowed the administrator to create the initial SafeHouse volume using a known password.
The hard drive from the master PC was then replicated hundreds of times using off-the-shelf disk replication software.
Users received training on SafeHouse and were instructed to immediately change the volume password so that it wasn't left set to the fixed default value.
This is as simple as it gets.
SafeHouse is ready for action from the moment users receive their new PCs.
Some of the potential weaknesses mentioned below due to replicating the encryption keys are more theoretical in nature, and in real life, would rarely, if ever, be a problem. None of these weaknesses could be reasonably exploited by somebody stealing a laptop computer out of hotel room. The reality is that people writing down passwords on sticky notes poses an exponentially greater risk.
Starting everyone off with the same password may or may not be considered an issue. From one perspective, it would not be, because the volumes would not initially contain any data. On the other hand, some might argue that lazy users won't change the fixed password, and that leaves them completely vulnerable.
Due to the replication process, the computer-generated random encryption key used to physically encrypt the date inside the SafeHouse volumes would be the same for all PCs since the big, but initially empty, volume file was copied from the master hard drive image. This won't stop SafeHouse from working, but it does open up some security holes that many people would not be willing to accept. For example, if the encryption key (not the same as a password) was somehow found out (not all that likely in real life), since that same key is used on all volumes, all volumes would therefore be compromised. Had the master volume not been replicated, only a single volume would be compromised given the same theoretical attack.
Another side-effect of having all volumes based upon the same encryption key is that absolute security built into the password reset process would be somewhat weakened.
Add a "run once" script to Windows which launches the SafeHouse Change Password dialog. The fixed password could be pre-stuffed into the old password field using command line options, leaving users only needing to fill in their new password and save. This way, users will be forced to change their password the first time they fire up their new machines.
Better yet, use the "run once" script to launch the Create Volume wizard. This way, everyone gets a new volume which completely bypasses any of the aforementioned issues relating to replicating encryption keys. SafeHouse will be fully operational the moment the new volume file has been created. Here, the visual differences to the user will be minor, yet the security offered by SafeHouse will once again approach the theoretical limits of modern-day cryptography.
In this scenario the SafeHouse Setup program is run using both the /silent and /create options. With these switches, the core files are installed silently without any visual interface. Once the files are installed and the registry has been configured, the Create Volume wizard in launched (due to the /create option) using the command line settings specified to the Deployment Wizard. The default command line arguments were used for creating the volume, which launches the wizard in full GUI mode, allowing the user to step through the wizard, choose a password and create their first volume.
The SafeHouse Setup program will terminate immediately after the Create Volume wizard finishes up. Windows will need to be restarted before users are able to open the volume just created. It is up to external scripting to restart Windows.
Provided that the custom Setup program included .BRAND file, these first volumes created by users would belong to the respective group and be able to have their passwords reset if ever lost.
Command used to run the installer:
C:\> SETUP.EXE /silent /create
Create volume options specified in Deployment Wizard:
/create="c:\SafeHouse\SafeHouse.sdsk" /size=25MB /description="Private Files" /expandableto=256 /setup
Very little effort is needed to deploy this way since you are letting SafeHouse do all the work in a single step.
The same custom Setup program can be used for both silent and non-silent installs since the command line to create the first volume works equally well in either mode.
If you're okay with users being presented with the SafeHouse Create Volume wizard, there really aren't any cons to this solution.
See the SDWCREAT.EXE program for a full list of command line options that can be used to fine-tune the Create Volume wizard.
This scenario is a slight twist on the previous one. Here, the desire is to have the Setup program run without any GUI at all; not even when the Create Volume wizard is launched. This is accomplished through a creative set of command line arguments specified within the Deployment Wizard. You'll notice that /silent and /go are passed to the wizard, as well as a fixed starting password named "default". This gives the Create Volume wizard enough information to be able to do its job without needing to display a dialog.
With these options, all SafeHouse volumes start out in life with a common fixed password, which is why the batch file used to run this script immediately invokes the Change Password wizard. The fixed password is pre-stuffed into the dialog; leaving the user needing only to choose their real password and click the Finish button.
The use of a fixed password here is temporary; lasting only a few seconds. It's needed to make the logic work since the Create Volume wizard cannot run silently within having a password to work with. The users never need to know the value of this temporary password because the script stuffs it into the Change Password wizard which pops up immediately after Setup terminates.
As described in the previous solution, Windows will still need to be restarted before users are able to open their new volumes, and the Setup program should include your .BRAND file to allow lost passwords to be reset in the future.
Command used to run the installer:
C:\>
SETUP.EXE /silent
/create
C:\>
SDWCHANG.EXE /change="c:\SafeHouse\SafeHouse.sdsk"
/password="default"
Create volume options specified in Deployment Wizard:
/create="c:\SafeHouse\SafeHouse.sdsk" /size=25MB /password="default" /silent /go /setup [other options omitted]
The Setup program will run 100% silently without any visual display.
Users see the Change Password wizard instead of the Create Volume wizard. Although the end result is identical to the prior solution, some people believe that this approach presents a somewhat simpler first exposure to SafeHouse for new users.
If you would also like a standard GUI installer, you should create a separate one which uses a more-traditional command line for the Create Volume wizard.
See the SDWCREAT.EXE program for a full list of command line options that can be used to fine-tune the Create Volume wizard. Some options you might find important, such as minimum password lengths, etc., were omitted from this example to keep the focus on the approach used for this solution.
The Change Password wizard can also be run silently if you include the /newpassword command line option. This makes it easy for you to create your own dialog to prompt the user for their first password (using Visual Basic, etc.), and then silently invoke the SDWCHANG.EXE utility to finalize the change. The advantage of using your own dialog is that you have total control over the information which is presented to the user, which might be a good opportunity to fill them in on what's taking place.
If you do decide to invoke the Change Password wizard silently from Visual Basic, we recommend that you take a look at the SafeHouse ActiveX Component which is designed to greatly simplify this task.
In this scenario, the custom Setup program is first run silently to get the core files and registry settings installed. But unlike some of the other solutions we've presented, notice that here the /create option is not included. Without this option, the Setup program will completely ignore the Create Volume wizard. Setup will terminate as soon as the core files are installed without attempting to launch the Create Volume wizard.
You still need to plan for getting the first volume created, which is why this scenario involves a few separate steps in your automation scripts as shown below:
C:\>
SETUP.EXE /silent
C:\> [run
your own dialog utility which prompts for the password]
C:\>
SDWCREAT.EXE /create="c:\SafeHouse\SafeHouse.sdsk"
/size=25MB /password="XXXXX"
/silent /go [other options omitted]
Once the Setup program completes, the next step in the script launches a program or dialog that you've created. Here is where you let the user in on what's taking place and ask them to choose their initial password. You must then pass that password to the Create Volume wizard as a command line argument. This allows the wizard to create the volume silently using the specified password.
If you wanted to get fancy, you could include a drop list in your dialog which gives users a choice over the size of their first volume, and then pass that to the wizard as a command line argument as well.
If you are also deploying with a GUI installer, you will not need to create a second version of Setup. When Setup is run silently this way it skips running the Create Volume wizard, meaning that the command line options for creating the volume specified to the Deployment Wizard will be used only for the GUI mode, allowing you to choose options which are tuned specifically for that mode.
Involves a few more steps when crafting your automated deployment scripts, but the increased flexibility may be worth it.
See the SDWCREAT.EXE program for a full list of command line options that can be used to fine-tune the Create Volume wizard. Some options you might find important, such as minimum password lengths, etc., were omitted from this example to keep the focus on the approach used for this solution.
It doesn't so much matter if your own dialog is run in the script in advance of the Setup program. All that matters is that your script invokes both the Setup and Create Volume programs, passing the user's chosen password to SDWCREAT.EXE on the command line.
Your dialog program can silently launch the Create Volume wizard with the help of the SafeHouse ActiveX Component.
This scenario demonstrates how a custom password provider could be used in combination with the /usepassworddll command line option to the Create Volume wizard. As seen in some of the previous solutions, a custom Setup program is run using both the /silent and /create options.
Here, the custom Setup program must include your password provider DLL. The Deployment Wizard gives you the option to do this (click for instructions). Your DLL will be installed into the SafeHouse program files directory alongside all the other SafeHouse files.
The Create Volume wizard command line options specified to the Deployment Wizard instruct the program to run silently, but also tell it to call your custom password provider to obtain the password. This is powerful stuff. Imagine the possibilities. Sure, your DLL could pop up a dialog and prompt for the password, but it could also do something far more complex, like query a corporate database for the password. All that really matters is that, one way or another, your DLL is able to come up with a password which it can hand back to the Create Volume wizard through the defined programming interface.
C:\> SETUP.EXE /silent /create
Create volume options specified in Deployment Wizard:
/create="c:\SafeHouse\SafeHouse.sdsk" /size=25MB /usepassworddll /silent /go /setup [other options omitted]
SafeHouse includes a sample custom password provider C++ project to get you started. See the Custom Password Provider reference material for more information.
Runs as a single command in your automation scripts.
Gives you total control over the visual interface presented to users when prompting for their initial password.
Can be used to acquire passwords from a limitless number of sources.
Requires C++ programming.
See the SDWCREAT.EXE program for a full list of command line options that can be used to fine-tune the Create Volume wizard. Some options you might find important, such as minimum password lengths, etc., were omitted from this example to keep the focus on the approach used for this solution.
There are a variety of permutations of this solution which could be crafted using a custom password provider. For example, you could choose to run the Create Volume wizard separately from the Setup program by not including /create on the Setup command line. Examples of this are presented in some of the other solutions.
As you've seen in the solutions presented above, SafeHouse offers an extreme degree of flexibility when it comes to crafting your deployment scenario. The flexibility is there. With some creative thinking, you can spin the concepts we've outlined above into any number of finely-tuned deployment solutions.
Don't forget to consider using a custom configuration file to shape some of the behavior of the Create Volume wizard. The Deployment Wizard can prompt for your preferences and build this file for you, so don't shy away from it simply because the file's syntax seems complicated.
If you are tasked with deploying SafeHouse to a large number of users and could use some help with choosing the best deployment options, please get in touch with us. We're more than happy to discuss ideas and help you figure out the best approach to take given your requirements.