Thursday, October 22, 2015

RDS/RDP Support for TLS 1.1 and TLS 1.2 - KB3080079

Great news!

It appears Microsoft has finally released a patch for Windows 7/Server 2008 R2 that adds support for TLS 1.1 and 1.2 to the RDP protocol. The patch can be found at https://support.microsoft.com/en-us/kb/3080079.

But what about enabling TLS 1.2 support in your RDS 2012 R2 farm? When you set the security options on a Session Collection, clearly it lists support for TLS 1.0 only, as shown below.
TLS 1.0 support in the RDS console
TLS 1.0 support in the RDS console
Well, apparently RDS already supports TLS 1.2, despite what the GUI states. Microsoft also recently published another KB article explaining this - https://support.microsoft.com/en-us/kb/3097192

Consider the following scenario:
  • You have a computer that's running Windows Server 2008 R2, Windows Server 2012, or Windows Server 2012 R2.
  • You have the Remote Desktop Connection Broker (RDCB) role configured on this computer.
  • You try to secure the RDP connections to the target computers by using SSL encryption (Transport Layer Security (TLS)).In this scenario, you may notice that the Security Layer list displays SSL (TLS 1.0), even though it's actually using TLS 1.2
This issue is caused by a bug in the Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 GUIs. You can safely ignore the TLS version that's displayed in the GUI because this does not reflect the version of TLS that's being used for client connections.
This is a welcome security improvement from Microsoft. Weaknesses have recently been found in the TLS 1.0 protocol, and any companies that require PCI compliance must phase out the usage of the TLS 1.0 protocol by June 2016, as mandated by PCI DSS 3.1.

---EDIT---

After receiving a comment that this patch was not working, I spun up a quick lab environment to test out KB3080079 and ensure it actually worked as advertised. I enabled verbose Schannel logging to determine which version of TLS was in use when a RemoteApp was launched. I was using RDS on Server 2012 R2 - I did not test RDS on Server 2008 R2. My testing was successful - TLS 1.0 was used as expected before the patch was installed, and TLS 1.2 was used afterwards. This was tested both with and without RD Gateway. See my results below.

Without KB3080079, TLS 1.0 is used
Without KB3080079, TLS 1.0 is used
After installing KB3080079, TLS 1.2 is used
After installing KB3080079, TLS 1.2 is used


Wednesday, October 14, 2015

Hyper-V dynamic MAC addressing is a cluster...

Hyper-V dynamic MAC addressing is a cluster. There - I said it.

Microsoft has been making great strides with Hyper-V by adding new features and functionality. If you compare Hyper-V on Server 2012 R2 to VMware 5.5, most people would agree that Hyper-V is "good enough" and has most of the features that the majority of businesses require. Unfortunately Microsoft has overlooked a small detail - MAC addresses. Yes, MAC addresses - something you'd think would have already been a solved problem. If you've used Hyper-V in any capacity, you probably know that there are two methods for handling MAC addresses for your virtual guests:

  • Static addresses - where you can permanently set whichever MAC address you want
  • Dynamic addresses - where each guest pulls from a dynamic pool of MAC addresses that is defined automatically on a host.
MAC address options in Hyper-V Manager
MAC address options in Hyper-V Manager

Most organizations are likely utilizing dynamic MAC addresses for their virtual guests, as it's kind of the default "set it and forget it" method. This is fine for most purposes, especially if you statically set IP addresses inside your guests, or if you only have single Hyper-V hosts with local storage.

The dynamic MAC address range is set automatically on each host based on the IP address of the host, to ensure ranges do not conflict on multiple hosts. You can view the MAC address range for a host by opening Hyper-V Manager, and in the Actions pane, clicking on Virtual Switch Manager, and then by selecting the MAC Address Range option in the left pane of the Virtual Switch Manager.

Defining the dynamic MAC address pool on each host
Defining the dynamic MAC address pool on each host

The problem comes when you have multiple Hyper-V hosts in a failover cluster. When a VM using dynamic MAC addressing live migrates to a new node in a failover cluster, it retains the same MAC address to prevent network disruptions. However, as soon as that VM is rebooted, it will grab a new MAC address from the node it's currently on.

Now, in most scenarios that's fine. If you have servers that are using statically set IP addresses, the MAC address changing on reboot will have little effect. If you are hosting virtual desktops using DHCP, this shouldn't matter much either, as it's expected for the IP address of a desktop to change when using DHCP.

Thursday, October 8, 2015

IE Trusted Sites Not Working in RDS

Ran into a fun issue this week. For some reason, Internet Explorer Trusted Sites were not applying correctly when using Internet Explorer as an RDS RemoteApp. When looking at the Trusted Sites list, it would appear blank, yet you would be prevented from modifying the list because it was controlled by Group Policy. This caused all sorts of problems with internal websites that must be in the Trusted Sites zone to work properly.

In order to manage the Trusted Sites list, we utilized the Site to Zone Assignment GPO setting, and had quite an extensive list of entries. GPUpdate was showing the GPO was applying successfully. This was further confirmed by looking in the registry and finding the entries listed correctly under HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap.

So there were no Group Policy errors, and the sites were being written to the registry correctly, yet it still wasn't working. It was time to pull out ProcessMonitor and figure out what was happening. First, a healthy and working session.

A working ProcMon capture
A working ProcMon capture
As we can see above, the user is successfully reading from the registry, including the subkeys Ranges and Domains. Next, through sheer dumb luck, I discovered that when IE Enhanced Security Configuration is enabled, the Trusted Sites list is not read from the registry. Here's a ProcMon from a system with IE ESC enabled.

A ProcMon showing IE ESC enabled
A ProcMon showing IE ESC enabled
The two screenshots are distinctly different. Notice in this capture that the system looks for the EscRanges and EscDomains subkeys, something that wasn't occurring on a working session with IE ESC disabled. Now, in my instance, IE ESC was disabled for users, so that shouldn't be the issue. Let's take a look at the ProcMon from an IE RemoteApp session...

A ProcMon taken from an IE RemoteApp session
A ProcMon taken from an IE RemoteApp session

Well that certainly looks familiar, doesn't it? We can see that Internet Explorer is looking up the EscRanges and EscDomains subkeys again, almost as if Enhanced Security Configuration is enabled, despite it clearly being off as shown by Server Manager and in the registry.

After doing some research (aka Googling), I discovered a TechNet forum post where someone offered a solution to this issue. There is an extremely deep registry key that needs to be changed.
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap
Under this registry key, you may find a DWORD called IEHarden. It was set to 1 on my RDS servers. By changing this value to 0, and resetting the user's profile (either delete their roaming profile or delete their User Profile Disk), this resolved the issue, and IE Trusted Sites were read correctly from the registry when using the IE RemoteApp.

The problem registry setting...
The problem registry setting...
This one caused me a day and a half of pain - I hope this post shows up in Google for someone else and helps them out!