I recently setup YubiKey PIV auth for AD, so I can use the certificate in my YubiKey to get the Kerberos ticket and logon to workstations. This provides better security because it greatly reduces the use of passwords.
However, I am a beginner in the topics of PKI / ADCS / PKCS11 / Smartcard / Kerberos, so I still do not quite understand how that works, so I am not gonna provide a comprehensive tutorial in this post. Instead, I will just point out some common mistakes during the process, so people having the same trouble can save their time.
I am using ADCS with a two-tier PKI. Single-tier PKI is similar and simpler.
The setup involves these parts:
Setup required GPO (group policy objects)
Setup ADCS templates
Install YubiKey Minidriver
Enroll a user certificate
To my understanding, you need a separate YubiKey ADCS template for user certs. After setting it up, users can just insert their YubiKey and create a ADCS certificate request (using the “Manage User Certificates” MMC), and Windows will generate a certificate in the YubiKey’s Authentication (slot 9a) PIV slot (I am not sure if the private key is generated on the key or on Windows then copied to the key). Then, Windows will ask ADFS to sign the certificate. After that, you can logon with your YubiKey and its PIN. No password required.
To get it work is not that hard. Almost all you need is the YubiKey Docs . Thanks to Yubico, their docs are really good and detailed.
Follow the docs and setup your ADCS infra. I have a couple of notes:
- The enroll part of this docs is confusing. For my understanding, users can
just open “Manage User Certificates” MMC and navigate to “Personal” store
and create a request (not the custom one). Windows will automatically prompt
for YubiKey PIN and enroll it. I do not know how to do that on behalf of other
- I do not recomment following this docs to setup ADFS from scratch, if you do not have an ADFS infra already. I strongly recomment you setup a two-tier PKI. You may follow this TechNet article or my friend’s blog (in Chinese). They are very similar, and choosing a two-tier PKI over a single-tier PKI offers great security and scalability benefits.
- I do not quite know why we need to use
certutil -scroots updateto load the root CA to the key. Anyways I still did it.
If you are super lucky, you will be ready to go:
(YubiKey sign-on works; Kerberos tickets got; user certificate published in AD)
% ykman piv info
PIV version: 5.4.3
PIN tries remaining: 3/3
Management key algorithm: 3
PUK is blocked
Management key is stored on the YubiKey, protected by PIN.
CCC: No data available
Subject DN: CN=Yuuta Liang,OU=Domain Users,DC=AD,DC=YUUTA,DC=MOE
Issuer DN: CN=Yuuta Home Issuing CA,DC=AD,DC=YUUTA,DC=MOE
Not before: 2023-04-16T21:33:55
Not after: 2024-04-15T21:33:55
However, you may not be that lucky. Here are some common mistakes.
(VMware) YubiKey Passthrough #
If you are using a Windows VM in VMware to operate the YubiKey, you may encounter some (?) issues with the VMware built-in virtual smart card reader. To completely passthrough the YubiKey as a USB device, you may need to add the following lines to your VM.vmx file:
usb.generic.allowHID = "TRUE"
usb.generic.allowLastHID = "TRUE"
usb.quirks.device0 = "0x1050:0x0407 allow"
Read more: YubiKey Docs.
Just make sure you shutdown the VM and close the VMware tab, so it is not locking the vmx file.
Also make sure you close all programs on the host using your YubiKey. VMware will prompt you for that.
Smart card logon is not supported for your user account #
Make sure you issued a certificate with the
Domain Controller Authentication
template to your domain controller. It is differ from the
template. I think the main difference is that the former has
extended key usage.
If your domain controller has full GUI installation, just go to
Manage computer certificates MMC,
Personal store, and create a request. It will
automatically do everything.
If your domain controller is core, then it is more complex. Fortunately, you do
not have to deal with CSR / certreq stuff yourself. There is a very nice cmdlet
that does all for you:
Get-Certificate. Just execute the following command on
Get-Certificate -Template "DomainControllerAuthentication -CertStoreLocation cert:\LocalMachine\My
and you will be ready to go (thanks to https://xdot509.blog/2020/12/21/ldaps-domain-controller-certificates/ ).
You can use remote certlm MMC to check the certificate. However, unfortunately, it cannot create ADCS certificate requests (only the custom requests).
The revocation status of the smart card could not be determined #
This is very nasty: Windows cannot access the CRL URLs specified in the cert chain. You must make sure:
For all certificates (from the leaf, which is your user certificate, to the root CA):
- The CRL URL must be accessible. If you host it on HTTP, make sure it exists. This is especially nasty if you have a separate public-accessible HTTP server that holds the CRL. Make sure your CRLs are updated!
- The CRL must not expire. CRLs do expire. Check and update them if needed. You can download the CRL and open it on Windows, and the nice dialog has an entry of its validity date. This is problematic if you have an offline root CA which is not regularly powered on. Make sure you power it on again and publish the latest CRL. Do that regularly.
You can check the CRL using built-in Windows tools:
certutil -verify C:\path\to\cert.crt: Export your user certificate (public key only) and run this command. It will tell you if everything is OK or not. Run that command on ALL levels of your certificate path. You may find the switch
-f -urlfetchhelpful, but I do not quite know how they work.
certutil -URL C:\path\to\cert.crt: This is a very nice GUI that fetches CRL automatically and tells you what is wrong. Again, run that on all levels.
Certificate enrollment or certreq: RPC Server Unavailable #
My issue is that my ADCS Server has a wrong NTP configuration, so it cannot establish Kerberos connections. There are mutiple other reasons for this error, for example, network profile set to Public / Private instead of Domain.