Implementing Yubikey Smartcard for Domain Logon

A smartcard is a tamper-resistant device or card that stores x.509 symmetric certificates, a users private keys and is accessed with a pin. Smartcards stores both Rivest-Shamir-Adleman (RSA) and Elliptical Curve Encryption (ECC) cipher suits, providing 2FA as the both the device and known secret are required to logon. 


Despite the benefits over password based authentication, some misconceptions with smartcards and implementation gaps can be exploited.


Windows password authentication is subject to brute force, dictionary, guessing, phishing attacks and so on. Smartcard's are resistant to these attacks, the belief is that smartcards don't utilise passwords, this isn't strictly true. When a users account is configured for a smartcard, their password is reset to a random 120 character password. At the AS_REP stage of the Kerberos authentication process, the KDC sends the NTLM password hash in the PAC file to accommodate SSO when Kerberos is not available.


The users password will resist even the most determined and well equipped John the Ripper advocate. With the passwords hash is susceptible to Pass-the-Hash (PtH) and far easier than cracking  passwords.

Implementing Yubikey Smartcard

This step by step guide will focus on self-enrolling users supplied with a Yubikey 5C smartcard. Its assumed a Windows Enterprise Certificate Authority (CA) is available. For smartcards to work the Windows client must be domain joined and not a vm, at least not Hyper-V, the smartcard doesn't pass-through correctly.  

Yubikey provide a guide on enrolling users (here) and its fine for a lab, in production some un-expected behaviours may present themselves.

Lets get started by downloading and installing both Yubikey Drivers and Yubikey Manager GUI on to the Domain joined Windows 10 client from

Logon to the Certificate Authority server with Domain Admins or delegated CA Manage rights.

At the run command type 'certsrv.msc' and navigate 'certificate templates', right click 'Manage'.

Yubikey's instructions, reference the 'Smartcard Logon' template and its fine to deploy as long as the 'User' template has not been previously deployed. With both the 'User' and 'Smarcard Logon' templates deployed  inconsistent logon failures may occur. 


Assuming the 'User' template has been previously deployed, duplicate the 'User' template, add the smartcard functionality, deploy, finally remove the original users template. This will be covered in greater detail in a moment.

Copy the 'User' template and name 'User Auth and Smartcard'.

General Tab:


The validity period is set to 1 year, meaning the smartcard certificate will re-enrol yearly.

Compatibility Tab:


Set the compatibility to the lowest common denominator, if Windows 7 is still in the environment select Windows 7 on the  'Certificate Recipient' dropdown. 

Request Handling Tab:


Remove the check box for 'Renew with the same key', re-enrolment will fail.

Select 'Prompt the user during enrolment'.

Cryptography Tab: 

Select 'Key Storage Provider' and 'ECDH_P384' or lower, ECDH_P512 isn't supported.

Select 'Requests must use one of the following providers' and then 'Microsoft Smart Card Key Storage Provider'

The SHA Request hash has been set to SHA384, this setting is inherited from the CA Hash Algorithm and overridden. This can be found by opening the properties and general tab of the CA itself.

The table below shows equivalent levels of encryption for both Rivest-Shamir-Adleman (RSA) and Elliptical Curve Encryption (ECC). Its clear that ECC requires shorter key lengths and less processing compared to RSA. A modest increase in the ECC key results in an increasing larger key size for RSA.

Devisable by

Extensions tab:

Edit the 'Application Policies' and add 'Smart Card Logon'.

Subject Name tab:

The new template is based on the default 'User' template and requires e-mail address during enrolment. Assuming every account has an email address in production this isn't a problem. If this is a lab with no email server an additional attribute needs setting against the users Active Directory object, this is covered later on.

Select 'User Principal Name'.

Security Tab:

Select 'Enroll' and 'Autoenroll' for the 'Domain Users' group.

'OK' the changes to the 'User Auth and Smartcard' template.

Issue both the 'User Auth and Smartcard' and 'Domain Controller Authentication' templates by right clicking on the 'Certificate Templates' folder, 'New' and 'Certificate Template to Issue'.

Logon to each Domain Controllers (DCs) and run 'gpupdate /force' to auto enrol the DC certificate, check the CA for DC issued certificates. Failure in enrolling the DC certificates will result in the following error smartcard logon  "You cannot use a smartcard to log on because smart card logon is not supported for your user account". 

Check the 'Domain Controller Policy' GPO for auto enrolment if the DC certificates don't enrol, update the GPO, run 'gpupdate /force'. 

The previous 'User' template can be removed at this point, assuming its been deployed in the first place.

That's all the CA tasks complete.

From a DC\Server\Client with the Group Policy Editor feature installed set the following auto-enrolment User policy settings.

Elliptic Curve Cryptography (ECC) certificate will require the 'Allow ECC certificates to be used for logon authentication' GPO enabled at Computer Configuration > Administrative Templates > Windows Components > System > Smart Card.

Setting 'Interactive logon: Require smart card' in Security Options with enforce smart card logon. 


Do not initially set this otherwise the users are unable to logon to enrol their smart card certificate.

As I mentioned earlier, email servers will be available in production and this step wont be necessary.


In the lab environment the mail attribute requires populating to successfully enrol our smartcard certificate.


Open DSA.msc (Active Directory Users and Computers) and change the 'mail' attribute of the user accounts to include 'username@fqdn'.

That's all the backend configuration completed, its time to enrol the first user.

Before starting the next stage, the few times I've enrolled users in an Enterprise, it's been via the handholding method.


Each user is taken through the initial smartcard setup and enrolled. Its time consuming, slow, but the users are taught the end to end process and the importance of changing the default pin. The alternative, enrolment on behalf of the users, recording their new pins within a spreadsheet. It effectively knowing everyone's logon credentials, storing in an excel spreadsheet. Any views please share? 

As the user, logon to the Windows 10 client.

Insert the Yubikey.

Open the 'Yubikey Manager' and select 'Configure PINs'

Select the 'Use default' for the 'Current PIN', type the 'New PIN', 'Confirm new PIN' and then click 'Change PIN'.

Click on the The 'Host Process for Windows Tasks'  to start the certificate enrollment process.

Alternatively, try 'gpupdate /force' at the run command or launch 'certmgr.msc', right click on 'Personal', 'All tasks', 'Request New Certificate', then follow the prompts on the wizard.

Click 'Next' at the 'Certificate Enrollment' screen. 

Click 'Enroll'.

Type the PIN that was set in Yubikey Manager.

Once enrolled, click 'Finish'.

Logon to the CA confirming the enrolment of the 'User Auth and Smartcard' certificate.

To prevent smartcard authentication, it may been lost or compromised, revoke the certificate. 

Securing Smartcard Authentication (Considerations)

Smartcard deployment completed and its time to pack up.........this is the article that just keeps giving. 

The user is able to bypass smartcard authentication with their existing password, set the 'Smart card is required for interactive logon', the users password is updated with a random 120 character password.

The flipside, the password is now static and wont change....ever...unless the attribute is switched off and back on again.


A 120 character password would take 7.182075067492658e+217 years to brute force, not a feasible attack vector. 


The risk is from PtH, the NTLM hash is provided as part of the PAC file during logon for SSO.

Updating NTLM Hash Daily


As part of defence in depth its worth enabling  daily changes to the users NTLM hash by either flipping the smartcard attribute or enabling 'msDS-ExpirePasswordsOnSmartCardOnlyAccounts'. Although the attack vector remains it may disrupt the attackers timeframe to pass the hash laterally whilst searching for a route to higher privileges. 

Don't set up a scheduled task on the Domain Controller with a Domain Admin service account to execute the following PowerShell script to flip the smartcard logon attribute.... absolutely mental and an abuse of DA.

Create a service account that has write delegated permissions to the smartcard logon attribute for the Users OU. The service account is given 'Logon as Batch' on a member server with the AD Tools installed. Created a scheduled task to run daily and the script is encoded to Base64, run directly from the actions tab within the task. Embedding Base64 directly within the Scheduled Task prevents poorly permissioned scripts on some dodgy file share.

$scTrue = Get-ADUser -Filter * -Properties * | where {$_.SmartcardLogonRequired -eq "True"} | Select-Object name,SmartcardLogonRequired

foreach ($user in $scTrue)


$name = $

Set-ADUser -Identity $name -SmartcardLogonRequired:$false

Set-ADUser -Identity $name -SmartcardLogonRequired:$true


Alternatively to flipping the smartcard attribute the same can be achieved with 2016 Domain Functional level. 

Open ADSIEdit and set the 'msDS-ExpirePasswordsOnSmartCardOnlyAccounts' to 'TRUE'.

Set a Fine Grain Password Policy (FGPP) to expire the passwords daily.

The users password is changed after each authentication with a smartcard.

We're done with the false sense of security and hammering AD replication (daily), a little harsh I know.

Credential Guard

Previously, I demonstrated how Windows Defender Credential Guard uses Virtualized Based Security (VBS) to isolate the LSA protecting Domain Authentication protocols Kerberos and NTLM. If your not familiar with VBS and Credential Guard its worth taking a few minutes to read the article (here) for pre-requisites and implementation. 


Nonetheless, other techniques are available to coax out hashes, its not a complete solution.


Final Thoughts

The primary focus of this article is deploying Yubikey Smartcards within a Domain, I hope I've delivered. But in doing so, a whole can of worms was opened trying to prevent a common issue with smartcards, PtH.


The solution to PtH is to deploy a combination of Credential Guard and Smartcards in unison to protect both the password and the password hash.

Thanks for your time.