Implementing Yubikey Smartcard for Domain Logon
​
A smartcard is a tamper-resistant device or card that stores x.509 symmetric certificates, and a user's private keys and is accessed with a pin. Smartcards stores both Rivest-Shamir-Adleman (RSA) and Elliptical Curve Encryption (ECC) cipher suites, providing 2FA as both the device and known secret are required to login.
Despite the benefits of password based authentication, some misconceptions about 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, but this isn't strictly true. When a user's 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 user's password will resist even the most determined and well-equipped John the Ripper advocate.
The password may have been reset to a 120 character password, alas the password hash remains susceptible to Pass-the-Hash (PtH) and is far easier than cracking passwords.
When the account is not set to use a smartcard, the original password persists and remains vulnerable to brute forcing with the further issue that the user's passwords may not rotate under the normal account password expiration process.
​
Implementing Yubikey Smartcard
​
This step-by-step guide will focus on self-enrolling users supplied with a Yubikey 5C smartcard. It assumes 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 provides a guide on enrolling users (here) and it's fine for a lab, in production some unexpected behaviours may present themselves.
​
Let's get started by downloading and installing both Yubikey Drivers and Yubikey Manager GUI onto the Domain joined Windows 10 client from https://www.yubico.com/support/download/smart-card-drivers-tools/.
​
Log on 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 it's 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, and 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). It's clear that ECC requires shorter key lengths and less processing compared to RSA. A modest increase in the ECC key results in an increasingly larger key size for RSA.
RSA | ECC | Devisable by |
|---|---|---|
512 | 112 | 4.6 |
1024 | 160 | 6.4 |
2048 | 224 | 9.1 |
3072 | 256 | 12.1 |
7680 | 384 | 20 |
15360 | 512 | 30 |
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 to be set against the user's 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'.
​
Log on to each Domain Controller (DCs) and run 'gpupdate /force' to auto-enrol the DC certificate, and 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, it's 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, and slow, but the users are taught the end-to-end process and the importance of changing the default pin. The alternative, is enrolment on behalf of the users, recording their new pins within a spreadsheet. It effectively knows everyone's logon credentials, stored 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 be lost or compromised, revoke the certificate.
​
​
Securing Smartcard Authentication (Considerations)
​
Smartcard deployment is completed and its time to pack up.........this is the article that just keeps giving.
​
The user can bypass smartcard authentication with their existing password, set the 'Smart card is required for interactive logon', and the user's password is updated with a random 120-character password.
​
On the flip side, the password is now static and won't 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 login for SSO.
​
Updating NTLM Hash Daily
As part of defence in depth, it's worth enabling daily changes to the user NTLM hash by either flipping the smartcard attribute or enabling 'msDS-ExpirePasswordsOnSmartCardOnlyAccounts'. Although the attack vector remains it may disrupt the attacker's 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 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 = $user.name
Set-ADUser -Identity $name -SmartcardLogonRequired:$false
Set-ADUser -Identity $name -SmartcardLogonRequired:$true
}
​
Alternatively, 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 you're not familiar with VBS and Credential Guard it's worth taking a few minutes to read the article (here) for pre-requisites and implementation.
​
Nonetheless, other techniques are available to coax out hashes, it's not a complete solution.
​
Final Thoughts
​
The primary focus of this article is deploying Yubikey Smartcards within a Domain, which 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.
​
​
.