Windows Server 2019 – Encryption technologies

How to install Ubuntu Server 19.10

An idea that has taken a fast step from something the big organizations are playing around with to everybody needs it is the use of encryption. Most of us have been encrypting our website traffic for many years by using HTTPS websites, but even in that realm there are surprising exceptions, with a lot of the cheap web-hosting companies still providing login pages that transmit traffic in clear text. This is terrible, because with anything that you submit over the internet now using regular HTTP or an unencrypted email you have to assume that it is being read by someone else. Chances are you are being paranoid and nobody is actually intercepting and reading your traffic, but you need to know that if you are accessing a website that says HTTP in the address bar, or if you are sending an email from any of the free email services, any data that is being entered on that web page or in that email can easily be stolen by someone halfway around the world. Data encryption is an absolute requirement these days for corporate information that needs to traverse the internet; though at the same time I say that, the back of my mind is telling me that the vast majority of companies are still not using any kind of encryption technology on their email system, and so that is still a potential disaster waiting to happen for most.

While we are getting better and better at protecting internet browser traffic, we traditionally still are not paying a lot of attention to data that is safe within the walls of our organization. The bad guys aren’t dumb, though, and they have a very large toolbox of tricks to socially engineer their way into our networks. Once inside, what do they find? In most cases, it’s a big free-for-all. Get a hold of one user account or one computer and you’ve got keys to a large part of the kingdom. Fortunately, there are several technologies built into Windows Server 2019 that are designed to combat these intrusions and protect your data even while it sits within the four walls of your data center. Let’s look at some information on them so that you can explore the possibility of using these encryption technologies to further protect your data.

BitLocker and the virtual TPM

BitLocker is a technology that has become pretty familiar to see on our client systems within corporate networks. It is a full-drive encryption technology, giving us the advantage of making sure our data is fully protected on laptops or computers that might be stolen. If a thief gets their hands on a company laptop, claws out the hard drive, and plugs it into their computer…sorry, Charlie, no access. The entire volume is encrypted. This makes all kinds of sense for mobile hardware that could be easily lost or stolen, but in the beginning stages of this technology there was never real consideration for using BitLocker to protect our servers.

With the escalated adoption of cloud computing resources, suddenly it makes much more sense to want BitLocker on our servers. More particularly when talking about the cloud, what we really want is BitLocker on our virtual machines, whether they be client or server OSes. Whether you are storing your Virtual Machines (VMs) in a true cloud environment provided by a public cloud service provider or are hosting your own private cloud where tenants reach in to create and manage their own VMs, without the possibility of encrypting those virtual hard drives—the VHD and VHDX files—your data is absolutely not secure. Why not? Because anyone with administrative rights to the virtualization host platform can easily gain access to any data sitting on your server’s hard drives, even without any kind of access to your network or user account on your domain. All they have to do is take a copy of your VHDX file (the entire hard drive contents of your server), copy it to a USB stick, bring it home, mount this virtual hard disk on their own system, and bingo—they have access to your server hard drive and your data. This is a big problem for data security compliance.

Why has it historically not been feasible to encrypt VMs? Because BitLocker comes with an interesting requirement. The hard drive is encrypted, which means that it can’t boot without the encryption being unlocked. How do we unlock the hard drive so that our machine can boot? One of two ways. The best method is to store the unlock keys inside a Trusted Platform Module (TPM). This is a physical microchip that is built right into most computers that you purchase today. Storing the BitLocker unlock key on this chip means that you do not have to connect anything physically to your computer in order to make it boot, you simply enter a pin to gain access to the TPM, and then the TPM unlocks BitLocker. On the other hand, if you choose to deploy BitLocker without the presence of a TPM, to unlock a BitLocker volume and make it bootable, you need to plug in a physical USB stick that contains the BitLocker unlock keys. Do you see the problem with either of these installation paths in a virtual machine scenario? VMs cannot not have a physical TPM chip, and you also have no easy way of plugging in a USB stick! So, how do we encrypt those VMs so that prying eyes at the cloud hosting company can’t see all my stuff?

Enter the virtual TPM. This capability came to us brand new in Windows Server 2016; we now have the capability of giving our virtual servers a virtual TPM that can be used for storing these keys! This is incredible news, and means that we can finally encrypt our servers, whether they are hosted on physical Hyper-V servers in our data center or sitting in the Azure Cloud.

Shielded VMs

Using BitLocker and virtual TPMs in order to encrypt and protect virtual hard drive files produces something called Shielded VMs. Shielded virtual machines were a capability first introduced in Windows Server 2016, and have been improved in Server 2019. I know this is just a tiny taste and preview of this amazing new technology, but I wanted to mention it here because it definitely relates to the overall security posture of our server environments.

We will cover much more detail on Shielded VMs in Chapter 12, Virtualizing Your Data Center with Hyper-V.

Encrypted virtual networks

Wouldn’t it be great if we could configure, control, and govern our networks from a graphical administrative interface, rather than looking at router CLIs all day? Would we not benefit from networking flexibility to move servers and workloads from one subnet to another, without having to change IP addressing or routing on those servers? Couldn’t we find some way to automatically encrypt all of the traffic that is flowing between our servers, without having to configure that encryption on the servers themselves?

Yes, yes, yes! Through the use of Software Defined Networking (SDN) and a new capability called encrypted virtual networks, we can accomplish all of these things. This section of text is really just a reference point, a place to steer you back toward Chapter 5, Networking with Windows Server 2019, if you skipped over it and landed here instead. We have already discussed SDN and its new capability to create and automatically encrypt virtual networks that flow between Hyper-V VMs and Hyper-V host servers, so if this idea intrigues you, make sure to head back and revisit that chapter.

Encrypting File System

The Encrypting File System (EFS) is a component of Microsoft Windows that has existed on both client and server OSes for many years. Whereas BitLocker is responsible for securing an entire volume or disk, EFS is a little more particular. When you want to encrypt only particular documents or folders, this is the place you turn to. When you choose to encrypt files using EFS, it is important to understand that Windows needs to utilize a user certificate as part of the encrypt/decrypt process, and so the availability of an internal PKI is key to a successful deployment. Also important to note is that authentication keys are tied to the user’s password, so a fully compromised user account could negate the benefits provided by EFS.

I think that many companies don’t employ EFS because you leave the decision on what documents to encrypt up to the user. This also means that you depend on them to remember to do the encryption in the first place, which means they will have to understand the importance of it in order to make it worthy of their time. I wanted to mention EFS because it is still alive and is still a valid platform for which you can encrypt data, but most administrators are landing on BitLocker as a better solution. Lack of responsibility on the user’s part and a good centralized management platform do put BitLocker a solid step ahead of EFS. Both the technologies could certainly co-exist, though, keeping data safe at two different tiers instead of relying on only one of the data encryption technologies available to you.


A lot of the encryption technology built into OSes revolves around data at rest. But what about our data on the move? We talked about using SSL on HTTPS websites as a way of encrypting web browser data that is on the move across the internet, but what about data that is not flowing through a web browser?

And what if I’m not even concerned about the internet; what if I am interested in protecting traffic that could even be flowing from point to point inside my corporate network? Is there anything that can help with these kinds of requirements? Certainly.

IPsec is a protocol suite that can be used for authenticating and encrypting the packets that happen during a network communication. IPsec is not a technology that is particular to the Microsoft world, but there are various ways in Windows Server 2019 that IPsec can be utilized in order to secure data that you are shuttling back and forth between machines.

The most common place that IPsec interaction shows up on a Windows Server is when using the Remote Access role. When configuring VPN on your RA server, you will have a number of different connection protocols that the VPN clients can use to connect to the VPN server. Included in this list of possible connection platforms are IPsec (IKEv2) tunnels. The second remote access technology that uses IPsec is DirectAccess. When you establish DirectAccess in your network, every time that a client computer creates a DirectAccess tunnel over the internet to the DirectAccess server, that tunnel is protected by IPsec. Thankfully the Remote Access Management Console that you use to deploy both VPN and DirectAccess is smart enough to know everything that is needed to make IPsec authentication and encryption work, and you don’t need to know a single thing about IPsec in order to make these remote access technologies work for you!

The big missing factor with IPsec provided by the Remote Access role is traffic inside your network. When you are talking about VPN or DirectAccess, you are talking about traffic that moves over the internet. But what if you simply want to encrypt traffic that moves between two different servers inside the same network? Or the traffic that is flowing from your client computers inside the office to their local servers, also located in the office? This is where some knowledge of the IPsec policy settings comes in handy, because we can specify that we want traffic moving around inside our corporate networks to be encrypted using IPsec. Making that happen is a matter of putting the right policies into place.

Configuring IPsec

There are two different places that IPsec settings can be configured in a Microsoft Windows environment. Both old and new systems can be supplied with IPsec configurations through the traditional IPsec Security Policy snap-in. If you are running all systems that are newer, such as Windows 7 and Server 2008 and above, then you can alternatively employ the Windows Defender Firewall with Advanced Security for setting up your IPsec policies. WFAS is the most flexible solution, but isn’t always an option depending on the status of legacy systems in your environment.

First, let’s take a glance at the older IPsec policy console. We will start here because the different options available will help to build a baseline for us to start wrapping our minds around the way that IPsec interaction works between two endpoints. There are three different classifications of IPsec policy that can be assigned to your machines that we will encounter in this console. Let’s take a minute to explain each one, because the policy names can be a little bit misleading. Understanding these options will put you a step ahead for understanding how the settings inside WFAS work as well.

Server policy

The server policy should probably be renamed to Requestor policy, because that is really what this one does. When a computer or server makes a network request outbound to another computer or server, it is requesting to establish a network connection. On these requesting computers—the ones initiating the traffic—this is where we tell the IPsec Server policy to apply. Once applied, the server policy tells that computer or server to request IPsec encryption for the communication session between the initiating machine and the remote computer. If the remote system supports IPsec, then the IPsec tunnel is created in order to protect the traffic flowing between the two machines. The Server policy is pretty lenient though, and if the remote computer does not support IPsec, then the network connection is still successful, but remains unencrypted.

Secure Server policy

The difference here is that the Secure Server policy requires IPsec encryption in order to allow the network communication to happen. The regular server policy that we talked about earlier will encrypt with IPsec when possible, but if not possible it will continue to flow the traffic unencrypted. The Secure Server policy, on the other hand, will fail to establish the connection at all if IPsec cannot be negotiated between the two machines.

Client policy

The Client policy needs to be renamed to Response policy, because this one is on the other end of the connection. The Client policy does not care about requesting an IPsec session, it only cares about receiving one. When a computer makes a network request to a server, and that computer has the Server or Secure Server policy so it is requesting IPsec, then the server would need to have the Client policy assigned to it in order to accept and build that IPsec tunnel. The Client policy responds by allowing the encryption to happen on that session.

IPsec Security Policy snap-in

The original console for manipulating IPsec settings is accessed via MMC. Open that up, and add the IP Security Policy Management snap-in. Interestingly, when adding this snap-in you will notice that you can view either the local IPsec policy of the machine, which you are currently logged in to, or you can open the IPsec policy for the domain itself. If you are interested in configuring a domain-wide IPsec implementation, this would be your landing zone for working on those settings. But for the purposes of just sticking our head in here to poke around a little, you can choose the Local computer in order to take a look at the console:

Once inside, you can see any existing IPsec policies that might be in place, or you can start creating your own by using the Create IP Security Policy… action available when right-clicking on IP Security Policies. Doing this will invoke a wizard that will walk through the configuration of your particular IPsec policy:

Using WFAS instead

The newer platform used for establishing IPsec connection rules is the Windows Defender Firewall with Advanced Security. Go ahead and open that up, as you are already familiar with doing. Once inside, navigate to the Connection Security Rules section, which is listed immediately below Inbound Rules and Outbound Rules. Connection Security Rules, is where you define IPsec connection rules. If you right-click on Connection Security Rules and choose New Rule… you will then walk through a wizard that is similar to the one for creating a firewall rule:

Once inside the wizard to create your new rule, you start to see that the options available to you are quite different from the ones shown when creating a new firewall rule. This is the platform from which you will establish IPsec connection security rules that define what the IPsec tunnels look like, and on which machines or IP addresses they need to be active:

We do not have space here to cover all of the available options in this wizard, but I definitely recommend picking up from here and taking it a step further with some added knowledge on TechNet, as given here:

Comments are closed.