Windows Azure Pack: Configuring Remote Desktop Gateway for VM Console Access

發行項
05/14/2014

The free Windows Azure Pack (WAP) delivers the on-demand, self-service user interface from our Microsoft Azure public cloud platform to on-premises Private Clouds in your datacenter. In a prior article, we walked through the steps of getting started with WAP by building the necessary components for a basic lab environment. If you missed that article, be sure to use the link below to read it first, and then come back to this article to continue expanding your lab with additional functionality.

BUILD IT! Step-by-Step: Getting Started with On-demand Private Clouds using Windows Azure Pack

In this article, we’ll extend the original WAP lab environment with an additional VM that functions as a Remote Desktop Gateway. This additional VM will provide us with the ability to connect to the virtual server console of VMs running in our Private Clouds, even if those VM’s are provisioned on isolated virtual networks. As long as there’s physical network connectivity between the Remote Desktop Gateway, VMM Management Servers and Hyper-V hosts, we can securely extend remote console access to all VM’s.

WAP Architecture with Remote Desktop Gateway

Before we proceed with the configuration steps, let’s take a look at the revised architecture for our lab with the Remote Desktop Gateway added.

WAP Remote Console Architecture – Microsoft TechNet

Based on this architecture, here’s the steps that occur when using WAP to establish VM console access:

The tenant user first authenticates via a Browser to the Windows Azure Pack (WAP) Tenant Portal.
The WAP Portal then communicates via a Service Provider Foundation (SPF) web services interface to System Center 2012 R2 Virtual Machine Manager to determine the resources and, in this case, remote console connection properties to surface via the WAP Portal.
When the tenant user clicks the Connect|Console button in the WAP Portal, the user receives an auto-generated RDP connection file that, when opened, launches the users local Remote Desktop Connection client.
The local Remote Desktop Connection client reads the RDP connection file and connects via the Remote Desktop Gateway to the Hyper-V host and through the host’s VMBus to the running Virtual Machine.

The experience that the tenant user sees from the WAP Portal is shown below …

WAP VM Console Access – Tenant User Experience

Tenant Computers Require RDP 8.1

To be able to leverage remote VM console access via the WAP Portal using the architecture above, tenant users need to be using client devices that support Remote Desktop Protocol (RDP) 8.1. This is a requirement to support the pluggable authentication and authorization (PAA) that this WAP Remote Desktop Gateway scenario uses. If tenants are running Windows 8 on client devices, they can upgrade to Windows 8.1 to meet these requirements. If they are running Windows 7 SP1 on client devices, they will also need to install KB2830477.

Remote Desktop Gateway in DMZ

In the architectural diagram above, the Remote Desktop Gateway is running on a common internal physical network with the VMM management server and Hyper-V hosts. However, some organizations may wish to further isolate the Remote Desktop Gateway in a DMZ security zone with firewalled communication between the Remote Desktop Gateway and the other WAP components. If implementing such a DMZ configuration for the Remote Desktop Gateway, keep these requirements in mind:

The Remote Desktop Gateway will require tcp/443 (https) to be open inbound to the DMZ segment from the public network segment where tenant users are located.
The Remote Desktop Gateway will require tcp/2179 (vmconnect) to be open outbound from the DMZ segment to the internal physical network segment where the Hyper-V hosts are located.

NOTE: In this configuration, the Remote Desktop Gateway does not use or require tcp/3389 (rdp) between the DMZ segment and the internal physical network segment where the Hyper-V hosts are located. From a security standpoint, I recommend specifically blocking tcp/3389 between these security zones, to further protect the Hyper-V hosts from unauthorized Remote Desktop access to the host server console.
By default, the Remote Desktop Gateway will expect to be able to query DNS to resolve the fully qualified domain names for Hyper-V hosts to IP addresses on which those hosts are reachable from the DMZ network segment. This means that DNS will need to be available within the DMZ to provide host name resolution, commonly in a DNS split zone configuration.

NOTE: If you prefer to disable DNS resolution from the Remote Desktop Gateway and configure connectivity via direct IP Addresses instead, please review the following article from Marc van Eijk on the Hyper-V.nu blog. Marc does a great job of explaining the configuration changes needed to support direct IP Address connectivity.

READ IT! Windows Azure Pack Remote Console with the RD Gateway in a DMZ

Security, Trust and Certificates

By now, you may be wondering how security is maintained when permitting tenant users to establish remote console access to virtual machines from a public network segment, such as the Internet. In the architectural diagram above, you’ll note that the Remote Desktop Gateway and the Hyper-V hosts both have a trusted relationship with the VMM management server. In this architecture, the VMM management server serves as a trusted token issuing server, so that it can supply on-demand tokens inside the RDP connection files that are generated for authenticated tenant users when they attempt to connect to a VM console.

How are these trusted relationships validated?

With keys from a mutually trusted certificate chain.

Certificate Authority (CA)

When configuring a trusted certificate on the VMM management server, Remote Desktop Gateway and each Hyper-V host, you could certainly generate a self-signed certificate and manually import it on every server as a Trusted Root Certificate Authority. But, that can be a lot of work even in a small lab environment, and as you’ve probably noticed, certificates are used for securing lots of applications and services nowadays. I strongly recommend considering building your own Certificate Authority (CA) for your lab environment instead. It’s actually not much more work than using self-signed certificates when you have more than a few servers in your lab, and provides much better security and ongoing management capabilities.

If you’ve never configured a CA before, you can setup Active Directory Certificate Services (ADCS) in a few minutes and use it as your Trusted Root Certificate Authority internally. You’ll find the steps needed in the following article by my friend and colleague, Yung Chou.

READ IT! Enterprise PKI with Windows Server 2012 R2 Active Directory Certificate Services

Define Certificate Template for Trust Relationship

The certificate used to create a trust relationship between the VMM Management Server, Remote Desktop Gateway and Hyper-V hosts has a few special property requirements. Specifically, this certificate must include an Enhanced Key Usage (EKU) field that contains the Client Authentication object ID, it must support the SHA256 hash algorithm, and it must have a 2,048 bit or longer key length. Since these requirements are unique in comparison to many of the default certificate templates included with the installation of Active Directory Certificate Services, we’ll create a new certificate template on our CA server for issuing the appropriate certificate for remote console connections.

Complete the following steps on the server installed with Active Directory Certificate Services and configured as your Enterprise CA:

Launch the Server Manager tool, and select Tools| Certificate Authority from the top menu bar.
In the Certification Authority window, expand your CA server name in the left navigation pane.
In the Certification Authority window, right-click on Certificate Templates in the left navigation pane, and then click Manage on the right-click pop-up menu.
In the Certificate Templates Console window, right-click the Smartcard Logon template in the center pane, and then click Duplicate Template on the right-click pop-up menu.
In the Properties of New Template window,click the General tab and then enter Remote Console Connect in the Template Display Name field.
In the Properties of New Template window, click the Cryptography tab and then enter the following field values:

Minimum key size: 2048

Requests must use one of the following providers: Selected

Providers: Microsoft Enhanced RSA and AES Cryptographic Provider
In the Properties of New Template window, click the Subject Name tab and then select the radio button option for Supply in the request.

If prompted with a warning dialog box, click the OK button in the dialog box to acknowledge the warning message.
In the Properties of New Template window, click the Security tab and then ensure that your Active Directory username is listed with Enroll permissions.
In the Properties of New Template window,click the OK button.
Close the Certificate Templates Console window.
In the Certification Authority window, right-click on Certificate Templates in the left navigation pane and then select New | Certificate Template to Issue.
In the Enable Certificate Templateswindow, select the Remote Console Connect certificate template and then click the OK button.

An appropriate certificate template for issuing the certificate for validating a trusted relationship between the VMM Management Server, Remote Desktop Gateway and Hyper-V hosts is now defined and enabled for new certificate requests.

Issue the Trusted Certificate

On the VMM Management Server, request and issue the certificate to be used for validating the trusted relationship between the VMM Management Server, Remote Desktop Gateway and Hyper-V hosts.

Create a folder named C:\Certs on the VMM Management Server
Using Notepad, create a certificate request .INF file named C:\Certs\RDGCert.inf. This file should include the contents shown below for requesting the trusted certificate. I’ve highlighted several lines that include particularly important values for generating the certificate request.

[Version]
Signature="$Windows NT$"
[NewRequest]
; Change to your,country code, company name and Remote Desktop Gateway server common name
Subject = "C=US, O=Your_Org, CN=Your_RDG_Server"
; Indicates both encryption and signing
KeySpec = 1
; Length of the public and private key, use 2048 or higher
KeyLength = 2048
; Certificate will be put into the local computer store
MachineKeySet = TRUE
PrivateKeyArchive = FALSE
RequestType = PKCS10
UserProtected = FALSE
; Allow the key to be shared between multiple computers
Exportable = TRUE
SMIME = False
UseExistingKeySet = FALSE
; ProviderName and ProviderType must be for a CSP that supports SHA256
ProviderName = "Microsoft Enhanced RSA and AES Cryptographic Provider"
ProviderType = 24
HashAlgorithm = sha256
; KeyUsage must include DigitalSignature. 0xA0 also includes Key Encipherment
KeyUsage = 0xa0
[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.2
Generate the certificate request for the trusted certificate.

Right-click on the Start button tip and select Command Prompt (Admin) and then run the following commands:

cd C:\Certs

certreq –f -new RDGCert.inf RDGCert.req
Verify that the certificate request file is valid.

certutil RDGCert.req
Submit the certificate request to the Active Directory Certificate Services CA.

certreq -attrib "CertificateTemplate:RemoteConsoleConnect" -submit RDGCert.req RDGCert.cer
Accept the Certificate and Store in the Local Computer \ Personal certificate store.

certreq -accept RDGCert.cer
Display the certificate information for the new trusted certificate.

certutil –store my

Locate the certificate with the Subject Name field set to CN=Your_RDG_Server, O=Your_Org, C=US. For this certificate, copy the value listed for Serial Number to your clipboard.
Export the trusted certificate as a PFX file so that it can be imported into the VMM management server database.

certutil –exportpfx my PASTE_CERTIFICATE_SERIAL_NUMBER_HERE C:\Certs\RDGCert.pfx

Paste the certificate Serial Number copied in step 7 into the above command line.

When prompted, enter and confirm a password to protect this certificate PFX file.

Import Trusted Certificate to VMM Database and Hyper-V Hosts

After the trusted certificate is issued, accepted and exported as a certificate PFX file, it can be easily imported into the VMM Management Server database and distributed to all Hyper-V hosts. Perform these steps at the VMM Management Server console.

Run Windows PowerShell ISE as Administrator .
In the Administrator: Windows PowerShell ISE window, execute the following code snippet to import the certificate PFX file into the VMM Management Server database.

$cert = Get-ChildItem C:\Certs\RDGCert.pfx

# Enter the password for the certificate PFX file when prompted using the command line below.
$mypwd = Read-Host –AsSecureString

$VMMServer = "ENTER_YOUR_VMM_MANAGEMENT_SERVER_FQDN_HERE"

Set-SCVMMServer -VMConnectGatewayCertificatePassword $mypwd `
-VMConnectGatewayCertificatePath $cert `
-VMConnectHostIdentificationMode FQDN `
-VMConnectHyperVCertificatePassword $mypwd `
-VMConnectHyperVCertificatePath $cert `
-VMConnectTimeToLiveInMinutes 2 `
-VMMServer $VMMServer
In the Administrator: Windows PowerShell ISE window, execute the following code snippet to distribute the trusted certificate to each Hyper-V host.

Get-SCVMHost -VMMServer $VMMServer | Read-SCVMHost

The portion of this configuration relating to the VMM Management Server and Hyper-V hosts is now complete.

Install and Configure Remote Desktop Gateway

At the server console of the Remote Desktop Gateway server, perform the steps below to install and configure the gateway for WAP Remote VM Console access.

Run Windows PowerShell ISE as Administrator .
In the Administrator: Windows PowerShell ISE window, execute the following command to install the RDS Gateway server role and associated management tools.

Install-WindowsFeature -Name RDS-Gateway `
-IncludeManagementTools
In the Administrator: Windows PowerShell ISE window, execute the following command from the System Center 2012 R2 VMM installation media to install the RD Gateway Console Connect pluggable authentication and authorization (PAA) component.

<VMM_Installation_Media_Root>\
AMD64\Setup\msi\RDGatewayFedAuth\RDGatewayFedAuth.msi
In the Administrator: Windows PowerShell ISE window, execute the following command to install the public key value from the trusted certificate provisioned on the VMM server.

Import-Certificate -CertStoreLocation cert:\LocalMachine\My `
-Filepath '\\VMM_SERVER_NAME\C$\Certs\RDGCert.cer'

After the certificate has been imported, copy the Thumbprint value for this certificate to your clipboard.
In the Administrator: Windows PowerShell ISE window, execute the following code snippet to configure the imported certificate as a Trusted Issuer Certificate.

$Server = "ENTER_RD_GATEWAY_SERVER_FQDN"

$Thumbprint = "PASTE_CERTIFICATE_THUMBPRINT_VALUE_HERE”

$TSData = Get-WmiObject -computername $Server `
-NameSpace "root\TSGatewayFedAuth2" `
-Class "FedAuthSettings"

$TSData.TrustedIssuerCertificates = $Thumbprint

$TSData.Put()
Request and Install an SSL Web Server certificate on the Remote Desktop Gateway server.

This step involves the same process as requesting a normal SSL certificate for a public web site. After receiving the new SSL certificate, it should be installed in the Local Computer\Personal certificate store.

NOTE: Ideally, the certificate would be requested from a Public CA so that it is trusted by tenant client devices running externally.

If you are not familiar with the steps for requesting and installing SSL Web Server certificates, please follow these steps on TechNet.
Assign the SSL Certificate to the Remote Desktop Gateway role service.

In the Server Manager tool, select Tools | Terminal Services | Remote Desktop Gateway Manager from the top menu bar.

In the RD Gateway Manager window, right-click on the Remote Desktop Gateway server name and then click Properties on the right-click pop-up menu.

In the Properties window, click the SSL Certificate tab.

On the SSL Certificate tab, click the Import Certificate… button and then select the previously installed SSL Web Server certificate.

Click the OK button.

Register RD Gateway in Windows Azure Pack Admin Portal

Now that the Remote Desktop Gateway server is configured, we can register it for use in the Windows Azure Pack Admin Portal with the following steps:

On the Windows Azure Pack Admin Portal home page, click VM Clouds in the left navigation pane.
On the VM Clouds page, select your VMM Management Server and then click the Edit button on the bottom toolbar.
On the Edit Properties form, enter the FQDN for your Remote Desktop Gateway server in the Remote Desktop Gateway FQDN field.

Click the button to register the Remote Desktop Gateway.

Congratulations! The Remote Desktop Gateway is now ready to be used for Remote VM Console Access.

共用方式為