First published on TechNet on May 11, 2016
Hello Everyone, my name is
and I'm a Technical Advisor for one of the Microsoft Active Directory support teams. This is my first blog and today I'll share with you how to configure a Hyper-V environment in order to enable virtual smart card logon to VM guests by leveraging a new Windows 10 feature:
virtual Trusted Platform Module (TPM).
Here's a quick overview of the terminology discussed in this post:
- Smart cards are physical authentication devices, which improve on the concept of a password by requiring that users actually have their smart card device with them to access the system, in addition to knowing the PIN, which provides access to the smart card.
- Virtual smart cards (VSCs) emulate the functionality of traditional smart cards, but instead of requiring the purchase of additional hardware, they utilize technology that users already own and are more likely to have with them at all times. Theoretically, any device that can provide the three key properties of smart cards (non-exportability, isolated cryptography, and anti-hammering) can be commissioned as a VSC, though the Microsoft virtual smart card platform is currently limited to the use of the Trusted Platform Module (TPM) chip onboard most modern computers. This blog will mostly concern TPM virtual smart cards.
For more information, read
Understanding and Evaluating Virtual Smart Cards
- Trusted Platform Module – (As Christopher Delay explains in his
) TPM is a cryptographic device that is attached at the chip level to a PC, Laptop, Tablet, or Mobile Phone. The TPM securely stores measurements of various states of the computer, OS, and applications. These measurements are used to ensure the integrity of the system and software running on that system. The TPM can also be used to generate and store cryptographic keys. Additionally, cryptographic operations using these keys take place on the TPM preventing the private keys of certificates from being accessed outside the TPM.
Virtualization-based security – The following Information is taken directly from
- One of the most powerful changes to Windows 10 is virtual-based security. Virtual-based security (VBS) takes advantage of advances in PC virtualization to change the game when it comes to protecting system components from compromise. VBS is able to isolate some of the most sensitive security components of Windows 10. These security components aren't just isolated through application programming interface (API) restrictions or a middle-layer: They actually run in a different virtual environment and are isolated from the Windows 10 operating system itself.
- VBS and the isolation it provides is accomplished through the novel use of the Hyper V hypervisor. In this case, instead of running other operating systems on top of the hypervisor as virtual guests, the hypervisor supports running the VBS environment in parallel with Windows and enforces a tightly limited set of interactions and access between the environments. Think of the VBS environment as a miniature operating system: It has its own kernel and processes. Unlike Windows, however, the VBS environment runs a micro-kernel and only two processes called trustlets
Local Security Authority (LSA)
enforces Windows authentication and authorization policies. LSA is a well-known security component that has been part of Windows since 1993. Sensitive portions of LSA are isolated within the VBS environment and are protected by a new feature called Credential Guard.
- Hypervisor-enforced code integrity verifies the integrity of kernel-mode code prior to execution. This is a part of the
VBS provides two major improvements in Windows 10 security: a new trust boundary between key Windows system components and a secure execution environment within which they run. A trust boundary between key Windows system components is enabled though the VBS environment's use of platform virtualization to isolate the VBS environment from the Windows operating system. Running the VBS environment and Windows operating system as guests on top of Hyper-V and the processor's virtualization extensions inherently prevents the guests from interacting with each other outside the limited and highly structured communication channels between the trustlets within the VBS environment and Windows operating system.VBS acts as a secure execution environment because the architecture inherently prevents processes that run within the Windows environment – even those that have full system privileges – from accessing the kernel, trustlets, or any allocated memory within the VBS environment. In addition, the VBS environment uses TPM 2.0 to protect any data that is persisted to disk. Similarly, a user who has access to the physical disk is unable to access the data in an unencrypted form.
VBS requires a system that includes:
- Windows 10 Enterprise Edition
- A-64-bit processor
- UEFI with Secure Boot
- Second-Level Address Translation (SLAT) technologies (for example, Intel Extended Page Tables [EPT], AMD Rapid Virtualization Indexing [RVI])
- Virtualization extensions (for example, Intel VT-x, AMD RVI)
- I/O memory management unit (IOMMU) chipset virtualization (Intel VT-d or AMD-Vi)
- TPM 2.0
TPM 1.2 and 2.0 provides protection for encryption keys that are stored in the firmware. TPM 1.2 is not supported on Windows 10 RTM (Build 10240); however, it is supported in Windows 10, Version 1511 (Build 10586) and later.
Among other functions, Windows 10 uses the TPM to protect the encryption keys for BitLocker volumes, virtual smart cards, certificates, and the many other keys that the TPM is used to generate. Windows 10 also uses the TPM to securely record and protect integrity-related measurements of select hardware.
Now that we have the terminology clarified, let's talk about how to set this up.
Setting up Virtual TPMFirst we will ensure we meet the basic requirements on the Hyper-V host. On the Hyper-V host, launch
and confirm the following values:
should state “UEFI”.
Secure Boot State
should be On.
Next, we will enable VBS on the Hyper-V host.
- Open up the Local Group Policy Editor by running
- Navigate to the following settings:
Computer Configuration, Administrative Templates, System, Device Guard
Turn On Virtualization Based Security
. Set the policy to
Now we will enable
Isolated User Mode
on the Hyper-V host.1. To do that, go to run type
on the left pane find Turn Windows Features on or off.
Check Isolated User Mode, click OK, and then reboot when prompted.
This completes the initial steps needed for the Hyper-V host.
Now we will enable support for virtual TPM on your Hyper-V VM guest.
Note: Support for Virtual TPM is only included in Generation 2 VMs running Windows 10.
To enable this on your Windows 10 generation 2 VM. Open up the VM settings and review the configuration under the Hardware, Security section.
Enable Secure Boot
and Enable Trusted Platform Module should both be selected.
That completes the Virtual TPM part of the configuration. We will now work on working on virtual Smart Card configuration.
Setting up Virtual Smart Card
In the next section, we create a certificate template so that we can request a certificate that has the required parameters needed for Virtual Smart Card logon.These steps are adapted from the following TechNet article:
Prerequisites and Configuration for Certificate Authority (CA) and domain controllers
- Active Directory Domain Services
- Domain controllers must be configured with a domain controller certificate to authenticate smartcard users. The following article covers Guidelines for enabling smart card logon:
- An Enterprise Certification Authority running on Windows Server 2012 or Windows Server 2012 R2. Again, Chris's
covers neatly on how to setup a PKI environment.
- Active Directory must have the issuing CA in the NTAuth store to authenticate users to active directory.
Create the certificate template
1. On the CA console (certsrv.msc) right click on Certificate Template and select Manage
2. Right-click the Smartcard Logon template and then click Duplicate Template
3. On the Compatibility tab, set the compatibility settings as below
4. On the
Request Handling tab, in the
Purpose section, select Signature and smartcard logon from the drop down
5. On the Cryptography Tab, select the
Requests must use on of the following providers
radio button and then select the
Microsoft Base Smart Card Crypto Provider option
Optionally, you can use a Key Storage Provider (KSP). Choose the KSP, under Provider Category select Key Storage Provider. Then select the Requests must use one of the following providers radio button and select the
Microsoft Smart Card Key Storage Provider option
6. On the General tab: Specify a name, such as TPM Virtual Smart Card Logon. Set the validity period to the desired value and choose OK
7. Navigate to
. Right click on Certificate Templates and select New, then Certificate Template to Issue. Select the new template you created in the prior steps.
Note that it usually takes some time for this certificate to become available for issuance.
Create the TPM virtual smart card
Next we'll create a virtual Smart Card on the
Virtual Machine by using the Tpmvscmgr.exe command-line tool.
1. On the Windows 10 Gen 2 Hyper-V VM guest, open an Administrative
and run the following command:
tpmvsmgr.exe create /name myVSC /pin default /adminkey random /generate
You will be prompted for a pin. Enter at least eight characters and confirm the entry. (You will need this pin in later steps)
Enroll for the certificate on the Virtual Smart Card Certificate on Virtual Machine. 1. In
, right click Certificates, click All Tasks then Request New Certificate.
2. On the certificate enrollment select the new template you created earlier.
3. It will prompt for the PIN associated with the Virtual Smart Card. Enter the PIN and click
4. If the request completes successfully, it will display Certificate Installation results page
5. On the virtual machine select sign-in options and select security device and enter the pin
That completes the steps on how to deploy Virtual Smart Cards using a virtual TPM on virtual machines. Thanks for reading!