Cloud evangelist with a passion for Microsoft Private Cloud and Public Cloud. Hopefully you will find something useful here.
-Kristian Nese

Thursday, February 6, 2014

Configuring Remote Console for Windows Azure Pack

Configuring Remote Console for Windows Azure Pack

This is a blog post that is part of my Windows Azure Pack
findings.

Lately, I have been very dirty on my hands, trying to
break, fix and stress test Windows Azure Pack and its resource providers.

Today, I will explain how we configure Remote Desktop as
part of our VM Cloud resource provider, to give console access to the virtual
machines running on a multi-tenant infrastructure.

Background

Windows Server 2012 R2 – Hyper-V introduced us for many
new innovations, and a thing called “Ehanced VM session mode”, or “RDP via
VMBus” was a feature that no one really cared about at first.

To put it simple: The traditional VMConnect session you
initiate when connecting to a virtual machine (on port 2179 to the host, that
then exposes the virtual machine) now supports redirecting local resources to a
virtual machine session. This has not been possible before, unless you are
going through a TCP/IP RDP connection directly to the guest – that indeed
required network access to the guest.

Hyper-V’s architecture has something called “VMBus” which
is a communication mechanism (high-speed memory) used for interpatition
communication and device enumeration on systems with multiple active
virtualized partitions. If you do not install the Hyper-V role, the VMBus is
not used for anything. But when Hyper-V is installed, the VMBus are responsible
for communication between parent/child with the Integration Services installed.

The virtual machines (guests/child partitions) do not
have direct access to the physical hardware on the host. They are only
presented with virtual views (synthetic devices). The synthetic devices take
advantages when Integration Services is installed for storage, networking,
graphics, and input system. The Integration Services is a very special
virtualization aware implementation, which utilizes the VMBus directly, and
bypasses any device emulation layer.

In other words:

The enhanced session mode connection uses a Remote
Desktop Connection session via the VMBus, so no network connection to the
virtual machine is required.

What problems
does this really solve?

·Hyper-V Manager let you connect
to the VM without any network connectivity, and copy files between the host and
VM.

·Using USB with the virtual
machine

·Printing from a virtual machine
to a local printer

·Take advantage of all of the
above, without any network connectivity

·Deliver 100% IaaS to customers/tenants

The last point is important.

If you look at the service models in the cloud
computing definition, Infrastructure as a Service will give the tenants the
opportunity to deploy virtual machines, virtual storage and virtual networks.

In other words, all of the fabric content is managed by
the service provider (Networking, Storage, Hypervisor) and the tenants simply
get an operating system within a virtual machine.

Now, to truly deliver that, through the power of
self-service, without any interaction
from the service provider, we must also support that the tenants can do
whatever they want with this particular virtual machine.

A part of the operating system is also the networking
stack. (Remember that abstraction is key here, so the tenant should also manage
– and be responsible for networking within their virtual machines, not only
their applications). So to let tenants have full access to their virtual
machines, without any network dependencies, Remote Desktop via VMBus is the
solution.

Ok, so now you know where we’re heading, and will use
RDP via VMBus together with System Center 2012 R2 and Windows Azure Pack. This
feature is referred to as “Remote Console” in this context, and provides the
tenants with the ability to access the console of their virtual machines in
scenarios where other remote tools (or RDP) are unavailable. Tenants can use
Remote Console to access virtual machines when the virtual machine is on an
isolated network, an untrusted network, or across the internet.

Requirements

Windows Server 2012 R2 – Hyper-V

System Center 2012 R2 – Virtual Machine Manager

System Center 2012 R2 – Service Provider Foundation
(which was introduced in SP1)

Windows Azure Pack

Remote Desktop Gateway

The Remote Desktop Gateway in this context will act
(almost similar) like it does for the VDI solution, signing connections from
MSTSC ro the gateway, but rather redirect to VMBus and not a VDI guest.

After you have installed, configured and deployed the
fabric, you can add the Remote Desktop Gateway to your VM Cloud resource
provider. You can either add this in the same operation as when you add your
VMM server(s), or do it afterwards. (This requires that you have installed a VM
with the RDGateway role, configured SSL certificates, both for VMMàHost->RDGW communication, and CA cert for external access).

Before we start to explain about the required
configuration steps, I would like to mention some important things.

This has been a valuable learning experience, and I
have been collaborated with Marc Van Eijk (Azure MVP), Richard Rundle (PM at
MS), Stanislav Zhelyazkov (Cloud MVP), and last but not least, Flemming Riis
(Cloud MVP).

Thanks for all the input and valuable discussions,
guys!

As part of this journey, I have been struggling with
certificates to get everything up and running. As you may be aware of, I am not
a PKI master, and I am not planning to become one either, but it is nice to
have a clear understanding of the requirements in this setup.

1)The certificate you need for
your VMM server(s), Hyper-V hosts (that is a part of a host group that is in a
VMM cloud, that is further exposed through SPF to a Plan in WAP) and the RD
Gateway can be self-signed. I bet
many will try to configure this with self-signed certificates in their lab, and
feel free to do so. But you must configure it properly. I’ve been burned here.
Many times.

2)The certificate you need to access this remotely should be from a CA. If you want to
demonstrate or use this in a real world deployment, this is an absolute
requirement. This certificate is then only needed on the RD Gateway, and should
represent the public FQDN on the RD Gateway that is accessible on port 443 from
the outside.

3)I suggest you repeat step 1 and 2 before you proceed.

4)I also suggest you to get your
hands on a trusted certificate so that you don’t have to stress with the
Hyper-V host configuration, as described later in this guide

Configuring
certificates on VMM

If you are using self-signed certificates, you should
start by creating a self-signed certificate that meets the requirement for this
scenario.

Once this is done, open MMC and add the certificate snap-in
and connect to local user.

Under personal, you will find these certificates.

1)Export the certificate (.cer) to
a folder.

2)Export the private key (.pfx) to
a folder – and create a password

For the VMM server, we load the pfx into the VMM database so
that VMM doesn’t need to rely on the certs being in the cert store of each
node. You shouldn’t need to do anything on the VMM server except import the pfx
into the VMM database using Set-SCVMMServer cmdlet. The VMM server is
responsible for creating tokens.

Now, open VMM and launch the VMM Powershell module,
and execute these cmdlets, since we also must import the PFX to the VMM
database:

This will import the pfx, and configure VMM to setup
the VMConnectGateway password, certificate, the host identification mode (which
is FQDN) and the time to live in minutes.

Once this is done, you can either wait for VMM to
refresh the Hyper-V hosts in each host group – to deploy the certificates, or
trigger this manually through powershell with this cmdlet:

Get-SCVMHost -VMMServer
"VMMServer01.Contoso.com" | Read-SCVMHost

Once each
host is refreshed in VMM, it installs the certificate in the Personal certificate store of the
Hyper-V hosts and configure the Hyper-V host to validate tokens by using the
certificate.

The
downside of using a self-signed certificate in this setup, is that we have to
do some manual actions on the hosts afterwards:

Configuring certificates on the Hyper-V hosts

Hyper-V will
accept tokens that are signed by using specific certificates and hash
algorithms. VMM performs the required configuration for the Hyper-V hosts.

Since using a
self-signed certificate, we must import the public key (not the private key) of the certificate to the Trusted
Root Certificateion Authorities certificate store for the Hyper-V hosts. The following
script will perform this for you:

You must restart the Hyper-V Virtual
Machine Management service if you install a certificate after you configure
Virtual Machine Manager. (If you have running virtual machines on the hosts,
put one host at a time in maintenance mode with VMM, wait till it is empty,
reboot, and perform the same action on every other hosts before you proceed.
Yes, we are getting punished for using self-signed certificates here).

Please
note:

This
part, where the Hyper-V Virtual Machine Management Service requires a restart,
is very critical. If remote console is not working at all, then it could have
been due to the timing of when the self-signed certificate was added to the trusted
root on the Hyper-V hosts. If the certificate is added to the trusted root
after VMM has pushed the certificate, Hyper-V won’t recognize the self-signed
cert as trusted since it queries the cert store on process startup, and not for
each token it issues.

Now we need to verify that the certificate
is really installed in the Personal certificate store of the Hyper-V hosts,
using the following cmdlet:

This Remote Desktop Gateway can only be used for Remote Console once it is configured for this. A
configuration change will occur, which makes the gateway unusable for other
purposes, as we will install an authentication plug-in from VMM media to this
server.

In order to support federated authentication, VMM has a
VMM Console Connect Gateway which is located at CDLayout.EVAL\amd64\Setup\msi\RDGatewayFedAuth.

For a HA scenario, you can install multiple quantities of
RD Gateways with the Console Connect Gateway behind a load balancer.

Once you have installed and configured the RD Gateway
with a trusted certificate from a CA for the front-end part (the public FQDN
that is added to the VM Cloud resource provider in WAP), you can move forward
and import the public key of the
certificate into the Personal certificate store on each RD Gateway server,
using the following cmdlet:

When the RD Gateway is authenticating tokens, it accepts
only tokens that are signed by using specific certificates and hash algorithms.
This configuration is performed by setting the TrustedIssuerCertificateHashes
and the AllowedHashAlgorithms properties in the WMI FedAuthSettings class

Use the following cmdlet to set the
TrustedIssuerCertificateHashes property:

8 comments:

Ernst M.
said...

In the technet doc the last step on the rdgw is to create/import a cert in RDGW MAnager. Did you leave this out on purpose or is it not needed?

http://technet.microsoft.com/en-US/library/dn469415.aspx'The last step is to select or create a self-signed certificate for RD Gateway. To accomplish this, open RD Gateway Manager, right-click Remote Desktop Gateway, and click Properties. In the Properties dialog box, click the SSL Certificate tab.This certificate is used by tenant client computers to verify the identity of the RD Gateway server. The CN name for the certificate must match the FQDN of the RD Gateway server. Open RD Gateway Manager and assign or create a self-signed certificate.'

I've mentioned "The certificate you need to access this remotely should be from a CA. If you want to demonstrate or use this in a real world deployment, this is an absolute requirement. This certificate is then only needed on the RD Gateway, and should represent the public FQDN on the RD Gateway that is accessible on port 443 from the outside.".

In my case, I used a trusted cert from a CA. But yes, of course, you should configure the SSL certificate for your remote desktop gateway.

So in this case, a trusted SSL with a public FQDN, accessed by tenants.

I've mentioned "The certificate you need to access this remotely should be from a CA. If you want to demonstrate or use this in a real world deployment, this is an absolute requirement. This certificate is then only needed on the RD Gateway, and should represent the public FQDN on the RD Gateway that is accessible on port 443 from the outside.".

In my case, I used a trusted cert from a CA. But yes, of course, you should configure the SSL certificate for your remote desktop gateway.

So in this case, a trusted SSL with a public FQDN, accessed by tenants.