How to Setup a Virtual Smart Card

Fun with Virtual Smart Cards!


Steps on how to enable a virtual smart card.


Virtual smart cards require a computer with an initialized TPM.  N.B., Windows 10 initializes the TPM by default.

Virtual Smart Card Configuration:

tpmvscmgr.exe create /name VSC /pin prompt /puk prompt /adminkey random /generate

Reset the Virtual Smart Card:

tpmvscmgr.exe destroy /instance root\smartcardreader\0000

PINs, PUKs, and Keys:

  1. Smart Card Personal Identity Number (PIN).  The PIN is essentially a password.  The PIN can be changed by the end user from any domain computer:

     CRTL-ALT-Delete → Change Password → Change PIN.
  2. Smart Card Personal Unlock Key (PUK).  Windows locks the PIN after three unsuccessful attempts.  End users can use their PUK to unblock their PIN:

     CRTL-ALT-Delete → Change Password → Unblock Smart Card.

    The PUK is optional but I recommend it.   It's simply too easy to lock the PIN! 

    The PUK changes the PIN.  Keep the PUK safe and only use it when its absolutely necessary.

    In addition, Windows does not include native tools to change the PUK. In order to choose a new PUK, the virtual smart card must first be deleted (i.e., destroyed) and then recreated.  Of course, this process deletes all certificates on the smart card.
  3. Admin Key.  The key benefit to the admin key is that it allows Administrators to generate certificate keys for enrolling-on-the-behalf of others.  Organizations that do not use enrollment stations should simply generate a random admin key.    


Container Does Not Exist on the Smart Card

T-Shoot Yubikey Minidriver


RDP fails to authenticate Yubikey smart card.


The requested key container does not exist on the smart card (Figure 1).
Figure 1.  Smart card container error.


  • Yubikey runs as PIV smart card.
  • Smart card has multiple authentication certificates.
  • Certificates reside on slots 81-95.


By default, Windows uses the NIST SP 800-73 PIV smart card driver.  Multiple certificates require the Yubikey smart card Minidriver.  Install this driver on both the client and the server.


The Yubikey smart card MSI package does not install the Minidriver on remote servers or virtual machines.  Nor does it provide an error. 

The MSI installer only works when a smart card is directly connected (e.g., workstation). 

To reiterate, the MSI package only updates the NIST driver when a smart card is attached to the local USB port.   

Instead, use the Yubikey limited INF installer on VMs or via RDP.  

Figure 2.  How to Install the Yubikey Minidriver.

Right-click on ykmd.inf.  Left-click on install.  That's It!

Fix IKEv2 Mobile Scripts on IOS10


Pre-existing IKEv2 VPN mobile configuration scripts do not work with new iPhones.  The script installs the VPN but connection attempts fail.

iPhone7 does not connect to the IKEv2 VPN.  However, older iPhones running IOS8 and IOS9 continues to connect.


Update the Mac OS and Apple Configurator 2 software.  Create a new mobile config after software updates are complete.


IOS 10 cannot connect to IKEv2 VPNs using mobile scripts designed for IOS 8 & 9.

Additional Information:

MDM Cert Enrollment


How to manually request and enroll certificates for BYOD devices with Windows CA server.


Automated mobile device management (MDM)  (e.g., Microsoft Workplace-Join,) provides a secure method for device key management.  However, rolling out the right MDM solution can be a serious undertaking.  It may be overkill for some organizations.

This article covers device key-management for special use situations.  It provides instructions on how to manually generate device (e.g., iPhone) certificates for mutual authentication (e.g., IKEv2 VPNs).



Step 1:  Request the device certificate from from any workstation:

  • Start → MMC → File → Add Snap-In:  Add Certificates - Current User
  • Certificates → Current User →  Personal → Certificates → All Tasks → Request New Certificate

Step 2:  Complete the Certificate Enrollment Wizard:                 

  • Select Policy: No changes.  Click Next.
  • → Request Certificates:  User Device Auth → Click Details →  Click Properties.
  • → Certificate Properties:      

        →  [Subject Tab]
                  Subject Name:
                       Common Name (CN) =;  add.
                       Email =;  add. Given Name:  First and last name; add.
                  Alternative Name:
                        DNS =; add. N.B., DNS must match Full CN.
                        Email =; add.
         → [General Tab]
                   Friendly name:
         → Click OK.

         → Request Certificates:  Add checkmark for User Device Auth → Click Enroll.
  • Note that status = Pending.
Step 3:   Approve request from Certificate Authority (CA) server.  

  • Open CA Server  MMC:
       → Certification Authority (Local) → Root-CA →  Pending Requests → Issue: 
Step 4:  Export certificate from workstation that initiated request:  
  • Certificates → Current User →  Certificate Enrollment Requests:
    → Certificate Export Wizard
         → Export Private Key:  Yes, export the key.
         → Export File Format:  Check Include all certificates in path.  Next.
         → Select Policy: No changes.  Click Next.
         → Security:  Check Password.  Enter Password.  Next.
                               N.B., Password = choose_password
         → File to Export:  Choose location:  C:\source\cert\user_device.pfx.  Next.
         → Export Root Certificate and VPN server certificate:  Location: \\securefileshare\
  • Repeat similar process to export CA public root certificate (CER).
  • Log onto the VPN server and repeat similar process to export public certificate (CER).
Step 5:  Distribute certificate files to client devices.
  • Distribute the client certificate and private key (e.g., PFX).  
  • Include the public VPN server and root certificates (e.g., CER).

Distribution methods: 

Security Considerations:

Safeguard your client PFX files!!  PFX files include certificates and their private keys.  An attacker can use this information to impersonate identity.  That means, it can be used to connect to the VPN, collect email, etc.  Do not let these PFX files fall into the wrong hands!  Mitigation:
  • Account for all PFX instances -these are security vulnerabilities!
  • Delete/ remove all device certificates generated from workstations.
  • Save client PFX file to secure off-line media. 
  • Consider IT policy that requires face-to-face installation with IT staff.
  • Email attachments can be forwarded -risk!
  • Internal web server on internal Wi-Fi SSID is preferred.  
  • Ad-Hoc Wi-Fi may be preferable to infrastructure mode. 
  • Do not enable the certificate's export flag.
  • Do not install on any rooted or jailbroken device.  
  • Ensure devices use encryption and passcodes.
  • Above all, use common sense!

That's It!

CA Template for VPNs


Prepare Windows CA certificate template for end-user enrollment.


  • These instructions are for situations that require minimal VPN support.
  • This solution only supports enrollment requests from the Windows certificate snap-in.
  • It enforces administrative approval for end-device enrollment -this is not a completely automated process.
  • Workplace Join is the preferred method for device enrollment.  It provides self-service automation.  It provides secure key management.  This walk-through is not for Workplace Join.


  1. Open certificate templates.  From the Windows CA:  Start → MMC → File → Add Snap-In:  Add Certificate Templates.
  2. Step 2:  Duplicate User template:  Certificate Templates → Right-Click on User (Template) →  Duplicate Template.  
  3. Step 3:  Edit Properties of New Template (Table 1):

Table 1:  New Certificate Template Properties.
Template Display Name
User Device Auth

Validity Period
3 Years

Publish in AD

Minimum key size

2048 or 3072


Microsoft RSA

Applications Policies

Client Authentication

Authenticated Users

Allow Read
Allow Enroll
Note:  3072 key size increases security strength for IKEv2 VPNs.  Choose validity to fit needs of organization.  Use short validity period for automated self-service (e.g., Workplace Join).  Disable certificate exports for automated self-service.   

The template becomes available for user enrollment requests from any Windows certificate snap-in.

How To Enable Startup PIN for BitLocker


How to enable Bit-Locker PIN for pre-authentication prompt.


Bit-locker encryption protects offline data.  Windows uses an encryption key stored in the TPM.  Therefore, the computer is vulnerable to authentication bypass compromises after Windows starts.  Data only remains fully encrypted (i.e., secure) before the operating system starts.

The BitLocker PIN is an optional security feature.  The computer will not load (i.e., boot into) Windows without PIN authentication.


Enable and enforce the Bit-Locker startup PIN.


Start by enabling Bit-Locker from Control Panel.  If this step is skipped you may receive the following error:

     "The group policy settings for bitlocker are in conflict and cannot be applied."

Once Bit-Locker in enabled, use the Group Policy Management or Local Group Policy Editor:

     Computer Config > Administrative Templates > BitLocker Drive Encryption > Operating System Drives

Policy Settings:

  Allow enhanced PINs for startup:

  Require additional authentication at startup:
       --Configure TPM startup:  Allow TPM
       --Configure TPM startup PIN:  Require PIN with TPM
       --Configure TPM startup key:  Allow startup key with TPM
       --Configure TPM startup key and PIN:  Allow startup key and PIN with TPM

   N.B., the enhanced PINs provide support for alphabetical and special character use.  This can make the PIN strength stronger and easier to remember.

Configure Client:

     Run the following command with Administrative privileges:
   manage-bde -protectors -add c: -TPMAndPIN

     That's it!


Multi-Factor Authentication Comparison Guide.

Integrate Two-Factor
 Authentication with Windows .
Take Away:  This article examines four multi-factor authentication solutions: (a) RSA SecureID tokens, (b) Microsoft Azure Multi-Factor (MFA) service, (c) certificate-based authentication (CBA), and (d) smartcard authentication.  Each MFA solution integrates with existing Windows' network infrastructure.
MFA improves network security by reducing vulnerabilities associated with Windows authentication.  MFA protects against compromise using a token generated one-time password (OTP), or user certificate stored on a smart card, in conjunction with a user account and password.  Malware or hackers cannot use stolen passwords without the additional OTP or certificate.

MFA Introduction: Multi-factor (MFA) or two-form authentication is a system that requires multiple verification methods for user and administrator sign-ins.  MFA requires more than a simple user name and password. The process requires at least two of the following:

Something logical (e.g., password).
Something physical (e.g., smart card).
Something biological (e.g., finger print reader).

Problem:  Compromise of administrator account credentials on domain-joined computers can jeopardize the integrity of the entire domain.  The compromise of remote access accounts can result in the access of sensitive information from external attackers.  Compromise is a consequence from malware, hackers, and additional threats.

Purpose:  The purpose of this MFA research is to:
Safeguard administrator accounts from compromise.
Protect remote access to internal networks.
Secure email on phones and webmail.
Do not compromise usability.

Significance:  MFA provides effective security control in two scenarios: (a) to secure administrator accounts and (b) to secure remote access.   Administrator accounts have a wide range of user rights; and compromise of one of these accounts can provide an intruder access to the entire Windows network.   MFA also provides an additional layer of security for users who require remote connectivity.

MFA enabled networks are less vulnerable to malware and hackers because stolen passwords are only useful with corresponding smart cards (or tokens).  In addition, MFA provides increased security because digital certificates and one-time passwords (OTP) are difficult to forge.

Applicable Use:  In most instances MFA can protect the following systems:

Workstation logins.
Server logins.
Virtual private network (VPN) logins.
Remote desktop services (RDP).
Exchange ActiveSync (smart phone email).
Outlook Web Access (OWA).
Radius (e.g., 802.1x, including wireless and wired networks).

RSA SecureID:  RSA SecureID provides two-factor user authentication through the use of hardware (e.g., USB dongle) or software (e.g., smartphone app) tokens.  Token serial numbers are assigned to Active Directory (AD) users on a Radius server.  The tokens generate a random authentication code (i.e., OTP) at fixed intervals (e.g., 60 seconds).  The temporary OTP is unique for each token.  Employees enter the RSA OTP, along with their username and password, during the login process.

Figure 1.  RSA SecureID workflow.
RSA SecureID also strengthens administrator authentication to sensitive servers such as Domain Controllers (DCs), file servers, or databases.  Network administrators should already use dual accounts.  The domain user account is used to log onto workstations for daily tasks.  The domain admin account is used for administrative purposes.  Security is substantially improved when SecureID OTPs are required for all administrative changes.    

The SecureID access manager operates on either RSA appliances or virtual machines (VMs).  The VM servers are included with licensing fees.  At least two access manager servers should run to ensure high availability.  RSA agents are installed on all devices (e.g., workstations, servers, etc…) that require MFA.

Windows Azure MFA:  Windows Azure MFA uses a locally hosted MFA server (VM) in conjunction with an ADFS proxy server for user authentication.  The ADFS Proxy is a service that brokers a connection between external users and the ADFS server.

ADFS is a single sign-on (SSO) technology that can be used to authenticate a user into multiple applications over the course of a SSO.  ADFS allows cross-forest trusts and extends that trust between web applications.  SSO and ADFS ensures user passwords never leave on-premise local servers.  Passwords are never moved to the cloud.

Azure MFA is limited to Web-based and Radius-based authentication.  The service is intended to secure access to remote resources (e.g., RDP, VPN, and Web pages).  The service is not intended to secure administrative roles.

Figure 2.  Microsoft Azure MFA.

CBA Authentication:  Certificate-based (CBA) resources authenticates with user assigned secure socket layer (SSL)/ transport layer security (TLS) certificates.  The user certificate is used in place of entering user credentials.  By itself, CBA is not two-factor authentication. Two-factor authentication is based on something you have plus something you know. CBA is only based on something you have.  However, CBA can be considered MFA when combined with local logins or smart phone pins.

CBA has similar limitations to Azure MFA.  CBA authenticates remote resources (e.g., RDP or Outlook Web App) but it does not secure administrative roles.  Administrators assign user certificates to devices (e.g., laptops).  Private-keys protect assigned certificates and prevent unauthorized copying/exporting.  In the event a device is stolen or lost, the certificate also remains protected with the device login credentials (e.g., Windows), pin number (e.g., phones), and hard drive encryption.  Administrators can easily revoke user certificates when employees report the device as lost or stolen.
CBA can also secures Exchange ActiveSync.  Administrators import user certificates to Apple iOS and Windows 8 phones for Exchange authentication.  Exchange policy enforces ActiveSync authentication per user or per group.  Exchange policy also enforces smart phone encryption and can wipe the phone after X number of unsuccessful logins.

CBA requires an enterprise AD CA.  Organizations that do not use domain CAs may want to reconsider this valuable resource.  Windows technology  increasingly depends on SSL certificates.  There is high likelihood that most organizations will require a domain CA in their near future.

Smart Card Authentication:  Smart cards are similar to RSA SecureID tokens.  Smart cards allow robust MFA and can secure administrator access to internal production servers.  Smart card authentication of secondary actions enables better segregation of user and administrator accounts.  Smart cards also provides domain user accounts MFA to workstations, applications, and other local resources.  Smart card drivers and functionality is included with Windows; external agents are not necessary.

Smart cards require an enterprise AD CA infrastructure that can be used with CBA.  Administration is mostly accomplished with CA policies and group policies.  Smart cards use memory to store private keys and user certificates.  The private key cannot be extracted from a smart card.  Smart cards require a password in addition to certificate authentication.  Physical cards and readers are the only hardware expense.

Conclusion:  Each MFA solution introduces similar benefits.  The primary differences are administrative support, end-user devices, and cost.  MFA advantages are summarized (Table 3).  RSA SecureID has a good reputation and may be the easiest solution to implement.  The disadvantage to RSA is that third party agents are required on every server.  RSA is also the most expensive solution available.  Windows Azure MFA is affordable but it only protects remote access servers; it does not provide MFA for administrative accounts.  Smart card and CBA are the most affordable solutions.  Smart card implementation is moderately complicated because it requires AD CA infrastructure.  However, AD CA services will provide most organizations additional benefits in the near future.  Smart cards offer the best value because of their affordability and integration with Windows infrastructure.

MFA technologies are briefly compared (Table 1).

Table 1
MFA Brief Comparison

RSA SecureID
One time password (OTP) generated from end-user tokens (e.g., USB dongles).
RSA SecureID requires (VM) RSA authentication servers.  RSA server agents install on devices and servers.
Modest Installation.

MS Azure
OTP using soft tokens (e.g., smart phone app).
MS Azure MFA requires local Active Directory Federated Services for external authentication (ADFS).
External access via locally hosted web proxy server in DMZ connects to an on-premise MFA Azure server.
Moderate installation.
Certificate-based.  Certificates are stored on devices (e.g., laptops).
Certificate based user authentication requires a Microsoft PKI infrastructure (AD Certificate Authority [CA]).
Moderate to complex installation.


Certificate-based.  Certificates are stored on external smart cards. 
Smart cards require AD CA infrastructure.  Smartcards and readers are the only hardware requirements.

Moderate to complex installation.

Pricing for MFA solutions are compared (Table 2).

Table 2
MFA Pricing per Technology
Licensing and Equipment
RSA SecureID
RSA VM servers included with licenses. 

One time purchase of Authentication Users licenses$81 per user.  Minimum 10 users: 

3 Year Tokens.  $55 per token. 
Minimum 10 users:

Annual Maintenance (SA).
$28 per user.  10 users: 

*Tokens and maintenance are reoccurring expenses.

Total installation for 10 Users:
$1640 (one time).

Total reoccurring (every 3 years) for 10 users:
$1390 (every 3 years).
MS Azure
On-premise server included with Azure licenses.
ADFS and IIS proxy included with current 2012R2 Data Center licenses.

$2 Per user per month subscription. 
10 users per year:

$240 (annually).

AD CA server included with 2012R2 Data Center licenses.  No additional out-of-pocket fees.

Smart Cards
Smart cards are dependent on AD CA infrastructure.

One time $30 per smart card per user.  10 users:

One time $30 per smart card reader per user.  10 users:

Total one-time price for smart cards and readers; based on 10 users:

Table 3. 
MFA Pros and Cons Summary

Easy to
Token/ Card
Cost per License
MS Azure
Smart Card

How to Sign Your PowerShell Scripts

By Steven Jordan on 4/17/2014.

Takeaway:  Sign PowerShell scripts with a code signing certificate.

Assumptions:  We'll assume a code-signing certificate is already installed the Windows certificate root store.  If you don't already have a code-signing certificate, obtain one:
  1. Enroll with the Windows Certificate Authority (CA) server.
  2. Enroll with a public CA.  Best option if you plan to publicly distribute your scripts.
  3. Generate a self-signed certificate.

Use the code-signing certificate located in the the Windows Certificate Store to sign PowerShell scripts.  First, export the certificate from the Certificate Store.  Export the certificate as follows:

Start → MMC → Add/Remove Snap-In → Certificates → Personal → Right click on the certificate → Export.

Save the certificate as a PFX file in a directory of your choice (e.g., c:\scripts).

Lastly, use the following PowerShell script to sign the code:

PS C:\scripts> $cert = Get-PfxCertificate C:\scripts\codesigncert.pfx  C:\scripts> Set-AuthenticodeSignature -Filepath pruneVSS.ps1 -Cert $cert

Directory: C:\scripts SignerCertificate Status Path ----------------- ------ ---- 2603FCAA10343AE1DD78AB41D984728D657499D3 Valid pruneVSS.ps1

That's it -the PowerShell script is signed.  Time to change the set-execution policy throughout the domain!

How to Create a Self Signing Certificate

by Steven Jordan on 4/16/2014

Take Away:  Use Microsoft Windows and its MakeCert tool to create free SSL certificates.  These custom-made certificates can be added as trusted resources for individual users and computers.  Their primary use is generally for testing purposes, code-signing, and other unique situations. 

Create certificates in three easy steps:
  1. Download MakeCert:  Use the Microsoft tool called MakeCert to generate the certificate.  Microsoft includes MakeCert with their Windows 8 Software and Development Toolkit.

    *Hint, choose the Windows App Certificate Kit to avoid downloading the entire SDK.

    MakeCert is also available for download on my OneDrive.
  2. Create a Certificate and Private Key: 

    a.) Makecert.exe is located in the c:\Windows Kits\8.0\bin\x64 directory by default.  Feel free to copy it to a different location.

    b.) Run makecert.exe with the following extended options: 

    C:\scripts>makecert -n "CN=Self Sign Cert" -a sha256 -eku "" -r -sv root.pvk root.cer -ss root -sr localmachine

    N.B., -n=Subject Name; -a=digest algorithm; -eku=Enhanced Key Usage, OID; -r=self signed; -sv= Subject PVK file; -ss=Certificate Store Name; -sr=Certificate store location.

    d.)  The above command requests a new private key password. 

    e.)  The new private key and certificate file are located in the same directory as the Makecert application.
  3. Pair the Certificate and Private Key:

    a.) Run the following command:

    C:\scripts>makecert -pe -n "CN=PowerShell local certificate root" -ss MY -a sha1 -eku "" -iv root.pvk - ic root.cer

    b.) The above command requests the private key password.

    c.) The certificate pair automatically imports into the Windows Certificate Store.  This is confirmed using the MMC Certificate Snap-In.

    Start → MMC → Add/Remove Snap-In → Certificates → Personal 

That's It!