Free disk encryption solution for windows servers in the cloud

Post date: Aug 9, 2014 8:53:18 AM


One concern most people have when going to the cloud is the feeling their data is visible for everyone who can access the virtual hard disks. To limit this risk many operating systems can use some form of encryption, for Windows we have 2 default options Bitlocker and EFS (Encrypted File System).

The benefit of bitlocker is that the disk encrypted and not only the files, of course you can combine the two solutions. Please test the solution in a lab first and make Shure that it fits your needs, I am not responsible if you lose access to disks, data or servers. Use at your own risk!!!!!

The code is at the end of this article.

Some good to know information

  1. In current state the script is a login script running under the computer account, because of this when you add new disks to a server je need to restart the server to encrypt the disk. Don’t do this under your administrator account or something because the script stores the encryption key in combination with the user that starts the encryption so if for example your admin account triggers the encryption the server can’t access this unlock key because only the admin is allowed. You can change this off course, the database is readable and simple and this user filter is in the SQL stored procedures. There is one workaround I also used for testing, call the script in a scheduled task that runs under the system account.
  2. The login script is checking that bit locker is installed this costs time, if you want to speed up the script then make Shure bitlocker is installed in some other way, for example part of your image, then you can remove this part off the script.


The Focus for us is encrypt data disks in Windows running in a virtual environment including cloud environments like azure and amazon aws, you can of course also use this solution in your own private cloud.

Because we would only encrypt data disks in the cloud we need to prevent that encryption keys are available in the cloud, to make this possible this solution stores al encryptions keys in a central SQL server database you can run on premise and store in an encrypted form.

Third-party options

For disk encryption there are multiple solutions like Trendmicro securecloud the downside is that it add additional costs but is unlike the bitlocker solution able to encrypt the operating system.

No OS disk encryption

We will not encrypt the Windows operating system disk (C:), the reason for this is that virtual environments don’t have A TPM chip we need to encrypt operating disks and also Bitlocker on OS disks is not supported for use in virtual environments.

Bitlocker and Microsoft support.

Currently Microsoft is not giving support for bitlocker in virtual environments, this does not mean you can’t use it but if there are issues with a virtual server that uses bitlocker you may need to unlock and decrypted the disk first. (Decrypting can be done when server is running, no restart required).

The basic setup

The basic setup for this solution to work is, one SQL server or cluster of SQL servers and a script running on your servers.

How the solution is working

First time

  1. The first time the script runs it will check the encryption status, all disks not C: drive will be encrypted and the encryption keys will be stored in a central SQL database.
  2. You have the option to prevent services like SQL, Exchange etc on your encrypted disks from stating till disks are unlocked (this is managed in the bitlocker script), applications known by the script will be change from automatic to manual starting.

Next time the server restarts

1. Services like Exchange and SQL will now be prevented from starting until the bitlocker script has unlocked all disks. 2. The bitlock.ps1 script will connect to the database using the computer account credentials, the database will return the needed encryption keys so the script can unlock the disk 3. After unlocking the disks the script will start the services that it manages.

Installation of the script.

You have multiple options to deploy and implement the solution, for this we have chosen for a Active Directory policy in combination with a local policy to speed up the unlock process.

Create a highly available fileshare or use the netlogon folder for holding the scripts bitlock.ps1 and bitlockstart.cmd and a folder with the name local with a second version of the bitlockstart.cmd for local use. This are the most important components where the batch will trigger the bitlock.ps1 script.

Alter the following settings in the bitlock.ps1 script. In the Services to alter section you can add services that needs to be prevented from starting wile disks are still locked. #———————————————————————– #Alter the settings to match your environment #———————————————————————–

#Services to alter $services +=”MSSQLSERVER” $services +=”SQLSERVERAGENT” #$services +=<your services>

#Database to store the keys $sqlserver = “SQL Server or cluster” $sqldbname = “Database name (default bitlock)”

#———————————————————————– #End Alter the settings to match your environment #———————————————————————–

Next create a policy or add the script to an existing policy, here are settings that works perfect with this script, It will prevent users from login to the server until disks are unlockt and profiles are accessible by the system.

For redundancy, speedup the starting process and standalone use you can use a local policy, de default script with this document are always copying the latest version of the backup script to c:\windows\bitlock\

Security and permissions

SQL Database

The SQL server will hold all encryption keys and without that information you can’t access the disks anymore. Next to that, losing the database you may give others access to the resources. For this we recommend to implement an SQL Always on cluster or other cluster solution. To prevent that others gain access to the keys we recommend the following. Implement database encryption (SQL 2012 feature) and always encrypt communication between SQL server and clients (SQL Feature), IPsec is also an option.

Depending on your needs you can use all versions of SQL (Express, Standard, Enterprise) but it is depending on your requirements like high availability or database encryption. To compare options between SQL versions please check this link

Access Credentials

In our setup we use the existing computer accounts because of the following reasons • Computer account passwords will change every 30 days by default • The SQL code we use checks the user requesting the encryption key, by using computer accounts only the computer needing the key can access it. • We don’t have to store extra account information in the cloud and as always less is better.

Installation of the SQL database server

I will assume you already have installed SQL with your needed specifications like cluster config etc etc and it is running is a “safe” location and that you have installed a server certificate to make secure connections between the clients and server. In this sample we use a SQL express with tools version (free edition) that will be running as a default instance, you can always use other versions like standard or enterprise if you need clustering and database encryption.

Create a local group

First create a new local group on the SQL server with the name bitlocker-access and add the domain groups Domain Computers and Domain Controllers to this new local group and press create. You could also use a domain group but using a local group can give you options to give non domain members access to the database later on.

This group will be used to give very limited permissions in the SQL database.

Configure secure connections

Since configuring SQL servers to use secure connections is not a standard for most people we document the steps here. You can also follow the instructions found here



Open the SQL Configuration manager.

Expand SQL Server Network Configuration, right-click the protocols for the server you want, and then click Properties.

Click Force Encryption and select Yes

Select your certificate.Press Ok

If you not use SQL Express this step is now done and you can restart the SQL Service.Is you use SQL Expres please follow the next steps

For SQL Expres enable TCP/IP, other versions have this on by default.

If SQL server will not restart anymore afther this please look in the eventlog and see if you have errors like.

In that case please look at fixing certificate issues elsewhere in this document

Open the Windows Firewall

SQL Servers are listening on port 1433 (if you use an SQL instance you may need to add port 1434 also), we have to configure the firewall to open that port. Please type this at the command line netsh firewall set portopening TCP 1433 “SQLServer” If you want to limit access even more you can also configure Connection Security Rules.

Install the Dacpac.

Now open a SQL Server management studio and connect to our server,



Configure Security permissions for the scripts.

For security reasons the bitlocker scripts will have only execute access on 2 stored procedures and so preventing access to the database tables.



First we create a new login

Here we add the group Bitlocker-Access we createdearlier.

In the user mapping section we give the account public access to the bitlock database.Press Ok

Now we gone give the account access to the stored procedures it needs.Go to the stored procedure CreateDiskentry en select properties.

Give the login Bitlocker-Access execute permissions on this stored procedure.

Do the same with the stored procedure getbitlockkey and ​getBitlockkeyfromID.

Fixing Certificate issues.

It can happen that your SQL server will not start after configuring the certificate, in that case please follow the steps you find here.

After some Google searching (a lot, actually) I came across this procedure which seems to have fixed it:

First we need to find the name of the service account used by the instance of SQL Server. It will probably be something like ‘SQLServerMSSQLUser$[Computer_Name]$[Instance_Name]‘.

One way to do this is to navigate to the installation directory or your SQL Instance. By default SQL Server is installed at C:\Program Files\Microsoft SQL Server\MSSQL10_50.InstanceName.

  1. Right click on the MSSQL folder and click Properties.
  2. Click the Security tab and write down the user in the Group or user names window that matches the pattern of ‘SQLServerMSSQLUser$[Computer_Name]$[Instance_Name]‘.
  3. Now, open the Microsoft Management Console (MMC) by click Start -> Run, entering mmc and pressing Enter.
  4. Add the Certificates snap-in by clicking File -> Add/Remove Snap-in… and double clicking the Certificates item (Note: Select computer account and Local computer in the two pages on the wizard that appears.
  5. Click Ok.
  6. Expand Certificates (Local Computer) -> Personal -> Certificates and find the SSL certificate you imported.
  7. Right click on the imported certificate (the one you selected in the SQL Server Configuration Manager) and click All Tasks -> Manage Private Keys…
  8. Click the Add… button under the Group or user names list box.
  9. Enter the SQL service account name that you copied in step 4 and click OK.
  10. By default the service account will be given both Full control and Read permissions but it only needs to be able to Read the private key. Uncheck the Allow Full Control option.
  11. Click OK.
  12. Close the MMC and restart the SQL service.

And here’s the source of the procedure:

Q and A

Q: Why do u use a script and a service and not just a service.

A: Bitlocker is tricky and using WMI of just calling manage-bde seems not to work as expected even when running under a domain admin or system account we were getting permission entry’s.

Q: Why do you use manage-bde in the powershell scripts and not commands like Add-BitLockerKeyProtector etc

A: The powershell commands will only work in combination with Windows 8.1 and Windows 2012R2 and so we limit the use of the script by using them.

Q: Why do u use a batch file for copying and starting powershell scripts instead of policies?

A: I have no real reason, for documentation scripts are easier (less screenshot making) so you can use policies for deployment and running if you want.

Q: Is this the perfect security solution?

A: No, there is no perfect solution and this is just A solution, you are free to make a better one or offcourse you can use a commercial tool. There are also options to encrypt and/or sign the scripts, you could also make a custom web application so the script don’t have to talk to the SQL database and in you could also add a user login screen with two factor authentication. It should also be possible to use truecrypt instead of bitlocker or something else. So please see this as just a starting point.